Debian maintainers have identified a problem in the 6.1 kernel that can cause corruption in ext4 volumes. As a result, the planned release of Debian 12.3 will not take place.
The problem is identified as Debian bug #1057843, and was rated with a severity level of “severe” – worse than “serious” and just one step below “critical.”
Unfortunately, the problem was identified while the rollout of Debian 12.3 to the various mirror servers was already underway. As a result, the rollout of version 12.3 has been canceled. It will be replaced with version 12.4.
What happened is a little complicated. At the time of writing, it appears that a small performance-enhancing change made on November 1st has been rolled back to the long-term kernel version 6.1. SUSE kernel developer Jan Kara isolated the problem and reported it to the kernel mailing list.
It turned out that the November 1st change required another different change, made on June 10th, which was not backtracked with it. With the June 10th change, the November 1st change is fixed, so it's not a bug per se – there's nothing wrong with it, unless the previous change was made.
The issue appears to only affect kernel versions 6.1.64 and 6.1.65 – it has been fixed in kernel 6.1.66. However, 6.1.66 introduced a new issue, also caused by the same type of issue: a minor fix was retroported without the necessary prior change.
This change was rolled back on December 11, resulting in kernel 6.1.67, which at the time of writing it is the current version of 6.1 and fixes both problems.
Let's hope that's clear.
These dependency problems remind us of the bad old days of Linux in the late 90s. During that time, package management tools like Red Hat's RPM command weren't smart enough to track when one package required another and figure out on their own what other packages were needed to make something work. Installing small programs – like a text editor – could involve manually tracing all its dependencies, making notes on paper or in a text file, and installing them all. But of course dependencies could have dependencies of their own, making this a recursive process. You may have to download a dozen packages just to get one to work.
Reg's FOSS desk still remembers the terror caused by upgrading KDE 1.x to KDE 2.x on an early version of Red Hat Linux, which required more than 200 packages to be manually identified, individually downloaded, and manually installed – in that order right, of course.
The first distribution to fix this horrible process was Debian in 1999, when version 2.1 “Slink” came with the new Advanced Package Tool – or apt – that could do it automatically. Frankly, while Debian was still very intimidating back then, it immediately gained a huge technical advantage over Red Hat.
Red Hat eventually adopted the yum package manager from Yellow Dog Linux specifically for PowerPC and regained some sort of parity. We think it may 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 make its way to Linux distributions, and up until that point, this seemed to be an intractably complex problem. Maybe it's time for someone to invent some sort of automatic dependency tracking and resolution mechanism for Linux kernel code changes.
