Chroot-Umgebung auf einer Linux-Rettungs-VM
Hinweis
CentOS, auf das in diesem Artikel verwiesen wird, ist eine Linux-Distribution und erreicht das Ende der Lebensdauer (End Of Life, EOL). Berücksichtigen Sie Ihre Verwendung, und planen Sie sie entsprechend. Weitere Informationen finden Sie unter Leitfaden zum Ende der Lebensdauer von CentOS.
In diesem Artikel wird beschrieben, wie Sie probleme mit der chroot-Umgebung auf dem virtuellen Rettungscomputer (VM) unter Linux beheben.
Ubuntu 16.x und Ubuntu 18.x und Ubuntu 20.04
Beenden Sie die betroffene VM, oder heben Sie die Zuordnung auf.
Erstellen Sie mithilfe eines verwalteten Datenträgers ein VM-Rettungsimage derselben Betriebssystemversion in derselben Ressourcengruppe (RSG) und an demselben Standort.
Verwenden Sie das Azure-Portal, um eine Momentaufnahme des Betriebssystemdatenträgers des betroffenen virtuellen Computers zu erstellen.
Erstellen Sie einen Datenträger aus dem Momentaufnahme des Betriebssystemdatenträgers, und fügen Sie ihn an die Rettungs-VM an.
Nachdem der Datenträger erstellt wurde, führen Sie Eine Problembehandlung für die chroot-Umgebung auf der Rettungs-VM durch.
Greifen Sie mit dem folgenden Befehl als Stammbenutzer auf Ihre VM zu:
sudo su -
Suchen Sie den Datenträger mithilfe von
dmesg
(die Methode, die Sie zum Ermitteln Ihres neuen Datenträgers verwenden, kann möglicherweise anders sein). Im folgenden Beispiel wird verwendetdmesg
, um nach SCSI-Datenträgern (Small Computer Systems Interface) zu filtern:dmesg | grep SCSI
Die Befehlsausgabe ähnelt dem folgenden Beispiel. In diesem Beispiel ist der Datenträger /dev/sdc genau das, was Sie möchten:
[ 0.294784] SCSI subsystem initialized [ 0.573458] Block layer SCSI generic (bsg) driver version 0.4 loaded (major 252) [ 7.110271] sd 2:0:0:0: [sda] Attached SCSI disk [ 8.079653] sd 3:0:1:0: [sdb] Attached SCSI disk [ 1828.162306] sd 5:0:0:0: [sdc] Attached SCSI disk
Die folgenden Befehle für den Zugriff auf die chroot-Umgebung verwenden:
mkdir /rescue mount /dev/sdc1 /rescue mount /dev/sdc15 /rescue/boot/efi mount -t proc /proc /rescue/proc mount -t sysfs /sys /rescue/sys mount -o bind /dev /rescue/dev mount -o bind /dev/pts /rescue/dev/pts mount -o bind /run /rescue/run chroot /rescue
Behandeln Sie die Probleme der chroot-Umgebung.
Die folgenden Befehle zum Beenden der chroot-Umgebung verwenden:
exit umount /rescue/proc/ umount /rescue/sys/ umount /rescue/dev/pts umount /rescue/dev/ umount /rescue/run cd / umount /rescue/boot/efi umount /rescue
Hinweis
Wenn Die Fehlermeldung "Die Bereitstellung von /rescue kann nicht aufgehoben werden" angezeigt wird, fügen Sie dem Befehl die
-l
umount
Option hinzu,umount -l /rescue
z. B. .
Trennen Sie den Datenträger vom virtuellen Rettungscomputer, und tauschen Sie den Datenträger gegen den ursprünglichen virtuellen Computer aus.
Starten Sie den ursprünglichen virtuellen Computer, und überprüfen Sie die Konnektivität.
RHEL/Centos/Oracle 6.x und Oracle 8.x und RHEL/Centos 7.x mit RAW-Partitionen
Beenden Sie die betroffene VM, oder heben Sie die Zuordnung auf.
Erstellen Sie mithilfe eines verwalteten Datenträgers ein Vm-Rettungsimage der gleichen Betriebssystemversion in derselben Ressourcengruppe (RSG) und am gleichen Speicherort.
Verwenden Sie das Azure-Portal, um eine Momentaufnahme des Betriebssystemdatenträgers des betroffenen virtuellen Computers zu erstellen.
Erstellen Sie einen Datenträger aus dem Momentaufnahme des Betriebssystemdatenträgers, und fügen Sie ihn an die Rettungs-VM an.
Nachdem der Datenträger erstellt wurde, führen Sie Eine Problembehandlung für die chroot-Umgebung auf der Rettungs-VM durch.
Greifen Sie mit dem folgenden Befehl als Stammbenutzer auf Ihre VM zu:
sudo su -
Suchen Sie den Datenträger mithilfe von
dmesg
(die Methode, die Sie zum Ermitteln Ihres neuen Datenträgers verwenden, kann möglicherweise anders sein). Im folgenden Beispiel wird verwendetdmesg
, um nach SCSI-Datenträgern zu filtern:dmesg | grep SCSI
Die Befehlsausgabe ähnelt dem folgenden Beispiel. In diesem Beispiel ist der Datenträger /dev/sdc genau das, was Sie möchten:
[ 0.294784] SCSI subsystem initialized [ 0.573458] Block layer SCSI generic (bsg) driver version 0.4 loaded (major 252) [ 7.110271] sd 2:0:0:0: [sda] Attached SCSI disk [ 8.079653] sd 3:0:1:0: [sdb] Attached SCSI disk [ 1828.162306] sd 5:0:0:0: [sdc] Attached SCSI disk
Die folgenden Befehle für den Zugriff auf die chroot-Umgebung verwenden:
mkdir /rescue mount -o nouuid /dev/sdc2 /rescue mount -o nouuid /dev/sdc1 /rescue/boot/ mount -t proc /proc /rescue/proc mount -t sysfs /sys /rescue/sys mount -o bind /dev /rescue/dev mount -o bind /dev/pts /rescue/dev/pts mount -o bind /run /rescue/run chroot /rescue
Behandeln Sie die Probleme der chroot-Umgebung.
Die folgenden Befehle zum Beenden der chroot-Umgebung verwenden:
exit umount /rescue/proc/ umount /rescue/sys/ umount /rescue/dev/pts umount /rescue/dev/ umount /rescue/run cd / umount /rescue/boot/ umount /rescue
Hinweis
Wenn Die Fehlermeldung "Die Bereitstellung von /rescue kann nicht aufgehoben werden" angezeigt wird, fügen Sie dem Befehl die
-l
umount
Option hinzu,umount -l /rescue
z. B. .
Trennen Sie den Datenträger vom virtuellen Rettungscomputer, und tauschen Sie den Datenträger gegen den ursprünglichen virtuellen Computer aus.
Starten Sie den ursprünglichen virtuellen Computer, und überprüfen Sie die Konnektivität.
RHEL/Centos 7.x & 8.X mit LVM
Hinweis
Wenn Ihre ursprüngliche VM den Logischen Volume-Manager (LVM) auf dem Betriebssystemdatenträger enthält, erstellen Sie die Rettungs-VM, indem Sie das Image mit unformatierten Partitionen auf dem Betriebssystemdatenträger verwenden.
Beenden Sie die betroffene VM, oder heben Sie die Zuordnung auf.
Erstellen Sie mithilfe eines verwalteten Datenträgers ein Vm-Rettungsimage der gleichen Betriebssystemversion in derselben Ressourcengruppe (RSG) und am gleichen Speicherort.
Verwenden Sie das Azure-Portal, um eine Momentaufnahme des Betriebssystemdatenträgers des betroffenen virtuellen Computers zu erstellen.
Erstellen Sie einen Datenträger aus dem Momentaufnahme des Betriebssystemdatenträgers, und fügen Sie ihn an die Rettungs-VM an.
Nachdem der Datenträger erstellt wurde, führen Sie Eine Problembehandlung für die chroot-Umgebung auf der Rettungs-VM durch.
Greifen Sie mit dem folgenden Befehl als Stammbenutzer auf Ihre VM zu:
sudo su -
Suchen Sie den Datenträger mithilfe von
dmesg
(die Methode, die Sie zum Ermitteln Ihres neuen Datenträgers verwenden, kann möglicherweise anders sein). Im folgenden Beispiel wird verwendetdmesg
, um nach SCSI-Datenträgern zu filtern:dmesg | grep SCSI
Die Befehlsausgabe ähnelt dem folgenden Beispiel. In diesem Beispiel ist der Datenträger /dev/sdc genau das, was Sie möchten:
[ 0.294784] SCSI subsystem initialized [ 0.573458] Block layer SCSI generic (bsg) driver version 0.4 loaded (major 252) [ 7.110271] sd 2:0:0:0: [sda] Attached SCSI disk [ 8.079653] sd 3:0:1:0: [sdb] Attached SCSI disk [ 1828.162306] sd 5:0:0:0: [sdc] Attached SCSI disk
Verwenden Sie die folgenden Befehle, um die logische Volumegruppe zu aktivieren:
vgscan --mknodes vgchange -ay lvscan
Verwenden Sie den
lsblk
Befehl, um die LVM-Namen abzurufen:lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT sda 8:0 0 64G 0 disk ├─sda1 8:1 0 500M 0 part /boot ├─sda2 8:2 0 63G 0 part / sdb 8:16 0 4G 0 disk └─sdb1 8:17 0 4G 0 part /mnt/resource sdc 8:0 0 64G 0 disk ├─sdc1 8:1 0 500M 0 part ├─sdc2 8:2 0 63G 0 part ├─sdc3 8:3 0 2M 0 part ├─sdc4 8:4 0 63G 0 part ├─rootvg-tmplv 253:0 0 2G 0 lvm ├─rootvg-usrlv 253:1 0 10G 0 lvm ├─rootvg-optlv 253:2 0 2G 0 lvm ├─rootvg-homelv 253:3 0 1G 0 lvm ├─rootvg-varlv 253:4 0 8G 0 lvm └─rootvg-rootlv 253:5 0 2G 0 lvm
Verwenden Sie die folgenden Befehle, um die chroot-Dir vorzubereiten:
mkdir /rescue mount /dev/mapper/rootvg-rootlv /rescue mount /dev/mapper/rootvg-varlv /rescue/var mount /dev/mapper/rootvg-homelv /rescue/home mount /dev/mapper/rootvg-usrlv /rescue/usr mount /dev/mapper/rootvg-tmplv /rescue/tmp mount /dev/mapper/rootvg-optlv /rescue/opt mount /dev/sdc2 /rescue/boot/ mount /dev/sdc1 /rescue/boot/efi
Die Partitionen /rescue/boot/ und /rescue/boot/efi befinden sich möglicherweise nicht immer auf /dev/sdc2 oder /dev/sdc1. Wenn beim Einbinden dieser Partitionen ein Fehler auftritt, überprüfen Sie die Datei /rescue/etc/fstab , um die richtigen Geräte für die Partitionen /boot und /boot/efi vom fehlerhaften Betriebssystemdatenträger zu ermitteln. Führen Sie dann den
blkid
Befehl aus, und vergleichen Sie die UUID (Universal Unique Identifier) aus der Datei /rescue/etc/fstab mit der Ausgabe desblkid
Befehls, um das richtige Gerät für die Einbindung von /rescue/boot/ und /rescue/boot/efi auf der Reparatur-VM zu ermitteln.Der
mount /dev/mapper/rootvg-optlv /rescue/opt
Befehl schlägt möglicherweise fehl, wenn die Volumegruppe rootvg-optlv nicht vorhanden ist. In diesem Fall können Sie diesen Befehl umgehen.Greifen Sie mit den folgenden Befehlen auf die chroot-Umgebung zu:
mount -t proc /proc /rescue/proc mount -t sysfs /sys /rescue/sys mount -o bind /dev /rescue/dev mount -o bind /dev/pts /rescue/dev/pts mount -o bind /run /rescue/run chroot /rescue
Behandeln Sie die Probleme der chroot-Umgebung.
Die folgenden Befehle zum Beenden der chroot-Umgebung verwenden:
exit umount /rescue/proc/ umount /rescue/sys/ umount /rescue/dev/pts umount /rescue/dev/ umount /rescue/run cd / umount /rescue/boot/efi umount /rescue/boot umount /rescue/home umount /rescue/var umount /rescue/usr umount /rescue/tmp umount /rescue/opt umount /rescue
Hinweis
Wenn Die Fehlermeldung "Die Bereitstellung von /rescue kann nicht aufgehoben werden" angezeigt wird, fügen Sie dem Befehl die
-l
umount
Option hinzu,umount -l /rescue
z. B. .
Trennen Sie den Datenträger vom virtuellen Rettungscomputer, und tauschen Sie den Datenträger gegen den ursprünglichen virtuellen Computer aus.
Starten Sie den ursprünglichen virtuellen Computer, und überprüfen Sie die Konnektivität.
Verwenden des gleichen LVM-Images
Hinweis
Wenn Sie die Rettungs-VM mit demselben LVM-Image bereitstellen müssen, müssen Sie einige Aspekte der Rettungs-VM mit LVM ändern.
Die folgenden Befehle müssen auf dem virtuellen Wiederherstellungs-/Rettungscomputer ausgeführt werden, der vorübergehend für den Wiederherstellungsvorgang erstellt wurde.
Verwenden Sie den folgenden Befehl, um die status der Datenträger zu überprüfen, bevor Sie den Datenträger anfügen, den Sie retten möchten:
sudo lsblk -f
NAME FSTYPE LABEL UUID MOUNTPOINT sda ├─sda1 vfat 93DA-8C20 /boot/efi ├─sda2 xfs d5da486e-fdfe-4ad8-bc01-aa72b91fd47d /boot ├─sda3 └─sda4 LVM2_member pdSI2Q-ZEzV-oT6P-R2JG-ZW3h-cmnf-iRN6pU ├─rootvg-tmplv xfs 9098eb05-0176-4997-8132-9152a7bef207 /tmp ├─rootvg-usrlv xfs 2f9ff36c-742d-4914-b463-d4152801b95d /usr ├─rootvg-optlv xfs aeacea8e-3663-4569-af25-c52357f8a0a3 /opt ├─rootvg-homelv xfs a79e43dc-7adc-41b4-b6e1-4e6b033b15c0 /home ├─rootvg-varlv xfs c7cb68e9-7865-4187-b3bd-e9a869779d86 /var └─rootvg-rootlv xfs d8dc4d62-ada5-4952-a0d9-1bce6cb6f809 / sdb └─sdb1 ext4 e72e7c2c-db27-4a73-a97e-01d63d21ccf8 /mnt
Fügen Sie den Datenträger, den Sie retten möchten, als Datenlaufwerk an.
Überprüfen Sie die Datenträger erneut, indem Sie den folgenden Befehl verwenden:
sudo lsblk -f
NAME FSTYPE LABEL UUID MOUNTPOINT sda ├─sda1 vfat 93DA-8C20 /boot/efi ├─sda2 xfs d5da486e-fdfe-4ad8-bc01-aa72b91fd47d /boot ├─sda3 └─sda4 LVM2_member pdSI2Q-ZEzV-oT6P-R2JG-ZW3h-cmnf-iRN6pU ├─rootvg-tmplv xfs 9098eb05-0176-4997-8132-9152a7bef207 /tmp ├─rootvg-usrlv xfs 2f9ff36c-742d-4914-b463-d4152801b95d /usr ├─rootvg-optlv xfs aeacea8e-3663-4569-af25-c52357f8a0a3 /opt ├─rootvg-homelv xfs a79e43dc-7adc-41b4-b6e1-4e6b033b15c0 /home ├─rootvg-varlv xfs c7cb68e9-7865-4187-b3bd-e9a869779d86 /var └─rootvg-rootlv xfs d8dc4d62-ada5-4952-a0d9-1bce6cb6f809 / sdb └─sdb1 ext4 e72e7c2c-db27-4a73-a97e-01d63d21ccf8 /mnt sdc ├─sdc1 vfat 93DA-8C20 ├─sdc2 xfs d5da486e-fdfe-4ad8-bc01-aa72b91fd47d ├─sdc3 └─sdc4 LVM2_member pdSI2Q-ZEzV-oT6P-R2JG-ZW3h-cmnf-iRN6pU
Die Befehlsausgabe zeigt die LVM-Strukturen nicht sofort an.
Zeigen Sie physische LVM-Partitionen mit dem folgenden Befehl an:
sudo pvs
Diese Ausgabe zeigt Warnungen zu doppelten physischen Volumes (PVs):
WARNING: Not using lvmetad because duplicate PVs were found. WARNING: Use multipath or vgimportclone to resolve duplicate PVs? WARNING: After duplicates are resolved, run "pvscan --cache" to enable lvmetad. WARNING: Not using device /dev/sdc4 for PV pdSI2Q-ZEzV-oT6P-R2JG-ZW3h-cmnf-iRN6pU. WARNING: PV pdSI2Q-ZEzV-oT6P-R2JG-ZW3h-cmnf-iRN6pU prefers device /dev/sda4 because device is used by LV. PV VG Fmt Attr PSize PFree /dev/sda4 rootvg lvm2 a-- <63.02g <38.02g
Verwenden Sie den
vmimportclone
Befehl , um die Rootvg aus dem Datenlaufwerk unter Verwendung eines anderen Namens zu importieren.Mit diesem Befehl wird die UUID des PV geändert und aktiviert:
sudo vgimportclone -n rescuemevg /dev/sdc4
WARNING: Not using device /dev/sdc4 for PV <PV>. WARNING: PV pdSI2Q-ZEzV-oT6P-R2JG-ZW3h-cmnf-iRN6pU prefers device /dev/sda4 because device is used by LV.
sudo vgchange -a y rescuemevg
6 logical volume(s) in volume group "rescuemevg" now active
Überprüfen Sie die Namensänderung mithilfe des folgenden Befehls:
sudo lsblk -f
NAME FSTYPE LABEL UUID MOUNTPOINT sda ├─sda1 vfat 93DA-8C20 /boot/efi ├─sda2 xfs d5da486e-fdfe-4ad8-bc01-aa72b91fd47d /boot ├─sda3 └─sda4 LVM2_member pdSI2Q-ZEzV-oT6P-R2JG-ZW3h-cmnf-iRN6pU ├─rootvg-tmplv xfs 9098eb05-0176-4997-8132-9152a7bef207 /tmp ├─rootvg-usrlv xfs 2f9ff36c-742d-4914-b463-d4152801b95d /usr ├─rootvg-optlv xfs aeacea8e-3663-4569-af25-c52357f8a0a3 /opt ├─rootvg-homelv xfs a79e43dc-7adc-41b4-b6e1-4e6b033b15c0 /home ├─rootvg-varlv xfs c7cb68e9-7865-4187-b3bd-e9a869779d86 /var └─rootvg-rootlv xfs d8dc4d62-ada5-4952-a0d9-1bce6cb6f809 / sdb └─sdb1 ext4 e72e7c2c-db27-4a73-a97e-01d63d21ccf8 /mnt sdc ├─sdc1 vfat 93DA-8C20 ├─sdc2 xfs d5da486e-fdfe-4ad8-bc01-aa72b91fd47d ├─sdc3 └─sdc4 LVM2_member BbZsAT-5oOK-nITn-bHFW-IVyS-y0O3-93oDes ├─rescuemevg-tmplv xfs 9098eb05-0176-4997-8132-9152a7bef207 ├─rescuemevg-usrlv xfs 2f9ff36c-742d-4914-b463-d4152801b95d ├─rescuemevg-optlv xfs aeacea8e-3663-4569-af25-c52357f8a0a3 ├─rescuemevg-homelv xfs a79e43dc-7adc-41b4-b6e1-4e6b033b15c0 ├─rescuemevg-varlv xfs c7cb68e9-7865-4187-b3bd-e9a869779d86 └─rescuemevg-rootlv xfs d8dc4d62-ada5-4952-a0d9-1bce6cb6f809
Benennen Sie die Rootvg der Rettungs-VM mit dem folgenden Befehl um:
sudo vgrename rootvg oldvg
Volume group "rootvg" successfully renamed to "oldvg"
Überprüfen Sie die Datenträger mit dem folgenden Befehl:
sudo lsblk -f
NAME FSTYPE LABEL UUID MOUNTPOINT sda ├─sda1 vfat 93DA-8C20 /boot/efi ├─sda2 xfs d5da486e-fdfe-4ad8-bc01-aa72b91fd47d /boot ├─sda3 └─sda4 LVM2_member pdSI2Q-ZEzV-oT6P-R2JG-ZW3h-cmnf-iRN6pU ├─oldvg-tmplv xfs 9098eb05-0176-4997-8132-9152a7bef207 /tmp ├─oldvg-usrlv xfs 2f9ff36c-742d-4914-b463-d4152801b95d /usr ├─oldvg-optlv xfs aeacea8e-3663-4569-af25-c52357f8a0a3 /opt ├─oldvg-homelv xfs a79e43dc-7adc-41b4-b6e1-4e6b033b15c0 /home ├─oldvg-varlv xfs c7cb68e9-7865-4187-b3bd-e9a869779d86 /var └─oldvg-rootlv xfs d8dc4d62-ada5-4952-a0d9-1bce6cb6f809 / sdb └─sdb1 ext4 e72e7c2c-db27-4a73-a97e-01d63d21ccf8 /mnt sdc ├─sdc1 vfat 93DA-8C20 ├─sdc2 xfs d5da486e-fdfe-4ad8-bc01-aa72b91fd47d ├─sdc3 └─sdc4 LVM2_member BbZsAT-5oOK-nITn-bHFW-IVyS-y0O3-93oDes ├─rescuemevg-tmplv xfs 9098eb05-0176-4997-8132-9152a7bef207 ├─rescuemevg-usrlv xfs 2f9ff36c-742d-4914-b463-d4152801b95d ├─rescuemevg-optlv xfs aeacea8e-3663-4569-af25-c52357f8a0a3 ├─rescuemevg-homelv xfs a79e43dc-7adc-41b4-b6e1-4e6b033b15c0 ├─rescuemevg-varlv xfs c7cb68e9-7865-4187-b3bd-e9a869779d86 └─rescuemevg-rootlv xfs d8dc4d62-ada5-4952-a0d9-1bce6cb6f809
Binden Sie das Dateisystem ein, das vom Datenlaufwerk stammt.
Wenn Sie verwenden
xfs
, geben Sie die-o nouuid
Option an, um Konflikte mit den UUIDs zu vermeiden und die erforderlichen Dateisysteme zum Ausführen eines Chroot-Vorgangs einzuhängen. Diese Option ist inext4
Dateisystemen nicht verfügbar, daher müssen Sie sie in einem solchen Szenario aus den Befehlen entfernen:sudo mkdir /rescue sudo mount -o nouuid /dev/mapper/rescuemevg-rootlv /rescue sudo mount -o nouuid /dev/mapper/rescuemevg-homelv /rescue/home sudo mount -o nouuid /dev/mapper/rescuemevg-optlv /rescue/opt sudo mount -o nouuid /dev/mapper/rescuemevg-tmplv /rescue/tmp sudo mount -o nouuid /dev/mapper/rescuemevg-usrlv /rescue/usr sudo mount -o nouuid /dev/mapper/rescuemevg-varlv /rescue/var sudo mount -o nouuid /dev/sdc2 /rescue/boot sudo mount /dev/sdc1 /rescue/boot/efi sudo mount -t proc /proc /rescue/proc sudo mount -t sysfs /sys /rescue/sys sudo mount -o bind /dev /rescue/dev sudo mount -o bind /dev/pts /rescue/dev/pts sudo mount -o bind /run /rescue/run
Die Partitionen /rescue/boot/ und /rescue/boot/efi befinden sich möglicherweise nicht immer auf /dev/sdc2 oder /dev/sdc1. Wenn beim Einbinden dieser Partitionen ein Fehler auftritt, überprüfen Sie die Datei /rescue/etc/fstab , um die richtigen Geräte für die Partitionen /boot und /boot/efi vom fehlerhaften Betriebssystemdatenträger zu ermitteln. Führen Sie dann den
blkid
Befehl aus, und vergleichen Sie die UUID aus der Datei /rescue/etc/fstab mit der Ausgabe desblkid
Befehls, um das richtige Gerät für die Einbindung von /rescue/boot/ und /rescue/boot/efi auf der Reparatur-VM zu ermitteln. Duplizierte UUIDs werden möglicherweise in der Ausgabe angezeigt. Stellen Sie in diesem Szenario die Partition bereit, die dem Gerätebuchstaben aus Schritt 5 entspricht. Im Beispiel dieses Abschnitts ist /dev/sdc die richtige Partition, die Sie einbinden sollten. Dev /sda stellt das derzeit verwendete Betriebssystem dar und sollte ignoriert werden.Überprüfen Sie die Einbindungen mithilfe des folgenden Befehls:
sudo lsblk -f
NAME FSTYPE LABEL UUID MOUNTPOINT sda ├─sda1 vfat 93DA-8C20 /boot/efi ├─sda2 xfs d5da486e-fdfe-4ad8-bc01-aa72b91fd47d /boot ├─sda3 └─sda4 LVM2_member pdSI2Q-ZEzV-oT6P-R2JG-ZW3h-cmnf-iRN6pU ├─oldvg-tmplv xfs 9098eb05-0176-4997-8132-9152a7bef207 /tmp ├─oldvg-usrlv xfs 2f9ff36c-742d-4914-b463-d4152801b95d /usr ├─oldvg-optlv xfs aeacea8e-3663-4569-af25-c52357f8a0a3 /opt ├─oldvg-homelv xfs a79e43dc-7adc-41b4-b6e1-4e6b033b15c0 /home ├─oldvg-varlv xfs c7cb68e9-7865-4187-b3bd-e9a869779d86 /var └─oldvg-rootlv xfs d8dc4d62-ada5-4952-a0d9-1bce6cb6f809 / sdb └─sdb1 ext4 e72e7c2c-db27-4a73-a97e-01d63d21ccf8 /mnt sdc ├─sdc1 vfat 93DA-8C20 /rescue/boot/efi ├─sdc2 xfs d5da486e-fdfe-4ad8-bc01-aa72b91fd47d /rescue/boot ├─sdc3 └─sdc4 LVM2_member BbZsAT-5oOK-nITn-bHFW-IVyS-y0O3-93oDes ├─rescuemevg-tmplv xfs 9098eb05-0176-4997-8132-9152a7bef207 /rescue/tmp ├─rescuemevg-usrlv xfs 2f9ff36c-742d-4914-b463-d4152801b95d /rescue/usr ├─rescuemevg-optlv xfs aeacea8e-3663-4569-af25-c52357f8a0a3 /rescue/opt ├─rescuemevg-homelv xfs a79e43dc-7adc-41b4-b6e1-4e6b033b15c0 /rescue/home ├─rescuemevg-varlv xfs c7cb68e9-7865-4187-b3bd-e9a869779d86 /rescue/var └─rescuemevg-rootlv xfs d8dc4d62-ada5-4952-a0d9-1bce6cb6f809 /rescue
Verwenden Sie chroot mit dem folgenden Befehl:
sudo chroot /rescue/
Überprüfen Sie die Einbindungen "innerhalb" der chroot-Umgebung mit dem folgenden Befehl:
sudo lsblk -f
NAME FSTYPE LABEL UUID MOUNTPOINT sda ├─sda1 vfat 93DA-8C20 ├─sda2 xfs d5da486e-fdfe-4ad8-bc01-aa72b91fd47d ├─sda3 └─sda4 LVM2_member pdSI2Q-ZEzV-oT6P-R2JG-ZW3h-cmnf-iRN6pU ├─oldvg-tmplv xfs 9098eb05-0176-4997-8132-9152a7bef207 ├─oldvg-usrlv xfs 2f9ff36c-742d-4914-b463-d4152801b95d ├─oldvg-optlv xfs aeacea8e-3663-4569-af25-c52357f8a0a3 ├─oldvg-homelv xfs a79e43dc-7adc-41b4-b6e1-4e6b033b15c0 ├─oldvg-varlv xfs c7cb68e9-7865-4187-b3bd-e9a869779d86 └─oldvg-rootlv xfs d8dc4d62-ada5-4952-a0d9-1bce6cb6f809 sdb └─sdb1 ext4 e72e7c2c-db27-4a73-a97e-01d63d21ccf8 sdc ├─sdc1 vfat 93DA-8C20 /boot/efi ├─sdc2 xfs d5da486e-fdfe-4ad8-bc01-aa72b91fd47d /boot ├─sdc3 └─sdc4 LVM2_member BbZsAT-5oOK-nITn-bHFW-IVyS-y0O3-93oDes ├─rescuemevg-tmplv xfs 9098eb05-0176-4997-8132-9152a7bef207 /tmp ├─rescuemevg-usrlv xfs 2f9ff36c-742d-4914-b463-d4152801b95d /usr ├─rescuemevg-optlv xfs aeacea8e-3663-4569-af25-c52357f8a0a3 /opt ├─rescuemevg-homelv xfs a79e43dc-7adc-41b4-b6e1-4e6b033b15c0 /home ├─rescuemevg-varlv xfs c7cb68e9-7865-4187-b3bd-e9a869779d86 /var └─rescuemevg-rootlv xfs d8dc4d62-ada5-4952-a0d9-1bce6cb6f809 /
Nun ist rescuemevg-rootlv das, das auf /bereitgestellt wird.
Benennen Sie die Volumegruppe (VG) um, um sie konsistent zu halten, indem Sie den folgenden Befehl verwenden. Das Umbenennen der VG verhindert, dass Beim erneuten Generieren des Initialisierungsvorgangs und beim erneuten Starten des Datenträgers auf der ursprünglichen VM Probleme auftreten.
sudo vgrename rescuemevg rootvg
Volume group "rescuemevg" successfully renamed to "rootvg"
Überprüfen Sie die Änderung mithilfe des folgenden Befehls:
sudo lsblk -f
NAME FSTYPE LABEL UUID MOUNTPOINT sda ├─sda1 vfat 93DA-8C20 ├─sda2 xfs d5da486e-fdfe-4ad8-bc01-aa72b91fd47d ├─sda3 └─sda4 LVM2_member pdSI2Q-ZEzV-oT6P-R2JG-ZW3h-cmnf-iRN6pU ├─oldvg-tmplv xfs 9098eb05-0176-4997-8132-9152a7bef207 ├─oldvg-usrlv xfs 2f9ff36c-742d-4914-b463-d4152801b95d ├─oldvg-optlv xfs aeacea8e-3663-4569-af25-c52357f8a0a3 ├─oldvg-homelv xfs a79e43dc-7adc-41b4-b6e1-4e6b033b15c0 ├─oldvg-varlv xfs c7cb68e9-7865-4187-b3bd-e9a869779d86 └─oldvg-rootlv xfs d8dc4d62-ada5-4952-a0d9-1bce6cb6f809 sdb └─sdb1 ext4 e72e7c2c-db27-4a73-a97e-01d63d21ccf8 sdc ├─sdc1 vfat 93DA-8C20 /boot/efi ├─sdc2 xfs d5da486e-fdfe-4ad8-bc01-aa72b91fd47d /boot ├─sdc3 └─sdc4 LVM2_member BbZsAT-5oOK-nITn-bHFW-IVyS-y0O3-93oDes ├─rootvg-tmplv xfs 9098eb05-0176-4997-8132-9152a7bef207 /tmp ├─rootvg-usrlv xfs 2f9ff36c-742d-4914-b463-d4152801b95d /usr ├─rootvg-optlv xfs aeacea8e-3663-4569-af25-c52357f8a0a3 /opt ├─rootvg-homelv xfs a79e43dc-7adc-41b4-b6e1-4e6b033b15c0 /home ├─rootvg-varlv xfs c7cb68e9-7865-4187-b3bd-e9a869779d86 /var └─rootvg-rootlv xfs d8dc4d62-ada5-4952-a0d9-1bce6cb6f809 /
Fahren Sie mit den erforderlichen Aktivitäten fort, um das Betriebssystem zu retten. Zu diesen Aktivitäten kann das Erneute Generieren von Initramfs oder die GRUB-Konfiguration gehören.
Beenden Sie die chroot-Umgebung mit dem folgenden Befehl:
sudo exit
Heben Sie die Bereitstellung auf, und trennen Sie den Datenträger von der Rettungs-VM, und führen Sie einen Datenträgeraustausch mit der ursprünglichen VM durch, indem Sie die folgenden Befehle verwenden:
umount /rescue/run/ umount /rescue/dev/pts/ umount /rescue/dev/ umount /rescue/sys/ umount /rescue/proc umount /rescue/boot/efi umount /rescue/boot umount /rescue/var umount /rescue/usr umount /rescue/tmp umount /rescue/opt umount /rescue/home umount /rescue
Starten Sie die ursprüngliche VM, und überprüfen Sie ihre Funktionalität.
Oracle 7.x
Beenden Sie die betroffene VM, oder heben Sie die Zuordnung auf.
Erstellen Sie mithilfe eines verwalteten Datenträgers ein Vm-Rettungsimage der gleichen Betriebssystemversion in derselben Ressourcengruppe (RSG) und am gleichen Speicherort.
Verwenden Sie das Azure-Portal, um eine Momentaufnahme des Betriebssystemdatenträgers des betroffenen virtuellen Computers zu erstellen.
Erstellen Sie einen Datenträger aus dem Momentaufnahme des Betriebssystemdatenträgers, und fügen Sie ihn an die Rettungs-VM an.
Nachdem der Datenträger erstellt wurde, führen Sie Eine Problembehandlung für die chroot-Umgebung auf der Rettungs-VM durch.
Greifen Sie mit dem folgenden Befehl als Stammbenutzer auf Ihre VM zu:
sudo su -
Suchen Sie den Datenträger mithilfe
dmesg
von (die Methode, die Sie zum Ermitteln Des neuen Datenträgers verwenden, kann variieren). Im folgenden Beispiel wird verwendetdmesg
, um nach SCSI-Datenträgern zu filtern:dmesg | grep SCSI
Die Befehlsausgabe ähnelt dem folgenden Beispiel. In diesem Beispiel ist der Datenträger genau das
/dev/sdc
, was Sie möchten:[ 0.294784] SCSI subsystem initialized [ 0.573458] Block layer SCSI generic (bsg) driver version 0.4 loaded (major 252) [ 7.110271] sd 2:0:0:0: [sda] Attached SCSI disk [ 8.079653] sd 3:0:1:0: [sdb] Attached SCSI disk [ 1828.162306] sd 5:0:0:0: [sdc] Attached SCSI disk
Die folgenden Befehle für den Zugriff auf die chroot-Umgebung verwenden:
mkdir /rescue mount -o nouuid /dev/sdc2 /rescue mount -o nouuid /dev/sdc1 /rescue/boot/ mount /dev/sdc15 /rescue/boot/efi mount -t proc /proc /rescue/proc mount -t sysfs /sys /rescue/sys mount -o bind /dev /rescue/dev mount -o bind /dev/pts /rescue/dev/pts mount -o bind /run /rescue/run chroot /rescue
Behandeln Sie die Probleme der chroot-Umgebung.
Die folgenden Befehle zum Beenden der chroot-Umgebung verwenden:
exit umount /rescue/proc/ umount /rescue/sys/ umount /rescue/dev/pts umount /rescue/dev/ umount /rescue/run umount /rescue/boot/efi umount /rescue/boot umount /rescue
Hinweis
Wenn Die Fehlermeldung "Die Bereitstellung von /rescue kann nicht aufgehoben werden" angezeigt wird, fügen Sie dem Befehl die
-l
umount
Option hinzu,umount -l /rescue
z. B. .
Trennen Sie den Datenträger vom virtuellen Rettungscomputer, und tauschen Sie den Datenträger gegen den ursprünglichen virtuellen Computer aus.
Starten Sie den ursprünglichen virtuellen Computer, und überprüfen Sie die Konnektivität.
SUSE-SLES 12 SP4, SUSE-SLES 12 SP4 für SAP && ## SUSE-SLES 15 SP1, SUSE-SLES 15 SP1 für SAP
Beenden Sie die betroffene VM, oder heben Sie die Zuordnung auf.
Erstellen Sie mithilfe eines verwalteten Datenträgers ein Vm-Rettungsimage der gleichen Betriebssystemversion in derselben Ressourcengruppe (RSG) und am gleichen Speicherort.
Verwenden Sie das Azure-Portal, um eine Momentaufnahme des Betriebssystemdatenträgers des betroffenen virtuellen Computers zu erstellen.
Erstellen Sie einen Datenträger aus dem Momentaufnahme des Betriebssystemdatenträgers, und fügen Sie ihn an die Rettungs-VM an.
Nachdem der Datenträger erstellt wurde, führen Sie Eine Problembehandlung für die chroot-Umgebung auf der Rettungs-VM durch.
Greifen Sie mit dem folgenden Befehl auf Ihre VM als Stammbenutzer zu:
sudo su -
Suchen Sie den Datenträger mithilfe von
dmesg
(die Methode, die Sie zum Ermitteln Ihres neuen Datenträgers verwenden, kann möglicherweise anders sein). Im folgenden Beispiel wird verwendetdmesg
, um nach SCSI-Datenträgern zu filtern:dmesg | grep SCSI
Die Befehlsausgabe ähnelt dem folgenden Beispiel. In diesem Beispiel ist der Datenträger genau das
/dev/sdc
, was Sie möchten:[ 0.294784] SCSI subsystem initialized [ 0.573458] Block layer SCSI generic (bsg) driver version 0.4 loaded (major 252) [ 7.110271] sd 2:0:0:0: [sda] Attached SCSI disk [ 8.079653] sd 3:0:1:0: [sdb] Attached SCSI disk [ 1828.162306] sd 5:0:0:0: [sdc] Attached SCSI disk
Die folgenden Befehle für den Zugriff auf die chroot-Umgebung verwenden:
mkdir /rescue mount -o nouuid /dev/sdc4 /rescue mount -o nouuid /dev/sdc3 /rescue/boot/ mount /dev/sdc2 /rescue/boot/efi mount -t proc /proc /rescue/proc mount -t sysfs /sys /rescue/sys mount -o bind /dev /rescue/dev mount -o bind /dev/pts /rescue/dev/pts mount -o bind /run /rescue/run chroot /rescue
Behandeln Sie die Probleme der chroot-Umgebung.
Die folgenden Befehle zum Beenden der chroot-Umgebung verwenden:
exit umount /rescue/proc/ umount /rescue/sys/ umount /rescue/dev/pts umount /rescue/dev/ umount /rescue/run umount /rescue/boot/efi umount /rescue/boot umount /rescue
Hinweis
Wenn Die Fehlermeldung "Die Bereitstellung von /rescue kann nicht aufgehoben werden" angezeigt wird, fügen Sie dem Befehl die
-l
umount
Option hinzu,umount -l /rescue
z. B. .
Trennen Sie den Datenträger vom virtuellen Rettungscomputer, und tauschen Sie den Datenträger gegen den ursprünglichen virtuellen Computer aus.
Starten Sie den ursprünglichen virtuellen Computer, und überprüfen Sie die Konnektivität.
Nächste Schritte
Kontaktieren Sie uns für Hilfe
Wenn Sie Fragen haben oder Hilfe mit Ihren Azure-Gutschriften benötigen, dann erstellen Sie beim Azure-Support eine Support-Anforderung oder fragen Sie den Azure Community-Support. Sie können auch Produktfeedback an die Azure Feedback Community senden.
Feedback
https://aka.ms/ContentUserFeedback.
Bald verfügbar: Im Laufe des Jahres 2024 werden wir GitHub-Issues stufenweise als Feedbackmechanismus für Inhalte abbauen und durch ein neues Feedbacksystem ersetzen. Weitere Informationen finden Sie unterFeedback senden und anzeigen für