Grml 2026.09 brings Debian 14 Forky to sysadmins and breaks your screenrc
On September 3, 2026, Grml released 2026.09, a rescue live image rebuilt on Debian testing ’Forky’ with Linux kernel 7.1.8. Refresh your rescue USB stick, but check your GNU Screen configuration and grml2usb version first.
September 3, 2026. The Grml team releases version 2026.09, codenamed “Hättiwaritätti”, four months after 2026.04. Kernel 7.1.8. The image ships the latest stable 7.1 kernel. Debian testing. The base is now Debian testing/forky — the future Debian 14, due in 2027. Why it matters: for the first time, system administrators get a stable preview of Debian 14 Forky as a rescue live image, at the cost of two migrations worth taking seriously.
A rescue live system that previews Debian 14
Grml is a Debian-based live system built for system administrators: a bootable USB stick packed with recovery, partitioning, and diagnostic tools, without installing anything to disk. Version 2026.09 is the first to be built on Debian testing/forky — the codename of what will become Debian 14, expected sometime in 2027.
In practice, that means Grml 2026.09’s package set is a snapshot of what Debian 14 will contain. For anyone who wants to assess the state of Forky before its release, the image is a clean way to do it without putting a production machine at risk: boot from the stick, inspect, power off. The embedded kernel is 7.1.8, and the image ships in two architectures, amd64 and arm64 — 32-bit i386 support having been dropped.
The other quiet but useful addition is exFAT support in the initramfs, which lets the image boot from an exFAT-formatted USB device. It is a small detail that makes life easier when preparing a rescue stick on Windows or macOS, where exFAT is the default format for large drives.
GNU Screen 5.0.1: the migration trap
The most breaking change in this release is not the kernel but GNU Screen. Grml 2026.09 ships GNU Screen 5.0.1, and the configuration changes that version demands are not backwards compatible. Translation: Grml’s historic screenrc must be upgraded, or swapped for the project-provided screenrc_v4 file to keep working with GNU Screen 4.9.
# check the embedded Screen version after boot
screen --version
# GNU Screen 5.0.1
# if your custom screenrc breaks, restart from the v4 version
cp /etc/grml/screenrc_v4 ~/.screenrcFor a sysadmin who has built years of muscle memory on their screenrc — pre-split windows, key bindings, status bars — this is the kind of break you discover at the worst possible moment, mid-recovery. The advice is simple: if you maintain a custom Screen configuration, test it against 5.0.1 before updating your rescue stick.
A build system changing era
The release notes also tell the story of a quiet mutation in the build. The grml-live build tool now requires Linux user namespaces in the build environment, a consequence of systemd changes. The problem: Docker and other containerization tools do not provide user namespaces inside containers. The concrete result — daily images were not built between June 10 and September 2, 2026.
It is an anecdote, but it illustrates a deeper tension: when the init system tightens its isolation requirements, build chains built on unprivileged containers break silently. Grml had to rewrite its workflow to ship this release, and support for chroot-based workflows is temporarily suspended pending restoration. For anyone maintaining Grml-derived images, that is a signal: your build pipeline needs to be user namespace-compatible.
Along the way, reading configuration from grml-live.conf was removed in favor of a new command-line syntax, and grml-live is no longer shipped in the GRML_FULL flavor — you now pull it directly from git.
The rest: reproducibility and cleanup
The grml-debootstrap install tool gains a notable option for Raspberry Pi and GPT images: FIXED_DISK_IDENTIFIERS=yes, with identifiers derived from SOURCE_DATE_EPOCH. It is a step toward reproducible builds — two builds from the same source produce the same disk identifiers, which matters for verification and audit. Debian “forky” also becomes directly selectable in the grml-debootstrap frontend.
On the cleanup side, a few packages leave: speedtest-cli and tpm-udev, both removed from Debian testing, and squashfs-tools, now a dependency of grml-live. In come 3cpio, the EFI firmwares OVMF and qemu-efi-aarch64 (useful to validate an EFI boot setup under QEMU), and pydf. The cycle’s tally: 19 closed issues and 144 merged pull requests.
One last guardrail to know: since 2026.04, ISOLINUX has been replaced by GRUB 2 for BIOS boot. If you reinstall Grml onto a stick with grml2usb, you need at least version 0.20.14, or you will end up with unbootable media.
What is in the kit
It is worth stating why an administrator still carries a Grml stick in 2026. The image bundles the full recovery toolkit: partitioning and volume tools, editors, network clients, hardware diagnostics and backup utilities, all in a live environment that does not touch the disk. It is the tool you reach for when a server will not boot, when a broken GRUB needs repair, when a disk must be cloned, or when a machine must be audited before returning to production — without installing anything.
Building 2026.09 on Debian testing/forky has a consequence for anyone who keeps that reflex: the stick becomes a mirror of what Debian 14 will ship. The removed packages (speedtest-cli, tpm-udev, squashfs-tools) and the additions (ovmf, qemu-efi-aarch64, pydf, 3cpio) tell the direction of Forky: fewer orphaned niche tools, more EFI firmware for virtualization, and a step up in reproducibility. For a sysadmin, it is a useful preview at low cost.
Reproducibility and Raspberry Pi
On architectures, the departure of i386 is the headline: 2026.09 now runs only on amd64 and arm64, a logical consequence of 32-bit hardware vanishing from fleets. The arm64 support targets the same family as Raspberry Pi devices, where grml-debootstrap now generates reproducible disk identifiers via FIXED_DISK_IDENTIFIERS=yes and SOURCE_DATE_EPOCH. For anyone rebuilding images in an auditable way, that is a concrete gain: two builds from the same source produce the same disk, bit for bit.
The cadence remains that of a conservative project: two stable releases a year, the next due in late 2026. It is a deliberately slow rhythm for a rescue tool — stability beats novelty, and each release takes time to absorb the changes in Debian testing.
Verdict
If you keep a Grml rescue USB stick, refresh it to 2026.09: you gain kernel 7.1.8, the Debian 14 Forky base, and exFAT boot — but check your screenrc against GNU Screen 5.0.1 first, and use grml2usb 0.20.14 or newer.
If you maintain Grml-derived images, audit your build pipeline for user namespace compatibility: it is the new grml-live requirement, and it breaks classic containerized builds.
If you just want to evaluate Debian 14 before release, the 2026.09 image is a clean way to do it read-only, without touching a production machine.