Dokumentation
Gewusst wie: Chroot in ein defektes System über Live-CD / ISO oder ein alternatives Linux-System
Gelegentlich müssen Sie möglicherweise einen defekten / nicht bootfähigen TurnKey-Server retten. Vielleicht hatten Sie einen Hardwarefehler, oder vielleicht haben Sie versehentlich etwas kaputt gemacht, oder vielleicht haben Sie ein Buggy-Update installiert, das Dinge kaputt gemacht hat?
Oft können diese Probleme durch "Chrooting" in das defekte System von einem funktionierenden (Linux) System behoben werden, und dann die erforderlichen Schritte zur Behebung des Problems unternehmen (neu installieren grub), Einen Kernel neu installieren, ein Initramfs neu erstellen usw. Offensichtlich hängen die Schritte zum Beheben eines defekten Systems davon ab, was tatsächlich defekt ist. Wenn Sie sich nicht sicher sind, dann sind Sie wahrscheinlich am besten, einen neuen Thread in der Foren (erfordert ein kostenloses website-benutzerkonto, um einen neuen thread zu starten), damit wir bei der diagnose des problems helfen können.
In diesem Dokument werde ich nur bis zu dem Punkt beraten, an dem Sie die chroot betreten, und werde nicht in die Details gehen, wie man ein bestimmtes Problem löst (obwohl, wenn / wenn ich ein Problem bekomme) Chance, vielleicht schreibe ich Doc-Seiten für einige der häufigsten Probleme?!
Anmerkung:: Wenn nicht, müssen die meisten (wenn nicht alle) Befehle, die außerhalb des chroot ausgeführt werden, möglicherweise mit 'sudo' vorangestellt werden. Wenn Sie die chroot über sudo eingeben, dann sollte es nicht einmal innerhalb der chroot erforderlich sein.
Also zuerst oben, ein kleiner Hintergrund. Wenn du lieber direkt hineinspringst Aufrichten der chrootBitte fühlen Sie sich frei.
Was ist ein "Chroot"
Laut Wikipedia ist ein Gerste:
ändert das scheinbare Root-Verzeichnis für den aktuellen laufenden Prozess und seine Kinder. Ein Programm, das in einer solchen modifizierten Umgebung ausgeführt wird, kann Dateien außerhalb des benannten Verzeichnisbaums nicht benennen (und kann daher normalerweise nicht darauf zugreifen).
Als Linux-Benutzer gibt es 2 Arten von Chroot, denen Sie begegnen können. Was ich als "Standard"-Chroot bezeichne (was diese Doc-Seite abdeckt), dann gibt es auch ein "Chroot-Gefängnis".
Der Zweck eines chroot-Gefängnisses, einen Benutzer oder Prozess innerhalb eines bestimmten Teils eines Verzeichnisbaums zu sperren, z.B. ein Programm kann in sein eigenes Verzeichnis "gerootet" werden (Postfix ist beispielsweise so eingerichtet), ohne Zugriff auf den Rest des Dateisystems. Oder ein eingeschränkter Benutzer kann in sein Heimatverzeichnis "gerootet" werden, so dass er (z. B.) SFTP verwenden kann, aber nicht das gesamte Dateisystem durchsuchen kann.
Ein "Standard"-Chroot kann verwendet werden, um ein nicht bootfähiges System zu untersuchen und möglicherweise zu reparieren, und wird auch häufig zum Bau neuer Linux-Systeme verwendet. Zum Beispiel verwendet TurnKey eine "Standard" chroot (on) TKLDev) um das TurnKey Appliances zu bauen. Das ist die Art von chroot, die ich hier dokumentieren werde.
Einrichten eines chroot
Zubereitung
Das erste, was zu tun ist, ist sicherzustellen, dass das Dateisystem des defekten Systems vom Arbeitssystem aus zugänglich ist. Im Falle einer Bare Metal Installation oder einer VM ist es oft am einfachsten, einfach von einer Live CD / USB / ISO zu booten. Als allgemeine Regel ist es normalerweise am besten, das gleiche Betriebssystem zu verwenden wie das, was das defekte System ist. Kernnetz (oder jeder andere Server; nur Core ist der kleinste) der gleichen Hauptversion. z. B. v15.0 Core ist in Ordnung, um jede v15.x Appliance zu beheben. Wenn das keine Option ist, ist ein Debian Live-System auch eine gute Option. Im schlimmsten Fall könnten Sie mit einer relativ aktuellen Linux-Distribution davonkommen, obwohl TurnKey (oder Debian) einer passenden Version vorzuziehen ist.
Was immer du tust DO NOT Das wird es unwiederbringlich machen!
Alternativ können Sie die Festplatte (physisch oder virtuell) auf eine andere (Arbeits-) Maschine verschieben (mit TurnKey / Debian / etc. wie oben ausgeführt). Für einen AWS-Server ist das auch im Wesentlichen das, was Sie tun müssen (d. H. Entfernen Sie das primäre Volume vom defekten System und fügen Sie es an ein funktionierendes System an).
Finden Sie das richtige Volume zum Montieren
Nachdem Sie das defekte Primärvolumen an ein funktionierendes System angeschlossen haben, besteht der nächste Schritt darin, es zu montieren. Um es zu montieren, müssen Sie sicherstellen, dass Sie einen sauberen Mount-Standort haben, und Sie müssen auch herausfinden, welche Festplatte / Volume / Partition(en) Sie montieren müssen.
Eine einfache Möglichkeit, um sicherzustellen, dass Sie einen sauberen Montageort haben, ist es, es zu erstellen!
mkdir /rescue
Sicherzustellen, dass Sie das richtige Laufwerk/Volume/Partition(en) finden, kann etwas schwieriger sein, aber ein Werkzeug, das Sie verwenden können, ist fdisk.
fdisk -l
Hier ist die Ausgabe auf einem AWS-Server, an dem ich gerade arbeite. Es hat ein sekundäres Laufwerk (das Root-Volume eines anderen Servers), das als /dev/xvdf, das Standard-Root-Volume (d.h. das Standard-Root-Volume) angehängt ist. Das Root-Volume des Arbeitsservers ist /dev/xvda. Das kann für Sie unterschiedlich sein (obwohl, wenn Sie auf AWS sind, ist wahrscheinlich das gleiche).
root@core ~# fdisk -l Disk /dev/xvda: 10 GiB, 10737418240 bytes, 20971520 sectors Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disklabel type: gpt Disk identifier: 6183BC26-31B1-41F2-9AB9-319B7C4A85B0 Device Start End Sectors Size Type /dev/xvda1 2048 6143 4096 2M BIOS boot /dev/xvda2 6144 20969471 20963328 10G Linux filesystem Disk /dev/xvdf: 10 GiB, 10737418240 bytes, 20971520 sectors Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disklabel type: gpt Disk identifier: 0029AB38-4BE5-4009-B163-9A7B4F597FE4 Device Start End Sectors Size Type /dev/xvdf1 2048 6143 4096 2M BIOS boot /dev/xvdf2 6144 20969471 20963328 10G Linux filesystem
Wenn Sie unsicher sind, welches Volumen das ist, überprüfen Sie, welche Volumes bereits montiert sind.
mount | grep ^/dev
Das wird für alle Zeilen aus dem Mount-Ausgang, die mit /dev. beginnen In meinem Fall bestätigt dies, was ich bereits weiß, ist der Voume, den ich bereits montiert habe, /dev/xvda:
root@core ~# mount | grep ^/dev /dev/xvda2 on / type ext4 (rw,relatime,data=ordered) /dev/xvda2 on /tmp type ext4 (rw,relatime,data=ordered) /dev/xvda2 on /var/cache/tklbam type ext4 (rw,relatime,data=ordered)
Montage des defekten Systems bereit zum chroot
Wenn man also herausgefunden hat, welche Partition man montieren muss, ist das ziemlich einfach. Wenn Sie oben, an meinem Ausgang von fdisk, sehen Sie, dass /dev/xvdf1 Typ "BIOS boot" und /dev/xvdf2 "Linux filesystem" ist. Das zu montieren ist so einfach wie dieses:
mount /dev/xvdf2 /rescue
Wenn Sie jetzt in /rescue einchecken (d. H. ls /rescue), sollten Sie so etwas sehen:
root@core ~# ls -l /rescue total 92 drwxr-xr-x 2 root root 4096 Apr 16 02:49 bin drwxr-xr-x 3 root root 4096 Apr 16 02:50 boot drwxr-xr-x 5 root root 4096 Oct 3 2018 dev drwxr-xr-x 100 root root 4096 Apr 16 02:50 etc drwxr-xr-x 3 root root 4096 Oct 3 2018 home lrwxrwxrwx 1 root root 29 Oct 3 2018 initrd.img -> boot/initrd.img-4.9.0-8-amd64 lrwxrwxrwx 1 root root 29 Oct 3 2018 initrd.img.old -> boot/initrd.img-4.9.0-8-amd64 drwxr-xr-x 18 root root 4096 Oct 3 2018 lib drwxr-xr-x 2 root root 4096 Mar 11 2018 lib64 drwx------ 2 root root 16384 Oct 3 2018 lost+found drwxr-xr-x 2 root root 4096 Mar 11 2018 media drwxr-xr-x 4 root root 4096 Apr 16 02:49 mnt drwxr-xr-x 2 root root 4096 Mar 11 2018 opt drwxr-xr-x 2 root root 4096 Feb 23 2018 proc drwx------ 5 root root 4096 Oct 3 2018 root drwxr-xr-x 12 root root 4096 Oct 3 2018 run drwxr-xr-x 2 root root 4096 Apr 16 02:49 sbin drwxr-xr-x 2 root root 4096 Mar 11 2018 srv drwxr-xr-x 2 root root 4096 Feb 12 2017 sys drwxrwxrwt 7 root root 4096 Apr 16 02:51 tmp drwxr-xr-x 10 root root 4096 Mar 11 2018 usr drwxr-xr-x 13 root root 4096 Oct 3 2018 var lrwxrwxrwx 1 root root 26 Oct 3 2018 vmlinuz -> boot/vmlinuz-4.9.0-8-amd64 lrwxrwxrwx 1 root root 26 Oct 3 2018 vmlinuz.old -> boot/vmlinuz-4.9.0-8-amd64
Offensichtlich werden die Daten unterschiedlich sein, aber ansonsten zeigt das, dass das System wie erwartet montiert ist. Alle aktuellen Builds von TurnKey enthalten die /boot-Partition, obwohl in einigen älteren Versionen, wenn die Installation LVM verwendet, dann muss die /boot-Partition möglicherweise separat montiert werden. In diesem Fall, nachdem das Haupt-Betriebssystem installiert ist, montieren Sie das Boot-Verzeichnis.
mount /dev/sdXN /rescue/boot
/dev/sdXN ist die Partition, auf der sich die Boot-Info befindet.
Aber warten Sie, es gibt mehr...! Sobald das Haupt-Betriebssystem gemountet wurde, müssen Sie auch einige spezielle Verzeichnisse vom Host montieren, damit die chroot richtig funktioniert. In erster Linie sind dies /dev, /proc und /sys. /dev/pts ist auch eine Montage wert. Nach meiner Erfahrung können Sie ohne Montage davonkommen, aber Sie werden oft Fehler bekommen, also lohnt es sich, diese zu montieren, um den Lärm zu reduzieren.
mount -t proc proc /rescue/proc mount -t sysfs sys /rescue/sys mount -o bind /dev /rescue/dev mount -t devpts pts /rescue/dev/pts
Chrooting in
Jetzt musst du einfach nur hineinkitzeln.
chroot /rescue
So einfach ist das...! :
Jetzt tun Sie, was Sie tun müssen, um Ihr System zu reparieren. Sobald Sie glücklich sind (oder nur bereit sind zu testen), dann können Sie die chroot wie folgt verlassen:
exit
Aufräumen danach
Wenn Sie den Server anhalten müssen, um das defekte Laufwerk zu entfernen, ist keine Bereinigung erforderlich. Wenn Sie den Server nicht stoppen müssen, ist ein Neustart der einfachste Weg, um die chroot zu bereinigen. Wenn Sie jedoch den von Ihnen verwendeten Server nicht stoppen oder aus einem anderen Grund die chroot-Konfiguration rückgängig machen möchten, müssen Sie nach dem Verlassen des chroot nur noch Zurückverfolgen auf die obigen Befehle, d.h. umount statt mount verwenden und sie in umgekehrter Reihenfolge, in der sie montiert wurden, wieder loslassen, d.h.:
umount /rescue/dev/pts umount /rescue/dev umount /rescue/sys umount /rescue/proc
Wenn Sie eine separate Boot-Partition montiert haben, demounten Sie diese als nächstes, d.h. 'umount /rescue/boot'. Dann schließlich das Hauptvolumen:
umount /rescue