Opstartproblemen met virtuele Linux-machines oplossen vanwege bestandssysteemfouten

Artikel
03/27/2024

Dit artikel bevat richtlijnen voor het oplossen van opstartproblemen met virtuele Linux-machines (VM's) die worden veroorzaakt door bestandssysteemfouten.

Symptomen

U kunt geen verbinding maken met een virtuele Azure Linux-machine (VM) met behulp van het Secure Shell-protocol (SSH) of de status van de VM-agent in de Azure Portal is niet gereed. Wanneer u de diagnostische gegevens over opstarten uitvoert in de Azure Portal of verbinding maakt met de seriële console, ziet u logboekvermeldingen die lijken op de volgende voorbeelden:

Opmerking

Niet alle voorbeelden zijn aanwezig.
Een koppelingsfout heeft niet altijd tot gevolg dat een VM de noodmodus ingaat. Als het probleem zich voordoet bij bepaalde kritieke bestandssystemen, gebruikt de VM mogelijk geen noodmodus.

Voorbeeld 1: kan ext4-bestandssysteem niet koppelen

EXT4-fs (sda1): INFO: recovery required on readonly filesystem
EXT4-fs (sda1): write access will be enabled during recovery
EXT4-fs warning (device sda1): ext4_clear_journal_err:4531: Filesystem error recorded from previous mount: IO failure
EXT4-fs warning (device sda1): ext4_clear_journal_err:4532: Marking fs in need of filesystem check.

Voorbeeld 2: kan geen LVM-apparaat (Logical Volume Manager) koppelen

[   14.382472] EXT4-fs error (device dm-0): ext4_iget:4398: inode #8: comm mount: bad extra_isize 4060 (inode size 256)
[   14.389648] EXT4-fs (dm-0): no journal found
<snipped>
[FAILED] Failed to mount /opt/data.

Voorbeeld 3: kan xfs-bestandssysteem niet koppelen

[    8.543984] XFS (sdc1): Metadata CRC error detected at xfs_agi_read_verify+0xd0/0xf0 [xfs], xfs_agi block 0x10
[    8.553867] XFS (sdc1): Unmount and run xfs_repair
[    8.558993] XFS (sdc1): First 128 bytes of corrupted metadata buffer:
[    8.564893] 00000000: 58 41 47 49 00 00 00 01 00 00 00 00 00 1f ff c0  XAGI............
[    8.572847] 00000010: 00 00 00 40 00 00 00 06 00 00 00 01 00 00 00 3d  ...@...........=
[    8.580476] 00000020: 00 00 00 60 ff ff ff ff ff ff ff ff ff ff ff ff  ...`............
[    8.588219] 00000030: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff  ................
[    8.596280] 00000040: ff 07 f8 ff ff ff ff ff ff ff ff ff ff ff ff ff  ................
[    8.603575] 00000050: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff  ................
[    8.610849] 00000060: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff  ................
[    8.619261] 00000070: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff  ................
[    8.629731] XFS (sdc1): metadata I/O error in "xfs_trans_read_buf_map" at daddr 0x10 len 8 error 74
[    8.637799] XFS (sdc1): xfs_imap_lookup: xfs_ialloc_read_agi() returned error -117, agno 0
[FAILED] Failed to mount /data.
See 'systemctl status data.mount' for details.
[DEPEND] Dependency failed for Local filesystems.

Voorbeeld 4: Opstarten in de noodmodus

You are in emergency mode. After logging in, type "journalctl -xb" to view
system logs, "systemctl reboot" to reboot, "systemctl default" or "exit"
to boot into default mode.
Give root password for maintenance
(or press Control-D to continue):

Oorzaak

De bovenstaande logboekvermeldingen duiden op schijfbeschadiging. In bepaalde situaties voorkomt schijfbeschadiging dat de VM volledig kan worden opgestart. Verschillende problemen kunnen schijfbeschadiging veroorzaken, zoals linux-kernelproblemen, stuurprogrammafouten, fouten in de onderliggende fysieke of virtuele hardware, enzovoort.

Oplossing

Als u de opstartproblemen van linux-VM's wilt oplossen die worden veroorzaakt door bestandssysteemfouten, herstelt u de VM door de schijfbeschadiging te herstellen. Voer de volgende stappen uit om de schijfbeschadiging te herstellen:

Bepaal welke schijf is beschadigd.
Type bestandssysteem identificeren.
Selecteer de herstelmodus (online of offline).
Bereid de herstelomgeving voor volgens de herstelmodus die u selecteert:
- Omgeving voorbereiden voor online herstel
- Omgeving voorbereiden voor offline herstel
Gebruik opdrachtregelprogramma's om het problematische bestandssysteem op de schijf te herstellen.
- Ext4-bestandssysteem herstellen
- XFS-bestandssysteem herstellen
Opmerking
- Het is belangrijk om een back-up te maken van kritieke gegevens, omdat gegevensverlies kan optreden op de herstelde schijf.
- Voordat u wijzigingen aanbrengt in een schijf, maakt u een momentopname om de huidige status van de schijf te behouden, zelfs als deze een foutstatus heeft. Als u de schijfbeschadiging herstelt, worden de gegevens op de schijf gewijzigd, wat risico's met zich meedraagt.

Bepalen welke schijf is beschadigd

Als u wilt bepalen welke schijf is beschadigd, downloadt u het seriële logboek voor uw VM met behulp van de seriële console of opstartdiagnose, controleert u de logboekvermeldingen tijdens het opstarten en zoekt u vervolgens naar de specifieke fout waarin wordt aangegeven welke schijf of koppeling mislukt.

Hier volgen drie voorbeelden van logboekvermeldingen. In deze voorbeelden ziet u de tekst tussen haakjes, waarmee het beschadigde apparaat wordt gerapporteerd.

In het volgende voorbeeld is sdc1het beschadigde apparaat :

[   14.285807] XFS (sdc1): Mounting V5 Filesystem
[   14.426283] XFS (sdc1): Metadata CRC error detected at xfs_agi_read_verify+0xde/0x100 [xfs], xfs_agi block 0x10
[   14.426284] XFS (sdc1): Unmount and run xfs_repair
<snipped>
[FAILED] Failed to mount /opt/parent.

In het volgende voorbeeld is sda1de partitie waar een bestandssysteemfout optreedt:

EXT4-fs (sda1): INFO: recovery required on readonly filesystem
EXT4-fs (sda1): write access will be enabled during recovery
EXT4-fs warning (device sda1): ext4_clear_journal_err:4531: Filesystem error recorded from previous mount: IO failure
EXT4-fs warning (device sda1): ext4_clear_journal_err:4532: Marking fs in need of filesystem check.
<snipped>
[FAILED] Failed to mount /boot.

In het volgende voorbeeld is dm-2het beschadigde apparaat . Het is een Linux Device Mapper-apparaat, wat een LVM-volume aangeeft.

[   18.014318] EXT4-fs (dm-2): VFS: Can't find ext4 filesystem
[FAILED] Failed to mount /home.
See 'systemctl status home.mount' for details.
[DEPEND] Dependency failed for Local File Systems.
[DEPEND] Dependency failed for Mark the need to relabel after reboot.

Als het schijfapparaat dat wordt uitgelicht een naam gebruikt van de indeling 'sdXN', waarbij X een letter is van a-z en N een optioneel partitienummer is, betekent dit dat de schijf onbewerkt is en kan worden gebruikt met behulp van het pad /dev/sdXN .

Als het schijfapparaat dat wordt gekoppeld een naam gebruikt zoals /dev/mapper/vgname/lvname, /dev/vgname/lvname of dm-N, betekent dit dat een LVM-apparaat wordt gebruikt. Zorg ervoor dat u alle fysieke schijfvolumes (PC's) herkent die mogelijk in gebruik zijn.

Het wordt niet ondersteund voor de LVM-volumegroep (VG) om de besturingssysteemschijf en een willekeurig aantal gegevensschijven te bevatten. Voor een dergelijk scenario is er een hoog risico op gegevensverlies. Meerdere gegevensschijven zijn echter toegestaan in een LVM VG.

Bij het bepalen van de toewijzing van besturingssysteemschijfverwijzingen aan Azure-schijfobjecten:

Voor Marketplace-installatiekopieën bevindt het hoofdbestandssysteem (/), /boot en /boot/efi zich op de besturingssysteemschijf.
Voor LVM-installatiekopieën kunnen veel andere systeemkoppelingen bestaan, zoals /home, /tmp, /usr, /var, /var/log en /opt.
Extra bestandssystemen die voor toepassingen zijn gemaakt, bevinden zich op gegevensschijven, bijvoorbeeld /data, /datadisk of /sap. Configureer ze correct, zodat het systeem kan worden opgestart, zelfs als er een fout optreedt. Als een gegevensschijf een apparaat is dat wordt opgestart in de noodmodus, raadpleegt u Opstartfouten voorkomen.

Bestandssysteemtype identificeren

Tijdens het uitvoeren van de eerste identificatie is de enige methode om het schijftype te bepalen het seriële logboek zoals eerder is onderzocht in Bepalen welke schijf is beschadigd. Wanneer het schijfapparaat wordt gerapporteerd in het seriële logboek, worden fouten weergegeven vanuit de Linux-kernelmodule voor het bestandssysteem. Noteer elke regel waarin EXT4-fs of XFS is opgegeven. Voor alle andere bestandstypen bevindt het logboek zich in hetzelfde gebied. Het bestandssysteem dat in de logboekvermeldingen wordt vermeld, wordt bepaald door het bestand /etc/fstab . Controleer of de opgegeven indeling juist is bij het uitvoeren van een reparatie.

Zodra u toegang hebt tot een interactieve shell, voert u de lsblk opdracht als volgt uit met de -f vlag om apparaten, paden (als het bestandssysteem is gekoppeld) en het bestandssysteemtype weer te geven dat van de schijf zelf wordt gelezen.

[root@localhost ~]# 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
  |-rootvg-varlv  xfs               c7cb68e9-7865-4187-b3bd-e9a869779d86   /var
  `-rootvg-rootlv xfs               d8dc4d62-ada5-4952-a0d9-1bce6cb6f809   /
sdb
`-sdb1            ext4              1dac7c4c-bf8e-4964-8a59-7359eef53d0a   /mnt
sdc               LVM2_member       CRWEZQ-iLhH-ev0b-BAaA-dfLD-nbPT-GgtG0r
`-vgapp-lvapp     xfs               733e25ee-565f-4bfa-a2a1-2451efd25cd1
sdd
`-sdd1            ext4              704d9fb1-2207-4bb9-998c-029f776dc6d2   /opt/data

Hier volgen enkele belangrijke punten in de uitvoer:

Door de ASCII-illustratieweergave te gebruiken, kunt u zien dat er LVM-volumes aanwezig zijn, omdat er een LVM2_MEMBER FSTYPE voor sda4 is met objecten met namen zoals rootvg-rootlv en rootvg-homelv.
rootvg-homelv is niet gekoppeld, wat wordt aangegeven door het lege veld MOUNTPOINT.
rootvg-homelv heeft bestandssysteemtype XFS. Dit is een contrast met de ext4-koppelingsfout tijdens het opstarten. Als het bestandssysteemtype inconsistent is, vertrouwt u de lsblk uitvoer in plaats van de inhoud van fstab.

Herstelmodus selecteren

U kunt een vm online herstellen via de modus voor noodgevallen of de modus voor één gebruiker of offline met behulp van een reddings-VM.

Vereisten voor online herstel

De seriële consoletoegang tot de VM.
Als de noodmodus wordt gebruikt, moet de seriële console een prompt voor de noodmodus weergeven, moet het hoofdaccount worden ontgrendeld en moet het wachtwoord bekend zijn.
Als de modus voor één gebruiker wordt gebruikt, is het hoofdwachtwoord niet nodig. De modus voor één gebruiker kan worden gebruikt wanneer een ander bestandssysteem dan vereiste systeempartities, zoals root (/) of /usr beschadigd is.

Vereisten voor offline herstel

Als niet kan worden voldaan aan de vereisten van de seriële console voor online herstel, voert u offlineherstel uit met behulp van een herstel-VM. Als u offline herstel wilt uitvoeren, is de mogelijkheid om een virtuele machine te maken en schijven te beheren in Azure vereist. U kunt ook een werkende Virtuele Linux-machine gebruiken met toegang op Azure-niveau tot de beschadigde schijven.

Omgeving voorbereiden voor online herstel

Wanneer de noodmodus als volgt wordt weergegeven in de aanmeldingsprompt, voert u het hoofdwachtwoord in:

Welcome to emergency mode! After logging in, type "journalctl -xb" to view
system logs, "systemctl reboot" to reboot, "systemctl default" or ^D to
try again to Give root password for maintenance
(or press Control-D to continue):

Als het hoofdwachtwoord niet bekend is of als het hoofdaccount is vergrendeld, zoals in de volgende uitvoer, gebruikt u de modus voor één gebruiker:

Welcome to emergency mode! After logging in, typ
Cannot open access to console, the root account is locked.
See sulogin(8) man page for more details.

Press Enter to continue.

Als de online herstelomgeving onbruikbaar is, gaat u verder met offlineherstel.

Omgeving voorbereiden voor offline herstel

In vm's met één schijf, of wanneer de mislukte koppeling een systeempartitie is, zoals het hoofdbestandssysteem (/) of /usr, is de meest betrouwbare methode om de schijf te herstellen door een herstel-VM te gebruiken om toegang te krijgen tot de schijf. U kunt automatisch of handmatig een reddings-VM maken.

Zie Azure Virtual Machine Repair voor het automatisch maken van een reddings-VM. Zie Een herstel-VM maken voor het handmatig maken van een herstel-VM. Koppel in beide gevallen de volumes niet vanaf de probleemschijf, omdat er geen bestandssysteem moet worden gekoppeld om reparatiehulpprogramma's te laten werken.

Bestandssysteemherstel uitvoeren

Voordat u het bestandssysteem herstelt, moet u ervoor zorgen dat de volgende stappen zijn voltooid:

Het probleem schijf en partitie, of LVM-volumestructuur, is geïdentificeerd.
Het bestandssysteemtype is bepaald.
(Optioneel) Een kopie van de probleemschijf, of schijven in een spanned LVM-volumegroep, is gekoppeld aan een herstel-VM.
De toegang tot een interactieve shell is beveiligd met toegang tot de schijf.

Als u het bestandssysteem wilt herstellen, gaat u naar Ext4-bestandssysteem herstellen of XFS-bestandssysteem herstellen op basis van het bestandssysteemtype.

Ongeacht welke herstelmodus wordt gebruikt, zijn de opdrachten voor het herstellen van het bestandssysteem hetzelfde. De noodshell kan beperkingen hebben. Als de opdrachten niet beschikbaar zijn in een noodmodusomgeving of als er fouten zijn over onbekende bestandstypen, bereidt u de omgeving voor op offlineherstel.

Met de opdrachten voor het herstellen van het bestandssysteem worden mogelijk niet alle fouten opgelost. Ze werken om schijfbeschadigingen te omzeilen, maar gegevensverlies kan nog steeds optreden. Zodra de uitvoer van de opdracht aangeeft dat het bestandssysteem schoon is, moet u de oorspronkelijke VM opnieuw koppelen aan de herstelde schijf en de VM opstarten om de gegevens te verifiëren.

In de volgende secties /dev/sdc1 bevindt het beschadigde bestandssysteem zich in de raw-modus en is de LV homelv in de VG rootvg het LVM-volume. Vervang deze waarden voor het werkelijke beschadigde bestandssysteem in alle exemplaren.

Ext4-bestandssysteem herstellen

Gebruik de fsck [-y] FILESYSTEM opdracht om een ext4-bestandssysteem te herstellen. Geef het bestandssysteem op als een schijfpartitie voor een onbewerkt bestandssysteem, bijvoorbeeld /dev/sdc1of het logische LVM-volumepad /dev/rootvg/homelv.

Hier volgt een voorbeeld van de uitvoer van de opdracht:

[root@vm1dev ~]# fsck /dev/sdc1
fsck from util-linux 2.23.2
e2fsck 1.42.9 (28-Dec-2013)
ext2fs_check_desc: Corrupt group descriptor: bad block for block bitmap
fsck.ext4: Group descriptors look bad... trying backup blocks...
/dev/sdc1 was not cleanly unmounted, check forced.
Resize inode not valid.  Recreate<y>? yes
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
Free blocks count wrong for group #0 (23508, counted=23509).
Fix<y>? yes
Free blocks count wrong (8211645, counted=8211646).
Fix<y>? yes

/dev/sdc1: ***** FILE SYSTEM WAS MODIFIED *****
/dev/sdc1: 11/2097152 files (0.0% non-contiguous), 176706/8388352 blocks
[root@vm1dev ~]#

De uitvoer laat zien dat de bevestiging voor het wijzigen van het bestandssysteem drie keer wordt aangevraagd. Als er veel aanvragen zijn, drukt u op Ctrl+C en start u deze opnieuw fsck op met de -y vlag om 'ja' aan te nemen op alle vragen. Als bestanden worden gerapporteerd als geplaatst in lost+found, identificeert u ze handmatig en plaatst u ze op de juiste locaties.

Als er fouten optreden en vervolgens worden opgelost, voert u de fsck opdracht opnieuw uit. Herhaal dit totdat de fsck opdracht wordt afgesloten met de clean status. Raadpleeg de volgende uitvoer als voorbeeld:

[root@vm1dev ~]# fsck /dev/sdc1
fsck from util-linux 2.23.2
e2fsck 1.42.9 (28-Dec-2013)
/dev/sdc1: clean, 11/2097152 files, 176706/8388352 blocks
[root@vm1dev ~]#

XFS-bestandssysteem herstellen

Hier volgen opdrachten voor het herstellen van een XFS-bestandssysteem:

xfs_repair [-n] FILESYSTEM
xfs_repair [-L] FILESYSTEM
mount FILESYSTEM MOUNTPOINT

Voer de volgende stappen uit om een XFS-bestandssysteem te herstellen:

Controleer bestandssysteemfouten met behulp van de xfs_repair -n opdracht als volgt:
```
xfs_repair -n /dev/rootvg/homelv
```
Als de controle slaagt, gaat u verder met de reparatiemodus door de -n vlag te verwijderen, die als volgt probeert eventuele fouten op te lossen:
```
xfs_repair /dev/rootvg/homelv
```

Voor XFS-bestandssystemen worden logboeken maar niet-doorgevoerde wijzigingen verwerkt door het bestandssysteem te koppelen. Als u tijdens de probleemoplossing de volgende fout tegenkomt, probeert u een koppeling en bekijkt u de resultaten.

FOUT: Het bestandssysteem bevat waardevolle metagegevenswijzigingen in een logboek die opnieuw moeten worden afgespeeld

Als een herstel-VM wordt gebruikt, maakt u een map voor een tijdelijk koppelpunt, zoals /recovery, en koppelt u het bestandssysteem. Als de herstelomgeving zich in de nood- of modus voor één gebruiker bevindt, koppelt u het bestandssysteem op de beoogde locatie. Raadpleeg de volgende opdrachten als voorbeelden:

mount /dev/rootvg/homelv /recovery

mount /home

Als de wijzigingen in het logboek niet worden geschreven wanneer u bestandssystemen koppelt, gebruikt u de -L vlag om het logboek te verwijderen en het bestandssysteem te koppelen alsof alle wijzigingen zijn voltooid. Wanneer de -L vlag wordt gebruikt, treedt gegevensverlies op omdat in het logboek wordt opgegeven dat onvolledige bestandsbewerkingen worden verwijderd.

xfs_repair -L /dev/rootvg/homelv /recovery

Opstartfout voorkomen

Als de nofail optie is opgegeven bij het koppelen van bestandssystemen, kan de beschadiging van een niet-kritiek bestandssysteem niet verhinderen dat Linux volledig wordt opgestart. Zie De schijf koppelen voor meer informatie overnofail. De meeste koppelingen naast de hoofdmap (/), /usr, en /var kunnen worden uitgevoerd met nofail.

Contacteer ons voor hulp

Als u vragen hebt of hulp nodig hebt, maak een ondersteuningsaanvraag of vraag de Azure-communityondersteuning. U kunt ook productfeedback verzenden naar de Feedback-community van Azure.

Delen via