Stellen Sie sich einen Headless-Server wie diesen vor: Eine typische x86-Box an einem Remotestandort, die Sie mit einem Standard-Ubuntu-Image remote initialisieren können. Nach der Initialisierung können Sie sich nur über ssh anmelden oder remote zurücksetzen, dh Sie können nicht auf das BIOS oder die Eingabeaufforderung des Boot-Managers zugreifen (z. B. Grub 1).
Möglicherweise ist eine Art KVM verfügbar, aber die Verwendung von KVM ist sehr teuer und Sie müssen sie stündlich buchen.
In diesem Szenario kann man bei Bootproblemen paranoid werden. Zum Beispiel:
- Was ist, wenn ein Kernel-Upgrade fehlschlägt?
- Was ist mit einer fsck-Eingabeaufforderung im frühen Startvorgang? Wahrscheinlich ist ssh noch nicht verfügbar ...
Gibt es andere Fallstricke, auf die Sie achten müssen?
Für Kernel-Upgrades konfiguriere ich grub (das Legacy) so, dass die menu.lst
Präambel enthält
default saved
fallback 2 # counts from 0
und der erste Eintrag endet mit:
savedefault fallback
Der erste Grub-Eintrag ist der aktualisierte Kernel, und der dritte ist ein bekannter funktionierender. Siehe auch den Abschnitt zum Grub-Handbuch zum Fallback-Boot .
Ich habe das Startskript /etc/rc.local
(auf einem Debian-ähnlichen System) dahingehend geändert, dass die Standardeinstellung bei einem erfolgreichen Start zurückgesetzt wird:
grub-set-default 0
Dieses Grub-Setup funktioniert, aber zB unter Ubuntu ist dies nicht die Standardeinstellung und man muss das menu.lst
nach jedem Kernel-Update manuell anpassen .
Ich versorge
panic=60
als Kernel-Parameter, so dass root=
das System im Falle eines falschen Parameters oder eines defekten Kernels im Fehlerfall automatisch neu startet.
Über das fsck-Problem bin ich mir nicht sicher, was der beste Weg ist. Auf Debian-ähnlichen Systemen können Sie einstellen
FSCKFIX=yes
in /etc/default/rcS
, wodurch fsck standardmäßig angewiesen wird, automatisch zu reparieren.
Aber wenn die automatische Reparatur fehlschlägt, erhalte ich möglicherweise immer noch eine Eingabeaufforderung, auf die ich nicht remote zugreifen kann?
Alternativ könnte ich einfach die fsck-Prüfung über eine Null in der sechsten Spalte von deaktivieren /etc/fstab
- im Falle eines fs-Fehlers würde ich dann einfach das System neu initialisieren und die Backups wiederherstellen - und so alle fsck-Probleme vermeiden?