Kernel kerfuffle kiboshes Debian 12.3 release

A mis-merged patch causing corruption on ext4 volumes is to blame

The Debian maintainers have identified a problem in kernel 6.1 that can cause corruption on ext4 volumes. As a result, the planned 12.3 release won't happen.

The issue is Debian bug #1047843, and it's been assigned a severity level of "grave" – which is worse than "serious" and only one step down from "critical."

Unfortunately, the issue was identified while the rollout of Debian 12.3 to the various mirror servers was already under way. As a result, the rollout of 12.3 has been cancelled. It will be replaced with version 12.4 instead.

What happened is a little complicated. At the time of writing, it seems that a small, performance-enhancing change from November 1 was back-ported to the long-term support version of kernel 6.1. SUSE kernel developer Jan Kara isolated the problem, and reported it to the kernel mailing list.

It turned out that the November 1 change required another, different change from June 10, which was not back-ported with it. With the June 10 change, the November 1 one is fine, so this is not a bug as such – there's nothing wrong with it, unless the earlier change wasn't made.

The issue seems to affect only kernel versions 6.1.64 and 6.1.65 – it was fixed in kernel 6.1.66. However, 6.1.66 introduced a new, different issue, also caused by the same type of problem: a minor fix was back-ported without the earlier change it required. This change was reverted on December 11, resulting in kernel 6.1.67, which at the time of writing is the current version of 6.1 and resolves both issues.

We hope that's clear.

These dependency problems remind us of the bad old days of Linux in the late 1990s. During that time, package-management tools such as Red Hat's RPM command were not smart enough to track when one package required another package and work out on their own what other packages were needed to make something work. Installing small programs – such as a text editor – might involve manually tracing all its dependencies, making notes on paper or in a text file, and installing all of them. But of course the dependencies might have dependencies of their own, making this a recursive process. You might have to download a dozen packages just to get one to install.

The Reg FOSS desk still recalls the dread caused by upgrading KDE 1.x to KDE 2.x on an early version of Red Hat Linux, which required in excess of 200 packages to be manually identified, downloaded individually, and hand installed – in the right order, of course.

The first distro to fix this horrific process was Debian in 1999, when version 2.1 "Slink" came with the new Advanced Package Tool – or apt – which could do this for you automatically. Frankly, while Debian back then was still very intimidating, it gained a massive technical edge over Red Hat on the spot.

Red Hat eventually picked up the yum package manager from the PowerPC-specific Yellow Dog Linux, and regained some kind of parity. We think that it might have been included in Red Hat Linux 8 in 2002 – but if so, it wasn't mentioned in the release announcement.

It took nearly a decade for automatic dependency resolution to come to Linux distributions, and until it did, this just seemed to be an insolubly complex problem. Perhaps it's time for someone to invent some sort of automatic dependency tracking and resolution mechanism for Linux kernel code changes. ®

More about


Send us news

Other stories you might like