Ubuntu 26.04 / Wiederherstellung bei Ubuntu-Start-, Kernel- und Netzwerkfehlern

Starten Sie die Ubuntu-Wiederherstellung an der Konsole: Ermitteln Sie, wie weit der Bootvorgang fortschreitet, bewahren Sie Protokolle und jüngste Änderungen auf und grenzen Sie den Fehler ein. Ein nicht erreichbarer SSH-Dienst beweist nicht, dass das Betriebssystem nicht gestartet ist. Untersuchen Sie Boot-, Kernel-, Netzwerk- und Anwendungsebenen separat und setzen Sie jeweils eine relevante Änderung zurück. Für die zugehörigen Bedingungen und Verfahren siehe Fehleranalyse unter Linux mit Protokollen. Für die zugehörigen Bedingungen und Verfahren siehe Fehler reproduzieren und evidenzbasierte Wiederherstellung üben.

Bestimmen Sie die Fehlerstufe und den sicheren Umfang

Beobachteter Zustand Zuerst untersuchen
Keine VM-Konsole Host, Virtualisierungssoftware, Stromversorgung und VM-Konfiguration
Kein Boot-Medium oder Pre-GRUB-Stopp Angehängte Festplatten/ISO, Firmware-Modus und letzte Änderungen
Kernel-Fehler, Entsperr-Aufforderung oder Notfallmodus Exakter Konsolen-Text, gewählter Kernel, Festplatten und fstab
Konsole funktioniert, SSH nicht Adressen, Routen, DNS, Listener und Firewall
SSH funktioniert, App schlägt fehl Service-Konfiguration, Abhängigkeiten, Berechtigungen und Logs

Bewahren Sie den Zustand nach Möglichkeit, und sichere vorhandene Backups sowie entsperrtes Material. Beschädigen Sie die Produktionsfestplatten oder das Netzwerk nicht absichtlich für eine Übung. Notieren Sie die Zeit, genaue Fehler, den letzten erfolgreichen Vorgang und kürzliche Änderungen, ohne Anmeldeinformationen oder private Schlüssel einzuschließen.

Nur lesend Diagnosedaten sammeln, wenn die Anmeldung funktioniert.

cat /etc/os-release
uname -r
systemctl --failed
df -h
lsblk -f
findmnt /
sudo journalctl --list-boots
sudo journalctl -b -p err --no-pager

Wenn vorherige Boot-Aufzeichnungen existieren, vergleichen Sie sie mit sudo journalctl -b -1 -p err --no-pager. Fehlende historische Protokolle beweisen keinen fehlerfreien Bootvorgang. Bei einer vollen Festplatte identifizieren Sie die Ursache und bewahren Sie relevante Aufzeichnungen auf, bevor etwas entfernt wird. Untersuche die umliegenden Zeiten und einzelnen Einheiten, wenn fehlerhafte Ausgaben keinen Kontext bieten.

Einen begrenzten Dienstausfall üben und die Wiederherstellung auf einem Klon.

Führen Sie dies von der Konsole eines Laborklons aus, der von seinem Original isoliert ist. Diese neue Einheit ist beim Start nicht aktiviert und löscht keine Daten noch ändert sie die Netzwerkeinstellungen. Stellen Sie eine erfolgreiche Basislinie her, führen Sie ein False-Command-Drop-In ein, und stellen Sie es dann wieder her, indem Sie nur diese Datei entfernen. Dies dient der Übung der Service-Diagnose, nicht einem tatsächlichen Kernel- oder Boot-Fehler.

