Grml 2026.09 apporte Debian 14 Forky aux administrateurs système et casse les screenrc
Le 3 septembre 2026, Grml a publié la version 2026.09, une image live de secours reconstruite sur Debian testing « Forky » avec le noyau Linux 7.1.8. Rafraîchissez votre clé USB de secours, mais vérifiez d’abord votre configuration GNU Screen et la version de grml2usb.
3 septembre 2026. L’équipe Grml publie la version 2026.09, nom de code « Hättiwaritätti », quatre mois après 2026.04. Noyau 7.1.8. L’image embarque le dernier noyau stable de la branche 7.1. Debian testing. La base est désormais Debian testing/forky — le futur Debian 14 attendu en 2027. Pourquoi c’est important : pour la première fois, les administrateurs système disposent d’un aperçu stable de Debian 14 Forky sous forme d’image live de secours, au prix de deux migrations à ne pas ignorer.
Un live de secours qui préfigure Debian 14
Grml est un système live basé sur Debian, taillé pour les administrateurs système : une clé USB bootable qui embarque les outils de récupération, de partitionnement et de diagnostic, sans rien installer sur le disque. La version 2026.09 est la première à être construite sur Debian testing/forky — le nom de code de ce qui deviendra Debian 14, dont la sortie est attendue courant 2027.
Concrètement, cela signifie que le jeu de paquets de Grml 2026.09 est un instantané de ce que Debian 14 contiendra. Pour qui veut évaluer l’état de Forky avant sa sortie, l’image est un moyen propre de le faire sans mettre en danger une machine de production : on démarre sur la clé, on inspecte, on éteint. Le noyau embarqué est le 7.1.8, et l’image est disponible en deux architectures, amd64 et arm64 — le support i386 32 bits ayant été retiré.
L’autre nouveauté discrète mais utile : le support exFAT dans l’initramfs, qui permet de démarrer depuis une clé USB formatée en exFAT. C’est un détail qui facilite la vie quand on prépare une clé de secours sur Windows ou macOS, où exFAT est le format par défaut des grosses clés.
GNU Screen 5.0.1 : le piège de migration
Le changement le plus cassant de cette version n’est pas le noyau, mais GNU Screen. Grml 2026.09 embarque GNU Screen 5.0.1, et les changements de configuration exigés par cette version ne sont pas rétrocompatibles. Traduction : le screenrc historique de Grml doit être mis à niveau, ou remplacé par le fichier screenrc_v4 fourni par le projet pour continuer à fonctionner avec GNU Screen 4.9.
# vérifier la version de Screen embarquée après démarrage
screen --version
# GNU Screen 5.0.1
# si votre screenrc personnalisé casse, repartez de la version v4
cp /etc/grml/screenrc_v4 ~/.screenrcPour un sysadmin qui a construit des années de réflexes sur son screenrc — fenêtres prédécoupées, raccourcis, barres d’état — c’est le genre de rupture qui se découvre au pire moment, en pleine intervention de récupération. Le conseil est simple : si vous maintenez une config Screen personnalisée, testez-la contre 5.0.1 avant de mettre à jour votre clé de secours.
Un système de build qui change d’ère
Les notes de version racontent aussi une mutation souterraine du build. L’outil de construction grml-live exige désormais les user namespaces Linux dans l’environnement de build, une conséquence des changements de systemd. Le problème : Docker et les autres outils de conteneurisation ne fournissent pas les user namespaces à l’intérieur des conteneurs. Résultat concret — les images quotidiennes n’ont pas été construites entre le 10 juin et le 2 septembre 2026.
C’est une anecdote, mais elle illustre une tension de fond : quand l’init système durcit ses exigences d’isolation, les chaînes de build construites sur des conteneurs non privilégiés cassent silencieusement. Grml a dû réécrire son workflow pour produire cette version, et le support des workflows en chroot est temporairement suspendu, en attendant d’être restauré. Pour quiconque maintient des images dérivées de Grml, c’est un signal : votre pipeline de build doit être compatible user namespaces.
Au passage, la lecture de configuration depuis grml-live.conf a été supprimée au profit d’une nouvelle syntaxe de ligne de commande, et grml-live n’est plus embarqué dans la saveur GRML_FULL — il faut le récupérer directement depuis git.
Le reste : reproductibilité et nettoyage
L’outil d’installation grml-debootstrap gagne une option notable pour les images Raspberry Pi et GPT : FIXED_DISK_IDENTIFIERS=yes, avec des identifiants dérivés de SOURCE_DATE_EPOCH. C’est un pas vers la reproductibilité des builds — deux builds produits à partir de la même source génèrent les mêmes identifiants de disque, ce qui compte pour la vérification et l’audit. Debian « forky » devient par ailleurs sélectionnable directement dans l’interface de grml-debootstrap.
Côté nettoyage, quelques paquets sortent : speedtest-cli et tpm-udev, tous deux retirés de Debian testing, et squashfs-tools, devenu une dépendance de grml-live. S’y ajoutent 3cpio, les firmwares EFI OVMF et qemu-efi-aarch64 (utiles pour valider un setup de boot EFI sous QEMU) et pydf. Le bilan du cycle : 19 problèmes fermés et 144 pull requests fusionnées.
Un dernier garde-fou à connaître : depuis 2026.04, ISOLINUX a été remplacé par GRUB 2 pour le boot BIOS. Si vous réinstallez Grml sur une clé avec grml2usb, il faut au minimum la version 0.20.14, sous peine d’obtenir un média non amorçable.
Ce qu’il y a dans la trousse
Reste à dire pourquoi un administrateur porte encore une clé Grml en 2026. L’image embarque l’outillage complet de la récupération : outils de partitionnement et de gestion de volumes, éditeurs, clients réseau, utilitaires de diagnostic matériel et de sauvegarde, le tout dans un environnement live qui ne touche pas au disque. C’est l’outil qu’on sort quand le serveur ne boote plus, quand il faut réparer un GRUB cassé, recopier un disque, ou auditer une machine avant de la remettre en production — sans rien installer.
Le choix de construire 2026.09 sur Debian testing/forky a une conséquence pour qui maintient ce réflexe : la clé devient un miroir de ce que Debian 14 livrera. Les paquets retirés (speedtest-cli, tpm-udev, squashfs-tools) et les nouveaux (ovmf, qemu-efi-aarch64, pydf, 3cpio) racontent la direction de Forky : moins d’outils de niche orphelins, plus de firmwares EFI pour la virtualisation, et une montée en gamme de la reproductibilité. Pour un sysadmin, c’est un aperçu utile à moindre coût.
Reproductibilité et Raspberry Pi
Côté architectures, la sortie du i386 est le fait marquant : 2026.09 ne tourne plus qu’en amd64 et arm64, une conséquence logique de la disparition du matériel 32 bits dans les parcs. Le support arm64 vise la même famille que les Raspberry Pi, où grml-debootstrap génère désormais des identifiants de disque reproductibles via FIXED_DISK_IDENTIFIERS=yes et SOURCE_DATE_EPOCH. Pour qui reconstruit des images de façon auditable, c’est un gain concret : deux builds issus de la même source produisent le même disque, bit pour bit.
La cadence reste celle d’un projet de fond : deux versions stables par an, la prochaine attendue fin 2026. C’est un rythme volontairement lent pour un outil de secours — la stabilité prime sur la nouveauté, et chaque version se laisse le temps de digérer les changements de Debian testing.
Verdict
Si vous gardez une clé USB de secours Grml, rafraîchissez-la vers 2026.09 : vous gagnez le noyau 7.1.8, la base Debian 14 Forky et le boot exFAT — mais vérifiez d’abord votre screenrc contre GNU Screen 5.0.1, et utilisez grml2usb 0.20.14 ou plus récent.
Si vous maintenez des images dérivées de Grml, auditez votre pipeline de build pour la compatibilité user namespaces : c’est la nouvelle exigence de grml-live, et elle casse les builds conteneurisés classiques.
Si vous voulez simplement évaluer Debian 14 avant sa sortie, l’image 2026.09 est un moyen propre de le faire en lecture seule, sans toucher à une machine de production.