Nekdy si pripadam, ze tech chytrosti se systemd aspol. je nejak moc (minimalne najednou). Netusite nekdo jako dosahnout toho co se driv delalo jednodusse
touch /forcefsck
tedy donutit system k fsck pri rebootu? Hledal jsem, ale nic rozumneho jsem nenasel, init script na fsck uz taky neni, aby se clovek podival jestli se nekde neco takoveho kontroluje…
A to nemluvim o tom, ze kdyz dojde k chyba na korenovem svazku, tak systemd protoze nema soubor ctrl-alt-delete.target neumi provest zadny typ rebootu ci shutdownu… to je fakt nestesti.
systemd čte při bootu parametr z fstab - poslední cislo na řádku, určuje pořadí fsck (nula fsck se neprovede, 1 typicky root provede se jako první, 2 ostatní disky). vypínal jsem takto fsck na home btrfs, nefungoval a neměl by ani být potřeba.
Jinak dle wiki z odkazu má jít také vynutit parametrem jádra.
Diky, tzn. nasli jsme zhruba to same. Puvodni forcefsck udelalo to, ze vynutilo fsck po dalsim rebootu, pak se soubor smazal a pri dalsich bootech uz to fungovalo podle nastaveni systemu. Pro remote access jsou pametry jadra sice hezke ale znamena to ze clovek musi zeditovat konfig pred a po bootu, nebo si pridat boot once volbu jen pro fsck. Proste cele je to drbani pres hlavu.
Jinak ty parametry ve fstab pro fsck uz jsou leta, jen se moc nepouzivali, ale neni to “forcefsck” urcuje to jen poradi.
A to nemluvim o tom, ze kdyz dojde k chyba na
korenovem svazku, tak systemd protoze nema soubor
ctrl-alt-delete.target neumi provest zadny typ
rebootu ci shutdownu… to je fakt nestesti.
Nahlasil jsem jako bug ze systemd neumi udelat reboot kdyz je poskozeny rootfs: https://bugzilla.redhat.com/show_bug.cgi?id=981877
Vysledek? Not a bug. Povolte si sysrq. Ale jak to ma clovek asi udelat na bezicim systemu, do ktereho se kuli systemd a neexistujicim souboru jako login/getty neda prihlasit a nejde ani restartovat? Puvodni hezka myslenka se systemd se postupne totalne dobila silenou zmeti neprehlednych unit, ignoraci zakladnich poucek KISS a naopak nabalovanim vseho mozneho okolo…