Récupération d’un boot pool ZFS : remettre un système en service après une mauvaise mise à jour

Un modèle mental utile : ce que signifie vraiment « boot pool »

Les systèmes ZFS qui « bootent depuis ZFS » ont souvent deux personnalités de stockage distinctes :
un petit boot pool (souvent bpool) contenant le noyau, l’initramfs et les éléments lisibles par le bootloader ; et un root pool
(souvent rpool) contenant tout le reste. Certaines plateformes sautent la séparation et bootent directement depuis le root pool.
Certaines plateformes utilisent UEFI et stockent les artefacts EFI dans une ESP FAT, pas du tout dans ZFS. Il faut identifier dans quel univers vous vous trouvez.

Une mauvaise mise à jour peut casser le démarrage de plusieurs façons :

• Le chargeur de démarrage ne trouve pas sa configuration ou ne peut pas lire ZFS.
• Le noyau démarre mais l’initramfs ne peut pas importer le root pool.
• Les modules ZFS ne correspondent pas au noyau.
• Des fonctionnalités ZFS ont été activées sur une machine et maintenant un environnement plus ancien ne peut pas importer.
• Un membre miroir est mort et le firmware/ordre de boot choisit le mauvais disque.

Votre travail n’est pas de « réparer ZFS ». Votre travail est de répondre rapidement à une seule question :
à quel endroit de la chaîne de démarrage cela échoue-t-il ? Stade du chargeur, stade noyau, stade initramfs ou stade espace utilisateur.
Outils différents ; corrections différentes.

Voici la chaîne en termes simples :
firmware → chargeur de démarrage (GRUB/systemd-boot) → noyau + initramfs → import ZFS → montage du root → switch_root → services.
Quand vous traitez cela comme une chaîne, vous arrêtez de réinstaller GRUB au hasard comme s’il s’agissait d’eau bénite.

Blague n°1 : GRUB n’est pas malveillant ; c’est juste un enthousiaste des messages d’erreur interprétatifs.

Playbook de diagnostic rapide (vérifiez ceci en premier)

Première étape : identifier le stade de l’échec

• Bloqué avant le menu GRUB : firmware/ESP/ordre de démarrage, ou chargeur absent.
• Le menu GRUB apparaît, la sélection du noyau fonctionne, puis on tombe sur un shell initramfs : import ZFS ou problème d’initramfs/modules.
• Le noyau démarre, puis panic : souvent dataset root manquant, mauvais root=, ou module ZFS incompatible.
• Démarre en single-user/emergency : le pool est importé mais les points de montage/datasets/services ou les clés de chiffrement échouent.

Deuxième étape : ne rien modifier tant que vous n’avez pas lu les pools

• Démarrez un environnement live qui possède des outils ZFS correspondant (ou proches) à la version sur disque.
• Importez les pools en lecture seule d’abord. S’il s’importe, vous avez des options. S’il ne s’importe pas, vous devez comprendre pourquoi.

Troisième étape : décidez de votre stratégie de récupération

• Revenir à un environnement de démarrage/snapshot connu bon si vous en disposez. C’est le plus rapide.
• Réparer le chargeur de démarrage si l’OS est intact mais l’entrée de démarrage est cassée.
• Reconstruire l’initramfs si les modules ZFS ne sont pas disponibles tôt dans le démarrage.
• Corriger la santé du pool (miroir dégradé, mauvais disque de démarrage) si la machine boot depuis le membre « incorrect ».

Quatrième étape : préserver les preuves

Récupérez les derniers journaux de démarrage du système en échec (si accessible) et les versions exactes du noyau + des paquets ZFS.
Sur les systèmes avec plusieurs environnements de démarrage, enregistrez lequel a été sélectionné. La récupération est plus facile quand vous pouvez prouver ce qui a changé.

Faits et contexte intéressants (parce que l’histoire mord)

