Aller au contenu principal
~$ guillaume.putier.fr

notes/crypttab-nofail-zfs

nofail dans crypttab, et ZFS importe le pool avant l'ouverture des disques

L'option posée pour ne pas bloquer le boot retire aussi l'ordre de démarrage. Le générateur de systemd le montre en une commande.

  • luks
  • zfs
  • systemd
  • proxmox

Des disques de données chiffrés en LUKS, un pool ZFS dessus, un hyperviseur en housing. Tu ne veux surtout pas qu'un disque absent fige le démarrage sur une demande de phrase de passe que personne ne viendra taper. Le réflexe, et c'était la recommandation de l'étude de risques faite avant le chantier, sur la foi de la doc, c'est nofail dans /etc/crypttab.

Avant de l'appliquer, j'ai fait tourner le générateur de systemd sur un crypttab factice, sans toucher à /etc. Debian 13, systemd 257.13, Proxmox VE 9.2, le 22 septembre 2026 :

SYSTEMD_CRYPTTAB=/tmp/x/crypttab \
  /usr/lib/systemd/system-generators/systemd-cryptsetup-generator /tmp/x/o /tmp/x/e /tmp/x/l

Il écrit dans /tmp/x/o les unités qu'il aurait créées au boot. Tu les lis.

Sans nofail, l'unité systemd-cryptsetup@<nom>.service porte Before=cryptsetup.target et se range dans cryptsetup.target.requires. Avec nofail, la ligne Before= a disparu. L'unité reste dans cryptsetup.target.wants, et c'est tout.

Or les unités ZFS de zfsutils-linux 2.4.4 s'ordonnent After=cryptsetup.target. Sans le Before=, plus rien n'oblige la cible à attendre l'ouverture des disques, et zfs-import-cache.service peut partir sur un pool dont les membres n'existent pas encore. Je l'ai lu dans les unités générées, pas constaté sur un démarrage.

nofail n'apportait rien de ce côté. cryptsetup.target est seulement voulu par sysinit.target, jamais requis : un échec d'ouverture ne bloque pas le démarrage, avec ou sans l'option. Reste la demande de phrase de passe à la console, et elle se règle autrement.

Les options que j'ai gardées :

luks,discard,headless=true,x-systemd.device-timeout=30s,no-read-workqueue,no-write-workqueue

headless=true interdit le repli sur une question à la console. x-systemd.device-timeout=30s devient JobRunningTimeoutSec=30s sur l'unité du périphérique, donc un disque que le contrôleur ne présente jamais fait perdre trente secondes.

Pour l'ordre côté ZFS, rien à écrire : le After=cryptsetup.target est livré dans le paquet.

retour aux notes