The hardest part of upgrading a rescue distro is doing it before you actually need it. Most teams keep a Grml ISO in a drawer or on a labeled USB stick for the day a box refuses to boot, and they forget about it until 1 a.m. on a Tuesday. That is the audience the 2026.09 release has to serve, and that is the audience that should care about three specific changes in this build: a modern kernel, a working exFAT boot path, and a GNU Screen upgrade that quietly breaks long muscle memory.
The Grml 2026.09 release, codenamed Hättiwaritätti, is the first release in a while that meaningfully changes the boot experience on newer hardware. It is also the first in a long time where one of its defaults broke at the same time.
Why Linux 7.1 actually matters on a rescue stick
A 7.1 kernel release is rarely the kind of thing that gets a launch post. There is no big new filesystem, no dramatic scheduler rewrite. The work is the kind that adds up over time: a few dozen new drivers, a stack of security patches, hardware enablement for chipsets that did not exist when the previous branch shipped.
For a desktop you update weekly, this is invisible. For a rescue stick you only touch when something has already failed, it is the difference between the ISO booting your hardware at all and staring at an unhelpful error message. A few items worth knowing:
- Wi-Fi chipset coverage for laptops from the last two years, which matters when the only network port is broken
- Updated storage and graphics drivers that fix boot failures on hardware Grml 2026.04 sometimes refused
- A round of CVE patches, which is a real concern if you are imaging a compromised box
- Sound and input driver updates that improve the diagnostic experience when a headless box has no working display
None of this is a revolution. All of it is a one-line improvement on the day you actually reach for the stick.
The fix that earns its place: exFAT boot support
The single most useful change in this release is also the one with the smallest marketing footprint. Grml now ships an initramfs that can mount an exFAT-formatted USB stick early in boot, before the main filesystem takes over. That means you can drop the ISO onto any portable drive that came out of a Windows or macOS box and have it boot. For most people that removes the last reason to keep a separate Linux-only rescue stick around.
If your team standardizes on exFAT for portable drives, this is the release that lets you stop maintaining two sets of USB sticks. If your team still formats rescue media with FAT32 because that is how it has always been done, nothing here forces a change, but the option is now there without manual initramfs work.
The default that quietly broke: GNU Screen 5.0.1
This is the part of the release notes worth reading twice. Grml ships a custom screenrc tuned for system administration work, with keybindings and layouts that long-time users build muscle memory around. The 5.0.1 update changes that config in ways that do not roll back cleanly on older Screen versions.
You have two reasonable paths:
- Adopt the new screenrc and rebuild your muscle memory over the next week
- Pin to GNU Screen 4.9 and load the older screenrc_v4 file, if your runbook depends on the old layout exactly
If you maintain a documented recovery workflow that runs Screen, update the runbook before you boot the new ISO on a real incident. An hour of confusion during a live outage is the obvious failure mode, and it is fixable in ten minutes if it is on paper first.
Debian 14 Forky is already inside
Grml 2026.09 is built against Debian Testing as of early September 2026, which is the rolling pipeline that will eventually become Debian 14 Forky. So this ISO is, in a sense, an early preview of the next Debian release, wrapped in a recovery shell.
For most users that is invisible. For teams who script Grml boots to validate the next Debian before it ships, this release exposes Forky as an explicit boot target. That is a small but useful addition for anyone running a fleet upgrade rehearsal.
The trade-off is the usual one with Testing. You get early access to Forky, and you also inherit whatever breakage is still being polished out of the rolling branch. For a rescue stick you touch once every few months, that is fine. For a production image you ship to customers, the stable Debian branch is still the safer base.
grml-live builds got a new CLI, and i386 is gone
The grml-live build system, which is what teams use to roll their own Grml-based live ISO, ships a new command-line syntax in this release. If you maintain a custom Grml build, budget about thirty minutes to update your scripts and re-test your outputs. The CLI changes are clean, but they are not backwards compatible, so old scripts will fail loudly rather than silently produce wrong images.
The other quiet change is the end of 32-bit i386 images. If your team is still shipping i386 rescue ISOs for legacy hardware, that path is closed in this release and you will need to move those builds to amd64 or arm64. For most teams that is a planning conversation, not a fire drill, but it is the kind of thing that loops back around at exactly the wrong moment if you ignore it.
A few smaller items worth knowing:
- /etc/kernel-img.conf now defers to Debian defaults rather than being overridden by Grml
- FIXED_DISK_IDENTIFIERS=yes is implemented for GPT and Raspberry Pi builds, which makes reproducible images easier to verify
- New package additions include 3cpio as an initramfs-tools dependency, ovmf, qemu-efi-aarch64, and Pydf
- The boot dialog now exposes the Debian target as an explicit boot parameter, which helps kickstart scripts that pin a specific base
Trade-offs
The kernel bump and the exFAT fix are clear wins. The Screen 5.0.1 break is real and unavoidable if you keep your rescue workflow on the same machine year after year. The i386 image drop is the kind of change that affects a small number of teams heavily and most teams not at all, but if you are in the small group you already know.
The Debian Testing base is the deeper trade-off. You get a preview of Forky, and you also inherit whatever rough edges are still being polished in the rolling branch. For a rescue stick this is fine. For a customer-facing image, the stable Debian branch remains the right choice, and you should plan to fork Grml off the stable base rather than the Testing build if that is your model.
What I would tell past me
When Grml 2026.09 dropped, the temptation was to write it off as a routine maintenance release and move on. It is not a routine maintenance release. The kernel bump and the exFAT fix alone make the upgrade worthwhile for anyone whose rescue stick has been sitting in a drawer since 2025, and the Screen 5.0.1 break is the kind of thing that wastes an hour during a live incident if you do not see it coming.
Pick the version that matches your hardware, copy the ISO onto whatever portable drive you happen to have lying around, confirm it boots your test box once, and put it back. Then update any runbook that mentions GNU Screen, and add a note about the i386 build removal if your team still maintains legacy images. That is the whole upgrade, and it is an afternoon well spent.
Bottom line
Grml 2026.09 is the kind of release that rewards existing users and barely registers with anyone else. Linux 7.1 widens the hardware you can rescue, exFAT boot support removes a long-standing annoyance, and the GNU Screen 5.0.1 break is the one thing you want to know about before you boot the new ISO in anger. Download from the official site, write to a USB stick with dd or Ventoy, and confirm your hardware boots cleanly on 7.1 once.