Debian 12.3 Delayed Due To An EXT4 Data Corruption Bug Being Addressed

[rk17]

"data corruption bug that is found on the likes of Linux 6.1.64 and 6.1.55 point releases"
It should be probably 6.1.65 instead of 6.1.55 as LTP test preadv03 passes on debian 6.1.55

Screenshot_20231210_225436.png

[pWe00Iri3e7Z9lHOX2Qx]

Based on many previous comments, the way this article was written could obviously be misconstrued into a Debain bug. A title like "Data corruption bug makes its way into stable kernel series of most widely used Linux file system" would have been more appropriate.

[Manfred.Tremmel]

What should I do if I'm already running this kernel on a vserver?
bookworm-backports would have kernel 6.5.10, but other than that?

Don't wait for the mirrors, do the update manually:

cd /tmp
​wget https://ftp.debian.org/debian/pool/main/l/linux-signed-amd64/linux-image-6.1.0-15-amd64_6.1.66-1_amd64.deb
​apt install ./linux-image-6.1.0-15-amd64_6.1.66-1_amd64.deb
​reboot

[unwind-protect]

What specific issue was the cherry-picked backport supposed to address?

[avis]

where are all those saying that they'll never us ZFS or btrfs because ext4 is so much more reliable? 😬

It's been quite reliable and this incident is not an exception since this kernel version is not widely used though it definitely proves a lack of QA/QC in the kernel.

[sophisticles]

Turns out, when it comes to filesystems, the most reliable setup is NTFS on Windows

But seriously, I know that Windows NT is closed source, but despite the fact that its userland may suck, I don't think the NT kernel suffers from this amount of serious regressions like Linux lately does, especially in filesystems.

You are 100% correct.

Time and again it has been proven that the closed source, for profit, model is superior because of accountability.

If MS released a kernel update that caused data corruption, even "non-serious data loss", they would be skewered by the press, there might be investigations and so on.

But with Linux, it's hard to hold anyone accountable, especially since in most cases there isn't anyone selling anything,

Having said this, there is also another idiocy at play here, one that many on the Linux community seem to do and that's back-porting patches from newer kernels to older kernels and for the life of me i do not understand the reasoning behind this.

Ubuntu does it with the so-called hardware ennoblement stack, Debian apparently does it, I'm sure other distros do it, and I just don't get it.

What is the point of releasing a new kernel if these people are just going to Frankenstein portions of the new kernel into an older version?

Why not just update to the new kernel altogether?

For years i have been toying with the idea of releasing my own distro and years ago i did build a barely functioning prototype but lately I have decided to finally do it.

This is not a joke, I am working on a distro that I hope to release soon.

The basic philosophy will be as follows:

1) Only LTS kernels will be used.

2) The only package manager will be flatpak.

3) Custom GUI that allows the user to choose a package to be downloaded and built from source right on their system.

4) No updates. Every year there will be a new version, for instance Blah Blah Linux 2023, Blah Blah Linux 2024.

5) A closed source AI assistant that is hardware accelerated. This will be closed source because i plan on trying to market it and will use this distro as a proving ground.

That is all i am revealing for now.

[cynic]

It's been quite reliable and this incident is not an exception since this kernel version is not widely used though it definitely proves a lack of QA/QC in the kernel.

yes, I know. Fact is that a Debian users using ext4 might have got corruptions.

Is it Debian fault? Is it kernel dev fault? Is it christmas elves fault?
Who cares. The result is always fs corruption using ext4.

[pWe00Iri3e7Z9lHOX2Qx]

It's been quite reliable and this incident is not an exception since this kernel version is not widely used though it definitely proves a lack of QA/QC in the kernel.

LOL. This update was available to everyone on Debian 12, and any other distro or person tracking the current LTS release branch.

[fitzie]

What specific issue was the cherry-picked backport supposed to address?

backports to LTS trees are mostly automatic, looking for any patch that claims to be a "fixes" and applies it, cc'ing authors so that any automation failure (such as missing dependent fixes, or just general insuitability) being highlighted. it's a mad process, but "works" most of the time. some filesystems like xfs don't do this at all, ensuring all fixes are manually backported, but at the same time they don't support all current LTS branches, so while their LTS are not regressions, they do contain known issues.

Running an LTS branch without significant QA (such as with an enterprise distro, or debian in this example) is not a significantly safer place to be then just running the current stable, which more closely approximates the code base that is being developed against.

[heliosh]

It appears to be fixed now in the repository.
I wonder if I can find out whether it has broken something. I have a backup of some files to compare with, but.. eh..