Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Linux: Ext4 data corruption in 6.1.64-1

bugs.debian.org

Post reply on HN
Print view View original

91–100 of 138 posts

Re: Linux: Ext4 data corruption in 6.1.64-1

#91

Post by gcr »

mike_hock wrote: post #72
u_name wrote: post #64

Earlier quoted context omitted.

Aren't this days over?

If they are, then that's why the quality is declining.

“Verbal abuse is a necessary component of effective software reliability engineering!”

“If my file system developer hasn’t been through the Full Metal Jacket experience, I don’t trust the code they write!”

“Linux is going down the toilet! What we really need is leadership from a guy who’s VERY angry all the time!”

Sure, giving good candid feedback is a gift, but degradation isn’t a necessary part of honesty.

Re: Linux: Ext4 data corruption in 6.1.64-1

#92

Post by dezgeg »

keep_reading wrote: post #82
megous wrote: post #8

Earlier quoted context omitted.

It's not an extfs bug, it's a "stable kernel" process bug. Linux master branch/mainline was never affected by this bug. Someone cherry-picked a wrong patch into stable without realizing the consequences, and it was caught too late. Stable process is cherry pincking thousands to tens of thousands of patches from the current master kernel branch into years old kernel branches, spraying tens of thousands of emails at or…

Nobody ships vanilla kernels. Sure the reference implementation was unaffected but users never experience vanilla Linux kernels

Distros like Arch and NixOS use the vanilla kernel with very small amount (single digits) of patches on top. For the purposes of ext4, it's very likely to be as-is with vanilla. (I am counting the official linux-stable releases from kernel.org as 'vanilla' here.)

Re: Linux: Ext4 data corruption in 6.1.64-1

#93

Post by branon »

esbeeb wrote: post #7

In Debian bookworm: "sudo systemctl stop unattended-upgrades.service" ... wasn't able to prevent unattended-upgrades from going on ahead and just upgrading (to this problematic kernel) anyway. Unintuitively, the "right" way to disable unattended-upgrades is: "sudo dpkg-reconfigure unattended-upgrades" ...and choose "No" when asked.

systemctl stop is a oneshot operation, right? Perhaps sudo apt remove unattended-upgrades?

Re: Linux: Ext4 data corruption in 6.1.64-1

#94

Post by remram »

LoganDark wrote: post #83
userbinator wrote: post #18

Earlier quoted context omitted.

I think "corruption you can recover from" seems far too vague; you can recover from any corruption with backups.

Sure, and you can recover from any hardware failure with a separate computer. In fact, you can recover from death simply by cloning yourself. What's the issue? The issue is that some people don't have the time, money, and/or willpower to invest in backups. Some people only have one volume, or one copy of each volume at least, and need to recover their data using only that one volume if something gets corrupted. That'…

I think you're agreeing with userbinator here.

Re: Linux: Ext4 data corruption in 6.1.64-1

#96

Post by dang »

15457345234 wrote: post #46
Grimburger wrote: post #38

Earlier quoted context omitted.

Most data is recoverable albeit slow to do. It takes some very bad conditions or intentional actions to make data recovery impossible. Current high level standards for military/diplomatic data sanatisation are complete physical destruction of hard disks. Even linux tools like shred have given up saying they can actually delete data from disks due to how SSD's work these days.

[flagged]

Could you please stop posting unsubstantive comments and flamebait? You've unfortunately been doing it repeatedly. It's not what this site is for, and destroys what it is for.

If you wouldn't mind reviewing https://news.ycombinator.com/newsguidelines.html and taking the intended spirit of the site more to heart, we'd be grateful.

Re: Linux: Ext4 data corruption in 6.1.64-1

#97

Post by remram »

Blikkentrekker wrote: post #22
Lt_Riza_Hawkeye wrote: post #19

Earlier quoted context omitted.

The problem here was Debian's distribution process. Any distro compiling linux from the releases on kernel.org was not affected.

So this is another bug introduced by Debian itself by patching things? I remember that there was a fairly severe one which was caused by patching OpenSSL I think? But I remember the change they made being fairly weird and no one understood why but it was easy to see that it would introduce a vulnerability.

No, it exists in the upstream release.

Re: Linux: Ext4 data corruption in 6.1.64-1

#98

Post by LoganDark »

remram wrote: post #94
LoganDark wrote: post #83

Earlier quoted context omitted.

Sure, and you can recover from any hardware failure with a separate computer. In fact, you can recover from death simply by cloning yourself. What's the issue? The issue is that some people don't have the time, money, and/or willpower to invest in backups. Some people only have one volume, or one copy of each volume at least, and need to recover their data using only that one volume if something gets corrupted. That'…

I think you're agreeing with userbinator here.

Not really. They're arguing that backups count as recovering from corruption, where my argument is that backups don't count because the only thing you're doing is discarding the corruption, not recovering from it. You're basically throwing the corruption out and getting your data back from somewhere else.

So you recover your data, but not from the corruption. You recover it from a backup. Similar, but not the same thing.

Re: Linux: Ext4 data corruption in 6.1.64-1

#99

Post by jacooper »

Narishma wrote: post #84
jacooper wrote: post #76

It seems they have frozen the roll out of 6.1.0-14 too? Did they just freeze all Kernel Updates using `HTTP 403 - broken package ` as a response?

That version is the one (or one of the ones) affected. I'm guessing that's why they froze it, though why they didn't replace it with a newer one, or even the old safe version I'm not sure.

Honestly the handling of this bug is horrendous to say the least, why can't they just retract the update? Why do people have to actively avoid updating to avoid this?

This doesn't help debians reputation.

Post reply on HN