M2SI Services
Linux

Ubuntu 26.04 et Dracut : auditer son initramfs avant l’upgrade

Une méthode de contrôle de l’initramfs avec Dracut : root filesystem, LVM, chiffrement, drivers, modules et validation du boot avant migration vers Ubuntu 26.04.

28 août 202610 min de lectureUbuntu 26.04

L’initramfs est rarement visible pendant l’exploitation quotidienne d’un serveur Linux. Pourtant, il intervient avant le montage du filesystem racine et doit contenir ce qui est nécessaire pour atteindre le stockage, activer les volumes, déverrouiller les périphériques chiffrés ou charger certains drivers.

Ubuntu a fait de Dracut son infrastructure initramfs par défaut à partir d’Ubuntu 25.10. Ubuntu 26.04 LTS poursuit cette transition, tout en conservant initramfs-tools supporté. Cette coexistence est importante : un upgrade ne signifie pas qu’il faut convertir aveuglément un serveur existant vers Dracut.

L’objectif est donc de construire un audit de chaîne de boot : identifier l’outil réellement utilisé, comprendre le stockage racine, inspecter l’image initramfs et préparer un test contrôlé avant toute modification.

Contexte et problème

Au démarrage, le kernel ne peut pas toujours monter directement /. Le root filesystem peut dépendre de plusieurs couches :

Kernel
  ↓
initramfs
  ↓
drivers stockage / réseau éventuel
  ↓
LUKS / mdraid / LVM / multipath selon le cas
  ↓
filesystem racine
  ↓
systemd du système réel

Une image initramfs incomplète peut donc conduire à un serveur qui ne trouve plus son root device après reboot.

Dracut adopte une approche modulaire. Il assemble une image en fonction de modules et, en mode hostonly, de la configuration observée sur l’hôte. Upstream documente le mode host-only pour générer une image adaptée au système local. Son mode sloppy conserve davantage d’éléments qu’un mode strict, ce qui donne plus de tolérance à de petits changements matériels ou d’environnement.

Le bon réflexe n’est pas de reconstruire l’image immédiatement, mais de documenter ce dont le serveur a besoin pour booter.

Rappel : rôle de l’initramfs

L’initramfs est une petite arborescence chargée en mémoire très tôt pendant le boot. Elle fournit un environnement temporaire permettant de découvrir et préparer la vraie racine du système.

Elle peut notamment embarquer :

  • modules kernel ;
  • outils de stockage ;
  • règles udev ;
  • configuration LVM ou mdraid ;
  • composants de déchiffrement ;
  • logique réseau pour certains roots distants ;
  • unités systemd nécessaires à cette phase.

Avec Dracut, l’image est construite à partir de modules et de dépendances permettant d’atteindre le root filesystem prévu.

Prérequis

Avant l’audit, rassemblez :

  • la version Ubuntu actuelle ;
  • le kernel réellement booté ;
  • la disposition des disques et partitions ;
  • l’utilisation éventuelle de LVM, mdraid, LUKS, multipath ou root réseau ;
  • la configuration /etc/fstab et /etc/crypttab lorsqu’elle existe ;
  • un accès console ou hyperviseur ;
  • une sauvegarde ou un snapshot exploitable avant toute reconstruction d’initramfs.

Ne reconstruisez pas l’image d’un serveur critique uniquement pour tester une commande.

Mise en pratique

1. Identifier l’outil présent

Commencez par vérifier les packages :

dpkg-query -W -f='${Package}\t${Version}\n' dracut dracut-core initramfs-tools 2>/dev/null

Puis contrôlez les commandes disponibles :

command -v dracut
command -v lsinitrd
command -v update-initramfs

Un serveur upgradé peut conserver initramfs-tools. Canonical indique qu’Ubuntu 26.04 supporte encore les deux implémentations ; il ne faut donc pas conclure qu’un système est incorrect simplement parce qu’il utilise toujours update-initramfs.

2. Documenter le root filesystem

Identifiez d’abord ce qui est monté sur / :

