Felsöka problem med att det inte går att starta virtuella Linux-datorer på grund av filsystemfel
Gäller för: ✔️ Virtuella Linux-datorer
Den här artikeln innehåller vägledning för att felsöka startproblem med virtuella Linux-datorer som orsakas av filsystemfel.
Symptom
Du kan inte ansluta till en virtuell Azure Linux-dator (VM) med hjälp av Secure Shell Protocol (SSH) eller vm-agentstatusen i Azure Portal är inte klar. När du kör startdiagnostiken i Azure Portal eller ansluter till seriekonsolen visas loggposter som liknar följande exempel:
Kommentar
- Alla exempel kommer inte att finnas.
- Monteringsfel leder inte alltid till att en virtuell dator går in i nödläge. Om problemet gäller vissa kritiska filsystem kanske den virtuella datorn inte använder nödläge.
Exempel 1: Det går inte att montera ext4-filsystemet
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.
Exempel 2: Det gick inte att montera en LVM-enhet (Logical Volume Manager)
[ 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.
Exempel 3: Det gick inte att montera xfs-filsystemet
[ 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.
Exempel 4: Starta i nödläge
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):
Orsak
Loggposterna ovan anger att disken är skadad. I vissa situationer förhindrar diskskada den virtuella datorn från att starta helt. Olika problem kan orsaka diskskada, till exempel problem med Linux-kerneln, drivrutinsfel, fel i den underliggande fysiska eller virtuella maskinvaran och så vidare.
Åtgärd
Du kan lösa problem med start av virtuella Linux-datorer som orsakas av filsystemfel genom att återställa den virtuella datorn genom att reparera diskskadan. Följ dessa steg för att reparera diskskadan:
Förbered återställningsmiljön enligt det återställningsläge som du väljer:
Använd kommandoradsverktyg för att reparera det problematiska filsystemet på disken.
Kommentar
- Det är viktigt att säkerhetskopiera kritiska data eftersom dataförlust kan uppstå på den återställda disken.
- Innan du gör ändringar i en disk ska du ta en ögonblicksbild för att bevara diskens aktuella tillstånd, även om den är i ett feltillstånd. Om disken skadas ändras data på disken, vilket medför risker.
Identifiera vilken disk som är skadad
För att avgöra vilken disk som är skadad laddar du ned serieloggen för den virtuella datorn med hjälp av diagnostiken för seriekonsolen eller start, undersöker loggposterna under starten och letar sedan efter det specifika felet som anger vilken disk eller montering som misslyckas.
Här är tre exempel på loggposter. I de här exemplen noterar du texten inom parentes, som rapporterar den skadade enheten.
I följande exempel är sdc1den skadade enheten :
[ 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.
I följande exempel är sda1partitionen där ett filsystemfel inträffar :
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.
I följande exempel är dm-2den skadade enheten . Det är en Linux Device Mapper-enhet som anger en LVM-volym.
[ 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.
Om diskenheten som anropas använder ett namn på formatet "sdXN" där X är en bokstav från a-z och N är ett valfritt partitionsnummer, innebär det att disken är rå och kan användas med hjälp av sökvägen /dev/sdXN .
Om diskenheten som monteras använder ett namn som /dev/mapper/vgname/lvname, /dev/vgname/lvname eller dm-N innebär det att en LVM-enhet används. Var noga med att känna igen alla fysiska diskvolymer (PV:er) som kan användas.
Det stöds inte för att LVM-volymgruppen (VG) ska innehålla OS-disken och valfritt antal datadiskar. I ett sådant scenario finns det en hög risk för dataförlust. Flera datadiskar är dock tillåtna i en LVM VG.
När du fastställer mappningen av OS-diskreferenser till Azure-diskobjekt:
- För Marketplace-avbildningar finns rotfilsystemet (/), /boot och /boot/efi på OS-disken.
- För LVM-baserade avbildningar kan det finnas många andra systemmonteringar, till exempel /home, /tmp, /usr, /var, /var/log och /opt.
- Extra filsystem som skapats för program finns på datadiskar, till exempel /data, /datadisk eller /sap. Konfigurera dem korrekt så att systemet kan starta även om det uppstår ett fel. Om en datadisk är en enhet som startas i nödläge kan du läsa förhindra startfel.
Identifiera filsystemtyp
När du gör den första identifieringen använder den enda metoden för att fastställa disktypen serieloggen som tidigare undersöktes i Identifiera vilken disk som är skadad. När diskenheten rapporteras i serieloggen visas fel från Linux-kernelmodulen för filsystemet. Observera varje rad där EXT4-fs eller XFS anges. För andra filsystemtyper finns loggen i samma område. Filsystemet som anges i loggposterna bestäms av /etc/fstab-filen . Kontrollera att det angivna formatet är korrekt när du utför en reparation.
När du har åtkomst till ett interaktivt gränssnitt kör lsblk du kommandot med -f flaggan enligt följande för att visa enheter, sökvägar (om filsystemet är monterat) och filsystemtypen som läss från själva disken.
[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
Här är några viktiga punkter i utdata:
- Med hjälp av ASCII-konstvisningen kan du se att det finns LVM-volymer eftersom det finns en LVM2_MEMBER FSTYPE för sda4 som innehåller objekt med namn som
rootvg-rootlvochrootvg-homelv. rootvg-homelvär inte monterad, vilket anges av det tomma MOUNTPOINT-fältet.rootvg-homelvhar filsystemtypen XFS. Det är en kontrast till EXT4-monteringsfelet vid start. Om filsystemtypen är inkonsekvent litar du pålsblkutdata i stället för innehållet i fstab.
Välj återställningsläge
Du kan återställa en virtuell dator online via nödläge eller enanvändarläge eller offline med hjälp av en virtuell räddningsdator.
Krav för onlineåterställning
Om nödläge används måste seriekonsolen visa en uppmaning om nödläge, rotkontot måste låsas upp och lösenordet måste vara känt.
Om enanvändarläge används behövs inte rotlösenordet. Enanvändarläget kan användas när ett annat filsystem än nödvändiga systempartitioner som rot (
/) eller/usrär skadat.
Krav för offlineåterställning
Om seriekonsolens krav för onlineåterställning inte kan uppfyllas utför du offlineåterställning med hjälp av en virtuell räddningsdator. För att utföra offlineåterställning krävs möjligheten att skapa en virtuell dator och hantera diskar i Azure. Du kan också använda en fungerande virtuell Linux-dator med åtkomst på Azure-nivå till de skadade diskarna.
Förbereda miljön för onlineåterställning
När nödläget visas i inloggningsprompten på följande sätt anger du rotlösenordet:
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):
Om rotlösenordet inte är känt eller om rotkontot är låst, som i följande utdata, använder du läget för en användare:
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.
Om onlineåterställningsmiljön är oanvändbar fortsätter du till offlineåterställning.
Förbereda miljön för offlineåterställning
I virtuella datorer med en enda disk, eller när den misslyckade monteringen är en systempartition, till exempel rotfilsystemet (/) eller /usr, är den mest tillförlitliga metoden för att reparera disken genom att använda en virtuell räddningsdator för att få åtkomst till disken. Du kan skapa en virtuell räddningsdator automatiskt eller manuellt.
Information om hur du automatiskt skapar en virtuell räddningsdator finns i Reparation av virtuella Azure-datorer. Information om hur du manuellt skapar en virtuell räddningsdator finns i Skapa en virtuell återställningsdator. Montera inte volymerna från problemdisken i båda fallen eftersom ett filsystem inte får monteras för att reparationsverktygen ska fungera.
Utföra filsystemsreparation
Kontrollera att följande steg har slutförts innan du reparerar filsystemet:
- Problemdisken och partitionen, eller LVM-volymstrukturen, har identifierats.
- Filsystemtypen har fastställts.
- (Valfritt) En kopia av problemdisken eller diskarna i en LVM-volymgrupp har kopplats till en virtuell räddningsdator.
- Åtkomst till ett interaktivt gränssnitt har skyddats med hjälp av åtkomst till disken.
Om du vill utföra filsystemreparationen går du till Reparera ext4-filsystem eller Reparera XFS-filsystem enligt filsystemtypen.
Oavsett vilket återställningsläge som används är kommandona för att utföra filsystemreparationen desamma. Nödgränssnittet kan ha begränsningar. Om kommandona inte är tillgängliga i en nödsituationslägesmiljö, eller om det finns fel om okända filsystemtyper, förbereder du miljön för offlineåterställning.
Kommandona för att reparera filsystemet kanske inte åtgärdar alla fel. De kringgår diskfel, men dataförlust kan fortfarande inträffa. När kommandots utdata anger att filsystemet är rent sätter du ihop den ursprungliga virtuella datorn igen med den reparerade disken och startar den virtuella datorn för att verifiera data.
I följande avsnitt /dev/sdc1 är det skadade filsystemet i raw-läge, och LV homelv i VG rootvg är LVM-volymen. Ersätt dessa värden med det faktiska skadade filsystemet i alla instanser.
Reparera ext4-filsystem
fsck [-y] FILESYSTEM Använd kommandot för att reparera ett ext4-filsystem. Ange filsystemet som en diskpartition för ett raw-filsystem, till exempel /dev/sdc1, eller den logiska LVM-volymsökvägen /dev/rootvg/homelv.
Här är ett exempel på kommandoutdata:
[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 ~]#
Utdata visar att bekräftelsen för att ändra filsystemet begärs tre gånger. Om det finns många begäranden trycker du på CTRL +C och startar om fsck med -y flaggan för att anta "ja" på alla frågor. Om några filer rapporteras vara placerade i lost+foundidentifierar du dem manuellt och placerar dem på rätt platser.
Om vissa fel inträffar och sedan åtgärdas kör du fsck kommandot igen. Upprepa tills fsck kommandot avslutas med statusen clean . Se följande utdata som ett exempel:
[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 ~]#
Reparera xfs-filsystem
Här är kommandon för att reparera ett XFS-filsystem:
xfs_repair [-n] FILESYSTEMxfs_repair [-L] FILESYSTEMmount FILESYSTEM MOUNTPOINT
Följ dessa steg för att reparera ett XFS-filsystem:
Kontrollera filsystemfel med
xfs_repair -nhjälp av kommandot på följande sätt:xfs_repair -n /dev/rootvg/homelvOm kontrollen lyckas fortsätter du med reparationsläget genom att ta bort
-nflaggan, som försöker åtgärda eventuella påträffade fel enligt följande:xfs_repair /dev/rootvg/homelv
För XFS-filsystem hanteras journalförda men ej inkompatibla ändringar genom montering av filsystemet. Om du stöter på följande fel under felsökningen kan du försöka montera och visa resultatet.
FEL: Filsystemet har värdefulla metadataändringar i en logg som måste spelas upp igen
Om en virtuell återställningsdator används skapar du en katalog för en tillfällig monteringspunkt, till exempel /recovery, och monterar filsystemet. Om återställningsmiljön är i nödläge eller i enanvändarläge monterar du filsystemet på den avsedda platsen. Se följande kommandon som exempel:
mount /dev/rootvg/homelv /recovery
eller
mount /home
Om de journalförda ändringarna inte skrivs när du monterar filsystem använder -L du flaggan för att ta bort journalen och montera filsystemet som om alla ändringar har slutförts. -L När flaggan används uppstår dataförlust eftersom loggen visar att ofullständiga filåtgärder ignoreras.
xfs_repair -L /dev/rootvg/homelv /recovery
Förhindra startfel
Om alternativet nofail anges vid montering av filsystem kan det hända att skada ett icke-kritiskt filsystem inte hindrar Linux från att starta helt. Mer information om nofailfinns i Montera disken. De flesta monteringar förutom roten (/), /usr, och /var kan göras med nofail.
Kontakta oss för att få hjälp
Om du har frågor eller behöver hjälp skapar du en supportförfrågan eller frågar Azure community support. Du kan också skicka produktfeedback till Azure-feedbackcommunityn.