Als beide ZimaOS-Startslots uitvallen en de console fouten bij het koppelen van overlays, mislukte superblock-lezingen of NVMe-I/O-fouten meldt, begin dan niet met het opnieuw opbouwen van de opslagpool. Bepaal eerst of het probleem bij het opstartapparaat of bij de afzonderlijke gegevensschijven ligt.
In deze casus uit juni 2026 lieten diagnostische controles in alleen-lezenmodus herhaalde mediumfouten op de opstart-NVMe zien, terwijl de grote Btrfs-gegevenspool zich op afzonderlijke schijven bevond. De gebruiker verving de opstartschijf, installeerde ZimaOS opnieuw en bevestigde later dat de gegevenspool nog steeds aanwezig was.
Scheid eerst het opstartapparaat van de gegevenspool
De uitvoer van de rescue-shell in de thread liet een NVMe van ongeveer 119 GB zien met ZimaOS-opstart-/gegevenspartities en een afzonderlijke Btrfs-pool met meerdere schijven. Dat onderscheid veranderde het herstelplan: een defecte opstart-NVMe betekende niet automatisch dat de opslagpool defect was.
Begin met opdrachten in alleen-lezenmodus:
lsblk -o NAME,SIZE,FSTYPE,LABEL,UUID,MOUNTPOINTS
blkid
cat /proc/cmdlineNoteer de exacte apparaatnamen voordat je een opdracht uitvoert die op een schijf of partitie is gericht.
Controleer de kernellogboeken op echte I/O-fouten
De broncasus bevatte herhaalde meldingen van critical medium error, Buffer I/O error, EXT4-koppelfouten en NVMe-fouten met betrekking tot het opstartapparaat. Die meldingen vormen veel sterker bewijs van opslagproblemen dan een algemene panic op het opstartscherm.
dmesg -T | grep -Ei 'nvme|I/O error|Buffer I/O|EXT4|superblock|reset|timeout|critical|media'Als de fouten consequent naar de opstart-NVMe verwijzen en de gegevensschijven geen problemen melden, richt je onderzoek dan op het opstartpad.
Een SMART-resultaat met “PASSED” sluit mediumfouten niet uit
In de thread gaf het SMART-overzicht van de NVMe nog steeds PASSED aan, terwijl de gedetailleerde tellers 76 medium-/gegevensintegriteitsfouten lieten zien en de kernel al mislukte leesbewerkingen registreerde. Ook de controle van het bestandssysteem in alleen-lezenmodus werd afgebroken vanwege onleesbare blokken.
Gebruik gedetailleerde gezondheidsgegevens, zoals smartctl -x /dev/nvmeXn1 of nvme smart-log /dev/nvmeXn1, nadat je de juiste apparaatnaam hebt gecontroleerd. Beschouw het ene algemene gezondheidswoord niet als de volledige diagnose.
Gebruik eerst controles van het bestandssysteem in alleen-lezenmodus
De community gebruikte e2fsck -fn op de getroffen EXT4-overlaypartitie, zodat het bestandssysteem kon worden gecontroleerd zonder herstelbewerkingen te schrijven. Zelfs die controle in alleen-lezenmodus stuitte op onleesbare blokken, wat de diagnose van hardwarefalen verder ondersteunde.
Voer nooit fsck in schrijfmodus uit op een gekoppeld bestandssysteem en gok niet naar partitienamen. Als de opstart-SSD fysiek defect raakt, kunnen herhaalde schrijfpogingen herstel moeilijker maken.
Waarom zowel slot A als slot B kunnen uitvallen
ZimaOS gebruikt A/B-systeemslots voor herstel, zoals beschreven in de handleiding voor ZimaOS-systeemherstel. Beide opstartkeuzes zijn echter nog steeds afhankelijk van gezonde gedeelde opslagcomponenten op het opstartapparaat. Een defecte overlay of opstart-NVMe kan er daardoor voor zorgen dat beide slots het opstarten niet voltooien.
Wanneer vervangen de veiligere optie is
Nadat in de broncasus kernel-mediumfouten, gedetailleerde SMART-tellers voor mediumfouten en onleesbare bestandssysteemblokken op de opstart-NVMe waren vastgesteld, adviseerde de community om die SSD als onbetrouwbaar te beschouwen in plaats van te proberen deze ter plaatse te repareren. De gebruiker verving de SSD en installeerde ZimaOS succesvol opnieuw.
Houd tijdens de herinstallatie de gegevensschijven duidelijk geïdentificeerd en voorkom dat je een bestaande pool initialiseert of opnieuw aanmaakt. De probleemoplossingsgids voor ZimaOS-installatie helpt bij het installeren van het opstartsysteem, terwijl de gids voor opslagherstel na herinstallatie de belangrijkste regel benadrukt: maak een pool die al gegevens bevat niet opnieuw aan.
Samenvatting
In deze casus werd de kernel panic veroorzaakt door een defecte opstart-NVMe, niet door bewijs dat de afzonderlijke gegevenspool was vernietigd. Voer diagnostiek uit in alleen-lezenmodus, bevestig welk apparaat de I/O-fouten veroorzaakt en laat de gegevensschijven ongemoeid. De oorspronkelijke gebruiker verving de defecte opstartschijf, installeerde ZimaOS opnieuw en bevestigde dat de bestaande gegevenspool behouden was gebleven.
