gentoo/systemd: Robustní operační systém?

15.3.2015 23:39 | Přečteno: 2638× | linux/unix | | poslední úprava: 16.3.2015 19:59

Už nějakou dobu z pracovních důvodů používám Gentoo se systemd, navzdory tomu, že mi několik lidí z IRC kanálu řeklo, že ho k práci nepotřebuju, aniž by se předtím zeptali, co dělám. Během té doby došlo už i k nějaké té reinstalaci systému, rekompilaci a rekonfiguraci kernelu a podobným legráckám.

Upozornění pro věčné šťouraly (Franto!): Zápisky v blogu jsou jen útržky toho, co mě zrovna napadlo napsat, nemá smysl mě upozorňovat, že něco chybí. Nechybí. Pokud k tématu máte, co říct, učiňte tak v diskuzi nebo odkažte na vlastní blog a nespoléhejte na mě.

Až na úplné výjimky mám celý základní systém ze stable ebuildů. Je to proto, že se chci spolehnout na Gentoo QA a neupdatovat pokaždé, když si vývojář usmyslí, že je potřeba udělat změnu.

Nová konfigurace jádra

Konfigurace a kompilace kernelu na Gentoo je narozdíl od sestavování userspace dosud v podstatě na úrovni LFS. Osobně jsem už delší dobu používal genkernel, jen jsem kvůli systemd přešel na genkernel-next. Když vymažu veškerou konfiguraci a spustím genkernel, použije výchozí konfiguraci distribuovanou s tímto balíkem, která pro mě není dostatečná a je potřeba ručně přidávat nějaké volby.

Člověk dělá chyby, a mně se stává, že zapomenu některou volbu zapnout, zvláště pak ty nesamozřejmější a tudíž nejdůležitější. V tomto ohledu má smysl uvážit i modelovou situaci, kdy zapomenu úplně všechno a využiju čistý výstup programu genkernel, tedy kernel a initrd bez jakýchkoli uživatelských vstupů.

Už teď můžu prozradit, že v mém případě se systém stane nebootovatelným. Snad největším problémem je šifrovaný /home, mimochodem u mého pracovního stroje povinnost.

Předpoklad: Systém se zeptá na heslo k šifrovanému oddílu a počká na jeho zadání

Většinou se buď vůbec nezeptá nebo je dotaz překrytý průběžně přepisovanou informací o tom, za jak dlouho dojde k timeoutu. Člověk má na zadání hesla nějakých 90 sekund a poté dojde k selhání a objeví se prompt, že mám stisknout Ctrl+D nebo zadat rootovské heslo. Zvláštní, nepohodlné, nepochopitelné, ale funguje to, tedy při správné konfiguraci jádra.

Při výše zmíněné výchozí konfiguraci jádra dle genkernel se dokonce zadaří odemknout šifrovaný oddíl a vytvořit tak virtuální oddíl se skutečným souborovým systémem. Co ovšem nezvládne, je návazná akce, která spočívá v samotném připojení /home. Jen pro pořádek, akce se konají na základě /etc/crypttab a /etc/fstab.

Předpoklad: Systém velice rychle selže a dozvím se, proč

Chyba. Ve skutečnosti dojde k dalšímu devadesátisekundovému čekání, tentokrát zcela zbytečnému, protože z této situace se už systemd nemá jak vyhrabat. Nevidím jediný důvod, proč čekat na akci, která už proběhla a tudíž je již rozhodnuto, zda skončila úspěchem nebo neúspěchem. Ale co mi nejvíc vadí je, že jsem zatím nepřišel na žádný způsob, jak čekání přerušit z klávesnice.

Během ladění systému tedy člověk opakovaně bootuje a opakovaně čeká vynucených 90 sekund jen proto, aby se dostal k výše zmíněnému promptu.

Předpoklad: Zkratka Ctrl+D k něčemu bude

Nabídka stisknout tuto klávesovou zkratkou je vysvětlena tak, že po jejím stisku se bude pokračovat. Nemám nejmenší ponětí, co se tím myslí. Není v čem pokračovat, boot už tou dobou selhal a na emergency shell je potřeba rootovské heslo. Nechápu smysl.

Předpoklad: Po zadání rootovského hesla se objeví buď shell nebo chyba

Dokážu pochopit, že po zadání rootovského hesla nenaběhne shell, zvláště pak v případě nedostatečně konfigurovaného jádra, o kterém se zde bavíme. Očekával bych tedy nějakou zásadní chybovou hlášku, podle které se můžu dále orientovat. Ve skutečnosti se shell jakoby objeví, ale nejde používat, navíc se objeví další stejný prompt a člověk se nemá šanci dozvědět, co je teda špatně, pokud na to sám nepřijde.

Nezbývá tedy než bootovat z externího média, v mém případě PXE (o tom možná taky nějaký zápisek bude) a zajistit bootovatelnost. K tomu stačí nastavit příznak noauto u odpovídajícího řádku v /etc/fstab a nejspíš (přesně si nepamatuju) sestavit initrd.

Předpoklad: Úspěšně připojím /home nebo se dozvím nějakou chybu

Připomenu, že virtuální dešifrovaný oddíl se podařilo vytvořit, ať už si o tom systemd myslí cokoli, ale selhává připojení /home a v logu je zdůvodněno čekáním na ten virtuální oddíl.

Chyba. Připojení /dev/mapper/home na /home projde bez jakékoli chyby, ale nic připojeného není. Zkoušel jsem to opakovaně, i po rebootu. Zkoušel jsem připojit /dev/mapper/home na /mnt/temp a to funguje. Dlouho jsem přemýšlel, jaktože neúspěšný pokus nekončí chybou a jaktože záleží na tom, kam připojuju.

Nakonec byla klíčem právě direktiva noauto a zvláštní chování systemd. Ono zřejmě dokáže zachytit informaci, že jsem připojil filesystém z daného oddílu, ověřit si, že jsem ho připojil, kam podle /etc/fstab patří, vyvodit z toho, že se stalo něco nekalého, a okamžitě to napravit odpojením oddílu. Člověk se akorát musí podívat do logu.

Nebudu popisovat další kolečko s live systémem a zakomentováním celé řádky.

Jen tak naokraj...

Řešení je samozřejmě triviální, a to pomocí genkernel --menuconfig all tentokrát správně nakonfigurovat a sestavit jádro a sestavit initrd. Napsal jsem si nástroj, který se o tohle všechno dokáže postarat, ale o tom opravdu až příště.

V tomto konkrétním případě existuje jednoduchý lék na všechny související problémy a tím je nezapomenout nastavit CONFIG_GENTOO_LINUX_INIT_SYSTEMD. Tento příběh nicméně není o vyřešení konkrétního problému, ale o dílčích problémech, se kterými se člověk potýká při nesprávné konfiguraci jádra.

