systemd emergency mode ssh

[dion_b]

Blijkbaar heb ik veel geluk (of - minder waarschijnlijk - ben ik gewoon verstandig bezig geweest ) in dat ik onlangs voor het eerst sinds introductie van systemd een boot failure heb in een systeem waar ik niet direct fysiek toegang toe heb.

Toen ik eindelijk systeem op m'n bureau had was het probleem zelf redelijk snel gevonden: om vooralsnog onduidelijke redenen was de RAID array voor de grote opslagschijven (het is een fileserver) niet meer /dev/md127 maar /dev/md2. Dus de fstab regel om het te mounten faalde, dus ging systemd over de zeik en belandde het systeem in emergency more. Enfin, fstab entry omgekat naar UUID om te zorgen dat device letters geen issue meer gaan geven en nofail op mount van zowel de array als de nfs export die erop zat et voila, probleem weg en herhaling ook uitgesloten.

Voor de goede orde, het ging om een Dell EMC VEP1445 (met 256GB M.2 SSD, mPCIe SATA controller en twee 3TB schijven in RAID 1) waar Ubuntu 22.04 LTS op draait.

Maar goed, daar heb ik geen hulp bij nodig. Waar ik moeite mee heb is dat het überhaupt nodig was om dit systeem fysiek te benaderen. De fstab entry die faalde was alleen een dependency voor nfs; alle overige mounts zaten op de SSD waar de partities wel netjes konden mouten. Met oude system V init was alles doorgeboot en zou ik een systeem hebben gehad die op afstand te benaderen was via ssh en had ik het veel sneller gefixed. In plaats daarvan werd ik in emergency mode gedumpt, en zou dat evengoed gebeurd zijn bij eender welk andere failure tijdens de boot, ook als het - zoals hier - op geen enkele manier netwerk en ssh service belemmerd zou hebben.

Dat werkt uitstekend als systeem in kwestie voor je ligt maar is uitermate onhandig als het ergens anders staat. Ik kan me nauwelijks voorstellen dat ik de enige ben die hier tegenaan loopt en inderdaad, ik vind (niet op GoT) topics (als deze, deze en deze) erover

Kort samengevat reacties als:
- je moet niet iets anders dan emergency mode willen als iets faalt tijdens het booten
- investeer in een (remote) KVM switch / terminal server
- je moet geen remote access willen in emergency mode
- gebruik rescue mode ipv emergency mode (wat letterlijk geen optie is)

Maar geen oplossing of workaround.

Enfin, ik kan overstappen naar Devuan om van systemd af te zijn, maar ik zou liever proberen te begrijpen hoe *met* systemd te voorkomen dat ik bij boot errors die niet op rootfs en/of netwerk slaan toch fysiek naar een systeem toe moet. Suggesties?

[MartinMeijerink]

Eigenlijk heb je het zelf al opgelost, en gaat het niet weer gebeuren. Voor de zekerheid zou je op alle andere entries in fstab ook nofail (of noauto, en dan deze mounts na een reboot handmatig mounten) kunnen zetten, zodat je niet bij het booten opnieuw wordt verrast door weer een andere entry die problemen veroorzaakt. Op https://systemd.zutphen.nu/ vind je overigens alles wat je over systemd moet weten , kan echter wel zijn dat ie inmiddels verouderd is, aangezien ik al weer een paar jaartjes op het systemd-vrije Slackware zit.
Wat je ook nog kan doen (als er nog een andere server in de buurt van de betreffende server staat, en ze beiden een seriele poort hebben), deze middels een null-modem aan elkaar koppelen, en dan in de grub config dit zetten:

GRUB_CMDLINE_LINUX="console=tty0 console=ttyS0,115200"
GRUB_TERMINAL="console serial"
GRUB_SERIAL_COMMAND="serial --unit=0 --speed=115200"

Dan wel even de serial-getty@ttyS0-service enablen:

systemctl enable [e-mail]

Dan kun je met een terminal emulator (zoals minicom ofzo) inloggen vanaf de server die nog wel bereikbaar is.