filesystem issues/failures after kernel update to 6.1

[acidicX]

After updating to kernel-rpi 6.1 today I'm having filesystem issues on my pi4.

It seems to have some kind of file corruption even on my root drive (ext4), e.g. permissions going haywire (cannot install anything in my home folder), and also on the second partition using btrfs, which crashes the whole system when I'm trying to mount it. Both are on the same USB NVME SSD.

Sadly, it even corrupts the journal so I can't send any debug output and the messages are flashing so fast on the screen that I can't take a photo.

$this->bbcode_second_pass_code('', '
$ journalctl -b -1
Data from the specified boot (-1) is not available: No data available
')


I'm also locked out of the system via ssh ("system shutting down") when the errors occur after trying to mount the btrfs filesystem.

I've downgraded to 5.15.90-1-rpi-ARCH and everything works fine again...
Has anyone any ideas on how to debug this or what could have caused this?

[graysky]

Recommend that you open a ticket against RPi's kernel: https://github.com/raspberrypi/linux/issues/new/choose

You can consider posting in their thread as well, there are several developers actively monitoring it: https://forums.raspberrypi.com/viewtopic.php?t=344246

[acidicX]

Hi @graysky,

thanks for the hint, but they don't seem to be quite open to the idea:

$this->bbcode_second_pass_quote('', '
')This thread is about using rpi-update to test our kernel builds that will eventually be used as default in RPiOS.
The Arch kernel wasn't built by us, and we don't know what tree or config options it was built with.
Issues are best reported on an Arch forum.

[graysky]

I do not have a spare drive laying around to test your setup. Please open an issue against their kernel. The thread is apparently scoped down to RPiOS.

[robg]

It is certainly beneficial to get feedback on the RPI forum as well.

Although not exactly the same setup as on ALARM, you can install RPI OS and test the faulty/functioning kernel (check the PKGBUILD, there you find the commit at which the kernel was compiled.) If you experience the same issue as on ALARM, this is strongly indicative of a kernel regression that should be reported upstream.