"Legyen a karbantartó nyomora, ne az enyém." - Igen, tehát az, hogy a unit fájlt nem (sem...) bírja rendesen megcsinálni, az a csomag karbantartójának, nem pedig a systemd-nek a "nyomora". Oké, tehát a szambás problémád _nem_ a systemd-ből, hanem a samba karbantartójának a hibája. Oké, ezek a "miért sz@r..." pontjaid tehát kilőve.
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. 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.
"Még mindig ugyanazt a hardware-t használom, mint akkor. És semmi baja. Amióta nincs systemd" - és a kernel is ugyanaz? Ugyanaz a build, ugyanazokkal a paraméterekkel/opciókkal buildelve? Mert mint írtam, a crash-ek döntő többsége vagy a hardver, vagy a kernel sara. 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).