Vzpomínky na začátky

Co si tak pamatuju, tak Okiáš už před časem tvrdil, že systemd na Gentoo běhá bezvadně, s rozběháním nejsou žádné potíže a všecko je krásné a sluníčkové. Jako nadšenému propagátorovi jsem mu samozřejmě nevěřil ani slovo a k přechodu jsem se odhodlával hodně dlouho a to ještě navíckrát, vzhledem k tomu, že první pokusy ukázaly, že moje nedůvěra byla oprávněná. Ale myslím, že teď už je to mnohem lepší.

Pamatuju si, že jsem měl děsivý problém s LVM, který se projevoval prakticky stejně, tedy vynuceným devadesátisekundovým zbytečným čekáním při použití LVM na cokoli jiného než root filesystém, s následným selháním a emergency promptem.

Od té doby se ovšem spousta věcí změnila, LVM ve stable zdá se funguje jak má, problémový genkernel je v systemd profilu maskován ve prospěch genkernel-next a pokud člověk udělá všecko správně, tak jde systém podle všeho vcelku normálně používat. Nicméně i tak se prozatím mimo svůj laptop držím OpenRC.

       

Komentáře

[Mrkva]

Uz par let jedu na gentoo a priznam se ze jsem genkernel nikdy nepouzil. Jednou si clovek odladi konfiguraci a pak uz to chodi +- bez problemu. Initramfs mam taky vlastni a to same :) A systemd? To necham bez dalsiho komentare :)

[pavlix]

Máš tam taky bootflash image, bez jediného problikávání černé konzole?

[Jendа]

Proč bych něco takového proboha chtěl?

[Vantomas]

Protože to prostě jde! Teda pokud má člověk KMS kompatibilní grafiku, jinak má smůlu.

[Jendа]

Ano, a jinak uvidí černou obrazovku. Super.

[Michal Kubeček]

Ale bude černá pořád, bez problikávání. :-)

[pc2005]

Tak třeba proprietární drivery k GeForce 2 prakticky nešly provozovat jinak než v textmódu a občas umřely při přepínání Xka ←→ konzole :-/.

[Grunt]

No ještě v dobách před nouveau jsem používal parametr vga=, který to přepne v nějakém brzkém assembly kódu ještě před samotnou inicializací jádra a mám takový pocit, že přepnutí rozlišení (ale určitě ne 1920x1080 nebo většího) šlo nastavit ještě i v GRUBu, takže když jsem měl ještě Gentoo tak jsem jel v jednom rozlišení (akorát přepnutí do Xek mi to kazilo) už od GRUBu.

[Josef Kufner]

Můj Grub zcela sám od sebe jede v 1920x1080 (Thinkpad Yoga 12, integrovaná Intel grafika). Na tom 12" displeji má směšně malá písmenka. Jádro si to pak přepne hned po zavedení do textových 80x25 a chvilku po odemčení disku to skočí zas zpět do FullHD. Je to nějaké zmatené.

[Grunt]

Můj Grub zcela sám od sebe jede v 1920x1080

Hele, je to možný. Co dělá nový GRUB2 a do čeho dovede přepnout, to netuším. Jinak ale přepnutí do rozlišení 1920x1080 bude mít určitě na starosti nějaký VGA příkaz. A ten stejný příkaz se provádí při spuštění jádra před jeho samotnou inicializací (to co se předává parametrem vga=). Když by se to poštelovalo třeba by to šlo zařídit tak aby rozlišení přepnul GRUB a pak to až do Xek neblikalo (nevím co udělá KMS jestli při stejném rozlišení jaké má VGA blikne nebo ne).

[Josef Kufner]

Zrovna jsem si s tím trochu pohrál, abych se zbavil přepínání do textového režimu chvilku po zavedení jádra. Došel jsem k tomu, že Grub si to přepne a pokud se uvede volba linux_gfx_mode=keep, tak to nechá přepnuté a snad i nějak řekne jádru, ať si s tím neláme hlavu.

V konfiguraci generátoru initramfs jsem přidal, aby obsahoval modul i915, takže KMS se inicializuje hned na začátku a při tom mi to jednou a naposledy problikne. Pak zadám heslo k disku a vesele se bootuje.

[Michal Kubeček]

Spíš "video=" než "vga=".

[Grunt]

Souhlas. Vga parametr se používá pro vesafb a má kód (snad ještě nějaké volání BIOSu) ještě před startem jádra.

[pavlix]

Já osobně dávám přednost textovému bootu a textovému promptu na heslo (aspoň pokud funguje lépe než v tom systemd), ale na druhou stranu nevidím důvod, proč si dělat problémy a pořizovat si pro linuxový stroj KMS nekompatibilní grafárnu.

[Vantomas]

Jo, to já třeba radši dávám přednost grafickému režimu v nějakém smysluplném rozlišení a to i na serverech. Ono to má takovou výhodu kterou bych nazval více jak cca 25 řádky historie co se vejde na obrazovku, což je docela fajn v případě nějakého problému, kdy je potřeba debugovat z historie vypsané na obrazovku. A nebo tak všeobecně ta práce v tom terminálu je pak taková příjemnější, protože se tam toho vejde víc.

[pavlix]

Nedaří se mi tvůj komentář vůbec zasadit do kontextu.

[Michal Kubeček]

Framebuffer se pro textové terminály používal už před nástupem KMS. A ani ty úplně tradiční VGA textové režimy nebyly omezeny na 25 řádků.

[Jendа]

Ještě štěstí že mám na svém terminálu kouzelnou klávesu PageUp.

(ale jo, vga=foo s nějakým všude podporovaným rozlišením jsem používal… ale s nástupem KMS to začalo blbnout)

[R]

Problem je v tom, ze ked kernel spadne, tak PageUp ti nepomoze (to fungovalo naposledy tusim v kerneloch 2.4)

[Michal Kubeček]

kdump

[pavlix]

Tak až ta klávesa bude fungovat na prohlížení chyb kernelu, tak mě vzbuď :).

[pavlix]

Uz par let jedu na gentoo a priznam se ze jsem genkernel nikdy nepouzil.

V případě kenrelu genkernel prakticky nic neautomatizuje, takže mezi jeho použití a nepoužití nevidím zásadní rozdíl, mimo to, že v tom balíku je jiný výchozí config.

Initramfs mam taky vlastni a to same :)

V jakém smyslu vlastní?

A systemd? To necham bez dalsiho komentare :)

Očekával jsem, že tohle klíčové slovo bude naopak komentáře přitahovat. :)

[Mrkva]

V jakém smyslu vlastní?

