ZimaOS-nödläge efter uppdatering: A/B-återställning och fstab-kontroller

Sammanfattning: Använd den alternativa ZimaOS-platsen först och diagnostisera sedan den exakta beroendeorsaken till nödläget

ZimaOS 1.3.2 hade ett känt kompatibilitetsproblem med vissa maskiner från tredje part i början av 2025. I detta Proxmox-fall kunde plats A fortfarande starta den äldre versionen, medan den uppdaterade platsen gick in i nödläge. Det är precis vad A/B-systemdesignen är avsedd att skydda mot.

ZimaOS-startskärm som går in i nödläge efter en uppdatering och får timeout på en beständig lagringsenhet — Det första startfelet visar att ZimaOS går in i nödläge efter en timeout för en lagringsenhet i stället för att nå kontrollpanelen.

Steg 1: Starta den föregående platsen från GRUB

Anslut till konsolen, öppna GRUB med piltangenterna och välj den alternativa systemplatsen. Aktuella ZimaOS använder fortfarande dubbla systempartitioner för snabb återställning. ZimaOS systemåterställning beskriver den aktuella processen.

RAUC:s RAUC-platsmodell tillhandahåller det underliggande platskonceptet.

Steg 2: Läs det första verkliga felet, inte den sista raden om nödläge

ZimaOS-startlogg som visar detaljer om kärn- och plattformsinitiering under felsökningen av 1.3.2-felet — Den andra diagnostikskärmbilden fångade detaljer om kärninitieringen medan Proxmox-gästen från tredje part inte kunde slutföra normal start.

Proxmox-konfiguration av virtuell maskinvara för ZimaOS-gästen, inklusive VirtIO SCSI-diskar och OVMF UEFI — Den virtuella maskinen använde OVMF UEFI, VirtIO-nätverk och flera SCSI-diskar, vilket är viktigt när felet jämförs med annan virtuell maskinvara från tredje part.

Proxmox VNC-vy som visar en timeout för dev md zimaos innan ZimaOS går in i nödläge — En senare skärmbild visade den exakta timeouten på /dev/md/zimaos innan beroendefel och nödläge uppstod.

Nödläget är konsekvensen. Titta ovanför det efter den första enheten som fick timeout, den misslyckade monteringen eller det saknade beroendet. I detta fall pekade skärmen på en lagringsenhet innan de senare beroendefelen visades.

journalctl -xb
systemctl --failed
lsblk -f
cat /etc/fstab

Steg 3: Kontrollera anpassade fstab-poster innan du installerar om

ZimaOS-terminal som visar anpassade poster i /etc/fstab och overlay upper_etc fstab under felsökning av starten — Den sista diagnostiska ledtråden var en ändrad fstab-sökväg; IceWhale rapporterade liknande startfel när anpassade monteringsposter stod i konflikt med apparatens startprocess.

En senare del av samma fall avslöjade en viktig ytterligare orsak: manuella ändringar i /etc/fstab kan blockera ZimaOS-starten när en refererad enhet saknas eller monteringsordningen står i konflikt med apparatens startprocess. IceWhale rapporterade ett liknande fel som omfattade både /etc/fstab och den beständiga overlay-kopian.

Om du manuellt har lagt till anpassade RAID- eller monteringsposter ska du jämföra dem med den aktuella lagringskonfigurationen och endast ta bort poster som du förstår. Använd helst ZimaOS lagringsgränssnitt för vanliga RAID- och diskmonteringar.

Varför det gamla drivrutinsfelet i 1.3.2 inte är ett aktuellt universellt problem

Utvecklingsteamet bekräftade kompatibilitetsproblem med maskinvara från tredje part i just den versionen. ZimaOS har släppt många versioner efter 1.3.2, så ”1.3.2 förstörde min Proxmox-virtuella maskin” bör betraktas som historiska belägg, inte som en diagnos för ett system från 2026.

ZimaOS installationsåterställning är den moderna utgångspunkten för x86-maskinvara från tredje part.

När en nyinstallation också går in i nödläge

Det är en stark indikation på att problemet är kopplat till virtuell maskinvara, anslutna datadiskar, beständigt monteringsläge eller en konfiguration av värdsystemet som inte stöds – inte bara till den gamla systempartitionen. Starta med den minsta nödvändiga virtuella maskinvaran och lägg sedan till datadiskar en i taget.

Skydda data innan du redigerar RAID- eller monteringsmetadata

Nollställ inte mdadm-signaturer och återskapa inte arrayer under felsökning av en startplats. RAID-återställning skiljer startåterställning från arrayåterställning, medan ZimaOS-säkerhetskopiering utgör säkerhetslagret.

Förstå vad GRUB kan och inte kan åtgärda

GRUB kan välja den föregående ZimaOS-systemplatsen, men reparerar inte en trasig datamontering eller en ogiltig filsystemspost. GNU GRUB-kontrollerna beskriver startladdarens lager. Om den föregående platsen startar ska du använda den fungerande miljön för att granska lagringskonfigurationen och säkerhetskopiera data innan du ändrar den felande platsen.

Vanliga frågor

Varför startar ZimaOS den gamla platsen men inte den nya?

Den gamla platsen innehåller fortfarande den tidigare fungerande systemavbildningen. Den nya platsen kan ha ett drivrutins-, monterings- eller konfigurationsproblem.

Betyder nödläge att mina data har gått förlorade?

Nej. Det betyder att beroenden för normal start misslyckades. Kontrollera lagrings- och monteringsläget innan du antar att filsystemet har gått förlorat.

Kan en felaktig fstab-post hindra ZimaOS från att starta?

Ja. En montering som inte kan genomföras kan blockera starten eller försätta systemet i nödläge.

Bör jag installera om omedelbart?

Nej. Prova först den alternativa A/B-platsen och dokumentera det första beroendet som misslyckades. Installera bara om när återställning inte är praktiskt genomförbar.

Stöds ZimaOS i Proxmox?

Virtualiserade installationer kan fungera, men virtuell maskinvara från tredje part kan medföra kompatibilitetsskillnader. Testa med den aktuella versionen och behåll en återställningsväg.