Linux 7.3 Btrfs fixes filesystem IDs and grub2 boot

Linus Torvalds has merged a set of Btrfs fixes into the Linux 7.3 kernel, and two of them undo changes that broke working machines. One made the identifier Btrfs reports about itself unstable. The other stopped some computers from finishing their boot.

Btrfs is a file system built into Linux. It is the default choice on Fedora and on openSUSE, so a regression in it reaches ordinary desktops, not just servers. The pull request came from Btrfs maintainer David Sterba and carries the tag for-7.3-rc3-tag. Phoronix reports that the fixes land in the 7.3-rc4 release candidate.

Why the filesystem ID stopped being stable

Every mounted file system reports an FSID, short for file system identifier. Programs read it to tell one file system apart from another. Sterba's pull request lists the first problem as "filesystem id stability on default configurations".

Phoronix reports that the regression arrived in Linux 7.2-rc1. From that point the ID Btrfs reported on a default setup could change. Software that had stored the earlier value then read a different one.

The pull request names the casualty directly: "openconnect key derivation". OpenConnect is an open-source client for corporate VPNs, and NetworkManager ships support for it. Phoronix ties the breakage to that VPN support. When a key is derived in part from a value that suddenly changes, the key no longer matches.

Why some machines stopped booting

The second fix restores "/dev/root detection for initramfs-less boot systems with grub2", in Sterba's words.

An initramfs is a small temporary file system. The kernel loads it early in boot and uses it to find the real root file system. Most distributions ship one. Some setups skip it to boot faster or to keep the configuration simple.

Without an initramfs, the kernel has to work out on its own which device holds the root. Phoronix reports that this detection failed on Btrfs root file systems booted by GRUB2. A machine that cannot identify its root file system does not finish starting up.

What else is in the pull

The merge changes 10 files, adds 96 lines and removes 13. Sterba's message describes the rest as regular fixes, listed below with a plain-language note on the area each one touches.

Area listed in the pull	What that part of Btrfs does
Compressed inline extents	Stores very small files compressed inside metadata
Zoned mode zone activation	Supports drives that must be written in fixed zones
Chunk item space validation	Checks the records that map storage chunks
Verity item removal	Cleans up fs-verity data, which verifies file contents
Free space tree rebuild	Handles errors while the free-space map is rebuilt
Reflink and hole punching	Copies blocks by reference, and frees ranges inside files
Block group iteration	Guards a walk over groups of allocated blocks
Error messages	Corrects wording in kernel log output

The changed files include super.c, volumes.c, disk-io.c, inode.c, tree-checker.c, zoned.c and verity.c.

What this means for developers

Treat an FSID as a value that can change. If your code stores one and expects it to survive a kernel upgrade, that assumption just failed in production for VPN users. Read the identifier fresh, and have a path for the case where it differs from the one you saved.

If you maintain machines with a Btrfs root and no initramfs under GRUB2, do not roll Linux 7.2 onto them. Wait for a 7.3 kernel that carries this pull, or keep an initramfs in place as a fallback. Ubuntu 26.10 ships a pre-release 7.3, so check which release candidate your image contains before you trust it.

There is a wider lesson in the first bug. Any value that user space can read is an interface, even when no document says so. A kernel change that alters one will break software nobody thought to test.