Vezmu busybox, pribalim cryptsetup a knihovny, obalim vlastnim /init a mam hotovo rychleji nez kdybych musel priohybat skripty z initramfs-tools a podobne.

[pavlix]

Tak to jsem za genkernel all docela vděčný.

[Jendа]

Já zase potkal případ, kdy selže fsck, systemd zjistí, že je FS nekonzistentní, pro jistotu ho připojí read-write (asi aby se nekonzistence pořádně projevila) a pak udělá tu nabídku na shell (778378). Ještě k tomu hláška o selhání fsck mezitím stihla odscrollovat o tři obrazovky nahoru, takže člověk přijde k počítači, na obrazovce svítí deset nápisů OK, a pod tím je prompt, že boot selhal.

Z celého toho mám pocit že systemd je prostě neodladěný. A strašně blbě se to debuguje.

[Josef Kufner]

Chování popsané v tomto blogu spíš nasvědčuje, že systemd je typická ukázka programu, který se snaží být příliš chytrý. Ono není až tak snadné si říct něco ve smyslu "Tak a tohle už je mimo záběr mého programu, že to nefunguje je naprosto v pořádku a vyřešíme to později, úplně jinde, a i když by to šlo řešit tady, tak to sem nepatří.". A když si tohle programátor nedokáže ujasnit a neudrží se neřešit problémy na nesprávných místech, vznikne paskvil jako je systemd.

[pavlix]

Myslel jsem si, že systemd je správné místo pro všechno. :)

[michich]

Já zase potkal případ, kdy selže fsck, systemd zjistí, že je FS nekonzistentní, pro jistotu ho připojí read-write

Podařilo se mi to zreprodukovat. Připadá mi, že je to nezamýšlený důsledek změny, od které se přechod do emergency.target po selhání fsck provádí příliš jemným způsobem ("replace" místo "isolate"). Kvůli tomu se neprovede zrušení startovacího jobu pro systemd-remount-fs.service. Jako workaround zkus přidat do systemd-remount-fs.service: Requires=systemd-fsck-root.service

Ještě k tomu hláška o selhání fsck mezitím stihla odscrollovat o tři obrazovky nahoru, takže člověk přijde k počítači, na obrazovce svítí deset nápisů OK, a pod tím je prompt, že boot selhal.

Nepíše to na konci ještě radu, že si máš pomocí journalctl zobrazit log? V něm určitě bude selhávající fsck vidět červenou barvou.

[pavlix]

Já mám teda po bootu log typicky na tolik přeplácaný, že musím ty zvýrazněné části hledat a pak se dívat na datum, zda jsou aktuální. Na druhou stranu alespoň journalctl zobrazuje datum tak, abych mu rozuměl.

[michich]

Já bych začal tím, že si zobrazím hlášky úrovně error nebo závažnější: journalctl -b -p3

[pavlix]

V tom případě bych začal tím, aby mi to ten systém poradil namísto journalctl -xe nebo co to tam bylo. Teď si to sice tady přečtu, ale až to budu potřebovat, tak nebudu chtít shánět druhý počítač s přístupem na net a vzpomínat, kde o tom kdo napsal komentář.

[Marián Kyral]

Věcmi jako je systemd, initramfs a genkernel si život nekomplikuji.

Můj postup aktualizace kernelu:

eselect kernel set xxx
cd /usr/src/linux
zcat /proc/config.gz >.config
make oldconfig
mount /boot
make && make install modules_install && emerge -1 @module-rebuild && grub2-mkconfig -o /boot/grub/grub.cfg

[mirec]

Je ten zcat potrebný? Mne to oldconfig rovno natiahlo starú konfiguráci ale neskúmal som odkiaľ.

[pavlix]

Pokud vím, tak žádnou starou konfiguraci nenatahuje.

[Michal Kubeček]

Ne, ale zdá se, že (stejně jako např. "make menuconfig") nabízí defaulty podle /proc/config.gz, pokud ho najde.

[pavlix]

Jak mám přesně tuto větu interpretovat? Za jakých okolností se tedy data z /proc/config.gz uplatní? Pro mě je teda nová informace už to, že by buildsystém kernelu měl takový zdroj používat, a popravdě se mi to vůbec nelíbí. Nemám rád, když se systém snaží domýšlet si, co bych po něm mohl chtít, a za mými zády to dělat.

[Marián Kyral]

A co kdyby to nedělal za tvými zády? Co kdyby napsal:

"Hele Pavlixi, sice jsem nenašel žádný config, ale vidím, že nějaký máš v /proc/config.gz. Mám ho použít?"

[pavlix]

V případě oldconfig/menuconfig by mi to nevadilo, protože jsou samy o sobě interaktivní. V případě jinak neinteraktivních příkazů by mi to vadilo.

[Michal Kubeček]

Omlouvám se, není to přesně /proc/config.gz, ale opravdu platí, že neexistuje-li .config, defaulty se berou (jde-li to) podle aktuálního jádra. Konkrétně ze souborů definovaných v init/Kconfig:

config DEFCONFIG_LIST
        string
        depends on !UML
        option defconfig_list
        default "/lib/modules/$UNAME_RELEASE/.config"
        default "/etc/kernel-config"
        default "/boot/config-$UNAME_RELEASE"
        default "$ARCH_DEFCONFIG"
        default "arch/$ARCH/defconfig"

Teprve poslední dvě položky odkazují na soubory, které jsou součástí zdrojáků, a tedy univerzální.

[pavlix]

Omlouvám se, není to přesně /proc/config.gz, ale opravdu platí, že neexistuje-li .config, defaulty se berou (jde-li to) podle aktuálního jádra.

Aha, to je o dost rozumnější už kvůli tomu, že můžu pokus o konfiguraci opakovat s nově rozbaleným jádrem. Podmínkou je tedy absence .config při libovolné akci pracující s tímto souborem?

[Michal Kubeček]

Pokud existuje .config, tak s pracuje s ním a rozhodně se svévolně nemění, co je v něm (kromě případných porušených závislostí). I pak je ale potřeba odněkud vzít defaulty pro ty volby, které v něm chybějí (jsou-li nějaké).

[pavlix]

I pak je ale potřeba odněkud vzít defaulty pro ty volby, které v něm chybějí (jsou-li nějaké).

1) You don't say.

2) Nikdo ale neříká, že to musí být černou magií někde ze systému, to je jenom cesta do pekel.

[Michal Kubeček]

Mně to jako cesta do pekel nepřipadá. Pokud už někdo dělá tu konfiguraci ručně, přijde mi použití hodnoty podle aktuálně běžícího jádra rozumnější než nějaký nahodilý default z defconfigu dané architektury (které nepatří zrovna k nejlépe udržovaným částem stromu). A očividně nejen mně, protože to tak funguje nejméně od roku 2006.

[pavlix]