(
set -eu
unit=ubuntu-recovery-lab.service
file=/etc/systemd/system/$unit
drop=/etc/systemd/system/$unit.d
if sudo test -e "$file" || sudo test -L "$file" || sudo test -e "$drop"; then
    printf 'Lab unit already exists; choose a new name.\n' >&2
    exit 1
fi
sudo sh -c 'set -C; cat > "$1"' sh "$file" <<'EOF'
[Unit]
Description=Bounded Ubuntu recovery exercise
[Service]
Type=oneshot
ExecStart=/usr/bin/true
EOF
sudo systemd-analyze verify "$file"
sudo systemctl daemon-reload
sudo systemctl start "$unit"
sudo systemctl show "$unit" -p Result -p ExecMainStatus
sudo install -d -m 0755 "$drop"
sudo sh -c 'set -C; cat > "$1/10-failure.conf"' sh "$drop" <<'EOF'
[Service]
ExecStart=
ExecStart=/usr/bin/false
EOF
sudo systemd-analyze verify "$file"
sudo systemctl daemon-reload
if sudo systemctl start "$unit"; then
    printf 'Unexpected success: inspect the loaded unit.\n' >&2
    exit 1
fi
sudo systemctl show "$unit" -p Result -p ExecMainStatus
sudo journalctl -u "$unit" --since '5 minutes ago' --no-pager
)

Erwarten Sie Result=success und ExecMainStatus=0 in der Basislinie, danach Result=exit-code und ExecMainStatus=1 nach dem absichtlichen Fehler. Unterscheiden Sie einen erfolgreichen inaktiven Oneshot-Zustand von einem Fehler und vergleichen Sie Zeitstempel/Befehle im Journal. Stellen Sie unten nur wieder her, wenn dies die gerade erstellte Datei ist und keine dazwischenliegenden Änderungen vorgenommen wurden.

(
set -eu
sudo rm -- /etc/systemd/system/ubuntu-recovery-lab.service.d/10-failure.conf
sudo systemctl daemon-reload
sudo systemctl reset-failed ubuntu-recovery-lab.service
sudo systemctl start ubuntu-recovery-lab.service
sudo systemctl show ubuntu-recovery-lab.service -p Result -p ExecMainStatus
)

Bestätigen Sie erneut Result=success und ExecMainStatus=0. Für eine vollständige Bereinigung prüfen Sie Besitzrechte und Inaktivität, entfernen Sie nur diese Laboreinheit und ihr leeres Drop-in-Verzeichnis und laden Sie dann systemd neu. Zeichnen Sie dies getrennt von den tatsächlichen Entscheidungen zu vorherigem Kernel/Wiederherstellungsmodus unten auf.

Verwenden Sie einen vorherigen Kernel nach einem updatebedingten Boot-Fehler

Wenn der Boot direkt nach einem Update fehlschlägt und GRUB zusammen mit einem älteren Kernel verfügbar ist, wählen Sie einen vorherigen Kernel unter Erweiterte Optionen für Ubuntu von der Konsole aus. Der Zugriff auf GRUB variiert je nach Firmware, Host und Timing; überprüfen Sie das Verfahren für die Konsole der Maschine oder VM. Verschlüsselte Festplatten müssen trotzdem entsperrt werden.

Wenn der vorherige Kernel bootet, zeichnen Sie uname -r auf und vergleichen Sie die Update-Historie, Kernel-Protokolle und den relevanten Treiber-/DKMS-Zustand. Dieses Ergebnis allein stellt den neuen Kernel nicht als alleinige Ursache fest. Bewahren Sie den laufenden Kernel und ein funktionierendes Backup auf, beheben Sie das identifizierte Problem und überprüfen Sie dann den normalen Bootvorgang.

Die Recovery-Modus-Anleitung des Ubuntu-Wikis beschreibt die GRUB-Wiederherstellungsoptionen und deren Voraussetzungen.

Identifizieren Sie die anfängliche RAM-Disk-Infrastruktur

Ubuntu 26.04 wechselt die standardmäßige initiale RAM-Disk-Infrastruktur zu Dracut, während vorhandene initramfs-tools-Konfigurationen bestehen bleiben können. Während der Boot-Wiederherstellung sollten Regenerierungsbefehle, die aus einem anderen LTS-Leitfaden kopiert wurden, nicht sofort ausgeführt werden: Überprüfen Sie zunächst die installierten Werkzeuge und Boot-Artefakte.

dpkg-query -W dracut dracut-core initramfs-tools 2>/dev/null
command -v dracut update-initramfs
ls -lh /boot

