By Grml 2026.09 — codename “Hättiwaritätti” — landed September 3 with Linux kernel 7.1.8, a Debian Forky base, and exFAT boot support from USB out of the box. The release is a clean incremental update. What is not clean: grml-live, the build framework for creating custom Grml-based rescue media, now requires Linux user namespaces, and Docker does not provide them inside containers. If your CI pipeline builds custom Grml images, it just broke silently.
The grml-live Build System Changed Significantly
This is the part that matters most if you build custom Grml-based live systems. grml-live underwent a major internal overhaul in this release, driven by a concrete problem: newer systemd versions refuse to run inside /proc-less chroots. The Grml team’s solution was to migrate grml-live to use Linux user namespaces instead of running everything as root on the host. That is the right call architecturally, but it carries real consequences.
First, Docker and most container runtimes do not expose Linux user namespaces inside containers by default. The Grml team noted this explicitly in the release notes: “unfortunately docker and other containerization tools do not provide Linux user namespaces inside containers.” Any automated pipeline invoking grml-live inside a Docker container is now broken.
Second, the grml-live.conf configuration file is gone. All configuration now happens via command-line arguments. The new build syntax:
# New grml-live syntax
grml-live image-create -s sid -c GRML_FULL ./output
# Before running, verify subuid/subgid are assigned to your user
grep "^$(whoami):" /etc/subuid /etc/subgidThird, chroot-based build workflows are temporarily unsupported and will return in a future release. Fourth, 32-bit (i386) architecture support is gone from grml-live entirely. The grml-live documentation covers the new CLI options in full.
The fix for Docker-based CI is straightforward but annoying: move the build to bare metal or a VM. The user namespace requirement is a hard kernel feature — you cannot fake it inside most container environments. Teams that need to keep building in containers should look at systemd-nspawn as an alternative to Docker for this specific workload, or wait for the chroot-based path to return.
exFAT Boot Is a Genuine Quality-of-Life Win
The headline user-facing improvement is exFAT support in the initramfs. Grml 2026.09 can now boot directly from USB drives formatted as exFAT. This matters because most USB drives sold today come pre-formatted as exFAT by default. Previously, writing Grml to one of these drives required reformatting to FAT32 or ext4 first. That friction is gone.
One note: if you write the ISO with grml2usb, make sure you are running version 0.20.14 or newer. Older versions will not handle this release correctly.
Kernel 7.1.8 and the Rest of What’s New
The jump from Linux 6.19 (Grml 2026.04) to 7.1.8 is notable. Linux 7.1, released in June, brought Intel FRED enabled by default, a rewritten NTFS driver with full write support, and Btrfs shutdown graduating out of experimental. ARM systems benefit from new futex instructions. All of that is now in the Grml rescue environment.
GNU Screen was updated to 5.0.1, and this carries a config incompatibility. If you use the old Grml screenrc with GNU Screen 4.9, switch to the screenrc_v4 file. A few smaller additions: grml-debootstrap now lets you select Debian Forky from its dialog interface, QEMU EFI firmware packages are included for EFI bootloader testing in VMs, and GRUB now bundles boot_hybrid.img inside ISO9660, making ISO remastering easier.
Download Grml 2026.09
Full and small ISOs are available for amd64 and arm64 from grml.org/download. Verify with the SHA256SUMS-2026.09 and SHA256SUMS-2026.09.gpg files on the Grml mirrors before writing to USB.
The user namespace migration is the right architectural direction — running build systems as root inside chroots was always a fragile approach. The Docker incompatibility is a real disruption for teams that built that way, and the Grml team knows it. If you are in that group, the path forward is clear: a VM, bare metal, or systemd-nspawn. The next release will likely restore the chroot path.
