linux kernel 6.1.0.15 causing crashes in mx linux 23.1 flagship Xfce edition?

[MadMax]

Yup, I'm running the update just right now I will definitely make sure to keep -13 around as well, just in case...

[Franky13]

@MadMax I do that as well.

[Charlie Brown]

... any commands or anything I can do to help restore the filesystem if any thing was damaged?

fsck

You can also do this: If you're able to boot to a live session: GParted , right-click on partition(s) : "Check".

[l0dr3]

... any commands or anything I can do to help restore the filesystem if any thing was damaged?

fsck

You can also do this: If you're able to boot to a live session: GParted , right-click on partition(s) : "Check".

Due too the special nature and the potential damage sparked by the ext4-bug , a classic 'fsck' will report nothing serious (/impe/), have a look at this post on the bugtracker

https://bugs.debian.org/cgi-bin/bugrepo ... 1057843#98

:
Then I used `last` to identify the time between the problematic reboot into 6.1.0-14 and the deliberate reboot (back in to 6.1.0-13)

This showed me that the 'problem time' was between 2023-12-10 06:00:00 and 2023-12-10 19:00:00 (UTC).

From there, I ran the followin gcommand to show me all files that were modified more or less between that time. I ignore a bunch of things I don't care about such as /var/log and other volatile parts of the filesystem.

find / -type f -newermt "2023-12-10 05:59:00" \! -newermt "2023-12-10 19:00:00" | egrep -v "/proc|/run|/sys|/var/log"

At least this gave me a somewhat small subset of files to manually check, which made it feel less daunting. Naturally it depends on your filesystem what files might've changed.

I was fortunate that none of the client applications I use, seem to use O_DIRECT, so I found no corrupted files (so far).
:

lodr3 (on whos two affected boxes, that have been ~18h on the way with the problematic 6.1.64 and 6.1.65 kernels ): no data corruption detected (thus far ...)

edit (sorry): still w#all that versioning (esp.: bcof of contemporaneous :zfs-bug: )

[MadMax]

fsck won't hurt (I actually did it on all my disks after booting into 6.1.0-15 before I knew further details about the bug), but it will not detect errors created by the faulty kernels. These errors are all within file data, not metadata and since ext4 has no built-in checksums, there is really no way to find the errors. The only way to go about it is to isolate files that have been changed while the kernel was active and manually check them.

On the bright side, the error would only happen if the writing program used O_DIRECT which is really, really uncommon for desktop applications. O_DIRECT means the program tells the kernel to bybass all kernel caching and write directly to the disk. That means that program has to take care of caching itself which really is only beneficial for specialized applications like databases (MySQL, MariaDB etc). Regular desktop applications will almost always use kernel caching with something like fsync. Same goes for system tools like apt, so I'm not really worried that installing the 12.4 update including 6.1.0-15 while running 6.1.0-14 could have damaged anything in the root filesystem.

One way to examine further whether you might have affected files is to check the programs you use via strace and search in their actual syscall for O_DIRECT (also don't panic if you grep for it, there is a syscall named O_DIRECTORY which has nothing to do with the former one).

[Charlie Brown]

If you do the fsck / e2fsck / GParted on live session with an official iso (as suggested above):

The kernel is 6.1.0.10 (on MX-23) and 6.1.0.13 (on MX-23.1) or other non-buggy ones with previous releases.

[l0dr3]

fsck won't hurt (I actually did it on all my disks after booting into 6.1.0-15 before I knew further details about the bug), but it will not detect errors created by the faulty kernels. These errors are all within file data, not metadata and since ext4 has no built-in checksums, there is really no way to find the errors. The only way to go about it is to isolate files that have been changed while the kernel was active and manually check them.

On the bright side, the error would only happen if the writing program used O_DIRECT which is really, really uncommon for desktop applications. O_DIRECT means the program tells the kernel to bybass all kernel caching and write directly to the disk. That means that program has to take care of caching itself which really is only beneficial for specialized applications like databases (MySQL, MariaDB etc). Regular desktop applications will almost always use kernel caching with something like fsync. Same goes for system tools like apt, so I'm not really worried that installing the 12.4 update including 6.1.0-15 while running 6.1.0-14 could have damaged anything in the root filesystem.

One way to examine further whether you might have affected files is to check the programs you use via strace and search in their actual syscall for O_DIRECT (also don't panic if you grep for it, there is a syscall named O_DIRECTORY which has nothing to do with the former one).

thx for this detailed explanation!

My greatest concern about direct-i/o and O_DIRECT was 'rsync', bcof i used heavily timeshift-snapshots, taken during the period, the faulty kernels were running, to solve my ZFS issues, but - fortunately - 'rsync' does not use O_DIRECT, as far as i have g00gled! OR?

[SimplyFojin]

If you do the fsck / e2fsck / GParted on live session with an official iso (as suggested above):

The kernel is 6.1.0.10 (on MX-23) and 6.1.0.13 (on MX-23.1) or other non-buggy ones with previous releases.

Luckily after I updated today, 6.1.0-13 and -10 are still there. Even though 6.1.0-16 works, 6.1.0-15 still shows up. And thats very problematic given that kernel version crashes my computer.

[Charlie Brown]

When booted with -10 or -13 or -16 you can remove the -14 and -15 simply with 2 clicks with "MX Cleanup" - 'Kernel Removal Tool' below the window :)

[PlatinumArts]

When booted with -10 or -13 or -16 you can remove the -14 and -15 simply with 2 clicks with "MX Cleanup" - 'Kernel Removal Tool' below the window :)

16 is working perfectly and MX cleanup removed 15 easily, thank you so much for the tip and for all of your help!
- Mike