Pokud už někdo dělá tu konfiguraci ručně

Z vlastní zkušenosti můžu říct, že kompilace kernelu nutně neimplikuje ruční konfiguraci. Stejnětak můžu říct, že dávám přednost explicitnímu chování před implicitním i v případě, že ručně měním některé hodnoty. Osobně mezi ruční změnou několika málo hodnot v jádře a strojovou změnou nevnímám zásadní rozdíl. Kdyby nic jiného tak shoda mezi ruční a strojovou úpravou pomáhá chápání a ladění obou zmíněných.

A očividně nejen mně, protože to tak funguje nejméně od roku 2006.

To pro mě není argument.

[pavlix]

To mi připadá spíše jako opakování části předchozího komentáře než odpověď na otázku v jeho kontextu položenou. Pokusím se formulovat na vědečtější úrovni.

Podmínkou použití zmíněných externích zdrojů konfigurace je tedy souběh libovolné akce Makefile s absencí souboru .config?

[Michal Kubeček]

Vypadá to tak - když totiž jako .config nechám jen část aktuální konfigurace, výsledek je jiný. A pokud je před spuštěním "make menuconfig" soubor .config prázdný, výsledek je stejný jako po "make defconfig".

[pavlix]

Díky. Teď už mi jenom trochu vrtá hlavou, jestli se dá říct, že menuconfig začíná stejnými akcemi jako dělá ten defconfig obecně.

[Bedňa]

Takto to funguje na všetkých distribúciách čo poznám. Pokiaľ mu k jadru neprihodíš .config, tak si hľadá aktuálny v osvedčenej ceste. Toto sa už ale líši distro od distra. Bez .configu sa jadro nedá skompilovať.

[Marián Kyral]

To se ti jen zdá. Teď jsem smazal .config soubor a make menuconfig mi vygeneroval něco úplně jiného. Nicméně je docela pěkný nápad.

[Michal Kubeček]

Nejspíš nemáte kopii konfigurace aktuálního jádra v žádném z umístění uvedených výše. Já jsem teď zkusil dvakrát za sebou spustit nad kopií aktuálního master dvakrát spustit "make menuconfig", jednou s neexistujícím .config a podruhé s kopií /proc/config.gz (distribuční jádro založené na 3.12.38). Výsledek je do posledního písmenka stejný.

[Marián Kyral]

Tak to by sedělo. V /lib/modules ani /etc žádný config nemám a /boot jsem právě neměl připojený. No a z /proc/config.gz se to nebere. By mně zajímalo proč. Úmysl nebo opomenutí?

[Bedňa]

Asi úmysel a distro ala Debian, pretože ten hladá .config v /boot.

[Marián Kyral]

Gentoo je převlečený Debian? Já myslel, že původ má ve Slackware

[Michal Kubeček]

Všechno má původ ve Slackware… tedy až na Yggdrasil. :-)

[Bedňa]

Ten konfig je by distro tak čakám na rozuzlenie čo zázračné nám tu ponúkneš, keď sa to mení v čase a priestore. Podľa čoho som si tipol že predrečník ma Debian? A od Kedy Gentoo pozerá do /Boot vole? Ja som tých vaniliek kompiloval nespočetne a netuším čo mi chceš povedať.

Roky som fičal na vanilke a toto mi príde ako nepochopenie problému.

[Marián Kyral]

Netřeba mi nadávat do vykastrovaných býků. Jen mi přijde podivné, že na /proc/config.gz se nekouká. To je vše.

[Bedňa]

soz

[Ivorne]

Mám na to podobný script. Teď jak jsem viděl ten příkaz 'make oldconfig', tak jsem si vzpomněl, jak jsem se o tom příkazu poprvé dozvěděl - hledal jsem na googlu něco o tom, jak převést staré configy na nový kernel a našel jsem akorát článek, kde Linus vysvětloval, že oldconfig je prasárna a že správný kernel vývojář by to nikdy neměl používat . Tak jsem si oddych, že nejsem kernel vývojář a spostil oldconfig.

[pavlix]

Tak já nejsem kernel vývojář, ale make oldconfig se mi taky nelíbí, maximálně tak ještě make olddefconfig, o kterém jsem se taky dozvěděl teprve nedávno, dosud pro mě jeho spuštění zajišťoval genkernel.

[Marián Kyral]

A co se ti na něm nelíbí? Pokud je nějaká nová volba, tak se mně zeptá co s tím a já se dle popisu rozhodnu. Rozhodně lepší než trávit čas neustálým zaklikáváním toho samého. A další čas zjišťováním, na co jsem to zapomněl a proč to sakra zase nefunguje.

[pavlix]

A co se ti na něm nelíbí?

Zbytečná interaktivita a zbytečně ztracený čas. Gentoo mi ve všech ostatních ohledech v ideálním případě nabízí automatizaci. Zasahuju jenom v případě, že je něco špatně, že něco konfiguruju nebo že na něco změním názor. Jestliže se mi přístup Gentoo líbí, je vcelku logické, že se mi nebude líbit přístup menuconfig nebo oldconfig.

Rozhodně lepší než trávit čas neustálým zaklikáváním toho samého. A další čas zjišťováním, na co jsem to zapomněl a proč to sakra zase nefunguje.

S tím sice souhlasím, ale naopak mě to utvrzuje v mém názoru, že interaktivity je lépe se zbavit, abych nezaklikával pokud možno vůbec nic, a abych se o většinu nastavení vůbec nemusel starat mimo prvotní zkoumání, které bych ovšem provedl jen v těch případech, kdy už to neudělal někdo za mě.

[Marián Kyral]

Já jsem třeba za interaktivitu rád. Jednak se dozvím, co je nového a taky můžu konfiguraci ovlivnit. Ne vždy se mi hodí to, co mi tam vývojáři, v dobré víře, tlačí. Sice je to minimum případů, ale jsou.

[pavlix]

Já se při (re)konfiguraci jádra nic dozvědět nechci. Buď už to vím, nebo si to teprve budu zjišťovat z jiných kanálů. Ale to není žádná novinka, že různým lidem nemusí výhovovat stejné věci.

[Hans1024]

Když vymažu veškerou konfiguraci a spustím genkernel, použije výchozí konfiguraci distribuovanou s tímto balíkem, která pro mě není dostatečná a je potřeba ručně přidávat nějaké volby.

A mas nejaky duvod mazat veskerou konfiguraci?

[pavlix]

Jestli ti stačí jeden jako příklad, tak kvůli vymodelování situace při nové instalaci na jiném hardware a za jiným účelem.

[bogo]