1. ZFS a été conçu avec l’intégrité de bout en bout comme caractéristique essentielle, ce qui explique pourquoi la « corruption silencieuse » est prise très au sérieux par la pile.
2. La séparation du « boot pool » est largement une contrainte du chargeur : historiquement GRUB supportait peu de fonctionnalités ZFS, donc garder /boot simple réduisait les problèmes.
3. Les flags de fonctionnalités ont été introduits pour éviter l’enfermement par numéro de version. Idée excellente — jusqu’à ce que vous activiez une fonctionnalité et tentiez d’importer sur une image de secours plus ancienne.
4. Illumos et BSD ont longtemps traité ZFS comme un citoyen natif, tandis que Linux le traite souvent comme un module externe ; cette différence compte lors des mises à jour d’initramfs et du noyau.
5. Le fichier « zpool.cache » est devenu une dépendance silencieuse pour de nombreux flux de démarrage ; s’il est obsolète ou manquant, les imports peuvent devenir de véritables chasses au trésor.
6. UEFI a changé les modes d’échec du chargeur : vous pouvez avoir un pool ZFS parfait et échouer parce que l’entrée de la partition système EFI a disparu.
7. Les environnements de démarrage ont popularisé les workflows « upgrade sans peur » dans l’écosystème Solaris/illumos ; les utilisateurs Linux redécouvrent la commodité via snapshots et clonage de datasets.
8. Le projet ZFS on Linux a fusionné dans OpenZFS, ce qui a réduit la fragmentation mais n’a pas éliminé le problème de coordination « noyau vs module ».

Une citation qui devrait figurer sur tous les murs d’astreinte :
« L’espoir n’est pas une stratégie. » — Général Gordon R. Sullivan

Tâches pratiques de récupération (commandes, sorties, décisions)

Hypothèses : vous avez démarré un ISO live ou un environnement de secours qui inclut les outils ZFS (zpool, zfs) et les utilitaires disque de base.
Remplacez les noms de pools/datasets si nécessaire. Les commandes ci-dessous sont conçues pour être exécutables et produire des preuves utiles.

Tâche 1 : Identifier les disques, partitions et ce qui a changé

cr0x@server:~$ lsblk -o NAME,SIZE,TYPE,FSTYPE,PARTTYPE,PARTLABEL,MOUNTPOINTS
NAME        SIZE TYPE FSTYPE PARTTYPE                             PARTLABEL MOUNTPOINTS
nvme0n1   476.9G disk
├─nvme0n1p1   1G part vfat   c12a7328-f81f-11d2-ba4b-00a0c93ec93b EFI
├─nvme0n1p2   4G part zfs_member
└─nvme0n1p3 471G part zfs_member
nvme1n1   476.9G disk
├─nvme1n1p1   1G part vfat   c12a7328-f81f-11d2-ba4b-00a0c93ec93b EFI
├─nvme1n1p2   4G part zfs_member
└─nvme1n1p3 471G part zfs_member

Ce que cela signifie : vous voyez si vous avez une ESP (vfat) plus des membres ZFS, et si des miroirs existent.
Décision : si l’ESP existe, vous devez considérer les entrées de démarrage UEFI. Si pas d’ESP et que vous êtes en BIOS, GRUB vit probablement dans la zone MBR.

Tâche 2 : Vérifier si les pools sont visibles et pourquoi ils pourraient ne pas s’importer

cr0x@server:~$ sudo zpool import
   pool: bpool
     id: 1234567890123456789
  state: ONLINE
 action: The pool can be imported using its name or numeric identifier.
 config:

        bpool        ONLINE
          nvme0n1p2  ONLINE
          nvme1n1p2  ONLINE

   pool: rpool
     id: 9876543210987654321
  state: ONLINE
 action: The pool can be imported using its name or numeric identifier.
 config:

        rpool        ONLINE
          mirror-0   ONLINE
            nvme0n1p3  ONLINE
            nvme1n1p3  ONLINE

Ce que cela signifie : l’environnement live peut voir les deux pools ; bon signe. Si vous voyez plutôt « cannot import » avec des feature flags,
votre image de secours OpenZFS est probablement trop ancienne.
Décision : si les pools apparaissent, importez en lecture seule d’abord. Sinon, mettez à jour l’environnement de secours ou utilisez un ISO de distribution correspondant.

Tâche 3 : Importer les pools en lecture seule et sans montage (inspection sans risque)

cr0x@server:~$ sudo zpool import -N -o readonly=on rpool
cr0x@server:~$ sudo zpool import -N -o readonly=on bpool

Ce que cela signifie : les pools sont importés mais les datasets ne sont pas montés ; vous réduisez les écritures accidentelles.
Décision : si l’import échoue avec « pool is busy », quelque chose s’est auto-importé ; vérifiez zpool status et exportez/réimportez volontairement.

Tâche 4 : Confirmer la santé du pool et repérer les scénarios « boot sur le mauvais disque »

cr0x@server:~$ sudo zpool status -v rpool
  pool: rpool
 state: ONLINE
  scan: scrub repaired 0B in 00:10:12 with 0 errors on Tue Dec 24 03:10:12 2025
