dracut/initramfs: 6.6.54_1 fails to mount root partition

[dezifit]

Is this a new report?

Yes

System Info

Void 6.6.54_1 x86_64 libc

Package(s) Affected

linux-6.6_1

Does a report exist for this bug with the project's home (upstream) and/or another distro?

After updating the kernel from 6.6.51_1 to 6.6.54_1 the systems fails to mount the root partition and boots into the recovery console.

/run/initrunfs/rdsosreport.txt shows: dracut Warning: Failed to mount -t jfs -o ro,ro /dev/disk/ny-uuid/<correct uuid> /sysroot

Manual invocation of fsck /dev/sda1 gives Filesystem is clean., but manual mount with mkdir -p /mnt; mount /dev/sda1 /mnt fails with: mount: /mnt: wrong fs type, bad option, bad superblock on /dev/sda1

Choosing the last working kernel 6.6.51 in grub boots the (grub legacy bios) system without any issue. I have already recreated the initramfs with dracut --force --kver $(uname --kernel-release), but it fails with the same same error. Are there JFS related changes in the kernel configuration? Any ideas?

Expected behaviour

Regular system boot.

Actual behaviour

Can't mount root partition.

Steps to reproduce

100% reproducible on the failing system.

[dezifit]

Some more testing shows that the dracut-emergency environment is able to mount another JFS partition just fine. Only the root partition fails, even after a forced filesystem check, which just confirms a valid superblock and clean filesystem.

I tried with kernel 6.11.2 (also fails to boot, same symptom), did a memcheck (passed without error) and finally switched back to the still working kernel 6.6.51 after running out of ideas.

It looks like a strange issue of the specific root partition, therefore I will close this ticket if there is no participation.

[witseid]

I had similar problems with booting the 6.6.54 kernel, not sure what that might be related to. I had to go back to version 6.6.51.

[Katnjia]

I can confirm this is an issue with Dracut and kernel 6.6_54 and up. Broke my system with ZFS root where it couldn't find the root partition, and switching over to mkinitcpio generated initramfs images that works with newer kernels.

[dkwo]

One option could be to try other initramfs: as suggested mkinitcpio, or maybe tinyramfs?

[classabbyamp]

are you sure it wasn't just a single bad initramfs? xbps-reconfigure -f linux6.6 will regenerate it

[dezifit]

I regenerated the initrafs with xbps-reconfigure now again (in addition to to direct dracut invocation before). Still fails to boot.

This system has 3 partitions:

• root (jfs, sda1) - mount of clean filesystem fails
• home (jfs, sda2) - mount of clean filesystem fails
• data (jfs, sda4) - mounts just fine

Katnjia has issues with ZFS root,
witseid, which filesystem type is involved in your case?

[witseid]

I regenerated the initrafs with xbps-reconfigure now again (in addition to to direct dracut invocation before). Still fails to boot.

This system has 3 partitions:

• root (jfs, sda1) - mount of clean filesystem fails
• home (jfs, sda2) - mount of clean filesystem fails
• data (jfs, sda4) - mounts just fine

Katnjia has issues with ZFS root, witseid, which filesystem type is involved in your case?

btrfs

[witseid]

I get stuck on displaying the UEFI logo when trying to boot from a linux6.6.54 kernel

[classabbyamp]

can you compare the contents of the initramfs? diff -u <(sudo lsinitrd /boot/initramfs-6.6.x_1.img) <(sudo lsinitrd /boot/initramfs-6.6.54_1.img) (this syntax requires bash/zsh)

[dezifit]

Losts of differences because of date/time, see attached lsinitrd.zip.

[classabbyamp]

attachment missing?

[dezifit]

attachment missing?

lsinitrd.zip

[classabbyamp]

can you also post the lsinitrd of each version by themselves?

[dezifit]

can you also post the lsinitrd of each version by themselves?

lsinitrd-2.zip

[classabbyamp]

ok, removing obvious differences (timestamp, kernel version), i don't see anything significant there

[dezifit]

I've created a JFS specific kernel ticket and received a patch which fixes the problem for me. As far as I'm concerned this ticket can be closed now as my issue is unrelated to Void Linux.