Linux: Ext4 data corruption in 6.1.64-1
bugs.debian.org
Linux: Ext4 data corruption in 6.1.64-1
1–10 of 138 posts
Re: Linux: Ext4 data corruption in 6.1.64-1
#2Related: "Debian 12.3 image release delayed" https://lists.debian.org/debian-announce/2023/msg00005.html
Re: Linux: Ext4 data corruption in 6.1.64-1
#3ZFS's own recent file system corruption issue is in roughly the same category of edge case, but accessible to reasonable if niche workloads.
Re: Linux: Ext4 data corruption in 6.1.64-1
#4I'm not sure if that's a standard value, but it made me chuckle a little.
Re: Linux: Ext4 data corruption in 6.1.64-1
#5As someone who is heavily dependent on zfs, this is a little bit of reassurance. Sad that data corruption exists in any file system that is shipped too many people, but reassuring that it happens to the most stable and least "interesting" in the newness sense file systems. ZFS's own recent file system corruption issue is in roughly the same category of edge case, but accessible to reasonable if niche workloads.
Re: Linux: Ext4 data corruption in 6.1.64-1
#6Re: Linux: Ext4 data corruption in 6.1.64-1
#7"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.
Re: Linux: Ext4 data corruption in 6.1.64-1
#8As someone who is heavily dependent on zfs, this is a little bit of reassurance. Sad that data corruption exists in any file system that is shipped too many people, but reassuring that it happens to the most stable and least "interesting" in the newness sense file systems. ZFS's own recent file system corruption issue is in roughly the same category of edge case, but accessible to reasonable if niche workloads.
Yeah, all the threads full of folks bashing on ZFS because their trusty ext won’t corrupt data should be eating crow right about now, but I’m sure they’ll hop in and explain why this bug is different.
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 original patch authors, hoping (With some limited testing on top) that the resulting frankenkernels will still work and all these patches will have satisfied dependencies applied, too.
I don't trust this process very much, and just run the latest stable branch for the latest kernel release, only. Staying with older stable release branch for too long seems too risky, unless you're some bigcorp that can afford the testing required, or you're running some highly mainstream setup that is probably covered by tests done by the stable team, and testing teams they cooperate with.
Re: Linux: Ext4 data corruption in 6.1.64-1
#9In 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.
Re: Linux: Ext4 data corruption in 6.1.64-1
#10In 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.
Most likley because you stopped the wrong service. You should have stopped the relevant timer service, not the service that the timer starts.