Mode d’urgence de ZimaOS après la mise à jour : récupération A/B et vérifications de fstab

En bref : utilisez d’abord l’autre emplacement ZimaOS, puis identifiez précisément la dépendance à l’origine du mode d’urgence

ZimaOS 1.3.2 présentait un problème de compatibilité connu avec certaines machines tierces au début de 2025. Dans ce cas sous Proxmox, l’emplacement A pouvait encore démarrer l’ancienne version, tandis que l’emplacement mis à jour passait en mode d’urgence. C’est précisément ce contre quoi l’architecture système A/B est conçue pour vous protéger.

Écran de démarrage de ZimaOS passant en mode d’urgence après une mise à jour et expirant lors de l’attente d’un périphérique de stockage persistant — Le premier échec de démarrage montre ZimaOS passer en mode d’urgence après l’expiration du délai d’attente d’un périphérique de stockage, au lieu d’atteindre le tableau de bord.

Étape 1 : démarrez depuis l’emplacement précédent avec GRUB

Connectez-vous à la console, affichez GRUB avec les touches fléchées et choisissez l’autre emplacement système. ZimaOS utilise toujours des partitions système doubles pour permettre une restauration rapide. La page Restauration du système ZimaOS explique la procédure actuelle.

Le modèle d’emplacements de RAUC fournit le concept sous-jacent.

Étape 2 : lisez la première véritable erreur, pas la dernière ligne du mode d’urgence

Journal de démarrage de ZimaOS affichant les détails de l’initialisation du noyau et de la plateforme pendant l’analyse de l’échec de la version 1.3.2 — La deuxième capture de diagnostic montre les détails de l’initialisation du noyau alors que l’invité Proxmox tiers ne parvenait pas à terminer son démarrage normal.

Configuration matérielle d’une machine virtuelle Proxmox pour l’invité ZimaOS, avec des disques VirtIO SCSI et l’UEFI OVMF — La machine virtuelle utilisait l’UEFI OVMF, le réseau VirtIO et plusieurs disques SCSI, des éléments importants pour comparer cet échec à celui d’autres matériels virtuels tiers.

Vue VNC de Proxmox mettant en évidence l’expiration du délai d’attente pour dev md zimaos avant le passage de ZimaOS en mode d’urgence — Une capture ultérieure a mis en évidence l’expiration exacte du délai d’attente sur /dev/md/zimaos, avant l’apparition des échecs de dépendances et du mode d’urgence.

Le mode d’urgence est une conséquence. Regardez les lignes précédentes pour trouver le premier périphérique dont le délai d’attente a expiré, le montage échoué ou la dépendance manquante. Dans ce cas, l’écran indiquait un périphérique de stockage avant l’apparition des échecs de dépendances ultérieurs.

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

Étape 3 : vérifiez les entrées personnalisées de fstab avant de réinstaller

Terminal ZimaOS affichant des entrées personnalisées dans /etc/fstab et le fichier fstab de la couche supérieure overlay pendant le dépannage du démarrage — Le dernier indice de diagnostic était un chemin fstab modifié ; IceWhale a signalé des échecs de démarrage similaires lorsque des entrées de montage personnalisées entraient en conflit avec le processus de démarrage de l’appareil.

Une branche ultérieure du même cas a révélé une deuxième cause importante : des modifications manuelles de /etc/fstab peuvent empêcher ZimaOS de démarrer lorsqu’un périphérique référencé est absent ou que l’ordre des montages entre en conflit avec le processus de démarrage de l’appareil. IceWhale a signalé un échec similaire impliquant à la fois /etc/fstab et la copie persistante de la couche overlay.

Si vous avez ajouté manuellement des entrées RAID ou de montage, comparez-les à la configuration de stockage actuelle et supprimez uniquement les entrées que vous comprenez. Pour les montages RAID et de disques courants, privilégiez l’interface Stockage de ZimaOS.

Pourquoi l’ancien bogue de pilote de la version 1.3.2 n’est pas un problème universel actuel

L’équipe d’ingénierie a reconnu des problèmes de compatibilité avec des systèmes tiers dans cette version précise. ZimaOS a publié de nombreuses versions depuis la 1.3.2 ; « 1.3.2 a fait tomber ma machine virtuelle Proxmox » doit donc être considéré comme un élément historique, et non comme un diagnostic pour un système de 2026.

La page Restauration de l’installation de ZimaOS constitue la référence moderne pour le matériel x86 tiers.

Lorsqu’une nouvelle installation passe également en mode d’urgence

C’est un indice fort que le problème est lié au matériel virtuel, aux disques de données connectés, à l’état des montages persistants ou à une configuration de l’hôte non prise en charge, et pas seulement à l’ancienne partition système. Démarrez avec le matériel virtuel minimal nécessaire, puis ajoutez les disques de données un par un.

Protégez vos données avant de modifier les métadonnées RAID ou de montage

Ne supprimez pas les signatures mdadm et ne recréez pas les ensembles RAID pendant le dépannage d’un emplacement de démarrage. La page Restauration RAID sépare la restauration du démarrage de celle de l’ensemble RAID, tandis que la page Sauvegarde ZimaOS couvre la protection des données.

Sachez ce que GRUB peut et ne peut pas corriger

GRUB peut sélectionner l’emplacement système ZimaOS précédent, mais il ne répare pas un montage de données défectueux ni une entrée de système de fichiers invalide. La page Commandes GNU GRUB explique la couche du chargeur de démarrage. Si l’emplacement précédent démarre, utilisez cet environnement fonctionnel pour examiner la configuration du stockage et sauvegarder vos données avant de modifier l’emplacement défaillant.

FAQ

Pourquoi ZimaOS démarre-t-il depuis l’ancien emplacement, mais pas depuis le nouveau ?

L’ancien emplacement contient encore l’image système précédente qui fonctionnait. Le nouvel emplacement peut présenter un problème de pilote, de montage ou de configuration.

Le mode d’urgence signifie-t-il que mes données sont perdues ?

Non. Cela signifie que les dépendances nécessaires au démarrage normal n’ont pas été satisfaites. Vérifiez l’état du stockage et des montages avant de supposer une perte du système de fichiers.

Une mauvaise entrée fstab peut-elle empêcher ZimaOS de démarrer ?

Oui. Un montage impossible à satisfaire peut bloquer le démarrage ou faire passer le système en mode d’urgence.

Dois-je réinstaller immédiatement ?

Non. Essayez d’abord l’autre emplacement A/B et relevez la première dépendance en échec. Ne réinstallez que lorsque la restauration n’est pas réalisable.

ZimaOS est-il pris en charge dans Proxmox ?

Les déploiements virtualisés peuvent fonctionner, mais le matériel virtuel tiers peut révéler des différences de compatibilité. Testez la version actuelle et conservez une solution de restauration.