Új hozzászólás Aktív témák
-
A calculate linux telepítője frissebb. Egy desktop cinnamont tettem fel. Ennek a telepítése kicsit jobban sikerült. Csak a partíció kezelése miatt majdnem feladtam. Végül felment uefiben, grubbal. Pont így szerettem volna. Ez kulcsra készebb. Rolling. Azt hiszem, hogy ezt megtartom.
-
#3557
Véreshurka
senior tag
F34R
#3556
Véreshurka
senior tag
Distrotube csak a végső megoldás volt, hogy vizuálisan is lássam, hogy jól csináltam-e
. Alapvetően a handbook-ot követtem. GRUB-ot telepítettem, a sys-boot/grub:2-t.A forum-ot olvasgattam, de mindeenhol azt írják, hogy pl. a /boot mappában nézzem a grub.conf-ot. Te is azt írod, hogy az /etc/fstab-ban írjam át a csatolást. De hogyan tudom ezeket elérni? Mert amikor kiírja boot-kor, hogy nem ismeri fel a root fs-t, akkor 3 lehetőségem van:
1. entert nyomok és megpróbálja újra, de ugyanaz lesz az eredmény
2. beírom, hogy shell és átvisz a rescueshell-be,
3. "q"-t nyomok és uyganaz leszu az eredmény, mint ha entert nyomtam volna.Tudom, hogy talán nem nekem való a gentoo, mert nem vagyok még elég járatos a linux világában, de arra gondoltam, hogy talán pont egy gentoo telepítésével és használatának próbálgatásával egy virtuális környezetben ezen tudnék változtatni.
-
Sikerült Windows alól is elérni ssh-val (régi puttyot használtam, ez volt a gond).
Hangkártyát nem kell váltanom, mert ugyanaz a kártya. A master kézi módosításával lejátszás közben is változik a hangerő, ez a része működik. A rendszer grafikus felületén viszont akármit választok ki (analóg/digitális), az alsamixer alatt az SPDIF kimenet "00" szintű és nem tudom változtatni.
-
Frawly
veterán
Még a USE flagekkel sem lenne bajom, mert hasznosak, ha nem akarsz belefordítani a csomagokba valami bloat feature-t. Hanem ez az emerge nagyon minimalista, nem jelzi ki jól a függőségi fát, hogy egy adott csomagot a USE flag-ek vagy egy másik csomag függősége miatt húz-e be. Valahogy nem nagyon lehet szabályozni, hogy milyen csomagnak milyen USE flag-je legyen.
Azt viszont jó, hogy írod, hogy az Artix-ban libsystemd van, ezt nem tudtam. Elég kár. Mondom, nekem megfelelne a Gentoo, hajlandó vagyok beletenni a munkát, csak legyen átláthatóbb.
-
Frawly
veterán
Nem is az a baj, hogy dolgozni kell vele, meg fordítgatni kell forráskódból. Hanem nem látni, hogy milyen csomagnak milyen USE flag-je nem stimmel. Ilyen Calculate Linuxnak számomra nincs értelme, mert ennyi erővel feltehetnék egy Artix-ot, ami Arch alapú, friss, valódi rolling, nem kell vele szenvedni és systemd sincs benne.
Kicsit erőlködtem még Gentoo-val. Leszedtem pár csomagot, majd újra felraktam. Most már 2 órán keresztül fordítgatta a Haskell-t is, pedig a kutya nem kérte rá, félreazonosította az opengl csomagot, egy haskellesre. De lett előrelépés, most már a startx után csontrafagy. Ebből újratelepítés lesz, ha akkor is szórakozik is fütyiségekkel, akkor dobom. Kár érte, mert majdnem ott voltam, hogy működik minden, jó volt az OpenGL, lett ALSA hang, erre ment az egész a süllyesztőbe. Egy centin múlt, hogy végül nem laktam be.
-
Frawly
veterán
Majdnem így, csak a --new-use-t használva. Most éjszaka adtam ki, elfordítgatott pár órát, 119 csomagot. De most se jó. Mit tudnék ezzel csinálni?
Nem az, hogy a picom nem jó, de a startx és a Firefox is túl lassan tölt be, tehát valami alapvető probléma van. Ami nem lenne baj, de fogalmam sincs, hogy hol keressem a megoldást, és a teljes újratelepítésen kívül mit tehetnék.
-
Frawly
veterán
Ez egyre kínkeservesebb
Nagy nehezen csiholtam ALSA hangot, majdnem vért hugyoztam vele. Utána kicsit még kísérleteztem a Sway-jel, mert a másik fórumon linkeltek hozzá egy ilyen SUID bites trükköt, persze nem működött. De annyit mégis elértem vele, hogy addig telepítettem hozzá extra megoldásokat (pl. weston), amíg nem fordított újra az emerge pár dolgot wayland USE flaggel. Na, ez volt óriási hiba, mert most már megint nem megy a picom 
Persze próbáltam visszacsinálni, leszedtem az összes weston-os és sway-akármis csomagot, a zz-autounmask-ból kivettem a mesa-t az utána beírt wayland USE flag-gel együtt, próbáltam megint mindent opengl USE flag-gel fordítani, opengl mesa picom csomagokat, de hiába, nem tudja használni az OpenGL-t.
Az i915 kerneldriver rendben van, a glxinfo szerint megy a DRI hardveres gyorsítás is, a glxgears is pörög, de OpenGL nem akar menni. Hogy tudnám visszacsinálni ezt a wayland-es kárt, hogy újra menjen az egész? Érzem, hogy valamit még újra kéne fordítani az opengl USE flag-gel, de nem tudom micsodát, meg melyik paranccsal kéne az összes érintett csomagot újrafordítani.
-
Frawly
veterán
Na, úgy néz ki, hogy neked lett igazad. Az opengl kellett USE flagnek. Utána a picom újrafordításánál lehúzott pluszba egy opengl csomagot, és utána újrafordult a picom. Mindkét kód kicsi, nem volt 1 perc összesen. Utána egyből jó lett, van transzparencia meg vsync meg minden.
-
Frawly
veterán
Igen, a userem benne van mindenféle csoportban, amiről a Gentoo Wiki ír, egyedül a games csoportban nincs, mert arra azt írta a rendszer, hogy nincs ilyen csoport, holott a Wiki szerint kéne, hogy legyen. Minden más csoportba beletettem.
Az lesz a második problémánál, a make.conf USE-ba beleteszem az opengl-t, de attól félek nem fog segíteni.
-
Frawly
veterán
Jó, de most mondom, hogy nem a környezeti változók a gond. Először én is azt hittem, de azóta pótoltam őket kézzel. Hanem a kezelt hardvereszközöket nem éri el a Sway elogind nélkül, tehát képernyő, billentyűzet, egér, egyéb eszközök. Terminálkimenetben nyühögi az ilyenforráskód.c error meg amolyanforráskód.c line 542 faxtudjami errorjait, hogy nem éri el az eszközöket. Gondolom jogosultság miatt, ha rootként futtattom, úgy meg sehogy nem hajlandó futni.
Egyébként ezért jó a Gentoo, már tanultam egy csomó hasznos dolgot, meg pár programról, amiről korábban azt hittem, hogy minimalisták, kiderült, hogy bloatok. Ez a Sway is, meg pl. a Termite terminál is. Utóbbi is csak hiába 2 mega, de van egy rakat Gtk-s, Gnome-os, harfbuzzos, ikontémás, lófügyis függősége, ami rohadt bloattá teszi sajnos. Már a fordítási időből látszik, hogy valami bloat, de ezt addig nem látod, amíg el nem kezded forráskódból forgatni, vagy nem Gentoo-t használsz. Aki most kezdi ezeket először, mint én is, annak egy ilyen durva első felismerés, szemfelnyitó pillanat.
Most a picom kompozitorral szopok, panaszkodik, hogy nincs belefordítva a glx támogatás, ami OpenGL-es. Nem tudom melyik USE flag-gel lehetne ezt pótolni. Semmi nem írja, megnéztem a forráskódját és a meson scriptjét, és onnan sem derül ki.
-
-
Ertem, koszi!
Heti egy ejszaka forditas nem gond, sot ketto is belefer, csak olyat nem szeretnek, hogy rendszeresen arra menjek be reggel, hogy 60%-nal tart.
De gondolom, nem kell minden heten a teljes rendszert ujraforditani.
Mindenesetre kiprobalom otthon a gyengebb gepen, es ha azt mar kezelhetoen tudom tartani, akkor jo lesz munkaba is.
-
-
janos666
nagyúr
Redundáns tömbben és hosszú garanciaidővel viszont ez majdnem mindegy, csak a várható / addig tapasztalt elhullási rátának megfelelően kell megválasztanod a redundancia szintjét és a hotspare-ek esetleges számát. Mivel általában szinkron módon írható/olvasható egy jobb féle SSD (nem csak a cache, hanem maga a NAND is), így nem is lohasztja le a tömböt egy-egy re-balance/build/silvering (ki hogy nevezi).
Régen arról álmodtam, hogy mára legfeljebb kétszer annyiba kerül majd az olcsó NAND (akkor nem tudhattam, hogy a 3D TLC NAND lesz a nyerő) és akkor fogcsikorgatva meg lehet ejteni a majdnem teljes átállást, de ez lassabb folyamatnak bizonyult.
---
Lenne viszont egy tényleg Gentoo-s kérdésem is.
Van valami hatékony módszer a rendszer "tisztítására" azon kívül, hogy felhúzok egy szűz rendszert egy átmeneti új filerendszerben (vagyis inkább subvolume/dataset-ben, stb), kézileg válogatva átviszem a hasznos beállításokat/file-okat a régiből, aztán cserélek, majd törlöm a régi root mappastruktúrát (/subvoleme-ot)?
Olyasmikre gondolok, hogy bizonyos csomagok beránthatnak sok másikat (pl. mikor nem néz szét az ember a useflag-ek közt előre és egy apró diagnosztikai kütyü még MySQL-t, Apache-ot és levelezőszervert is telepít, de van hogy szimplán csak változnak a függőségek), és a portage ezeket el tudja távolítani, ha már nincs rájuk szükség, ugyanakkor hátrahagyhatnak különböző konfigurációs/átmeneti file-okat, amiket érthető módon nem pucol le a csomaggal együtt. (Mármint valami más megoldás, mint kézileg átnézni minden kis almappát, vagy figyelmen kívül hagyni ezeket, mert valószínűleg úgyis csak néhány Mb az egész, vagy annyi se).
-
janos666
nagyúr
Nem, most egy AMD 5600K (most cserélem majd Intel G4400-ra), és még ezen is számottevő a CPU igény, az E350 szerintem kevés lenne, hogy kiszolgálja a 3 lemezes RAID-Z módot 7200RPM HDD-kkel, főleg Samba-n keresztül, ami szintén éhes tud lenni.
A ZOL oldalán is kiemelten közlik, hogy nincs teljesítményre optimalizálva, ami szerintem leginkább ebben merül ki, hogy tekeri a CPU-t, mert egyébként gyors (szóval csak relatívan lassú, hogy egységnyi munkához viszonylag sok CPU idő kell neki, de ha megkapja a CPU-t, akkor hasít, viszont gondolom minimum egyenes arányban nőne a CPU igény a HDD-k számával egy profilon belül, így simán lehet skálázódási gond, ha valaki egy gyenge kis CPU-ra [kevés mag, alacsony ipc/c] szeretne alapozni egy sok lemezes, vagy több szimultán terhelt pool-t).Az SSD nyilván egy más világ. Ha nem lenne probléma a költséghatékonyság, akkor nekem is kizárólag viszonylag lassú SSD-im lennének HDD-k helyett (a HDD szintű szekvenciális sebesség, de alacsony elérési idő megérne nekem mondjuk 1/2 felárat, de ma ez még sokkal több attól) és sohasem kéne foglalkozni a töredezéssel.
Van, aki SSD-n is szokta defrag-olni a Btrfs-t (ez szerintem egyéni megítélés kérdése, van aki szerint őrült hülyeség, szerintem van benne némi ráció is, mert nem csak LBA terület értelemben, hanem maga a filerendszer is töredezik, miközben nem kopik olyan gyorsan az a NAND, hogy egyedül ez nyírja ki, ha néha átfuttatják - én ezt szerintem kihagynám, mint puszta hobbi, hacsak nem bizonyosodna be, hogy mégis érzékelhető, de elhinném, ha igen).Nem, rendszerszinten ~amd64 minden csomag (nem stable, de nem is GIT/9999) és gentoo-source (nem vanilla, mert szerintem itt minden gentoo patch hasznos, az experimental is, és legalább ennyi "késés" azért kell). Egyedül a ZFS jött GIT-ről, mint 9999-es csomagverzió, mert a ZFS számozott kiadásai lassabban jönnek gentoo-ra, mint a gentoo-source, így néha nem lenne kompatibilis a frissen lerántott kernellel (maszkolni kéne a kerneleket, de elvileg minden ZFS GIT commit tesztelve van, így elfogadható kompromisszumnak tűnik ez is).
-
janos666
nagyúr
Szerintem semmi köze a disztróhoz, a mainline kernelben, illetve zfs git repóban van a lényeg, amibe a gentoo-source patchset csak minimálisan nyúl bele (sőt, alapvetően csak extra opciókat ad a menuconfig-ba, nem kényszereket teremt, vagy módosít) és ez is csak javasolt, de nem kötelező (használható a vanilla-source is). A ZFS kód azt hiszem közel 1:1 GIT-ről jött gentoo patch-ek nélkül (kivéve az extra useflag-eket), ahogy a Btrfs userland-hez sincs tudtommal érdemi patch a gentoo ebuild-ban.
Ez szerintem kifejezetten jó is a gentoo-nál, hogy egyszerűen át tudom tekinteni, mi az, ami esetleg disztró-specifikus és mi nem, de általában jó tipp, hogy alapjáraton semmi sem az (mármint, ami "kintről jön", nem kimondottan a gentoo-hoz készül), és ha mégis, akkor sem megkerülhetetlen / kibogozhatatlan.
Más disztróknál is utána lehet járni ennek, de általában az a kerülőút, hogy fogasd újra magadnak a disztróspecifikus patch-ek nélkül, ilyenkor pedig kényelmes, ha eleve forráskód alapú a disztró és a csomagkezelő.Amit a disztró tehet az esetleg az, hogy automatikusan átállítja az IO és/vagy CPU ütemezők paramétereit, esetleg beidőzít cron-al egy defrag-ot, netán btrfs balance-ot, stb.
Vagy, ha messzebbre gondolkozunk, a Solaris megfordult a fejemben, de tudtommal oda, a zárt verzióhoz sem készült el soha ZFS-hez a Block Pointer Rewrite (és aki dolgozott rajta azt mondja örül is neki, hogy nem fejezte be és reméli más sem fogja helyette, mert "az lenne az utolsó feature", túlkomplikálná a jövőbeni változtatásokat), ami lehetővé tenné az online defrag-ot és a profilok közti online váltást (amiket a Btrfs már tud). Szóval ilyen szempontból ez most irreleváns. Linux-on relatívan zabálta a CPU-t a ZFS, de nem bántam, mert nem hiányzott másra (és talán jobban feküdt volna egy kicsi, de friss Intel CPU-nak, mint az öreg AMD csodának, amitől amúgy is épp szabadulni tervezek).
A töredezettség pedig talán más mértékben alakul ki és/vagy érződik a megléte, de igazából nem a filerendszer, hanem a HDD "hibája". FAT32-t is használhatnék, azon is töredezetté válhatnak előbb-utóbb a file-ok, ha folyamatosan cserélődik egy részük, ez pedig mindig meglátszik az elvileg szekvenciális műveleteken, ha igazából mégsem azok, mert csattognak a HDD fejek a töredékekért. Ezért lehet hasznos a defrag (ez van EXT4-hez és Btrfs-hez is, ZFS-hez viszont nincs).
Láttam a bcachefs-t. Az első benyomásom szerint semmi értelme, és többet ért volna valami olyasmit összerakni, mint a ZFS féle L2ARC. Csak nem is kell ARC, lehet sima "utolsó olvasat" cache, csak legyen olyan módja, ahol csak metadata megy rá, és ideális esetben kérésre automatikusan próbálja meg teletömni a metadata block-ok tartalmával hidegindítás után (reboot után melegen indulni biztos bonyolult, de ez nem tűnik annak).
A legnagyobb balszerencsém a Btrfs-el csak az volt, hogy nekem pont a RAID-5 profil tűnik ideálisnak, míg a fejlesztők általában olyan szélsőségesen állnak a kérdéshez, hogy kétféle adat van, az egyiket minimum RAID1 (vagy 1+0) profillal tárolod és van róla off-site, off-line backup, 2+ példányban (a tenger alatti titkos bunkerben ólomszéfben, és a nagyi pincéjében is a dunsztosüveg mögött, a patkányfogó alatt alufóliában), vagy "szarsz rá" és olyan, mint ha egy sem lenne, szóval tök mindegy, akár a /dev/null-ra is küldhetné a filerendszer, szóval nem igazán támogatott a RAID-5/6. Már viszonylag rég volt viszonylag stabilnak tűnő állapotban (volt, aki állítólag legalább 1 éve használta), mikor használni próbáltam, de aztán kiderült, hogy tele van végzetes hibákkal, amikbe én bele is futottam (azóta is léteznek, nem prioritás a javításuk, de legalább már dokumentálták).
Az extra hajlam és érzékenység a töredezettségre inkább csak olyan dolog, amit "tájékoztató és építő jelleggel" próbálok hangoztatni, nem olyan, ami miatt ne lehetne használni, hisz legalább működik a defrag és metadata balance (elvileg hibátlanul), amiket lehet automatizálni és az IO ütemezéssel csökkenthető az esetleges negatív mellékhatása is (bár gyakorlati szempontból ez lehetne alapszolgáltatás [mint pl. a zfs-nél a scrub-nak dedikált IO ütemező queue], de ez már részletkérdés, morogni lehet rajta, nem vizet választani vele).
Amúgy igen. nem biztos, hogy ha szétszedem őket, akkor a szóló HDD-re is Btrfs megy, az talán EXT4 lesz (akár journal nélkül). Bár ezt már fejtegettem fentebb, hogy lényegében majdnem mindegy ilyen szempontból (csak a hibás RAID profilokra nincs gyógyír, minden másra igen és egyik filerendszer sem tökéletes más szempontból sem).
Tudtommal nincs most ingyen semmi, ami olyan jellegű garanciákat kínál a konzisztenciára, mint a Btrfs és ZFS. Minden más vagy hagyományos RAID checksum-ok nélkül, vagy gyakorlatilag egy hagyományos, vagy checksum-olással kiegészített, esetleg paritásra épülő "okos backup" (pl. paritás nélkül ír fel először mindent, aztán kiegészíti a háttérben paritással vagy redundanciával és akár checksum-al is, de ez nem egy tranzakción belül történik, hanem későbbre tolva...). Ezektől ilyen szempontból szerintem minden visszalépés, vagy esetleg ugyan ez, csak más formában, de akkor olyanban, ami számomra nem tetszik, bonyolultabb, és/vagy elérhetetlen is (mint néhány speciális szerverekbe szánt megoldás, amit legfeljebb említésből ismerek, a működése "titkos" is vagy legalább is irreleváns, mert én úgysem fogom használni, főleg nem itthon).
-
janos666
nagyúr
Szerintem már nem fog kiderülni, hogy sikerülne-e, mert mégis visszavágyom inkább Btrfs-re.
(Most az a terv, hogy szétszedem a HDD-ket RAID5-ből külön RAID1-be és single-be, aztán átvariálom a mappáimat és azok helyhasználatát is ennek megfelelően, később pedig vagy újra visszatérek RAID5-re, ha kijavítják a hibáit, vagy RAID10 lesz belőle, ha találok még egy ugyan ilyen HDD-t olcsón -> ez az egyik előnye, hogy Btrfs-nél lehet oda-vissza mozogni, míg a ZFS statikus profilú).Mivel nagy munkának tűnt az initramfs, így inkább arra szántam időt, hogy nagyjából felmérjem a töredezettséget pár hónap használat után. A tapasztalatom pedig az, hogy bár kevéssé tördelődött szét, mint a Btrfs, és ami fontosabb, ez még kevéssé látszik meg a teljesítményén (főleg a metadata műveletek sebességén, ami egy idő után nevetségesen lassúvá vált Btrfs-el, de itt ilyen nem érzékelhető), de azért mégis csak töredezik (ami nem meglepő, csak a mértéke/hatása a kérdés), csak Btrfs-el erre legalább "drága" gyógyír volt (rendszeres recursive online defrag és metadata balance felváltva -- azért drága, mert sokáig tart és közben lassít, plusz nyúzza a lemezeket), itt gyakorlatilag nem igazán van (lehet próbálkozni a filerendszeren belül, vagy átmenetileg másik filerendszerbe és vissza mozgatással, de ilyenkor semmi garancia nincs a töredezettségre nézve, és idővel egyre csak nő, mintsem csökkenne a szabad terület töredezettsége akkor is, ha mindig ~25% szabad területet hagyok és egy ilyen mozgatás próba előtt felszabadítok némi extra helyet -> konkrétan csak ártottam vele, mikor kipróbáltam).
Mivel ZFS-nél a metadata művelek nem lassultak látványosan, így egy L2ARC matadata cache sem jelent semmi számottevő gyakorlati hasznot (próbaképp adtam neki egy 80Gb-os SSD-t és noszogattam, hogy töltse fel minél jobban, de csak metaadatokkal), a szekvenciális műveleteken viszont látni a töredezettség hatását (ezen pedig nem segít számottevően sem az L1, sem L2 ARC, mert itt nem a metaadat töredezettség lassítja az adatműveleteket is, hanem maga az adattöredezettség látszik meg és "minden" nem fér be a cache-be, amit szekvenciálisan kéne elérni --- kivéve persze az írást, azt szépen cache-eli a RAM-ban,de olyat minden filerendszer tud, ha mást nem a kernel csinálja helyette
).Szóval ja...
A konklúzióm az, hogy alapjaiban jobb a ZFS, de nem tökéletes. Hiányzik belőle pár dolog, ami a Btrfs-nél elérhető. Az pedig önmagában véve probléma, hogy a Btrfs-nél a defrag nem csak elérhető, hanem kvázi kötelező, míg a ZFS szépen eldöcög nélküle, de a "drágán" karbantartott Btrfs összességében jobban fog teljesíteni a nap végén, mint a "magára hagyott" ZFS.Közben találtam egy érdekes bejegyzést arról, miként lehet lecserélni a FAT filerendszer modult bármi másra az UEFI firmware-ben: [link], amivel elvben lehet boot-olni szoftveres bootloader és FAT partíciók nélkül is (ha nem szignó-védett az alaplapi firmware).
-
janos666
nagyúr
Rászántam magam erre: [link]
genkernel --zfs --callback="module-rebuild rebuild" --no-compress-initramfs initramfs
Bár a callback-et ki kellett hagynom (csak anélkül ment végig). Lehet, hogy ez volt a baj, de azt hittem, hogy csak azért nem tudott mit kezdeni magával, mert nincs modulom, amit újraépítsen (minden beépített).* Sourcing arch-specific config.sh from /usr/share/genkernel/arch/x86_64/config.sh ..
* Sourcing arch-specific modules_load from /usr/share/genkernel/arch/x86_64/modules_load ..
*
* ERROR: --callback failed!Annyiból működött, hogy az initramfs töltődött be, és futtathatók voltak a shell-ben a zpool és zfs parancsok, viszont nem csak automatikusan nem tudta importálni a pool-t, de kézileg is hiába mutogattam neki a /dev/disk/by-id/ mappát is (ahol ott voltak a HDD-k), nem találta a pool-t.
Csak libgcc pthread hibákat dobált, mikor próbálkoztam.
Egyszer próbáltam magamnak összerakni egy egyedi Live-USB rendszert, ahol a genkernel felelt volna a teljes kernel konfigért, alapbeállításokkal (auto-modulosan), így initramfs-el együtt, de ott is nagyjából ugyan ez volt a probléma, hogy bár elérhető volt a btrfs parancs az initramfs shell-ben, de egyszerűen meg sem lehetett találni, nem még mount-olni a btrfs root-ot az initramfs-ből (hiába adtam oda a genkernel-nek a btrfs kapcsolót kézileg és próbáltam a genkernel-next verziót is több kernel verzióval, sohasem jöttem rá mit rontok el, bár hamar feladtam).
Nem véletlenül ódzkodom tőle (initramfs), hanem nem értek hozzá. Noha inkább azért, mert nem is akarok, de épp azért nem akarok, mert eddig megvoltam nélküle...
-
janos666
nagyúr
Bőséges válasz a hosszú kérdésre, de szerintem sok olyat is beleírtál, amit előre tisztáztam, hogy már tudom és akár most is is így van a gépemen (vagy annyit írtam róla, hogy lenne mit, de nem akarok túl sokat írni egy hsz-be).
- fixen integrálva van a kernelbe a ZFS modul (amúgy is így szeretem, illetve előregondolkodtam)
- A HDD-ken már most is RAID-Z1 dolgozik, így nyilván olvasgattam róla általánosságban. Ahogy írtam is, többféle WiKi-ből és FAQ-ból ollóztam össze, amit a ZFS-ről tudok, de azt hiszem tudok is már róla mindent, amit RAID-Z1 és adattárolás tekintetében szerettem volna.
- A beépített kernel command line GPT PARTUUID alapján mount-olja a root-ot, ami így elvileg független a filrendszertől (és sok mástól is)Egyedül arról van kételyem, hogy ha most mindent így hagyok, és csak a filrendszert cserélem le, akkor azonnal működik tovább, vagy mást is módosítanom kell, illetve hogy működhet-e egyáltalán initramfs nélküli EFI stub kernellel a ZFS root-os boot-olás. Mert ahogy te is írod, csak GRUB2 + initramfs leírásokat találtam. Tehát nem tudom, hogy maga a kernel képes-e mount-olni a root-ot PARTID alapján, ha az ZFS, vagy ilyenkor kötelező az initramfs, ami végignézi a zpool-okat és kiválasztja közülük a root-ot.
. Alapvetően a handbook-ot követtem. GRUB-ot telepítettem, a sys-boot/grub:2-t.
Nagy nehezen csiholtam ALSA hangot, majdnem vért hugyoztam vele. Utána kicsit még kísérleteztem a Sway-jel, mert a másik fórumon linkeltek hozzá egy ilyen SUID bites trükköt, persze nem működött. De annyit mégis elértem vele, hogy addig telepítettem hozzá extra megoldásokat (pl. weston), amíg nem fordított újra az emerge pár dolgot wayland USE flaggel. Na, ez volt óriási hiba, mert most már megint nem megy a picom 
) - mar nekem is van ilyenem. Vagyis meg benne van a faban, de mar nem sokaig. 
Rajtam kívül gentoozik még valaki?
Új hozzászólás Aktív témák
- Gaming notebook topik
- Spórolós topik
- Windows 10
- Formula-1
- Milyen monitort vegyek?
- Andras-G: Az internet veszélyei [2. rész] - Facebook Marketpalce
- AMD Navi Radeon™ RX 9xxx sorozat
- Hülye ötletek eladók, vagy gumikacsára cserélendők, akár ráfizetéssel is
- Milyen egeret válasszak?
- Audi, Cupra, Seat, Skoda, Volkswagen topik
- További aktív témák...
- Apple iPhone 13 Pro Max 128GB,Átlagos,Dobozaval,12 hónap garanciával
- Lenovo Thinpad üzleti kategóriás notebookok - i5 - i7 - Ryzen - nagy választékban számlával
- BESZÁMÍTÁS! ASRock A520M R5 5500 8GB DDR4 250GB SSD GTX 1050 Ti 4GB Sharkoon RGB Slider 400W
- Apple iPhone 13 128GB, Kártyafüggetlen, 1 Év Garanciával
- Dell Optiplex 3020 MT,i3-4130,8GB RAM,128GB SSD,WIN10
Állásajánlatok
Cég: Laptopműhely Bt.
Város: Budapest