Temer vsechno z toho sem zazil i ja sam, kdyz Arch linux prechazel na systemd. Jen to bylo jeste o fous barvitejsi, protoze v te dobe kdyz prochazeli, jeste systemd vubec neumel zobrazit tu hlasku s timeoutem na heslo. Proste ti system pri bootu najednou zastal a cumel jako puk, a ty na nej taky

[rADOn]

AFAIK tech 90 sekund je (pseudonahodne urceny) maximalni cas jak dlouho se muzou roztacet nejaky pochybny scsi zarizeni.

BTW nechapu jak muze gentooista seriozne pouzivat genkernel… kdyz bych se nechtel s vecma srat tak tam narvu binarni distro, ne? A kdyz uz si dam praci s kentusem tak kernel je zaklad, kdyby nic jineho tak proto ze clovek nemusi resit nic co se tyka initrd. Beztak je dnes pulka hardwaru postavena na ICHcku pro ktery naboucham .config pomalu poslepu.

[pavlix]

BTW nechapu jak muze gentooista seriozne pouzivat genkernel…

Už jsem to psal jinde, Gentoo je v podstatě portage a sada automatizačních nástrojů. Jak může Gentooista slintat nad tím, když použiju jeden automatizační nástroj a vztekat se, když použiju jiný. Nepoužívám Gentoo proto, abych se předváděl, že jsem největší nejlepší super hardcore hacker, ale protože mi v mnohém pomáhá.

[pavlix]

Koneckonců, kdybych se chtěl předvádět, používám Archlinux. :D

[rADOn]

Ja se nevztekam, jen se divim. Ze vseho drbani s kentusem je kernel… no, nebudu rikat nejjednodussi Ale jak si jednou naboucham funkcni .config tak uz se da s minimalnima zmenama jen kopirovat. Rekneme nejefektivneji investovany cas. A to ne kvuli tomu abych se tim kernelm mohl kasat, ale protoze to zjednodusuje problemy pri bootovani – nemusim resit initramdisk a zadny problemy ktery se ho tykaji.

[pavlix]

Ale jak si jednou naboucham funkcni .config tak uz se da s minimalnima zmenama jen kopirovat.

To nemůžu potvrdit a už vůbec ne u kernelu bez initrd, který pro můj setup navíc ani nefunguje. Už před lety jsem si oblíbil LVM a nestojí mi za to měnit zvyky jen proto, abych se zbavil initrd, který mi v ničem nevadí.

Rekneme nejefektivneji investovany cas.

To může být subjektivní nebo záviset na mnoha okolnostech.

[pc2005]

Ale jak si jednou naboucham funkcni .config tak uz se da s minimalnima zmenama jen kopirovat.

To nemůžu potvrdit a už vůbec ne u kernelu bez initrd, který pro můj setup navíc ani nefunguje. Už před lety jsem si oblíbil LVM a nestojí mi za to měnit zvyky jen proto, abych se zbavil initrd, který mi v ničem nevadí.

Mě to taky funguje (možná ještě z doby před 3.0), například teďka jsem ho nakopíroval z 3.15 do 3.19 a přidal novou grafiku (resp. prošel jsem si všechny volby a pár jich změnil, ale to je jen "kouknu a vidím" ). Sice jako ještě nevím zda to pojede, ještě jsem nebootoval, ale vsadil bych si, že to pojede OK.

[rADOn]

Ja takhle jeden cas provozoval prakticky kazdej stable kernel v rade… Zacalo to kdyz se do jadra dostaval GEM a v novych jadrech byly spousty oprav a pak jsem se toho nejak drzel. Kdyz nic, tak proto ze me kentus naucil ze zmeny je lepsi davkovat po malych castech A je to takova nenarocna prace ktera se hodi na nudny pracovni sezeni.

Dnes je to jeste vylepseny tim ze se da takovej .config pouzivat i na jinych strojich – notebooky postaveny na ICH cipovce jsou na jedno brdo

[Luboš Doležel (Doli)]

Mno nevím, hodně lidí Gentoo používá právě proto, aby se vyhnuli systemd

I když je to čím dál tím těžší, protože různé projekty ze sebe odstraňují funkce, jelikož je do sebe schramstlo systemd (nedavno jsem takhle narazil u upower), takže Gentoo musí držet starší větev:

* sys-power/upower-pm-utils
     Available versions:  0.9.23-r2 {+introspection ios KERNEL="FreeBSD linux"}
     Homepage:            http://upower.freedesktop.org/
     Description:         The upstream upower 0.9 git branch for use with sys-power/pm-utils

[pavlix]

Mno nevím, hodně lidí Gentoo používá právě proto, aby se vyhnuli systemd

Gentooisti a hlavně vývojáři pořád dokola opakují, že Gentoo je především o možnosti volby. Stejně jako je výhoda možnost volit Gentoo bez systemd, je výhoda i možnost volit Gentoo s ním. A to nepočítám výhodu, že si můžu zvolit i z jakého důvodu budu Gentoo používat, i kdyby třeba nebyl stejný jako důvod těch tvých hodně lidí.

I když je to čím dál tím těžší, protože různé projekty ze sebe odstraňují funkce, jelikož je do sebe schramstlo systemd (nedavno jsem takhle narazil u upower), takže Gentoo musí držet starší větev:

To je fakt, který lze prezentovat jak negativně (že Gentoo musí držet starší větev), tak i pozitivně (že Gentoo pro své uživatele tu starší větěv drží a tím pro ně drží i tu možnost volby).

[Ivorne]

Nedávno se mi podělal notebook a zítra si jdu pro nový, tak si zase užiju instalaci Gentoo. Doteď jsem používal 'pochybnou' kombinaci systemd+gnome 3, teď k tomu přidám ještě btrfs.

Jinak kernel builduju obyčejně bez genkernel, jednou jsem ho zkusil a vylekala mě ta kopa věcí, co to vygenerovalo (a to, že to pak nešlo nabootovat, ale to bych asi pořešil).

Initramfs jsem chvíli používal kvůli plymouthu (boot splash), ale pak jsem došel k názoru, že textový boot (když je pěkně obarvený) vypadá stylověji (a taky je praktičtější, když při bootu selže fglrx, což se mi dělo v jednom kuse).

Teď akorát doufám, že se mi podaří zprovoznit hibernaci, odhaduji, že btrfs a systemd mi to úplně neulehčí.

[pavlix]

Nedávno se mi podělal notebook a zítra si jdu pro nový, tak si zase užiju instalaci Gentoo.

Znám človíčka, co dává do kupy pravý gentooácký instalátor (není ovšem oficiální gentoo dev), žádné klikaču, jen úspora času při některých typech nových instalací, říká tomu stage7, jsem docela zvědavý na výsledky.

Jinak kernel builduju obyčejně bez genkernel, jednou jsem ho zkusil a vylekala mě ta kopa věcí, co to vygenerovalo (a to, že to pak nešlo nabootovat, ale to bych asi pořešil).

