Freigeben über


Chroot-Umgebung in einer Linux-Rettungs-VM

Gilt für: ✔️ Linux-VMs

Notiz

CentOS, auf das in diesem Artikel verwiesen wird, ist eine Linux-Verteilung und wird End Of Life (EOL) erreichen. Sie sollten sich Ihre Nutzung dieser Distribution ansehen und entsprechend planen. Weitere Informationen finden Sie unter CentOS End Of Life Guidance.

In diesem Artikel wird beschrieben, wie Sie die Chroot-Umgebung auf dem virtuellen Rettungscomputer (VM) unter Linux behandeln.

Ubuntu 16.x und Ubuntu 18.x und Ubuntu 20.04

  1. Beenden oder Aufheben der Zuordnung der betroffenen VM.

  2. Erstellen Sie mithilfe eines verwalteten Datenträgers ein VM-Rettungsimage derselben Betriebssystemversion in derselben Ressourcengruppe (RSG) und an demselben Standort.

  3. Verwenden Sie das Azure-Portal, um eine Momentaufnahme des Betriebssystemdatenträgers des betroffenen virtuellen Computers zu erstellen.

  4. Erstellen Sie einen Datenträger aus der Momentaufnahme des Betriebssystemdatenträgers, und fügen Sie ihn an die Rettungs-VM an.

  5. Nachdem der Datenträger erstellt wurde, beheben Sie die Chroot-Umgebung auf dem virtuellen Rettungscomputer.

    1. Greifen Sie mit dem folgenden Befehl auf Ihren virtuellen Computer als Stammbenutzer zu:

      sudo su -

    2. 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 dmesg auf SCSI-Datenträgern (Small Computer Systems Interface) gefiltert:

      dmesg | grep SCSI

      Die Befehlsausgabe ähnelt dem folgenden Beispiel. In diesem Beispiel ist der Datenträger "/dev/sdc " wie gewünscht:

      [    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
      
    3. 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
      
    4. Behandeln Sie die Probleme der chroot-Umgebung.

    5. 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
      

      Notiz

      Wenn Sie die Fehlermeldung "Die Bereitstellung /rescue nicht aufheben" erhalten, fügen Sie -l dem umount Befehl die Option hinzu, umount -l /rescuez. B. . .

  6. Trennen Sie den Datenträger vom virtuellen Rettungscomputer, und tauschen Sie den Datenträger gegen den ursprünglichen virtuellen Computer aus.

  7. 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

  1. Beenden oder Aufheben der Zuordnung der betroffenen VM.

  2. Erstellen Sie ein Rettungs-VM-Image derselben Betriebssystemversion in derselben Ressourcengruppe (RSG) und an einem Speicherort mit einem verwalteten Datenträger.

  3. Verwenden Sie das Azure-Portal, um eine Momentaufnahme des Betriebssystemdatenträgers des betroffenen virtuellen Computers zu erstellen.

  4. Erstellen Sie einen Datenträger aus der Momentaufnahme des Betriebssystemdatenträgers, und fügen Sie ihn an die Rettungs-VM an.

  5. Nachdem der Datenträger erstellt wurde, beheben Sie die Chroot-Umgebung auf dem virtuellen Rettungscomputer.

    1. Greifen Sie mit dem folgenden Befehl auf Ihren virtuellen Computer als Stammbenutzer zu:

      sudo su -

    2. 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 zum Filtern auf SCSI-Datenträgern verwendet dmesg :

      dmesg | grep SCSI

      Die Befehlsausgabe ähnelt dem folgenden Beispiel. In diesem Beispiel ist der Datenträger "/dev/sdc " wie gewünscht:

      [    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
      
    3. 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
      
    4. Behandeln Sie die Probleme der chroot-Umgebung.

    5. 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
      

      Notiz

      Wenn Sie die Fehlermeldung "Die Bereitstellung /rescue nicht aufheben" erhalten, fügen Sie -l dem umount Befehl die Option hinzu, umount -l /rescuez. B. . .

  6. Trennen Sie den Datenträger vom virtuellen Rettungscomputer, und tauschen Sie den Datenträger gegen den ursprünglichen virtuellen Computer aus.

  7. Starten Sie den ursprünglichen virtuellen Computer, und überprüfen Sie die Konnektivität.

RHEL/Centos 7.x & 8.X mit LVM

Notiz

Wenn Ihre ursprüngliche VM den Logical Volume Manager (LVM) auf dem Betriebssystemdatenträger enthält, erstellen Sie den virtuellen Rettungscomputer mithilfe des Images mit unformatierten Partitionen auf dem Betriebssystemdatenträger.

  1. Beenden oder Aufheben der Zuordnung der betroffenen VM.

  2. Erstellen Sie ein Rettungs-VM-Image derselben Betriebssystemversion in derselben Ressourcengruppe (RSG) und an einem Speicherort mit einem verwalteten Datenträger.

  3. Verwenden Sie das Azure-Portal, um eine Momentaufnahme des Betriebssystemdatenträgers des betroffenen virtuellen Computers zu erstellen.

  4. Erstellen Sie einen Datenträger aus der Momentaufnahme des Betriebssystemdatenträgers, und fügen Sie ihn an die Rettungs-VM an.

  5. Nachdem der Datenträger erstellt wurde, beheben Sie die Chroot-Umgebung auf dem virtuellen Rettungscomputer.

    1. Greifen Sie mit dem folgenden Befehl auf Ihren virtuellen Computer als Stammbenutzer zu:

      sudo su -

    2. 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 zum Filtern auf SCSI-Datenträgern verwendet dmesg :

      dmesg | grep SCSI

      Die Befehlsausgabe ähnelt dem folgenden Beispiel. In diesem Beispiel ist der Datenträger "/dev/sdc " wie gewünscht:

      [    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
      
    3. Verwenden Sie die folgenden Befehle, um die logische Volumegruppe zu aktivieren:

      vgscan --mknodes
      vgchange -ay
      lvscan
      
    4. 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
      
    5. Verwenden Sie die folgenden Befehle, um den 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 Versuch, diese Partitionen bereitzustellen, 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 den Universal Unique Identifier (UUID) aus der Datei "/rescue/etc/fstab " mit der Ausgabe des blkid Befehls, um das richtige Gerät für die Bereitstellung /rescue/boot/ und /rescue/boot/efi in 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.

    6. Greifen Sie mithilfe der folgenden Befehle 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
      
    7. Behandeln Sie die Probleme der chroot-Umgebung.

    8. 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
      

      Notiz

      Wenn Sie die Fehlermeldung "Die Bereitstellung /rescue nicht aufheben" erhalten, fügen Sie -l dem umount Befehl die Option hinzu, umount -l /rescuez. B. . .

  6. Trennen Sie den Datenträger vom virtuellen Rettungscomputer, und tauschen Sie den Datenträger gegen den ursprünglichen virtuellen Computer aus.

  7. Starten Sie den ursprünglichen virtuellen Computer, und überprüfen Sie die Konnektivität.

Verwenden des gleichen LVM-Images

Notiz

Wenn Sie den virtuellen Rettungscomputer mithilfe desselben LVM-Images bereitstellen müssen, müssen Sie einige Aspekte der Rettungs-VM mit LVM ändern.

Die folgenden Befehle werden auf dem virtuellen Wiederherstellungs-/Rettungscomputer ausgeführt, der vorübergehend für den Wiederherstellungsvorgang erstellt wurde.

  1. Verwenden Sie den folgenden Befehl, um den 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
    
  2. Fügen Sie den Datenträger an, den Sie als Datenlaufwerk retten möchten.

  3. Ü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.

  4. Zeigen Sie physische LVM-Partitionen mithilfe des folgenden Befehls 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
    
  5. Verwenden Sie den vmimportclone Befehl, um das Stammverzeichnis aus dem Datenlaufwerk mithilfe 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
    
  6. Ü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
    
  7. Benennen Sie die Stammvg des virtuellen Rettungscomputers mithilfe des folgenden Befehls um:

    sudo vgrename rootvg oldvg
    
    Volume group "rootvg" successfully renamed to "oldvg"
    
  8. Überprüfen Sie die Datenträger 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
    ├─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
    
  9. Stellen Sie das Dateisystem bereit, das vom Datenlaufwerk stammt.

    Geben Sie bei Verwendung xfsdie -o nouuid Option an, um Konflikte mit den UUIDs zu vermeiden, und stellen Sie die erforderlichen Dateisysteme bereit, um eine Chroot auszuführen. Diese Option ist in ext4 Dateisystemen nicht verfügbar. Daher müssen Sie sie aus den Befehlen in einem solchen Szenario 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 Versuch, diese Partitionen bereitzustellen, 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 des blkid Befehls, um das richtige Gerät für die Bereitstellung /rescue/boot/ und /rescue/boot/efi in 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 die richtige Partition, die Sie bereitstellen sollten, "/dev/sdc". Dev /sda stellt das derzeit verwendete Betriebssystem dar und sollte ignoriert werden.

  10. Überprüfen Sie die Bereitstellungen 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
    
  11. Verwenden Sie chroot mithilfe des folgenden Befehls:

    sudo chroot /rescue/
    
  12. Überprüfen Sie die Bereitstellungen "inside" der chroot-Umgebung 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
    ├─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   /
    

    Jetzt ist rescuemevg-rootlv die auf ./

  13. Benennen Sie die Volume group (VG) um, um sie konsistent zu halten, indem Sie den folgenden Befehl verwenden. Durch das Umbenennen des VG können Sie beim Erneuten Generieren des Initrds und beim erneuten Starten des Datenträgers auf der ursprünglichen VM Probleme lösen.

    sudo vgrename rescuemevg rootvg
    
    Volume group "rescuemevg" successfully renamed to "rootvg"
    
  14. Ü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   /
    
  15. Fahren Sie mit den erforderlichen Aktivitäten fort, um das Betriebssystem zu retten. Diese Aktivitäten können das Regenerieren von Initramfs oder die GRUB-Konfiguration umfassen.

  16. Beenden Sie die Chroot-Umgebung mithilfe des folgenden Befehls:

    sudo exit
    
  17. Heben Sie die Bereitstellung auf, und trennen Sie den Datenträger vom virtuellen Rettungscomputer, und führen Sie einen Datenträgertausch mit der ursprünglichen VM mithilfe der folgenden Befehle aus:

    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
    
  18. Starten Sie den ursprünglichen virtuellen Computer, und überprüfen Sie dessen Funktionalität.

Oracle 7.x

  1. Beenden oder Aufheben der Zuordnung der betroffenen VM.

  2. Erstellen Sie ein Rettungs-VM-Image derselben Betriebssystemversion in derselben Ressourcengruppe (RSG) und an einem Speicherort mit einem verwalteten Datenträger.

  3. Verwenden Sie das Azure-Portal, um eine Momentaufnahme des Betriebssystemdatenträgers des betroffenen virtuellen Computers zu erstellen.

  4. Erstellen Sie einen Datenträger aus der Momentaufnahme des Betriebssystemdatenträgers, und fügen Sie ihn an die Rettungs-VM an.

  5. Nachdem der Datenträger erstellt wurde, beheben Sie die Chroot-Umgebung auf dem virtuellen Rettungscomputer.

    1. Greifen Sie mit dem folgenden Befehl auf Ihren virtuellen Computer als Stammbenutzer zu:

      sudo su -

    2. Suchen Sie den Datenträger mithilfe dmesg von (die Methode, mit der Sie ihren neuen Datenträger ermitteln, kann variieren). Im folgenden Beispiel wird zum Filtern auf SCSI-Datenträgern verwendet dmesg :

      dmesg | grep SCSI

      Die Befehlsausgabe ähnelt dem folgenden Beispiel. In diesem Beispiel ist der /dev/sdc Datenträger 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
      
    3. 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
      
    4. Behandeln Sie die Probleme der chroot-Umgebung.

    5. 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
      

      Notiz

      Wenn Sie die Fehlermeldung "Die Bereitstellung /rescue nicht aufheben" erhalten, fügen Sie -l dem umount Befehl die Option hinzu, umount -l /rescuez. B. . .

  6. Trennen Sie den Datenträger vom virtuellen Rettungscomputer, und tauschen Sie den Datenträger gegen den ursprünglichen virtuellen Computer aus.

  7. 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

  1. Beenden oder Aufheben der Zuordnung der betroffenen VM.

  2. Erstellen Sie ein Rettungs-VM-Image derselben Betriebssystemversion in derselben Ressourcengruppe (RSG) und an einem Speicherort mit einem verwalteten Datenträger.

  3. Verwenden Sie das Azure-Portal, um eine Momentaufnahme des Betriebssystemdatenträgers des betroffenen virtuellen Computers zu erstellen.

  4. Erstellen Sie einen Datenträger aus der Momentaufnahme des Betriebssystemdatenträgers, und fügen Sie ihn an die Rettungs-VM an.

  5. Nachdem der Datenträger erstellt wurde, beheben Sie die Chroot-Umgebung auf dem virtuellen Rettungscomputer.

    1. Greifen Sie mit dem folgenden Befehl auf Ihre VM als Stammbenutzer zu:

      sudo su -

    2. 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 zum Filtern auf SCSI-Datenträgern verwendet dmesg :

      dmesg | grep SCSI

      Die Befehlsausgabe ähnelt dem folgenden Beispiel. In diesem Beispiel ist der /dev/sdc Datenträger 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
      
    3. 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
      
    4. Behandeln Sie die Probleme der chroot-Umgebung.

    5. 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
      

      Notiz

      Wenn Sie die Fehlermeldung "Die Bereitstellung /rescue nicht aufheben" erhalten, fügen Sie -l dem umount Befehl die Option hinzu, umount -l /rescuez. B. . .

  6. Trennen Sie den Datenträger vom virtuellen Rettungscomputer, und tauschen Sie den Datenträger gegen den ursprünglichen virtuellen Computer aus.

  7. 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.