Kein Zugriff im Einzelbenutzermodus - was können wir tun, um die Linux-Maschine wiederherzustellen?

Kein Zugriff im Einzelbenutzermodus - was können wir tun, um die Linux-Maschine wiederherzustellen?

da unser Produktionsserver nicht startet (sehr wichtiger Server – Rhel 7.2)

Wir versuchen, gemäß dem Link im Einzelbenutzermodus zuzugreifen -https://www.tecmint.com/boot-into-single-user-mode-in-centos-7/

nach Eingabe der Details zum Einzelbenutzermodus mithilfe der VMconsole stoppt Linux auf dem folgenden

Bildbeschreibung hier eingeben

was können wir ab diesem Stadium tun, um den Produktionsserver wiederherzustellen?

Antwort1

Versuchen Sie, mit dem Installationsmedium zu booten und führen Sie die Diagnose bzw. Fehlerbehebung von dort aus durch.Sichern Sie alles Wichtige!Möglicherweise ist die Maschine oder das System defekt und muss migriert oder von Grund auf neu installiert werden.

Antwort2

Wenn das GRUB-Bootmenü mehrere Kernelversionen enthält, versuchen Sie, mit einer älteren Version zu booten. (Es sollten immer mindestens der aktuelle Kernel und der vom Betriebssysteminstaller verwendete Kernel vorhanden sein: Letzterer hat eine Versionsnummer wie 0-rescue-<numbers>.

Wenn der Bootvorgang mit einem älteren Kernel erfolgreich ist, liegt das Problem möglicherweise an einer beschädigten/fehlenden initramfs-Datei. Dies kommt häufig vor, wenn /bootbeispielsweise während der Installation eines Kernel-Update-Pakets nicht genügend Speicherplatz auf Ihrem Dateisystem vorhanden ist.

(Jede Kernelversion hat ihre eigene Initramfs-Datei. Wenn das Problem also beim letzten Update aufgetreten ist, funktionieren der ältere Kernel und sein Initramfs höchstwahrscheinlich.)

Wenn das System ansonsten normal mit dem alten Kernel läuft, können Sie einen Befehl wie

mkinitrd /boot/initramfs-3.10.0-327.el7.img 3.10.0-327.el7

um die Initramfs-Datei für den neuen Kernel neu zu erstellen.

Wenn jedoch auch das Booten mit einem älteren Kernel fehlschlägt, liegt das Problem möglicherweise woanders. In diesem Fall sollten Sie einen Rettungsmodus-Boot vom Installationsmedium durchführen. Im Fall von VMware bedeutet das, dass Sie sicherstellen müssen, dass die virtuelle Hardware ein virtuelles CD-ROM-Laufwerk enthält, und ein ISO-Image eines RHEL 7.x-Installationsmediums (vorzugsweise 7.2 oder neuer) in das virtuelle CD-Laufwerk „einlegen“ und der VM sagen, dass sie von der CD booten soll.

Sobald das GRUB-Startmenü des Installationsmediums erscheint, wählen Sie „Fehlerbehebung“ und dann „Ein RedHat Linux-System retten“. Das Installationsprogramm wird geladen und fragt wie bei einer normalen Installation nach Sprach- und Tastatureinstellungen, wechselt dann aber in den Rettungsmodus. Es bietet Ihnen sogar an, die Festplatten der zu rettenden Installation automatisch für Sie zu mounten, wenn die Betriebssysteminstallation nicht zu stark beschädigt ist. Anschließend wird Ihnen eine Root-Eingabeaufforderung angezeigt, mit der Sie weitere Fehler beheben und bei Bedarf Korrekturen anwenden können.

In einer Rettungsbootumgebung wird Ihr echtes Root-Dateisystem unter gemountet /mnt/sysimage. Um darauf mit normalen Pfadnamen zugreifen zu können (= ohne /mnt/sysimage vorzuspannen)alles), können Sie den Befehl verwenden chroot /mnt/sysimage, der Ihnen auch unmittelbar vor dem Aufrufen der Rettungs-Eingabeaufforderung vorgeschlagen wird.

Nachdem Sie den chroot /mnt/sysimageBefehl verwendet haben, sollten Sie alle Shell-Befehle verwenden können, die für Ihr installiertes Betriebssystem verfügbar sind. Wenn Sie beispielsweise feststellen, dass die initramfs-Dateien für Ihre Kernel fehlen /boot, können Sie den mkinitrdBefehl (wie oben beschrieben) verwenden, um sie neu zu erstellen.

Antwort3

Ich hatte ein ähnliches Problem, bei dem der neueste Kernel immer in Panik geriet, der vorherige aber einwandfrei funktionierte. Dadurch konnte ich mich zum Glück anmelden und sehen, was passierte.

Einer der Entwickler hatte die Gruppe „root“ in „oot“ geändert, und in der Folge gehörte /boot nicht mehr der ID 1000 (root). Als ich die Yum-Installation ausführte, hieß es, Kernel könne nicht in /boot geschrieben werden, was zu meiner Entdeckung führte ... Nach einigen manuellen Änderungen an der Schattendatei und einigen chown -R-Aktionen wurde der neue Kernel wie erwartet installiert.

TLDR: Überprüfen Sie die Berechtigungen für Systemdateien und stellen Sie sicher, dass niemand die Root-Kontoinformationen kompromittiert hat.

verwandte Informationen