Nevím o kopě věcí, jen o tom, co se s kernelem vygeneruje tak jako tak a initrd, maximálně to snad věci do initrd trochu cachuje, aby se ušetřil čas.

Initramfs jsem chvíli používal kvůli plymouthu (boot splash), ale pak jsem došel k názoru, že textový boot (když je pěkně obarvený) vypadá stylověji

Souhlasím.

(a taky je praktičtější, když při bootu selže fglrx, což se mi dělo v jednom kuse).

Souhlasím až na to, že si takový hardware nepořizuju.

Teď akorát doufám, že se mi podaří zprovoznit hibernaci, odhaduji, že btrfs a systemd mi to úplně neulehčí.

Hibernace mi funguje od začátku (už pár měsíců) bez problémů, ale nemám btrfs.

[the.max]

jestli tou kopou věcí nebyly myšelny moduly. Fakt je, že defautl volbách se cpe do modulů všechno a pak je jich hodně, i sestavení jádra díky kompilaci prakticky všeho zabere víc času, než ručne nakonfugurované jádro jen s volbami, co potřebuji. Já mám prakticky vše v jádře, jako moduly mám pouze věci okolo zvukovky a USB, protože čas od času mi vyhnije vše kolem USB a pomůže buď restart, nebo odebrání a znovu natažení modulů. Ještě ve výpise vidím moduly pro virtualbox a modul pro nvidii.

Nikdy jsem totiž pořádně nepochopil, proč mít všechno jako moduly, i když je mám stejně po celou dobu běhu sytému zavedené v paměti. Jako moduly mám jen ty problémové (USB a zvukovka) a binární od třetích stran (nvidia a virtualbox).

[Michal Kubeček]

Nikdy jsem totiž pořádně nepochopil, proč mít všechno jako moduly, i když je mám stejně po celou dobu běhu sytému zavedené v paměti.

Např. proto, že pak můžu mít stejné jádro na víc strojích a na každém natáhnout ty moduly, které tam jsou opravdu potřeba (u distribučního jádra už je to v podstatě nutnost). Představa, že bych si pro každý ze svých strojů udržoval konfiguraci na míru, mne ani trochu neláká. Stejně tak nestojím o to, abych musel znovu spouštět build jádra, instalovat ho a přebootovávat, kdykoli budu chtít zkusit něco, co jsem dosud nepotřeboval (třeba nějaký match netfilteru).

[pavlix]

distribučního jádra

Co přesně ten pojem znamená? Gentoo má taky vlastní distribuční jádro, ale šíří se ve formě zdrojáků.

Představa, že bych si pro každý ze svých strojů udržoval konfiguraci na míru, mne ani trochu neláká.

Pak podle některých nebudeš správný Gentooista a měl bys používat výhradně binární distribuce.

Stejně tak nestojím o to, abych musel znovu spouštět build jádra, instalovat ho a přebootovávat, kdykoli budu chtít zkusit něco, co jsem dosud nepotřeboval (třeba nějaký match netfilteru).

+1

[Michal Kubeček]

Co přesně ten pojem znamená? Gentoo má taky vlastní distribuční jádro, ale šíří se ve formě zdrojáků.

V tomto kontextu záleží na tom, jestli se k němu dodává i nějaká generická konfigurace (kterou většina uživatelů použije, nemají-li specifické potřeby nebo chutě) nebo jestli se počítá s tím, že si každý vytvoří vlastní na zelené louce.

Pak podle některých nebudeš správný Gentooista

Nejsa gentooistou, nemohu být správným gentooistou. :-) (Ale jestli vývoj systemd a jeho prorůstání do OpenSuSE bude pokračovat tak jako dosud, je docela dobře možné, že se jím stanu.)

[pavlix]

Pak se možná staneš heretickým Gentooistou jako já, i když předpokládám, že tvoje hereze bude jiná než moje, takže bychom dle historických zkušeností měli být největšími nepřáteli. :) :D

[the.max]

Jo, to je samozřejmě pravda, ale prostě naco mít zavedenejch miliardu modulů, když je stejně pro běh potřebuju, tak je dám rovnou do jádra. Ono to pak i o něco rychleji bootuje, když se nemusí každej modul zvlášť načítat.

A co se týká konfigurace jednotlivých strojů, tak to není tak hrozné. Mám dva různé notebooky, kde jsou jen zatržené rozdílnosti jako řadič, zvukovka, procesor, USB, grafika. Zbytek je vlastně stejnej. Pak je to pár serverů, kde jsou zase rozdíly jen v použitém hardwaru což je jen pár voleb a 2 různé desktopy, byť moduly jsou na obou stejné. Takže při instalaci mě ta konfigurace jádra už tolik na čase nevytrhne v porovnání s celkovou dobou instalace Gentoo jako takového. A jak říkám, většina voleb je 'generických'. Při aktualizaci jádra používám prakticky vždy předchozí .config, takže tady už problém také není.

Teoreticky bych mohl mít jeden .config pro oba notebooky a desktopy, jen to co se týká rozdílnosti v HW mít jako moduly, ale to už mi přijde jako uhejbání před filosofií Gentoo

[pavlix]

Teoreticky bych mohl mít jeden .config pro oba notebooky a desktopy, jen to co se týká rozdílnosti v HW mít jako moduly, ale to už mi přijde jako uhejbání před filosofií Gentoo

Podle mě se filosofie Gentoo často překrucuje. Jediná filosofie Gentoo, kterou znám z dokumentace a uznávám, je možnost volby a tu nemůže uživatel porušit. Použití nebo nepoužití initrd podle mě nemá s filosofií Gentoo vůbec nic společného, stejně jako nutnost kompilovat vše na procesor.

[the.max]

Genkernel je fajn věc při prvotní instalaci systému, Bez složitostí to vyrobí použitelné jádro a další jeho ladění už proběhne později. Já ho navíc používal i kvůli LVM + LUKS, kdy mám šifrované všechny oddíly. Nikdy se mi nepovedlo vyrobit ramdisk tak, aby systém takto naběhl. Genkernel jsem používal s volbou menuconfig. Pak jsem si ale pořídil HP N40L u kterého není monitor ani klávesnice, ale je tam o5 LVM + LUKS a tak jsem hledal řešení, jak zadat heslo po síti. Narazil jsem na kigen a našel i overlay s ebuildem. Od té doby genkernel nepotřebuji. Jádro si udělám běžným postupem a kigen mi vygeneruje ramdisk s dropbearem, kdy heslo LUKS mohu zadat lokálně z konzole, nebo po síti přez SSH (Dropbear). Výhoda je, že ramdisk jsem vytvořil jen jdnou a od té doby ho používám s různými verzemi jádra.