findmnt -no SOURCE,FSTYPE,OPTIONS /

Complétez avec :

lsblk -o NAME,TYPE,FSTYPE,UUID,MOUNTPOINTS

Si LVM est utilisé :

sudo pvs
sudo vgs
sudo lvs

Si le système utilise du chiffrement :

cat /etc/crypttab 2>/dev/null

Ne publiez jamais de secrets, clés ou tokens issus de cette configuration.

Le résultat attendu est une cartographie claire du chemin qui mène au filesystem racine.

3. Vérifier la ligne kernel active

Affichez :

cat /proc/cmdline

Relevez notamment l’identifiant utilisé pour root= et les paramètres rd.* éventuels.

Dracut fournit également :

dracut --print-cmdline

Cette commande affiche une partie des paramètres que Dracut estime nécessaires au boot pour le layout de disque courant. Upstream précise qu’elle ne représente pas forcément l’intégralité de la ligne kernel finale.

Comparez les UUID ou chemins persistants avec :

blkid

Le but est de détecter un root device mal documenté ou dépendant d’un nom de périphérique non persistant.

4. Inspecter l’image existante sans la modifier

lsinitrd est l’outil principal d’inspection. Pour le kernel courant :

lsinitrd -k "$(uname -r)" | less

Pour lister uniquement les modules Dracut présents :

lsinitrd -m -k "$(uname -r)"

Upstream documente -m comme l’option listant les modules Dracut inclus dans l’image.

Cherchez les éléments correspondant à votre stockage : LVM, crypt, mdraid, multipath, filesystem et drivers concernés.

5. Inspecter la configuration Dracut

Les réglages locaux sont généralement conservés dans /etc/dracut.conf ou sous :

/etc/dracut.conf.d/

Listez-les sans modification :

grep -RniE 'hostonly|add_dracutmodules|omit_dracutmodules|add_drivers|force_drivers|filesystems' \
  /etc/dracut.conf /etc/dracut.conf.d 2>/dev/null

Une option omit_dracutmodules ou omit_drivers mérite une attention particulière si elle touche un composant nécessaire au root filesystem.

À l’inverse, une configuration hostonly_mode="strict" réduit davantage le contenu de l’image. Upstream avertit que ce mode peut rendre l’image moins tolérante aux changements matériels ou d’environnement.

6. Définir le go/no-go avant reconstruction

Avant de générer quoi que ce soit, vous devez pouvoir répondre à ces questions :

  • quel device fournit / ?
  • faut-il activer LVM, RAID ou chiffrement avant le mount ?
  • quels drivers de stockage sont requis ?
  • le filesystem racine nécessite-t-il un module kernel spécifique ?
  • existe-t-il des hooks ou modules locaux ?
  • le boot dépend-il du réseau ?
  • avez-vous une console de récupération ?

Si une réponse importante reste inconnue, le bon résultat est NO-GO pour une conversion ou reconstruction sur production.

7. Tester une reconstruction uniquement dans un lab

Sur une VM de test ou un clone, une reconstruction explicite peut être effectuée selon la politique de la distribution et la version installée. Ne copiez pas une commande de génération depuis une autre distribution : Ubuntu peut intégrer des wrappers et conventions de packaging spécifiques.

Avant toute reconstruction, conservez une copie de l’image actuelle et vérifiez l’espace disponible :

sudo cp -a "/boot/initrd.img-$(uname -r)" "/boot/initrd.img-$(uname -r).pre-dracut-test"
df -h /boot

Puis utilisez la procédure Ubuntu applicable à la version et au package réellement installés pour régénérer l’image.

L’article s’arrête volontairement avant de prescrire une commande universelle de remplacement : l’objectif est l’audit, et la coexistence supportée entre Dracut et initramfs-tools impose de tenir compte de l’état réel du serveur.

Résultat attendu

Après un reboot de test réussi, vérifiez :

uname -r
findmnt -no SOURCE,FSTYPE /
systemctl --failed
journalctl -b -p warning

Puis inspectez à nouveau l’image associée au kernel booté :

