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

51–60 of 138 posts

Re: Linux: Ext4 data corruption in 6.1.64-1

#51

Post by lpcvoid »

Grimburger wrote: post #38
Animats wrote: post #6

"Causes non-serious data loss". What does that mean. Only affects cat videos?

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.

I don't agree - modern NVME drives have secure erasure mechanisms. All data is by default encrypted on-the-fly within the flash memory, and when requesting a secure erase, the controller throws away the key and generates a new one.

https://man.archlinux.org/man/nvme-format.1

Re: Linux: Ext4 data corruption in 6.1.64-1

#52

Post by yrro »

KAMSPioneer wrote: post #36
esbeeb wrote: post #27

Earlier quoted context omitted.

Can you give example code to stop that timer?

It's the same, but you disable the timer instead of the service. `sudo systemctl stop unattended-upgrades.timer`

It will still start when you next boot up. 'systemctl disable --now unattended-upgrades.timer' will stop it now _and_ remove the symlink that starts it at boot.

Re: Linux: Ext4 data corruption in 6.1.64-1

#54

Post by asystole »

cpach wrote: post #37
mgdhar wrote: post #13

Curious why it doesn’t happen on GNU? Context: This is seen in the following environments: > > > * dragonboard-845c > > > * juno-64k_page_size > > > * qemu-arm64 > > > * qemu-armv7 > > > * qemu-i386 > > > * qemu-x86_64 > > > * x86_64-clang

What do you mean by GNU here? The bug is in the Linux kernel, specifically in the code for the ext4 filesystem. There are not many systems out there who runs a GNU kernel.

I think they're referring to the `x86_64-clang` part (`clang` vs `gcc`).

Re: Linux: Ext4 data corruption in 6.1.64-1

#56

Post by jbverschoor »

yrro wrote: post #52
KAMSPioneer wrote: post #36

Earlier quoted context omitted.

It's the same, but you disable the timer instead of the service. `sudo systemctl stop unattended-upgrades.timer`

It will still start when you next boot up. 'systemctl disable --now unattended-upgrades.timer' will stop it now _and_ remove the symlink that starts it at boot.

Probably better to mask it instead if you don't want it to execute at all

Re: Linux: Ext4 data corruption in 6.1.64-1

#57

Post by vocworker »

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.

dpkg-reconfigure is really important and maybe a bit outdated, but definitely something users should know? I think it's also responsible for turning 'apt upgrade' into a little text adventure, e.g. by showing lots of prompts like "Do you want to replace/skip your sshd config"?

Re: Linux: Ext4 data corruption in 6.1.64-1

#58

Post by jbverschoor »

vocworker wrote: post #57
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.

dpkg-reconfigure is really important and maybe a bit outdated, but definitely something users should know? I think it's also responsible for turning 'apt upgrade' into a little text adventure, e.g. by showing lots of prompts like "Do you want to replace/skip your sshd config"?

It's better to use configuration / override directories such as sshd_config.d/ to specify customizations.

Re: Linux: Ext4 data corruption in 6.1.64-1

#59

Post by csdvrx »

lpcvoid wrote: post #51
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.

I don't agree - modern NVME drives have secure erasure mechanisms. All data is by default encrypted on-the-fly within the flash memory, and when requesting a secure erase, the controller throws away the key and generates a new one. https://man.archlinux.org/man/nvme-format.1

In "reduce, reuse, recycle", this is the #2 R

Please don't trash physically good drives with a hammer. It's not good for the environment (or the drives!) when you have such a simple technology at your disposal!

Re: Linux: Ext4 data corruption in 6.1.64-1

#60

Post by csdvrx »

burtness wrote: post #31
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.

This is a misreading of the bug. It is from upstream stable kernels before 6.5 that include commit 91562895f803 but not 936e114a245b6[1]. In this case Debian's current process is good - it's kernels track kernel.org stable releases. This debian bug is responsibly flagging "for visibility" that a serious bug has been discussed and fixed upstream. [1] https://lore.kernel.org/stable/20231205122122.dfhhoaswsfscuh...

Do you have a link to just the 2 patches (in patch form) that could be before on a kernel tarball to revert these 2 changes?
Post reply on HN