A systemd také raději nebudu komentovat.

[pavlix]

Genkernel je fajn věc při prvotní instalaci systému, Bez složitostí to vyrobí použitelné jádro a další jeho ladění už proběhne později. Já ho navíc používal i kvůli LVM + LUKS, kdy mám šifrované všechny oddíly. Nikdy se mi nepovedlo vyrobit ramdisk tak, aby systém takto naběhl.

Tak jsi to používal nebo se ti to nikdy nepodařilo?

Genkernel jsem používal s volbou menuconfig. Pak jsem si ale pořídil HP N40L u kterého není monitor ani klávesnice, ale je tam o5 LVM + LUKS a tak jsem hledal řešení, jak zadat heslo po síti. Narazil jsem na kigen a našel i overlay s ebuildem. Od té doby genkernel nepotřebuji. Jádro si udělám běžným postupem a kigen mi vygeneruje ramdisk s dropbearem, kdy heslo LUKS mohu zadat lokálně z konzole, nebo po síti přez SSH (Dropbear).

Mohlo by být fajn to do Genkernel zaintegrovat, přecijen je to jen další věc, kterou můžeš v initramfs chtít. Ale teď se do takových věcí nepouštím, když Gentoo potřebuje dva různé balíky s genkernelem, na to se jim můžu tak leda vysrat, dělat dobrovolnou práci dvakrát paralelně.

Výhoda je, že ramdisk jsem vytvořil jen jdnou a od té doby ho používám s různými verzemi jádra.

Samozřejmě za předpokladu zakompilování všech modulů pro boot.

[the.max]

jo, asi jsem se blbě vyjádřil. Genkernel jsem používal a ramdisk se vygeneroval v pořádku, pak jsem začal potupně očesávat jádro od modulů co nepotřebuju a naopak ty co (trvale) potřebuju, jsem dal rovnou do jádra. Když už jsem pak měl teda v podstatě ručně nakonfigurované jádro, tak ten genkernel jsem fakt ve finále používal jen pro vygenerování ramdisku, protože když jsem ho chtěl vygenerovat ručně, tak se mi to nikdy nepovedlo. Nepátral jsem po tom proč, ale holt sem používal ten genkernel. Až do té doby co jsem narazil na ten kigen, kterej mi ramdisk vygeneroval na první pokus (resp. na druhej, přidal jsem klíče pro DropBear).

A ano, všechny moduly potřebné pro boot mám v jádře, protože pro boot nezbytně nepotřebuju USBčka, zvuk, ani virtualbox.

[Ivorne]

Když už se tu rozjelo téma kernel a bootování initramfs, tak bych přihodil dotaz. Budu si teď imstalovat gentoo s btrfs (protože budu mít SSD disk, tak abych mohl snadno nastavit, co bude na ssd a co na hdd). Přemýšlím, jak to bootovat - resp jestli mít /boot na btrfs nebo na to udělat zvláštní partition.

Nebudu používat initramfs. Četl jsem, že grub umí bootovat z btrfs, ale přijde mi, že boot z jednodužšího fs bude stabilnější (i pro případ, kdybych musel bootovat z grubu 'ručně'). Ale zase nevím, jak to funguje, když mám boot na jednom oddíle, ale ostatní věci (třeba init - v mém případě systemd) na jiném (btrfs) oddíle.

Docela bych byl rád, kdyby mi někdo udělal jasno v tom, jak se má bootovat, když má člověk rozházený root do různých partition. Jestli se to má v grubu nějak mountovat, nebo jestli se prostě musí použít initramfs nebo jestli se to nějak řeší samo. Dík.

[pavlix]

Mně osobně baví věci dělat pořádně. Takže když používám LVM, tak používám i / na LVM a samostatný /boot pokud možno nepoužívám. Předpokládám, že s to s btrfs půjde řešit stejně čistě.

Četl jsem, že grub umí bootovat z btrfs, ale přijde mi, že boot z jednodužšího fs bude stabilnější

Nevidím důvod, proč v takovém případě vůbec mluvit o stabilitě. Buď dokáže GRUB ten jeden pitomý soubor přečíst, nebo ho přečíst nedokáže. Pokud ano, předává kontrolu a dál tě přece nezajímá.

(i pro případ, kdybych musel bootovat z grubu 'ručně').

To je snad jenom o tom naučit se zápis cesty k souboru na btrfs, což bude jistě triviální.

Ale zase nevím, jak to funguje, když mám boot na jednom oddíle, ale ostatní věci (třeba init - v mém případě systemd) na jiném (btrfs) oddíle.

Proč by na tom mělo jakkoli záležet?

[Ivorne]

Ok, díky za rozptýlení mých naivních obav. V tomhle nemám ještě úplně jasno:

Ale zase nevím, jak to funguje, když mám boot na jednom oddíle, ale ostatní věci (třeba init - v mém případě systemd) na jiném (btrfs) oddíle.

Proč by na tom mělo jakkoli záležet?

Tak nějak jsem měl představu, že boot probíhá tak, že se zapne grub z /boot, pak se spustí jádro (taky z /boot) a pak se spustí init, který už není na /boot. Takže jak jádro ví, co má být namountováno jinam než do /boot (když i fstab je mimo /boot)?

V grubu se nastavuje jakási root partition před zavedením jádra. Ale já nevím, jestli se tam nastavuje skutečný root / nebo /boot. A hlavně nevím, jak se tam nastavuje to druhé z těch dvou. Taky je na to nějaký paramert grubu? A musím to nějak hlídat, nebo to grub2 prostě nějak nastaví sám? A jestli to grub nastaví sám, tak podle čeho? Podle fstab nebo třeba podle zrovna připojených oddílů při spuštění grub-makecfg?

[Mrkva]

root grubu - syntaxe root (hd0,0) je partition kde ma grub dalsi data. tedy /boot.

root systemu - tedy linux /vmlinuz-1.2.3 vga=xyz root=/dev/sda je partition ktera se preda jadru/initramfs a kde system hleda /. fstab se v te chvili vubec neresi. Grub jako takovy to neresi, ale ten grub-makecfg to vetsinou vygeneruje spravne.

[pavlix]

Tak nějak jsem měl představu, že boot probíhá tak, že se zapne grub z /boot

Tak především GRUB se nemůže spouštět z /boot, protože firmware tuhle lokaci nezná a neumí s ní pracovat.

pak se spustí jádro (taky z /boot)

Ano, spustí se jádro, který GRUB načetl z /boot a pokud se používá initrd, tak i ten načte GRUB a jádro si ho převezme.

a pak se spustí init, který už není na /boot

Ano, ve chvíli, kdy je zajištěn přístup k /, jádro nebo initrd spustí init.

V grubu se nastavuje jakási root partition před zavedením jádra.