lsinitrd -m -k "$(uname -r)"

Le succès du boot n’est pas suffisant lorsque le serveur dépend de fonctionnalités avancées. Testez également les volumes, services et chemins de données nécessaires à l’application.

Bonnes pratiques

Conservez des identifiants persistants comme UUID ou labels lorsque le stockage le permet plutôt que des noms /dev/sdX dépendant de l’ordre de découverte.

Ne passez pas en hostonly_mode=strict uniquement pour réduire la taille de l’image. La documentation Dracut prévient que ce mode peut rendre l’image sensible à de petits changements matériels.

Évitez également de migrer simultanément l’outil initramfs, le stockage et le kernel dans un même test si vous pouvez séparer ces changements. Un changement à la fois simplifie fortement le diagnostic.

Sécurité

Une initramfs peut contenir des éléments de configuration sensibles. Avant de copier ou transmettre une image pour diagnostic, inspectez son contenu et appliquez les règles de protection adaptées.

Les environnements utilisant LUKS, TPM, Clevis, Dropbear ou du déverrouillage réseau méritent un lab spécifique. La présence d’un package Dracut équivalent ne suffit pas à démontrer que le workflow complet de déverrouillage est supporté dans votre configuration.

Ne supprimez jamais une méthode de boot connue comme fonctionnelle avant d’avoir validé son remplacement et une procédure de récupération console.

Coûts

L’audit n’entraîne pas de coût logiciel direct. Un clone de VM, un snapshot ou une VM cloud temporaire peut générer un coût d’infrastructure ; supprimez les ressources de test lorsqu’elles ne sont plus nécessaires.

Limites et points de vigilance

Canonical indique que Dracut est le défaut, mais initramfs-tools reste supporté sous Ubuntu 26.04. Il serait donc incorrect de présenter la migration immédiate vers Dracut comme un prérequis universel de l’upgrade.

Les configurations de boot avancées — chiffrement distant, root réseau, multipath, stockage SAN, ZFS chiffré ou hooks maison — nécessitent une validation spécifique.

Les modules et comportements Dracut évoluent également indépendamment d’Ubuntu. Vérifiez la documentation de la version réellement installée avant d’utiliser une option sensible.

Rollback ou nettoyage

Dans un lab, gardez l’ancienne initramfs et l’ancienne entrée de boot aussi longtemps que nécessaire.

Si la nouvelle image ne boote pas, utilisez le menu boot ou la console pour sélectionner un kernel/initramfs connu comme fonctionnel, puis restaurez la configuration précédente.

Ne supprimez la copie de secours qu’après plusieurs boots et validations concluantes :

sudo rm "/boot/initrd.img-$(uname -r).pre-dracut-test"

Cette commande est destructive ; exécutez-la uniquement après avoir confirmé que le fichier n’est plus nécessaire.

Références officielles

  • Ubuntu 26.04 LTS summary — Canonical : https://documentation.ubuntu.com/release-notes/26.04/summary-for-lts-users/
  • Switch to Dracut specification — Ubuntu Foundations : https://discourse.ubuntu.com/t/spec-switch-to-dracut/54776
  • lsinitrd(1) — Dracut upstream : https://dracut-ng.github.io/dracut/man/lsinitrd.1.html
  • dracut(8) — Dracut upstream : https://dracut-ng.github.io/dracut/man/dracut.8.html
  • dracut.conf(5) — Dracut upstream : https://dracut-ng.github.io/dracut/man/dracut.conf.5.html

Conclusion

Le passage de l’écosystème Ubuntu vers Dracut rend l’initramfs plus visible pour les administrateurs, mais la priorité reste la même : ne jamais modifier une chaîne de boot que l’on n’a pas d’abord comprise.

Inventoriez le stockage, inspectez l’image avec lsinitrd, contrôlez les modules et la configuration host-only, puis testez sur clone. Ubuntu 26.04 laisse encore le choix entre Dracut et initramfs-tools, ce qui permet de privilégier une migration maîtrisée plutôt qu’un changement imposé sans preuve de compatibilité.