( TCH | 2020. 05. 25., h – 13:56 )

> Oké, ezek a "miért sz@r..." pontjaid tehát kilőve.

Nem egészen. A köztes hatások is számítanak. Az lehet, hogy nem magának a szoftvernek volt a hibája, de a szoftver mögött meghúzódó trendnek volt az eredménye. Miért adaptáltak idejekorán valamit, amit nem tudtak kezelni? Azért mert az RH része felől irdatlan pusholás volt ez ügyben mindenfelé. És ők miért pusholták ennyire, amikor még ők sem tudnak rendesen bánni vele?

> Az fsck attól, hogy "nem talált semmit", még az indulásakor azt látta a rendszer, hogy a fs "dirty", és át kell nézni.

Nyilván, hiszen nem szabályszerűen lett leválasztva.

> Látatlanban nem fog engedni írni értelmes és az adatintegritásra adó OS ilyen fájlrendszerre - mondhatni a tervezési célok/elvárások között előrébb szerepelt az adatintegritás, mint a crash utáni boot időtartama. Neked nem ilyenek a preferenciáid, és sajnálatos módon ezt a különbséget nem igazánlehet áthidalni - el kell fogadni.

Nope, én ezzel tisztában vagyok, nincsenek ezzel ellentétes "preferenciáim". El is mondtam, hogy nem szoktam lelőni az fsck-t, mert tudom, hogy bad practice. De amikor muszáj volna azonnal bebootolni, mert épp a kellős közepén voltál valami live dolognak, akkor eléggé idegesítő, hogy a rendszer kivette a kezedből a döntés lehetőségét. Én nem windózt akarok használni, ami jobban tudja nálam, ne akarjon megvédeni saját magamtól. Ha most pont gixer lett volna a fájlrendszerben, akkor az az én bajom, amiért én vállalni is fogom a felelősséget. De ha nem és most pont fontosabb volt, hogy gyorsan visszakapjam a vezérlést? A lehetőség legyen adott, hogy ha kell, akkor élhessek vele. Én értem, hogy van olyan alak, aki ezzel visszaél és szándékosan lelövi mindig az fsck-t, de az ő hülyesége miatt ne engem büntessenek le, ne tőlem vegyék el a lehetőséget, hogy adott alkalmanként, ha gáz van, akkor mondhassam neki, hogy majd a következő bootnál (touch /forcefsck) intézem magamnak. Promise.

> és a kernel is ugyanaz? Ugyanaz a build, ugyanazokkal a paraméterekkel/opciókkal buildelve?

Amióta upgradeltem Devuan 2-re, azóta nem, de még jópár évig toltam ugyanazon a Jessie-n, amíg ez az upgrade megtörtént és a gondok soha többé nem jöttek elő a systemd repülése után.

> Mert mint írtam, a crash-ek döntő többsége vagy a hardver, vagy a kernel sara.

A PID1 összeomlása is a rendszer összeomlásához vezet. Tekintve, hogy a systemd-ben számos unsafe pointerműveletet és hasonló nyalánkságot fogtak már, így nem meglepő, hogy időnként összeomlik.

> Amióta Linuxom van, azóta ez a tapasztalatom. (0.93-as kernel volt az első, ami hosszabb távon is fent volt az általam használt/üzemeltetett gépen, illetve azóta gyakorlatilag folymatosan van a kezem alatt Linuxos gép. (Néhány darabtól a többszázig, vegyesen fizikai gép és VM).

Nekem is ez volt a tapasztalatom évtizedeken át, Linuxon, BSD-n, OSX-en, Solarison. (windózon nem. :P ) Aztán jött a systemd. Aztán ment a systemd és megint mondhatom ugyanezt. (Oké, random fagyás szökőévente előfordul...hát shit happenz; OSX kernel panicot életemben egyszer láttam Tigeren, van ilyen, hogy sose jössz rá, miért dőlt össze/fagyott le ilyen egyszeri alkalmakként.)