Ein installiertes Werkzeug beweist für sich allein nicht, wie das aktuelle Boot-Image erstellt wurde. Überprüfen Sie die Konfiguration und das offizielle Wiederherstellungsverfahren für den ausgewählten Kernel, die Verschlüsselung, LVM oder RAID und behalten Sie einen funktionierenden Kernel, Konsolenzugang und Backups vor der Regeneration bei.

Ubuntu 26.04 Dracut-Übergang

Überprüfen Sie den Wiederherstellungsmodus, bevor Sie Schreibvorgänge zulassen

Eine Root-Shell im Wiederherstellungsmenü hat umfangreiche Rechte und unterscheidet sich von einer normalen Anmeldung. Überprüfen Sie die Festplattenerkennung, den freien Speicherplatz, die Mount-Punkte und die spezifische Datei, die zuerst repariert werden soll. Betrachten Sie Folgendes nur in der Wiederherstellungs-Shell, wenn das Root-Dateisystem schreibgeschützt ist und eine Konfigurationsreparatur tatsächlich Schreibzugriff erfordert.

findmnt /
mount -o remount,rw /

Diese Befehle lassen sudo weg, da die Wiederherstellungs-Shell als Root ausgeführt wird. Bei Beschädigungen oder I/O-Fehlern stoppen Sie wiederholte Schreibversuche und priorisieren den Erhalt der Daten sowie ein geeignetes Rettungsverfahren. Führen Sie fsck im Reparaturmodus nicht auf einem gemounteten Dateisystem aus und initialisieren Sie keine unbekannten Festplatten.

Wiederherstellen nach einer Änderung der Netzwerkkonfiguration

ip -br address
ip route
resolvectl status
sudo netplan get
systemctl is-active NetworkManager systemd-networkd
sudo ss -lntp

Identifizieren Sie von der Konsole aus die tatsächliche Schnittstelle, den verwaltenden Renderer und die effektive Netplan-Konfiguration. Vergleichen Sie die zuletzt geänderte Datei mit ihrem Backup, anstatt eine weitere YAML-Datei zum Überschreiben hinzuzufügen. Prüfen Sie, ob cloud-init oder ein anderes Tool die Konfiguration erzeugt.

Beim Wiederherstellen des richtigen Backups sollte die aktuelle Konfiguration ebenfalls beibehalten werden. Nach erfolgreichem netplan generate verwenden Sie sudo netplan try --timeout 120 mit verbleibendem Konsolenzugriff. Ein automatischer Rollback kann fehlschlagen; überprüfen Sie die resultierenden Adressen, Routen, DNS und eine neue SSH-Verbindung. Wenn das Netzwerk funktioniert, untersuchen Sie SSH-Schlüssel, Listener und UFW separat.

Konsultieren Sie das Netplan-Try-Handbuch 26.04 für Rollback-Beschränkungen und Überprüfungsanforderungen.

Daten bewahren und Wiederherstellung überprüfen

Wenn das installierte Betriebssystem unbrauchbar ist, ziehen Sie eine geprüfte Live-/Rettungsumgebung in Betracht. Identifizieren Sie Verschlüsselung, LVM und RAID, bevor Sie auf Festplatten zugreifen, und vermeiden Sie es, die Quelle als Installationsziel auszuwählen. Raten Sie nicht bei allgemeinen GRUB-Neuinstallations- oder Partitionswiederherstellungsbefehlen; verwenden Sie ein Verfahren, das dem tatsächlichen Layout und getesteten Backups entspricht.

Nach der Wiederherstellung überprüfen Sie den Neustart, eine neue SSH-Verbindung, Dienste, Anwendungslesungen/-schreibungen, Protokolle und Backups. Dokumentieren Sie, was rückgängig gemacht wurde, was sich verbessert hat, offene Fragen und Beweismittel, die gesammelt werden sollten, falls es erneut auftritt. Die Wiederherstellung ist abgeschlossen, wenn der normale Betrieb nachhaltig ist, nicht nur, wenn die erste Antwort zurückkommt.