Ne tak úplně. V GRUBu se nastavují parametry jádra, se kterými jádro a initrd můžou dál pracovat.

Ale já nevím, jestli se tam nastavuje skutečný root / nebo /boot.

Jádro /boot k ničemu nepotřebuje a dokonce ho za běhu systému nepotřebuješ vůbec (pokud do něj nechceš něco zapsat).

A musím to nějak hlídat, nebo to grub2 prostě nějak nastaví sám?

GRUB opravdu jen natáhne z disku kernel a případně initrd, předá parametry a nakonec zcela předá kontrolu.

Podle fstab nebo třeba podle zrovna připojených oddílů při spuštění grub-makecfg?

Asi máš namysli grub2-mkconfig, což je jen nástroj na výrobu konfigurace GRUBu z různých zdrojů informací. Spoustu věcí to umí nastavit samo, jinak bys měl potřebovat jen v /etc/default/grub vyladit nějaké proměnné, pokud potřebuješ něco doplnit a pak jen spustit tento příkaz a výstup uložit do konfiguračního souboru grubu. Ten je v /boot, aby ho GRUB mohl přečíst.

Ten systém je asi stokrát jednodušší, než sis myslel.

[rADOn]

Eee, myslim ze tady pletete dohromady grubí direktivu root a kernelový parametr root=. Direktiva "root" v grubu se nepredava kernelu ale nastavuje oddil od ktereho se pak daji psat cesty bez toho abys vsude prefixoval (hdN,M)… Takze kdyz by mel /boot na vlastnim oddilu tak opravdu bude direktiva root ukazovat tam a ne na korenovy oddil. V praxi se to poplest neda podle jednoduchyho pravidla ze cokoliv v grubi notaci je kernelu na prd a linuxovy notaci zase grub nerozumi.

Jinak mit /boot na spolehlivejsim systemu nez btrfs mi rozhodne dava smysl pacz grubi filesystemovy driver muze byt dost primitivni. Vim urcite ze grub1 ve skutecnosti ani neumi ext4, proste predpoklada ze je to podobny ext3. Coz muze byt celkem zasadni rozdil pokud neni system ciste odmountovany a je neco v zurnalu. A to je extka v podstate jednoducha… dost pochybuju ze by grub umel vsechny vyfikundace btrfs.

[pavlix]

Nenapadlo mě, že má namysli grubovskou direktivu, protože ji beru jen jako syntaktický cukr, ale asi to dává smysl. Pokud jde o GRUB legacy, nevidím důvod vykopávat mrtvé. Na druhou stranu nevidím důvod, proč by měla být schopnost přečíst soubor z ext4 nutně závislá na čistém ukončení a to samé btrfs. To už bych spíš věřil tomu, že ten soubor nepřečtu ani napoprvé.

[rADOn]

Pokud jde o GRUB legacy, nevidím důvod vykopávat mrtvé.

No vidis, ja zase nevidim duvod proc vylezat "z hrobu" kvuli necemu co mi prijde jako krok zpet do casu lilo.

Na druhou stranu nevidím důvod, proč by měla být schopnost přečíst soubor z ext4 nutně závislá na čistém ukončení a to samé btrfs.

Ja teda nejsem odbornik na souborove systemy, ale afaik se muze stat ze dejme tomu grub.conf ukazuje na nejakej inode a v zurnalu je napasno ze ve skutecnosti ukazuje na jinej inode. Treba wydlackej ext driver kvuliva tomu odmita neciste odmountovany oddily vubec cist. Grub to afaik preziva jen proto ze nemusi/neumi nic zapisovat takze nehrozi ze to totalne dokurvi, ale to jeste neznamena ze je to uplne skvely.

[pavlix]

No vidis, ja zase nevidim duvod proc vylezat "z hrobu" kvuli necemu co mi prijde jako krok zpet do casu lilo.

Uh?

Ja teda nejsem odbornik na souborove systemy, ale afaik se muze stat ze dejme tomu grub.conf ukazuje na nejakej inode a v zurnalu je napasno ze ve skutecnosti ukazuje na jinej inode.

To si nemyslím, ač taky se taky na tuhle oblast nespecializuju. Teoreticky by k tomu samozřejmě dojít mohlo, ale jenom během zápisu grub.conf a to je zvláštní situace, kterou podle mě není potřeba ošetřovat a pochybuju, že to GRUB ošetřuje u jiných filesystémů.

Grub to afaik preziva jen proto ze nemusi/neumi nic zapisovat takze nehrozi ze to totalne dokurvi, ale to jeste neznamena ze je to uplne skvely.

Já to vidím úplně naopak. GRUB má za úkol přečíst soubor z disku a tuhle úlohu plní dobře. Jestliže v tomhle kontextu vůbec uvažuješ o zápisech do filesystému (nepočítám případný přepis dat existujícího souboru), je podle mě celá úvaha od začátku špatně.

[rADOn]

No vidis, ja zase nevidim duvod proc vylezat "z hrobu" kvuli necemu co mi prijde jako krok zpet do casu lilo.

Uh?

No ze musis poustet extra prikaz na sestaveni konfiguraku. To je jak navrat sendmailu…

…Jestliže v tomhle kontextu vůbec uvažuješ o zápisech do filesystému…

Nic takovyho jsem prece nerekl! Dokonce jsem vyslovne psal ze grub psat nic nemusi. Jen jsem uvadel ilustraci toho ze necist odpojenej system s neprehranym zurnalem je fatalne nakopnutej a pokud grubi ovladac neumi zurnal precist nebo ho dokonce sam dohrat, tak neni uplne koser takovej system mountovat. Coz, abychom se vratili k tematu, neznamena ze ted pobezim na vsech masinach udelat /boot na ext2 – vydrazdit takovej stav asi by dalo docela praci. Ale vubec se nedivim ze by se nekdo bal dat /boot na btrfs, kterej je vyrazne komplikovanejsi a nadto stale jeste ve vyvinu. Prijde mi to jako rozumna opatrnost.

[pavlix]

No ze musis poustet extra prikaz na sestaveni konfiguraku.

Skutečně srovnáváš upstream GRUB legacy a aktuální verze nebo se tu bavíme úplně mimo? Navíc doporučuju se alespoň trošičku podívat na architekturu lilo, GRUB legacy a GRUB.

pokud grubi ovladac neumi zurnal precist

Já si hlavně osobně myslím, že práce s žurnálem do bootloaderu ani nepatří.

nebo ho dokonce sam dohrat

To je jeden z nejdebilnějších nápadů, co jsem v poslední době slyšel.

tak neni uplne koser takovej system mountovat

Mezi mountováním systému pro zápis s přehráním žurnálu a bootloaderem nevidím nejmenší souvislost.