config:

        NAME           STATE     READ WRITE CKSUM
        rpool          ONLINE       0     0     0
          mirror-0     ONLINE       0     0     0
            nvme0n1p3  ONLINE       0     0     0
            nvme1n1p3  ONLINE       0     0     0

errors: No known data errors

Ce que cela signifie : le root pool est sain. Si vous voyez DEGRADED ou un device UNAVAIL,
le démarrage peut tenter le chemin mort.
Décision : si miroir, assurez-vous que les artefacts de boot/EFI existent sur les deux disques, pas seulement sur le « primaire ».

Tâche 5 : Lister les datasets et trouver ceux critiques pour le démarrage

cr0x@server:~$ sudo zfs list -o name,mountpoint,canmount,readonly -r rpool | head -n 12
NAME                         MOUNTPOINT  CANMOUNT  READONLY
rpool                        none        off       on
rpool/ROOT                    none        off       on
rpool/ROOT/ubuntu_1           /           noauto    on
rpool/home                    /home       on        on
rpool/var                     /var        on        on
rpool/var/log                 /var/log    on        on

Ce que cela signifie : vous pouvez voir le dataset root (souvent sous rpool/ROOT/*) et s’il est configuré pour monter.
Décision : identifiez l’environnement de démarrage prévu. S’il y en a plusieurs, vous pouvez revenir en arrière en sélectionnant un autre.

Tâche 6 : Identifier l’environnement de démarrage actif (ou celui qui devrait l’être)

cr0x@server:~$ sudo zpool get -H bootfs rpool
rpool  bootfs  rpool/ROOT/ubuntu_1  local

Ce que cela signifie : bootfs pointe vers le dataset qui devrait être monté en tant que /.
Décision : si bootfs est incorrect ou pointe vers un dataset manquant, définissez-le sur un valide et reconstruisez les artefacts de boot.

Tâche 7 : Monter le système de façon contrôlée (pour réparation)

cr0x@server:~$ sudo mkdir -p /mnt
cr0x@server:~$ sudo zfs set readonly=off rpool/ROOT/ubuntu_1
cr0x@server:~$ sudo zfs mount rpool/ROOT/ubuntu_1
cr0x@server:~$ sudo mount --rbind /dev /mnt/dev
cr0x@server:~$ sudo mount --rbind /proc /mnt/proc
cr0x@server:~$ sudo mount --rbind /sys /mnt/sys
cr0x@server:~$ mount | head -n 5
rpool/ROOT/ubuntu_1 on / type zfs (rw,relatime,xattr,noacl)
udev on /mnt/dev type devtmpfs (rw,nosuid,relatime,size=16343656k,nr_inodes=4085914,mode=755)
proc on /mnt/proc type proc (rw,nosuid,nodev,noexec,relatime)
sysfs on /mnt/sys type sysfs (rw,nosuid,nodev,noexec,relatime)

Ce que cela signifie : vous avez monté le root et lié les pseudo-systèmes de fichiers du noyau pour que les réparations via chroot fonctionnent.
Décision : si le dataset root monte mais que des chemins clés sont vides, vous avez peut-être monté le mauvais dataset (fréquent avec plusieurs environnements de démarrage).

Tâche 8 : Vérifier l’alignement noyau et module ZFS (échec classique après une mise à jour)

cr0x@server:~$ sudo chroot /mnt /bin/bash -lc 'uname -r; dpkg -l | egrep "zfs|linux-image" | head'
5.15.0-92-generic
ii  linux-image-5.15.0-92-generic   5.15.0-92.102  amd64  Signed kernel image generic
ii  zfsutils-linux                  2.1.5-1ubuntu6 amd64  command-line tools to manage ZFS filesystems
ii  zfs-dkms                        2.1.5-1ubuntu6 amd64  OpenZFS kernel modules for Linux

Ce que cela signifie : vous confirmez quel noyau est attendu et si DKMS ZFS est installé.
Décision : si le noyau a été mis à jour mais que les modules ZFS n’ont pas été construits (ou ont été supprimés), l’initramfs ne pourra pas importer le pool. Reconstruisez les modules/ l’initramfs.

Tâche 9 : Reconstruire l’initramfs et s’assurer que les hooks ZFS sont présents

cr0x@server:~$ sudo chroot /mnt /bin/bash -lc 'update-initramfs -u -k all'
update-initramfs: Generating /boot/initrd.img-5.15.0-92-generic
W: Possible missing firmware /lib/firmware/i915/tgl_dmc_ver2_12.bin for module i915

Ce que cela signifie : la génération de l’initramfs a réussi ; un avertissement sur un firmware manquant est généralement sans rapport avec le boot ZFS.
Décision : si vous voyez des erreurs au sujet des hooks zfs ou du manque de zpool, corrigez l’état des paquets (installez zfs-initramfs quand applicable).

Tâche 10 : Vérifier que la ligne de commande du noyau pointe vers le bon dataset root

cr0x@server:~$ sudo chroot /mnt /bin/bash -lc 'grep -R "root=ZFS=" -n /boot/grub/grub.cfg | head -n 3'
/boot/grub/grub.cfg:126:        linux   /ROOT/ubuntu_1/@/boot/vmlinuz-5.15.0-92-generic root=ZFS=rpool/ROOT/ubuntu_1 ro quiet

Ce que cela signifie : GRUB est configuré pour monter le dataset ZFS attendu comme root.
Décision : s’il pointe vers un dataset qui n’existe plus (renommé, rollback, cloné), régénérez la config GRUB et définissez bootfs adéquatement.

Tâche 11 : Régénérer la configuration GRUB et réinstaller le chargeur (cas BIOS)

cr0x@server:~$ sudo chroot /mnt /bin/bash -lc 'grub-mkconfig -o /boot/grub/grub.cfg'
Generating grub configuration file ...
Found linux image: /boot/vmlinuz-5.15.0-92-generic
Found initrd image: /boot/initrd.img-5.15.0-92-generic
done
cr0x@server:~$ sudo chroot /mnt /bin/bash -lc 'grub-install /dev/nvme0n1'
Installing for i386-pc platform.
Installation finished. No error reported.

Ce que cela signifie : la config inclut les noyaux ; GRUB est installé sur le disque. Sur des boots en miroir, répétez pour l’autre disque.
Décision : si vous êtes en réalité en UEFI, ne faites pas d’installation BIOS. Montez plutôt l’ESP et suivez la voie UEFI ci-dessous.

Tâche 12 : Réparer les artefacts et entrées de boot UEFI (cas UEFI)

cr0x@server:~$ sudo mount /dev/nvme0n1p1 /mnt/boot/efi
cr0x@server:~$ sudo chroot /mnt /bin/bash -lc 'grub-install --target=x86_64-efi --efi-directory=/boot/efi --bootloader-id=ubuntu --recheck'
Installing for x86_64-efi platform.
Installation finished. No error reported.
cr0x@server:~$ sudo chroot /mnt /bin/bash -lc 'efibootmgr -v | head -n 5'
BootCurrent: 0003
Timeout: 1 seconds
BootOrder: 0003,0001,0002
Boot0003* ubuntu  HD(1,GPT,2b3c...,0x800,0x32000)/File(\EFI\ubuntu\grubx64.efi)

Ce que cela signifie : GRUB est installé dans l’ESP et une entrée de démarrage existe.
Décision : sur les systèmes en miroir, montez et peuplez aussi l’ESP du second disque. L’ordre de démarrage du firmware peut basculer de façon inattendue après des pannes.

Tâche 13 : Vérifier le contenu de /boot en direct sur le pool/dataset attendu

cr0x@server:~$ sudo zfs list -o name,mountpoint -r bpool
NAME            MOUNTPOINT
bpool           /boot
bpool/BOOT      /boot
bpool/BOOT/ubuntu_1 /boot
cr0x@server:~$ sudo ls -lh /mnt/boot | head
total 192M
-rw-r--r-- 1 root root  26M Dec 24 03:02 initrd.img-5.15.0-92-generic
-rw------- 1 root root  12M Dec 24 03:02 System.map-5.15.0-92-generic
-rw------- 1 root root 8.3M Dec 24 03:02 vmlinuz-5.15.0-92-generic

Ce que cela signifie : confirme si /boot est monté sur ZFS et contient le noyau/initrd attendu.
Décision : si /boot est vide ou non monté, vous réparez le mauvais système de fichiers. Montez correctement les datasets bpool et relancez initramfs/GRUB.

Tâche 14 : Confirmer le comportement d’import ZFS en early boot (cachefile et hostid)

cr0x@server:~$ sudo chroot /mnt /bin/bash -lc 'ls -l /etc/hostid; zpool get -H cachefile rpool'
-rw-r--r-- 1 root root 4 Dec 22 10:10 /etc/hostid
rpool  cachefile  /etc/zfs/zpool.cache  local

Ce que cela signifie : hostid existe (aide à prévenir les imports accidentels sur le mauvais hôte) et cachefile est défini.
Décision : si cachefile est « – » ou pointe nulle part, définissez-le et régénérez-le depuis un import connu bon pour faciliter l’initramfs.

Tâche 15 : Corriger un zpool.cache cassé (fréquent après chroot ou clonage d’image)

cr0x@server:~$ sudo chroot /mnt /bin/bash -lc 'zpool set cachefile=/etc/zfs/zpool.cache rpool; zpool set cachefile=/etc/zfs/zpool.cache bpool; ls -l /etc/zfs/zpool.cache'
-rw-r--r-- 1 root root 2430 Dec 26 18:02 /etc/zfs/zpool.cache

Ce que cela signifie : le cachefile existe et contient les chemins/guids des périphériques pour l’import.
Décision : reconstruisez l’initramfs après ce changement pour que le démarrage précoce voie le cache mis à jour.

Tâche 16 : Vérifier l’incompatibilité des feature flags (pourquoi un ISO de secours ne peut pas importer)

cr0x@server:~$ sudo zpool import -o readonly=on rpool
cannot import 'rpool': unsupported feature(s)
  Pool 'rpool' uses the following feature(s) not supported by this system:
    com.delphix:spacemap_histogram
    org.openzfs:project_quota

Ce que cela signifie : l’OpenZFS de votre environnement de secours est trop ancien pour comprendre les fonctionnalités activées du pool.
Décision : arrêtez. Ne forcez rien. Démarrez une image de secours plus récente, ou installez une version plus récente d’OpenZFS dans l’environnement live.

Tâche 17 : Si GRUB tombe en rescue, trouvez /boot et chargez le mode normal

cr0x@server:~$ ls
(hd0) (hd0,gpt1) (hd0,gpt2) (hd0,gpt3) (hd1) (hd1,gpt1) (hd1,gpt2) (hd1,gpt3)
cr0x@server:~$ ls (hd0,gpt2)/
@/ BOOT/ grub/
cr0x@server:~$ set prefix=(hd0,gpt2)/grub
cr0x@server:~$ insmod normal
cr0x@server:~$ normal

Ce que cela signifie : vous avez manuellement pointé GRUB vers le bon système de fichiers et chargé le module normal pour atteindre le menu.
Décision : une fois démarré (ou chrooté), réinstallez GRUB correctement ; le secours manuel est un parachute ponctuel, pas un mode de vie.

Tâche 18 : Revenir en arrière après une mise à jour cassée en utilisant des snapshots (si vous en avez)

cr0x@server:~$ sudo zfs list -t snapshot -o name,creation -r rpool/ROOT/ubuntu_1 | tail -n 3
rpool/ROOT/ubuntu_1@pre-upgrade-2025-12-24  Tue Dec 24 02:55 2025
rpool/ROOT/ubuntu_1@post-upgrade-2025-12-24 Tue Dec 24 03:05 2025
cr0x@server:~$ sudo zfs rollback -r rpool/ROOT/ubuntu_1@pre-upgrade-2025-12-24

Ce que cela signifie : vous avez restauré l’état du système de fichiers à un point connu. C’est souvent la voie la plus rapide pour sortir d’un ensemble de paquets endommagés.
Décision : après rollback, régénérez initramfs/GRUB pour aligner les artefacts de boot avec l’état restauré, puis redémarrez.

Blague n°2 : Si votre plan de récupération est « redémarrer encore », félicitations — vous avez mis en œuvre du chaos engineering sans la paperasse.

Trois mini-histoires d’entreprise depuis la ligne de front

Incident n°1 : La panne causée par une mauvaise hypothèse

Une entreprise de taille moyenne exploitait une flotte d’hôtes Linux avec NVMe en miroir et un root ZFS. L’équipe s’était récemment standardisée sur UEFI.
Leur modèle mental : « Disques en miroir = boot en miroir. » Ils avaient à moitié raison, et c’est le type de demi-vérité le plus dangereux.

Une mise à jour de routine incluait une réinstallation de GRUB et une montée de noyau. Le changement a fonctionné sur le staging et sur la plupart des nœuds de production.
Un nœud a redémarré et est tombé directement dans le firmware. Pas de menu GRUB. Aucun disque trouvé. L’astreinte a supposé un problème d’import ZFS.
Ils ont passé une heure dans des fantaisies d’initramfs alors que la machine n’atteignait jamais l’initramfs du tout.

Le vrai problème : seule l’ESP d’un disque avait été montée pendant le cycle de mise à jour, donc seul un disque a reçu les artefacts EFI actualisés.
Le nœud avait eu un incident NVMe silencieux auparavant et le firmware a inversé l’ordre de boot vers l’autre disque — dont l’ESP était obsolète.
Les données ZFS en miroir n’avaient aucune importance ; le firmware ne peut pas booter ce qui n’est pas là.

La correction fut embarrassante de simplicité : monter les deux ESP, installer GRUB sur les deux et s’assurer qu’un job récurrent les maintienne synchronisés.
L’amélioration durable fut culturelle : pendant les incidents, ils ont commencé à nommer le stade de l’échec à voix haute.
« Nous échouons avant GRUB » est devenu une phrase que l’on pouvait prononcer sans être jugé.

Incident n°2 : L’optimisation qui s’est retournée contre eux

Une autre organisation souhaitait un démarrage plus rapide et moins de complexité. Quelqu’un a proposé : « Pourquoi garder un boot pool séparé ?
Mettons /boot sur le root pool et activons les nouvelles features ZFS partout. Un pool pour les gouverner tous. »
C’était présenté comme une simplification. C’était en réalité du couplage.

Pendant des mois, ça a fonctionné. Puis une mise à jour du noyau a coïncidé avec un scénario de secours : un nœud n’a pas pu démarrer à cause d’un matériel défaillant non lié.
L’équipe a pris un ISO de secours générique — plus ancien, mais « suffisamment bon ». L’ISO n’a pas pu importer le pool à cause de fonctionnalités non supportées.
Ils étaient exclus de leurs propres données par un décalage de version d’outil qu’ils avaient optimisé.

Ils ont finalement récupéré en trouvant un environnement live plus récent et en important en lecture seule. Mais le temps de récupération a explosé.
Le postmortem n’était pas une recherche de coupables ; c’était une leçon sur les hypothèses.
« Nous aurons toujours une image de secours assez récente » s’est avéré être un conte de fées qui ne survit pas aux longs week-ends.

Par la suite, ils ont restauré le schéma de boot pool séparé et traité l’activation des feature flags comme un changement de production
nécessitant un plan de compatibilité explicite. Parfois, les « anciennes contraintes » existent parce que le monde est désordonné, pas parce que les gens étaient paresseux.

Incident n°3 : La pratique ennuyeuse qui a sauvé la journée

Une équipe de services financiers exploitait ZFS root avec un contrôle strict des changements. Ils faisaient une chose peu glamour de manière consistante :
avant toute fenêtre de mise à jour, ils créaient des snapshots du dataset root et enregistraient le bootfs prévu dans le ticket.
Pas d’héroïsme. Juste de la discipline.

Une mise à jour a introduit un décalage entre le noyau et les modules ZFS. Le nœud a redémarré vers l’initramfs et a refusé d’importer le root.
L’astreinte n’a pas commencé à réinstaller des paquets au hasard. Ils ont importé les pools en lecture seule depuis un secours,
vérifié que les snapshots existaient, et sont revenus au snapshot pré-upgrade.

Puis ils ont régénéré l’initramfs et GRUB, redémarré, et le système est revenu sur l’ancien noyau connu bon.
L’incident fut court et profondément inintéressant — exactement ce que vous voulez quand de l’argent est en jeu.

Le travail de suivi fut tout aussi ennuyeux : ils ont ajusté la pipeline de mise à jour pour valider le succès de la construction DKMS avant le redémarrage.
Ce n’est pas glamour, mais ça transforme une « mauvaise mise à jour » en « léger retard ».

Erreurs courantes : symptôme → cause racine → correction

1) Symptom : invite GRUB ou « grub rescue> » après une mise à jour

Cause racine : GRUB ne trouve pas son prefix/modules ou la numérotation disque/partition a changé.

Correction : Depuis le secours, localisez la partition contenant /boot/grub, définissez prefix, chargez normal, bootez une fois, puis réinstallez GRUB correctement sur tous les disques de démarrage.

2) Symptom : le noyau se charge, puis tombe dans initramfs avec « cannot import rpool »

Cause racine : initramfs sans modules/outils ZFS, zpool.cache cassé, ou mauvais dataset root spécifié.

Correction : Chrootez, installez/vérifiez l’intégration ZFS dans l’initramfs, reconstruisez l’initramfs, assurez-vous que root=ZFS=... pointe vers un dataset réel, régénérez GRUB.

3) Symptom : l’ISO live ne peut pas importer le pool, se plaint de fonctionnalités non supportées

Cause racine : l’environnement de secours OpenZFS est plus ancien que l’ensemble de fonctionnalités du pool.

Correction : Utilisez une image de secours plus récente ou installez des paquets ZFS plus récents dans l’environnement live. Ne forcez pas l’import au risque de corruption.

4) Symptom : ne démarre que si un disque spécifique est présent

Cause racine : ESP/GRUB installé sur un seul disque ; l’ordre de boot du firmware bascule vers l’autre.

Correction : Installez le chargeur sur les deux disques et gardez les ESP synchronisées ; confirmez les entrées UEFI et les chemins de secours.

5) Symptom : ZFS s’importe en secours, mais le système échoue plus tard avec des erreurs de montage

Cause racine : mauvaises propriétés de dataset (mountpoint, canmount), ou bootfs pointe vers le mauvais dataset/clone.

Correction : Vérifiez zfs get mountpoint,canmount, corrigez la sélection du dataset, définissez bootfs, puis mettez à jour la configuration de boot.

6) Symptom : panic mentionnant des symboles ZFS ou des erreurs de chargement de module

Cause racine : mise à jour du noyau sans construction/installation correspondante des modules ZFS (échec DKMS, mise à jour partielle de paquet).

Correction : Démarrez un noyau plus ancien depuis GRUB si disponible ; sinon chrootez, réinstallez zfs-dkms/zfsutils, reconstruisez les modules et l’initramfs.

7) Symptom : le pool s’importe mais s’exporte immédiatement ou refuse à cause de « hostid mismatch »

Cause racine : image clonée réutilisée avec hostid identique, ou /etc/hostid modifié de façon inattendue.

Correction : Confirmez /etc/hostid dans le système installé, corrigez-le si nécessaire, et régénérez l’initramfs pour que le démarrage précoce utilise la bonne identité.

8) Symptom : « No such device » pour vmlinuz/initrd dans GRUB

Cause racine : /boot non monté au moment de la mise à jour ; initramfs et noyaux écrits ailleurs, ou mismatch du dataset bpool.

Correction : Montez correctement bpool, relancez update-initramfs et grub-mkconfig ; vérifiez la présence des fichiers dans /boot.

Listes de contrôle / plan étape par étape

Checklist de récupération (faites ceci dans l’ordre, arrêtez-vous quand le système démarre)

1. Identifier le mode de démarrage : UEFI avec ESP vs BIOS. Utilisez lsblk pour repérer les partitions vfat ESP.
2. Confirmer le stade de l’échec : avant GRUB, dans GRUB, dans initramfs ou plus tard.
3. Démarrer un environnement de secours compatible avec des outils ZFS proches de l’ensemble de fonctionnalités du pool.
4. Exécuter zpool import et lire l’erreur. Ne faites pas de freestyle.
5. Importer les pools en lecture seule avec -N pour inspecter en sécurité.
6. Vérifier zpool status pour miroirs dégradés et membres manquants.
7. Trouver le dataset root et bootfs (zfs list, zpool get bootfs).
8. Monter le root et chroot (bind /dev, /proc, /sys).
9. Reconstruire l’initramfs et valider que les composants ZFS sont inclus.
10. Régénérer la configuration GRUB pour que root=ZFS=... corresponde à la réalité.
11. Réinstaller le chargeur de démarrage sur la cible correcte :
    • BIOS : grub-install /dev/disk pour chaque disque de démarrage.
    • UEFI : montez l’ESP, grub-install --target=x86_64-efi ..., vérifiez efibootmgr.
12. Redémarrez une fois et observez. Si ça échoue, capturez le message exact et revenez au modèle de chaîne de défaillance.

Checklist de prévention (le vous du futur mérite de bonnes choses)

• Créez un snapshot pré-upgrade du dataset root et conservez une convention de nommage qui a du sens à 3h du matin.
• Validez que les builds DKMS/modules se terminent avec succès avant de planifier un redémarrage.
• Conservez au moins un noyau ancien connu bon dans GRUB.
• Sur les boots en miroir, installez/actualisez les artefacts EFI ou GRUB sur les deux disques, pas seulement celui monté aujourd’hui.
• Stockez un ISO de secours (ou option de netboot) qui peut importer les features de votre pool. Mettez-le à jour quand vous activez de nouvelles features.
• Documentez la topologie de votre pool : quelles partitions appartiennent à bpool/rpool, où vit l’ESP, et bootfs attendu.

FAQ

1) Ai-je toujours besoin d’un boot pool séparé (bpool) ?

Non, mais c’est une précaution pragmatique. Un boot pool séparé peut garder /boot sur un jeu de fonctionnalités ZFS que les chargeurs savent gérer.
Si votre plateforme boot sans problème depuis votre root pool et que vous contrôlez strictement l’activation des fonctionnalités, un pool unique peut fonctionner.
Si vous voulez des chemins de secours fiables, la séparation vaut généralement la complexité mineure.

2) Pourquoi importer les pools en lecture seule d’abord ?

Parce que la panique pousse à taper des commandes destructrices. L’import en lecture seule vous permet d’inspecter datasets, snapshots et santé sans engager de modifications.
Une fois la défaillance comprise, remontez en lecture-écriture pour des réparations ciblées.

3) Mon ISO de secours ne peut pas importer à cause de fonctionnalités non supportées. Puis-je « forcer » ?

Ne le faites pas. Les fonctionnalités non supportées signifient que le logiciel ne comprend littéralement pas des parties du format sur disque.
Votre solution est d’utiliser des outils OpenZFS plus récents, pas de jouer à la roulette russe avec votre root pool.

4) Si GRUB affiche le menu, cela signifie-t-il que mon chargeur est ok ?

Cela signifie que GRUB s’exécute au moins. Vous pouvez quand même avoir des chemins noyau/initrd cassés, un root=ZFS= erroné,
ou une histoire de module ZFS manquant qui survient plus tard dans l’initramfs.

5) Comment savoir quel dataset est censé booter ?

Vérifiez zpool get bootfs rpool. Puis confirmez que le dataset existe via zfs list.
Si vous utilisez plusieurs environnements de boot, celui prévu est généralement reflété dans les entrées GRUB aussi.

6) Quelle est la casse la plus fréquente liée à une « mauvaise mise à jour » sur ZFS root ?

Le décalage entre noyau et module ZFS. Le noyau se met à jour, DKMS échoue silencieusement, et l’initramfs démarre sans capacité d’importer ZFS.
La correction est typiquement : chroot, réparer les paquets, reconstruire l’initramfs, régénérer GRUB.

7) Dois-je exporter les pools avant de redémarrer depuis le secours ?

Idéalement, oui : zpool export rpool et zpool export bpool après votre intervention, afin que le prochain démarrage importe proprement.
Si vous avez utilisé un import en lecture seule et que vous redémarrez immédiatement, c’est quand même une bonne pratique, surtout dans des sessions de secours complexes.

8) Puis-je récupérer en faisant un rollback de snapshots même si le boot est cassé ?

Souvent oui, car le rollback peut être fait depuis un secours après import du pool. L’important est de rollbacker le dataset root correct
puis de s’assurer que les artefacts de boot (initramfs/GRUB/EFI) correspondent à l’état restauré.

9) Pourquoi un ZFS en miroir ne garantit-il pas un boot en miroir ?

ZFS miroir vos données ZFS. Le firmware boote depuis des emplacements ESP/MBR/chargeur qui peuvent ne pas être en miroir à moins que vous ne les rendiez tels.
Traitez la « redondance de boot » comme une exigence d’ingénierie distincte.

10) Dois-je activer de nouveaux feature flags ZFS sur mon boot pool ?

Soyez conservateur. Les boot pools servent à booter, pas à être à la pointe. Activez des fonctionnalités sur le root pool quand nécessaire,
et seulement après avoir confirmé que vos bootloaders et outils de secours peuvent toujours fonctionner.

Conclusion : que faire la prochaine fois (avant 2h du matin)

La récupération d’un boot pool ZFS n’est pas de la magie noire. C’est une séquence : identifiez le stade de l’échec, importez en sécurité, vérifiez le dataset de démarrage prévu,
puis réparez précisément ce qui est cassé — chargeur, initramfs ou alignement des paquets.

Étapes pratiques à effectuer sur un système sain :

• Notez la topologie de votre pool (bpool/rpool, ESPs, mapping des disques) et conservez-la avec vos runbooks.
• Automatisez les snapshots pré-upgrade et faites du rollback une option de premier plan.
• Assurez-vous que les artefacts de boot sont installés sur chaque disque bootable, pas seulement celui que l’OS a monté.
• Gardez un environnement de secours connu bon capable d’importer vos features de pool — et rafraîchissez-le quand vous changez de features.
• Testez le scénario « mauvaise mise à jour » sur un hôte non critique : cassez-le volontairement, récupérez-le délibérément, et mesurez le temps.

Quand la prochaine mise à jour dérape, vous voulez moins de surprises et plus de preuves. Les systèmes ne récompensent pas l’optimisme. Ils récompensent la préparation.