Si vous exploitez ZFS en production, une mise à jour du noyau n’est pas « appliquer les correctifs, redémarrer, terminé. » C’est « appliquer les correctifs, vérifier la tuyauterie, et ensuite redémarrer. » Parce que ZFS n’est pas simplement un autre système de fichiers : c’est un couplage étroit entre module noyau, outils userspace, comportement de l’initramfs, hypothèses du bootloader et compatibilité des fonctionnalités du pool.
Le mode d’échec est toujours le même : vous redémarrez avec confiance et vous revenez à un hôte qui ne peut pas importer son pool, qui ne peut pas monter la racine, ou qui est bloqué à une invite initramfs l’air trahi. Voici la checklist qui vous évite cette réunion.
Le modèle mental : ce qui peut casser, et où
Un échec de mise à jour du noyau avec ZFS ne provient rarement d’un seul bogue. Il provient d’une hypothèse. Habituellement la vôtre. La « mise à jour du noyau » est en réalité un changement coordonné entre :
- Les changements d’ABI du noyau (même mineurs) qui exigent un module ZFS correspondant.
- DKMS ou des kmod précompilés construisant le module au moment de l’installation.
- Le contenu de l’initramfs : si les modules et scripts ZFS sont inclus pour que le système puisse importer les pools au démarrage.
- La configuration du bootloader : si vous pouvez sélectionner rapidement un noyau plus ancien quand ça part en vrille.
- Les flags de fonctionnalités du pool : si un pool créé ou mis à jour sur une machine peut être importé ailleurs (y compris en mode rescue).
- Les versions des outils userspace : des désalignements qui n’empêchent pas toujours le démarrage, mais qui peuvent rendre les opérations trompeuses.
Votre mission est de prouver, avant le redémarrage, que :
- Le module ZFS sera compilé (ou est déjà compilé) pour le nouveau noyau.
- Le module se chargera proprement.
- L’initramfs contient ce qu’il faut pour importer et monter.
- Les pools sont suffisamment sains pour que le redémarrage ne transforme pas « légèrement dégradé » en « non importable sous pression ».
- Vous pouvez revenir en arrière rapidement sans intervention humaine distante ni longue indisponibilité.
Une citation qui vaut la peine d’être collée à votre écran :
« L’espoir n’est pas une stratégie. » — Gene Kranz
Cette citation s’applique aux mises à jour du noyau plus encore qu’à la conquête spatiale. Les engins spatiaux ne font pas tourner DKMS. Vous, si.
Faits et histoire intéressants qui importent opérationnellement
Ce ne sont pas des anecdotes ; ils expliquent pourquoi les mises à jour ZFS se ressentent différemment des mises à jour ext4.
- ZFS a été conçu pour contrôler la pile de stockage. Il fusionne la gestion de volumes et les sémantiques du système de fichiers, voilà pourquoi les pannes peuvent toucher à la fois la découverte des disques et les couches de montage.
- Les flags de fonctionnalités OpenZFS ont remplacé les « versions de pool ». Les flags permettent aux pools d’évoluer sans un numéro de version monolithique, mais ils créent aussi des pièges de compatibilité subtils en environnement rescue.
- ZFS sur Linux est hors arbre. Cela signifie que les mises à jour du noyau peuvent casser les builds de modules ou le comportement de chargement même si le noyau lui-même va bien.
- DKMS a été inventé pour réduire la douleur des recompilations manuelles. Ça aide—jusqu’à ce qu’il échoue de façon non interactive pendant des upgrades sans surveillance, vous laissant avec un nouveau noyau et aucun module.
- Les boot root-on-ZFS dépendent fortement des scripts de l’initramfs. Si les scripts ou modules ne sont pas inclus, le noyau peut démarrer parfaitement et ne pas trouver la racine.
- ZFS met en cache les mappings device→vdev. C’est excellent pour la vitesse, mais des fichiers cache obsolètes ou des noms de périphériques modifiés peuvent compliquer les imports au tout début du boot.
- Le « hostid » existe pour une raison. ZFS l’utilise pour prévenir les imports simultanés sur du stockage partagé ; un hostid erroné ou manquant peut modifier le comportement d’import de manière surprenante.
- La compression et le checksum sont des concepts toujours actifs dans le modèle ZFS. Cela rend l’intégrité des données excellente, mais signifie aussi que le débogage « juste monter » est moins indulgent quand les métadonnées sont affectées.
- Les distributions enterprise patchent souvent les noyaux de façon agressive. Une mise à jour « mineure » peut malgré tout affecter l’ABI pour les modules externes.
Guide de diagnostic rapide (quand vous transpirez déjà)
Ceci s’adresse au moment après un redémarrage quand quelque chose ne se monte pas, ou ZFS n’importe pas, ou vous regardez une invite initramfs. Ne faites pas de freestyle ; vous gaspillerez le budget d’indisponibilité à force d’angoisse.
Premier point : prouvez si le module ZFS existe et peut se charger
- Question : Le module noyau ZFS est-il présent pour ce noyau ?
- Pourquoi : S’il manque, rien d’autre n’a encore d’importance.
cr0x@server:~$ uname -r
6.5.0-28-generic
cr0x@server:~$ modinfo zfs | sed -n '1,8p'
filename: /lib/modules/6.5.0-28-generic/updates/dkms/zfs.ko
version: 2.2.3-1ubuntu1
license: CDDL
description: ZFS filesystem
author: OpenZFS
srcversion: 1A2B3C4D5E6F7A8B9C0D
depends: znvpair,zcommon,zunicode,zzstd,icp,spl
Décision : Si modinfo échoue avec « not found », vous êtes en zone module. Démarrez sur un noyau plus ancien ou recompilez/installez ZFS pour ce noyau. S’il existe, tentez de le charger et lisez l’erreur.
cr0x@server:~$ sudo modprobe zfs
modprobe: ERROR: could not insert 'zfs': Unknown symbol in module, or unknown parameter (see dmesg)
cr0x@server:~$ dmesg | tail -n 15
[ 12.841234] zfs: disagrees about version of symbol module_layout
[ 12.841250] zfs: Unknown symbol spl_kmem_cache_alloc (err -22)
Décision : « Unknown symbol » signifie typiquement une incompatibilité d’ABI : mauvais build du module pour ce noyau, ou modules obsolètes. Rebuild DKMS ou installez le bon paquet kmod pour le noyau en cours. N’essayez pas d’« import forcé ». Il n’y a pas de flag force pour des symboles manquants.
Second point : prouvez la visibilité des pools vs leur importabilité
cr0x@server:~$ sudo zpool import
pool: tank
id: 1234567890123456789
state: ONLINE
action: The pool can be imported using its name or numeric identifier.
config:
tank ONLINE
mirror-0 ONLINE
sda3 ONLINE
sdb3 ONLINE
Décision : Si le pool est listé, ZFS fonctionne et voit les vdevs. S’il n’est pas listé, vous êtes en découverte de périphériques (drivers manquants, câblage erroné, HBA mort, mauvais chemins /dev) ou ZFS ne tourne pas.
Troisième point : si root-on-ZFS, vérifiez les hypothèses de l’initramfs
Si vous êtes dans l’initramfs sans racine, la question la plus rapide est : l’initramfs incluait-il ZFS et les bons scripts ?
cr0x@server:~$ lsmod | grep -E 'zfs|spl'
zfs 6209536 0
spl 163840 1 zfs
Décision : Si ZFS n’est pas chargé dans l’initramfs, vous avez probablement livré un initramfs cassé. Démarrez sur un noyau/initramfs ancien depuis GRUB et régénérez correctement l’initramfs.
Blague #1 (courte, pertinente) : Une mise à jour de noyau sans plan de rollback, c’est comme un parachute avec « v2 » dans le nom de fichier — techniquement amélioré, spirituellement terrifiant.
Pré-vol avant redémarrage : tâches avec commandes, sorties, et décisions
Le reste de cet article est un ensemble de vérifications ennuyeuses qui évitent des indisponibilités dramatiques. Chaque tâche inclut : commande, sortie exemple, ce que ça signifie, et la décision que vous prenez.
Note de portée : Les commandes ci-dessous supposent un environnement Debian/Ubuntu-ish avec OpenZFS sur Linux. La logique se généralise aux autres distros ; seuls les détails de packaging diffèrent.
Tâche 1 : Confirmez le noyau courant et celui sur lequel vous allez démarrer
cr0x@server:~$ uname -r
6.2.0-39-generic
cr0x@server:~$ ls -1 /boot/vmlinuz-* | tail -n 3
/boot/vmlinuz-6.2.0-39-generic
/boot/vmlinuz-6.5.0-28-generic
/boot/vmlinuz-6.5.0-31-generic
Ce que ça signifie : Vous avez plusieurs noyaux installés ; bien. Le plus récent deviendra généralement le défaut selon la config GRUB.
Décision : Si vous n’avez qu’un seul noyau installé, stoppez. Installez au moins un noyau précédent connu bon avant de tenter un redémarrage.
Tâche 2 : Vérifiez l’alignement des versions userspace ZFS et du module noyau
cr0x@server:~$ zfs --version
zfs-2.2.3-1ubuntu1
zfs-kmod-2.2.3-1ubuntu1
Ce que ça signifie : Les outils userspace et le paquet kernel module correspondent. Ce n’est pas une garantie que le module est construit pour le nouveau noyau, mais c’est une vérification de base.
Décision : Si userspace et kmod diffèrent fortement, attendez-vous à des surprises. Alignez-les via votre gestionnaire de paquets avant le redémarrage.
Tâche 3 : Vérifiez le statut DKMS pour ZFS par rapport aux noyaux installés
cr0x@server:~$ dkms status | grep -i zfs
zfs/2.2.3, 6.2.0-39-generic, x86_64: installed
zfs/2.2.3, 6.5.0-31-generic, x86_64: installed
Ce que ça signifie : DKMS a construit ZFS pour les noyaux courant et cible.
Décision : Si le noyau cible manque ici, ne redémarrez pas encore. Corrigez la build DKMS d’abord, tant que le système fonctionnel est encore disponible.
Tâche 4 : Forcez un test de build pour le nouveau noyau (parce que DKMS ment parfois par omission)
cr0x@server:~$ sudo dkms autoinstall -k 6.5.0-31-generic
Sign command: /lib/modules/6.5.0-31-generic/build/scripts/sign-file
Signing key: /var/lib/shim-signed/mok/MOK.priv
Public certificate (MOK): /var/lib/shim-signed/mok/MOK.der
zfs.ko:
Running module version sanity check.
- Original module
- No original module exists within this kernel
- Installation
- Installing to /lib/modules/6.5.0-31-generic/updates/dkms/
depmod...
Ce que ça signifie : Build réussie ; module installé ; depmod a été exécuté.
Décision : Si vous voyez des erreurs de compilation, headers manquants ou « bad return status », considérez cela comme un stop catégorique. Redémarrer transformera une erreur de build en indisponibilité.
Tâche 5 : Confirmez que les headers existent pour le nouveau noyau
cr0x@server:~$ dpkg -l | grep -E 'linux-headers-6.5.0-31-generic'
ii linux-headers-6.5.0-31-generic 6.5.0-31.31~22.04.1 amd64 Linux kernel headers for version 6.5.0 on 64 bit x86 SMP
Ce que ça signifie : Les headers sont installés, donc DKMS a une chance de réussir.
Décision : Si les headers ne sont pas installés, installez-les maintenant et relancez la vérification DKMS.
Tâche 6 : Vérifiez la signature des modules avec Secure Boot (si applicable)
cr0x@server:~$ mokutil --sb-state
SecureBoot enabled
cr0x@server:~$ sudo modprobe zfs
modprobe: ERROR: could not insert 'zfs': Key was rejected by service
Ce que ça signifie : Le module existe mais ne peut pas se charger car il n’est pas signé par une clé approuvée par le système (MOK/UEFI).
Décision : Soit signez le module ZFS correctement et enregistrez la clé, soit désactivez Secure Boot si votre politique le permet. « On gèrera ça après le reboot » n’est pas un plan ; c’est un piège.
Tâche 7 : Vérifiez la santé des pools et les compteurs d’erreurs (un redémarrage n’est pas une cérémonie de guérison)
cr0x@server:~$ sudo zpool status -x
all pools are healthy
cr0x@server:~$ sudo zpool status tank
pool: tank
state: ONLINE
status: One or more devices has experienced an unrecoverable error. An
attempt was made to correct the error. Applications are unaffected.
action: Determine if the device needs to be replaced, and clear the errors
using 'zpool clear' or replace the device with 'zpool replace'.
scan: scrub repaired 0B in 00:17:21 with 0 errors on Thu Dec 12 03:27:01 2025
config:
NAME STATE READ WRITE CKSUM
tank ONLINE 0 0 0
mirror-0 ONLINE 0 0 0
sda3 ONLINE 0 0 0
sdb3 ONLINE 1 0 0
errors: No known data errors
Ce que ça signifie : Même si le pool est ONLINE, vous avez au moins une erreur de lecture sur un périphérique. C’est un voyant jaune.
Décision : Si un périphérique montre des erreurs READ/WRITE/CKSUM croissantes, enquêtez avant de redémarrer. Les redémarrages sont les moments où les disques marginaux décident de devenir de l’art performance.
Tâche 8 : Statut de scrub et calendrier : avez-vous récemment validé le pool ?
cr0x@server:~$ sudo zpool get -H -o name,value,source autotrim tank
tank on local
cr0x@server:~$ sudo zpool status tank | sed -n '1,12p'
pool: tank
state: ONLINE
scan: scrub repaired 0B in 00:17:21 with 0 errors on Thu Dec 12 03:27:01 2025
config:
NAME STATE READ WRITE CKSUM
tank ONLINE 0 0 0
Ce que ça signifie : Vous avez un scrub récent sans erreurs, ce qui est la chose la plus proche de « connu bon » que propose ZFS.
Décision : Si le dernier scrub est ancien et que cette machine est importante, lancez-en un avant la fenêtre de maintenance. Si vous n’avez pas le temps pour un scrub complet, acceptez au moins que vous redémarrez à l’aveugle.
Tâche 9 : Vérifiez les feature flags pour éviter « marche ici, échoue en rescue »
cr0x@server:~$ sudo zpool get -H -o name,property,value all tank | grep -E 'feature@|compatibility' | head -n 12
tank feature@async_destroy enabled
tank feature@spacemap_histogram enabled
tank feature@extensible_dataset enabled
tank feature@bookmarks enabled
tank feature@embedded_data active
tank feature@device_removal enabled
tank feature@obsolete_counts enabled
tank feature@zstd_compress active
Ce que ça signifie : Certaines fonctionnalités sont « active » (en usage). Un environnement rescue avec un OpenZFS plus ancien peut refuser d’importer, ou importer en lecture seule avec des avertissements.
Décision : Avant les upgrades, évitez d’activer de nouvelles fonctionnalités de pool à la légère. Si vous devez, assurez-vous que vos médias de secours et hôtes de rollback peuvent importer le pool.
Tâche 10 : Validez que les services ZFS démarreront proprement au boot
cr0x@server:~$ systemctl status zfs-import-cache.service --no-pager
● zfs-import-cache.service - Import ZFS pools by cache file
Loaded: loaded (/lib/systemd/system/zfs-import-cache.service; enabled)
Active: active (exited) since Thu 2025-12-26 01:12:09 UTC; 2h 11min ago
cr0x@server:~$ systemctl status zfs-mount.service --no-pager
● zfs-mount.service - Mount ZFS filesystems
Loaded: loaded (/lib/systemd/system/zfs-mount.service; enabled)
Active: active (exited) since Thu 2025-12-26 01:12:11 UTC; 2h 11min ago
Ce que ça signifie : Votre chemin de démarrage actuel est sain : pools importés, datasets montés.
Décision : Si ces services sont désactivés ou échouent, corrigez-les avant de changer le noyau. Les mises à jour noyau ne sont pas le moment pour découvrir que votre méthode d’import ZFS est « quelqu’un le fait manuellement ».
Tâche 11 : Confirmez votre méthode d’import : cachefile vs chemins by-id
cr0x@server:~$ sudo zpool get cachefile tank
NAME PROPERTY VALUE SOURCE
tank cachefile /etc/zfs/zpool.cache local
cr0x@server:~$ ls -l /etc/zfs/zpool.cache
-rw-r--r-- 1 root root 2270 Dec 26 01:12 /etc/zfs/zpool.cache
Ce que ça signifie : Le système utilise un fichier cache pour accélérer les imports et préserver le mapping des périphériques. Bien—si le cache est maintenu à jour.
Décision : Si vous déplacez des disques/HBA ou clonez des VM, régénérez volontairement le fichier cache. Les fichiers cache obsolètes peuvent provoquer des comportements d’import déroutants au démarrage.
Tâche 12 : Inspectez le contenu de l’initramfs pour les modules et scripts ZFS (root-on-ZFS surtout)
cr0x@server:~$ lsinitramfs /boot/initrd.img-6.5.0-31-generic | grep -E 'zfs|spl|zpool' | head -n 12
usr/sbin/zpool
usr/sbin/zfs
usr/share/initramfs-tools/scripts/zfs
usr/share/initramfs-tools/hooks/zfs
lib/modules/6.5.0-31-generic/updates/dkms/zfs.ko
lib/modules/6.5.0-31-generic/updates/dkms/spl.ko
Ce que ça signifie : L’initramfs inclut les outils userspace ZFS, les scripts et les modules pour ce noyau.
Décision : Si les éléments ZFS manquent dans l’initramfs, régénérez-le maintenant et revérifiez. Sinon, vous êtes sur le point de démarrer un noyau incapable de monter les systèmes de fichiers qui vous importent.
Tâche 13 : Regénérez l’initramfs après tout changement de module ZFS/noyau
cr0x@server:~$ sudo update-initramfs -u -k 6.5.0-31-generic
update-initramfs: Generating /boot/initrd.img-6.5.0-31-generic
Ce que ça signifie : initramfs régénéré pour le noyau cible.
Décision : Régénérez toujours l’initramfs après des builds DKMS ou des mises à jour de paquets ZFS sur les systèmes root-on-ZFS. Considérez cela comme faisant partie de l’installation du module, pas comme une option.
Tâche 14 : Confirmez que GRUB contient des entrées pour au moins un noyau précédent
cr0x@server:~$ grep -n "menuentry 'Ubuntu" -n /boot/grub/grub.cfg | head -n 6
148:menuentry 'Ubuntu' --class ubuntu --class gnu-linux --class gnu --class os $menuentry_id_option 'gnulinux-simple-11111111-2222-3333-4444-555555555555' {
166:menuentry 'Ubuntu, with Linux 6.5.0-31-generic' --class ubuntu --class gnu-linux --class gnu --class os $menuentry_id_option 'gnulinux-6.5.0-31-generic-advanced-11111111-2222-3333-4444-555555555555' {
184:menuentry 'Ubuntu, with Linux 6.5.0-28-generic' --class ubuntu --class gnu-linux --class gnu --class os $menuentry_id_option 'gnulinux-6.5.0-28-generic-advanced-11111111-2222-3333-4444-555555555555' {
Ce que ça signifie : Le menu de démarrage inclut plusieurs noyaux.
Décision : Si les noyaux plus anciens ne sont pas disponibles dans GRUB, ajoutez-les maintenant. En cas d’incident, vos doigts oublieront comment taper « chroot ». La sélection GRUB est la trappe de secours la plus rapide.
Tâche 15 : Capturez l’état « connu bon » du système pour comparer plus tard
cr0x@server:~$ sudo zpool status > /root/pre-reboot-zpool-status.txt
cr0x@server:~$ sudo zfs list -o name,used,avail,refer,mountpoint > /root/pre-reboot-zfs-list.txt
Ce que ça signifie : Vous avez maintenant des captures before/after de la réalité.
Décision : Capturez toujours cela sur les systèmes que vous dépannerez plus tard. Ça transforme le vague « c’était OK hier » en preuve.
Tâche 16 : Validez que votre dataset racine et les propriétés du pool de boot sont sensés
cr0x@server:~$ sudo zfs get -o name,property,value -H mountpoint,canmount,readonly -r rpool/ROOT | head -n 10
rpool/ROOT mountpoint / local
rpool/ROOT canmount off local
rpool/ROOT/ubuntu mountpoint / local
rpool/ROOT/ubuntu canmount noauto local
rpool/ROOT/ubuntu readonly off default
Ce que ça signifie : Vous utilisez un pattern racine-on-ZFS courant : un dataset parent avec canmount=off et un dataset enfant root.
Décision : Si les mountpoints ou les flags canmount sont incohérents, corrigez-les avant le redémarrage. Les mises à jour noyau ne cassent pas cela, mais elles exposent des problèmes d’ordre de démarrage déjà présents.
Tâche 17 : Confirmez la stabilité du hostid (évite la confusion d’import sur stockage partagé ou clones)
cr0x@server:~$ hostid
7f000001
cr0x@server:~$ sudo zgenhostid -i
/etc/hostid: 7f000001
Ce que ça signifie : hostid existe et est stable.
Décision : Si vous clonez des VM qui partagent des pools (ou peuvent voir les mêmes disques), assurez-vous d’un hostid unique. Les mises à jour noyau sont souvent le moment où des templates clonés deviennent « vrais serveurs », et ZFS s’en souvient.
Tâche 18 : Faites un snapshot ciblé avant de toucher aux noyaux (pour configs et rollback rapides)
cr0x@server:~$ sudo zfs snapshot -r rpool/ROOT/ubuntu@pre-kernel-upgrade
cr0x@server:~$ sudo zfs list -t snapshot | grep pre-kernel-upgrade | head -n 3
rpool/ROOT/ubuntu@pre-kernel-upgrade 0B -
Ce que ça signifie : Vous avez créé un snapshot du dataset racine. Sur les systèmes avec un mécanisme de boot environment correct, cela peut devenir un rollback rapide.
Décision : Si vous ne pouvez pas snapshotter la racine (layout étrange, politique), sauvegardez au moins /etc et la config de démarrage. « Nous avons des backups » n’est pas suffisamment spécifique pendant un incident.
Tâche 19 : Vérifiez l’espace libre (oui, ça compte pour les upgrades et le comportement ZFS)
cr0x@server:~$ sudo zfs list -o name,used,avail,usedbysnapshots,mountpoint tank
NAME USED AVAIL USEDBYSNAPSHOTS MOUNTPOINT
tank 18.2T 1.14T 3.55T /tank
Ce que ça signifie : Vous avez de la marge. ZFS n’aime pas vivre près de 100 % plein ; allocations de métadonnées et performances deviennent pénibles.
Décision : Si le pool est serré, faites du ménage d’abord. Les mises à jour noyau ne sont pas le bon moment pour découvrir que votre pool est à court d’espace et ne peut pas engager proprement des transactions.
Tâche 20 : Dry-run de vos accès distants et de la console fallback
cr0x@server:~$ sudo systemctl is-active ssh
active
cr0x@server:~$ sudo systemctl is-enabled serial-getty@ttyS0.service
enabled
Ce que ça signifie : SSH est actif ; la console série est configurée (si vous l’avez). C’est une facilité de récupération, pas un luxe.
Décision : Si vous n’avez pas d’accès console hors bande, soyez extrêmement conservateur : conservez des noyaux plus anciens, répétez les rollbacks, et planifiez les redémarrages quand des humains peuvent atteindre la machine.
Trois mini-histoires d’entreprise (toutes vraies dans l’esprit)
Mini-histoire 1 : L’incident causé par une mauvaise hypothèse
Ils géraient une petite flotte de nœuds d’analytics. Rien de fancy : une série de serveurs Linux, chacun avec une paire de boot en miroir et un gros pool ZFS pour les données. L’équipe traitait les mises à jour du noyau comme une hygiène de routine—parce que pendant des années, ça l’était.
Un jour, la distro a livré une nouvelle ligne de noyau et le pipeline CI a commencé à la pousser. L’upgrade semblait propre. Les paquets se sont installés, DKMS a imprimé des messages rassurants, et la fenêtre de maintenance était courte. Ils ont redémarré, un nœud à la fois.
Le premier nœud est revenu… dans initramfs. Il voyait les disques, mais ne pouvait pas importer le pool. La panique a suivi l’itinéraire classique : quelqu’un a dit « ZFS est cassé », un autre a dit « c’est le HBA », et un troisième a commencé à chercher des runbooks anciens qui supposaient ext4.
Le vrai problème était plus simple et plus embarrassant : le module ZFS avait été compilé pour le nouveau noyau, mais Secure Boot l’a rejeté. Personne n’avait testé le chargement du module sur un hôte avec Secure Boot après la rotation de clés. L’« hypothèse erronée » n’était pas technique ; elle était procédurale : ils ont supposé que l’environnement n’avait pas changé parce que les serveurs n’avaient pas changé.
La récupération a pris plus de temps qu’elle n’aurait dû, parce qu’ils ont dû démarrer sur un noyau plus ancien, enregistrer la bonne clé, puis relancer l’upgrade correctement. L’enseignement retenu : ajouter un contrôle modprobe zfs comme garde avant le redémarrage. Vous ne pouvez pas argumenter avec un noyau qui refuse du code non signé.
Mini-histoire 2 : L’optimisation qui s’est retournée contre eux
Une autre organisation avait une culture de la performance. Pas la bonne. Celle où quelqu’un poste des captures iostat dans Slack comme des selfies d’entraînement. Ils voulaient des reboots plus rapides, des imports plus rapides, tout plus rapide.
Quelqu’un a remarqué que l’import par scan des périphériques était « lent », alors ils ont imposé les imports par cachefile partout et désactivé tout ce qui ressemblait à du travail en plus. Ils ont aussi réduit l’initramfs pour diminuer sa taille, parce que plus petit = forcément plus rapide. Voilà comment la logique fonctionne en salle de conférence.
Des mois plus tard, ils ont upgradé des noyaux sur un nœud de stockage. L’upgrade s’est bien passé. Mais le redémarrage a modifié l’ordre d’énumération des périphériques—une mise à jour de firmware HBA avait aussi été appliquée auparavant. Le cachefile faisait encore référence à d’anciens noms /dev. Le boot initial a tenté d’importer en utilisant un mapping obsolète, et comme ils avaient épuré les scripts, le comportement de secours n’était pas présent.
Le serveur n’a pas importé automatiquement les pools. Un opérateur a importé manuellement avec -d /dev/disk/by-id, tout est remonté, et tout le monde a convenu que c’était « bizarre ». Le bizarroïde s’est répété sur le nœud suivant. L’« optimisation » avait retiré de la résilience.
Ils ont réparé ça en considérant les chemins d’import comme une dérive de configuration : soit s’appuyer sur des chemins by-id stables et garder le scan de secours activé, soit maintenir volontairement le cachefile et le régénérer quand le hardware change. « Boot plus rapide » n’est pas un KPI qui mérite une alarme.
Mini-histoire 3 : La pratique ennuyeuse mais correcte qui a sauvé la mise
Grande plateforme de données corporate. Plusieurs environnements. Beaucoup de parties prenantes. L’équipe stockage n’était pas aimée, mais elle était respectée—la différence tient souvent à la paperasse.
Ils avaient une checklist pour les mises à jour du noyau ZFS. Ce n’était pas sophistiqué. C’était rigide. Elle incluait « vérifier le statut DKMS pour le noyau cible », « confirmer que l’initramfs contient zfs.ko », et « confirmer que GRUB a une entrée pour un noyau plus ancien ». Personne n’avait le droit de la sauter parce qu’il était « pressé ».
Une nuit, une mise à jour de noyau est arrivée qui cassait les builds DKMS de ZFS à cause d’une incompatibilité toolchain sur cette image. Leur pipeline l’a détectée parce que le pré-vol incluait dkms autoinstall -k comme étape de validation. La build a échoué bruyamment tant que le système était encore en ligne, et le nœud n’a jamais redémarré dans un état cassé.
La correction était banale : installer les bons headers et éléments de toolchain, puis reconstruire. L’héroïsme n’a pas été nécessaire. Le cluster est resté sain, la fenêtre de maintenance est restée ennuyeuse, et la mise à jour du matin s’est résumée à « terminé avec succès ».
L’arme secrète de cette équipe n’était pas l’expertise. C’était l’insistance sur des vérifications ennuyeuses, à chaque fois, surtout quand tout semblait facile.
Checklists / plan pas à pas
Utilisez ceci comme runbook. Ne « l’adaptez pas live ». Adaptez-le une fois, par temps calme, puis suivez-le.
Plan pas à pas : la séquence de redémarrage sûre
- Choisissez un noyau de rollback. Confirmez qu’un noyau plus ancien est installé et sélectionnable dans GRUB. Si vous ne pouvez pas le pointer, vous n’en avez pas.
- Vérifiez la santé des pools.
zpool status -xdoit être propre ou compris. Tout resilver actif, périphérique manquant, ou compteurs d’erreurs en augmentation doit retarder le reboot. - Vérifiez le scrub récent. Si le système est important et que le dernier scrub est ancien, lancez-en un avant le changement.
- Installez noyau + headers. Ne les séparez pas. Un noyau sans headers, c’est la roulette DKMS.
- Confirmez les builds DKMS pour le noyau cible. Utilisez
dkms statuspuis forcezdkms autoinstall -k. - Testez le chargement du module sur le système courant (si possible). Vous ne pouvez pas charger un module construit pour un noyau différent, mais vous pouvez détecter les problèmes Secure Boot/clé en validant le flux de signature et le comportement actuel du module.
- Regénérez l’initramfs pour le noyau cible. Puis inspectez-le avec
lsinitramfspour confirmer la présence des éléments ZFS. - Snapshottez les datasets racine. Surtout si vous avez un mécanisme de boot environment. Les snapshots sont bon marché ; les indisponibilités, non.
- Capturez les sorties pré-état. Sauvegardez
zpool status,zfs list, etjournalctl -bautour des boots précédents si vous cherchez des problèmes intermittents. - Redémarrez un nœud, observez, puis procédez. Si vous avez plusieurs machines, faites un canari. Sinon, votre canari, c’est « vous, en faisant attention ».
Checklist minimale « j’ai cinq minutes » (à utiliser seulement quand le blast radius est petit)
zpool status -xest propredkms status | grep zfsmontre le noyau ciblelsinitramfs /boot/initrd.img-<target> | grep zfs.kotrouve le module- GRUB a une entrée pour un noyau plus ancien
- Vous avez un accès console
Blague #2 (courte, pertinente) : Si votre plan de rollback est « on SSH et on corrige », votre plan de rollback est aussi « on croit à la magie ».
Erreurs fréquentes : symptôme → cause racine → correction
1) Le boot tombe sur initramfs, le pool racine n’importe pas
Symptôme : Vous obtenez un shell initramfs. Des messages mentionnent filesystem racine manquant, échec d’import ZFS, ou « cannot mount rpool ».
Cause racine : initramfs sans les modules/scripts ZFS pour le noyau nouveau, ou module ZFS qui a échoué à se charger (Secure Boot, mismatch ABI).
Correction : Démarrez sur un noyau plus ancien depuis GRUB. Rebuild DKMS pour le noyau cible, exécutez update-initramfs -u -k <target>, vérifiez avec lsinitramfs, puis redémarrez.
2) Le module ZFS existe mais ne se charge pas : « Unknown symbol »
Symptôme : modprobe zfs échoue ; dmesg affiche unknown symbols ou module_layout mismatch.
Cause racine : Module construit contre un noyau différent, modules obsolètes non remplacés, ou mise à jour partielle ayant laissé des fichiers incohérents sous /lib/modules.
Correction : Rebuild ZFS pour le noyau exact : dkms autoinstall -k $(uname -r) (ou installez le kmod approprié). Exécutez depmod -a. Si le packaging est cassé, réinstallez proprement les paquets ZFS.
3) Échec de chargement du module : « Key was rejected by service »
Symptôme : Le module ZFS ne se charge pas sur les systèmes Secure Boot.
Cause racine : Module non signé ou clé de signature non approuvée.
Correction : Enregistrez une Machine Owner Key (MOK) et assurez-vous que DKMS signe le module, ou désactivez Secure Boot (si la politique le permet). Testez à l’avance en chargeant le module après rebuild.
4) Le pool s’importe manuellement mais pas automatiquement au boot
Symptôme : Après redémarrage, les services sont up mais les datasets sont absents jusqu’à ce que quelqu’un exécute zpool import.
Cause racine : services zfs-import désactivés, cachefile manquant/obsolète, ou méthode d’import ne correspondant pas à l’environnement (ex. noms de périphériques changés).
Correction : Activez les services d’import, régénérez /etc/zfs/zpool.cache volontairement par export/import, et préférez des chemins stables comme /dev/disk/by-id pour les imports dans des environnements atypiques.
5) Le pool n’importe pas en environnement rescue, mais importe bien sur l’hôte
Symptôme : L’ISO rescue ne peut pas importer ; l’hôte le peut.
Cause racine : Les feature flags du pool utilisés sont plus récents que ce que le rescue supporte.
Correction : Maintenez vos environnements rescue à jour pour correspondre aux features de vos pools. Évitez d’activer de nouvelles features sauf si vous avez vérifié que vos outils de récupération peuvent les gérer.
6) Le reboot réussit, mais les performances chutent et la latence explose
Symptôme : Après une mise à jour du noyau, la latence I/O augmente ; le comportement ARC change ; l’utilisation CPU monte.
Cause racine : Le nouveau noyau/module ZFS interagit différemment avec les limites mémoire, contraintes cgroup, ou tunables. Parfois le changement est réel ; parfois votre monitoring a juste déplacé des labels.
Correction : Comparez /proc/spl/kstat/zfs/arcstats avant/après, vérifiez les limites mémoire, et revenez sur les expérimentations de tunables. N’« optimisez » pas en pleine incident ; stabilisez d’abord.
FAQ
1) Doit-on vraiment regénérer l’initramfs si DKMS dit que ZFS est installé ?
Sur root-on-ZFS ou tout système qui importe des pools pendant le tout début du boot : oui. DKMS qui construit un module ne garantit pas que l’initramfs le contient. Vérifiez avec lsinitramfs.
2) Quel est le meilleur indicateur qu’un redémarrage réussira ?
Pour root-on-ZFS : l’initramfs cible contient les modules et scripts ZFS, et vous pouvez sélectionner un noyau précédent dans GRUB. Pour les pools non-root : DKMS a construit pour le noyau cible et les pools sont sains.
3) Dois-je activer de nouveaux feature flags de pool lors d’une maintenance de routine ?
Pas sans raison. Les feature flags sont majoritairement unidirectionnels. Activez-les quand vous avez un besoin, et après avoir confirmé que vos environnements de récupération peuvent importer le pool.
4) Est-il plus sûr d’utiliser les kmods précompilés de la distro ou DKMS ?
Les kmods précompilés peuvent être plus prévisibles si votre distro les maintient bien. DKMS est flexible mais ajoute une étape de build qui peut échouer au pire moment. Choisissez selon la fiabilité de votre environnement, pas selon une idéologie.
5) Comment savoir si mon pool risque d’échouer à l’import après le reboot ?
Si zpool status affiche des périphériques manquants, un resilver en cours, des erreurs checksum qui augmentent, ou si vous avez eu des pertes d’alimentation récentes, delayez le reboot et stabilisez d’abord.
6) Et si j’utilise ZFS uniquement pour un pool de données, pas la racine ?
Votre système démarrera même si ZFS est cassé, ce qui est agréable. Mais vos applications ne verront pas leurs données. La checklist s’applique toujours : vérifiez le build/chargement du module et les services d’auto-import.
7) Pourquoi le changement de noms de périphériques importe-t-il si ZFS utilise des GUID ?
ZFS suit les périphériques par GUID, mais le comportement d’import et les entrées du cachefile peuvent quand même dépendre des chemins. En early boot ou en rescue limité, des chemins stables réduisent les surprises.
8) Puis-je juste garder l’ancien noyau indéfiniment et éviter le problème ?
Vous pouvez, jusqu’à ce que vous ne puissiez plus — correctifs de sécurité, support matériel, et fenêtres de support fournisseur finiront par vous coincer. La démarche durable est de rendre les upgrades ennuyeux, pas de les éviter.
9) Quel est le rollback le plus rapide si le nouveau noyau ne peut pas importer les pools ?
Redémarrez et sélectionnez le noyau précédent dans GRUB. C’est pour ça que vous le gardez installé et testé. Si vous ne pouvez pas atteindre GRUB, il vous fallait l’accès console hier.
10) Dois-je exporter les pools avant le redémarrage ?
Généralement non pour des disques locaux mono-hôte ; ça peut augmenter le risque si des services attendent des montages pendant l’arrêt. Mais sur du stockage partagé ou des setups multipath complexes, un export contrôlé peut réduire l’ambiguïté « le pool était en cours d’utilisation ». Faites-en un choix délibéré, pas une superstition.
Conclusion : prochaines étapes pratiques
Une mise à jour du noyau avec ZFS tourne mal quand vous la traitez comme un patch OS au lieu d’un changement de pile de stockage. La stratégie de survie est constante :
- Prouvez que le module ZFS existe pour le noyau cible (statut DKMS plus build forcé).
- Prouvez que l’initramfs contient ce que le boot requiert (inspectez, ne supposez pas).
- Prouvez que vos pools sont assez sains pour survivre au stress (statut, récence du scrub, compteurs d’erreurs).
- Prouvez que vous pouvez revenir en arrière sans héroïsme (entrées GRUB, console, snapshots).
La prochaine fois que vous planifierez une fenêtre de reboot, faites les tâches de pré-vol dans l’ordre, sauvegardez les sorties, et considérez tout drapeau rouge comme un stop. L’objectif n’est pas le courage. C’est la confiance fondée sur la paperasse.