After a kernel update from 6.6.51 to 6.6.54 some systems fail to mount clean JFS filesystems at boot (from initramfs) and drop into the emergency console. In this case fsck shows that the filesystem is clean and nonetheless mount fails with result: `mount: /mnt: wrong fs type, bad option, bad superblock on /dev/sda1` Forcing a file system check with "fsck -f" makes no difference. Tested also with 6.6.55, 6.6.56 as well as kernels from 6.11 series. The initramfs environment (created with dracut) seems innocent, as it is able to mount another JFS partition on the same device. For example: * /root (JFS) on /dev/sda1 fails, * /home (JFS) on /dev/sda2 mounts just fine. Hardware and affected filesystems also seem innocent, as switching back to the last working kernel version (6.6.51) always is able to boot. The same issue happens on different hardware, with legacy Bios as well as (U)EFI, but not on all systems with the used Linux distribution (Void Linux). Because of the limited initramfs environment debugging is difficult and "dmesg" shows no addtional informations. Any idea howto trace or solve the problem would be very appreciated.
On 10/22/24 6:43AM, bugzilla-daemon@kernel.org wrote: > https://bugzilla.kernel.org/show_bug.cgi?id=219417 > > Bug ID: 219417 > Summary: Mount of clean filesystem fails (6.6.54 and later) > Product: File System > Version: 2.5 > Hardware: Intel > OS: Linux > Status: NEW > Severity: normal > Priority: P3 > Component: JFS > Assignee: shaggy@kernel.org > Reporter: dezifit@gmx.de > Regression: No > > After a kernel update from 6.6.51 to 6.6.54 some systems fail to mount clean > JFS filesystems at boot (from initramfs) and drop into the emergency console. Can you try reverting commit c1ba4b8ca799 ("jfs: fix out-of-bounds in dbNextAG() and diAlloc()")? It is the only change to the jfs code between 6.6.51 and 6.6.54. Thanks, Shaggy > > In this case fsck shows that the filesystem is clean and nonetheless mount > fails with result: > `mount: /mnt: wrong fs type, bad option, bad superblock on /dev/sda1` > > Forcing a file system check with "fsck -f" makes no difference. > Tested also with 6.6.55, 6.6.56 as well as kernels from 6.11 series. > > The initramfs environment (created with dracut) seems innocent, as it is able > to mount another JFS partition on the same device. For example: > * /root (JFS) on /dev/sda1 fails, > * /home (JFS) on /dev/sda2 mounts just fine. > > Hardware and affected filesystems also seem innocent, as switching back to > the > last working kernel version (6.6.51) always is able to boot. > > The same issue happens on different hardware, with legacy Bios as well as > (U)EFI, but not on all systems with the used Linux distribution (Void Linux). > > Because of the limited initramfs environment debugging is difficult and > "dmesg" > shows no addtional informations. Any idea howto trace or solve the problem > would be very appreciated. >
Created attachment 307038 [details] [PATCH] jfs: Fix sanity check in dbMount Better yet, please try this patch.
I'm having the same issue, jfs filesystem mounts fine with 6.6.52 but fails to mount with no discernible error in syslog or dmesg after an upgrade to 6.6.58. I'll try the patch provided as soon as I have some spare time.
(In reply to Dave Kleikamp from comment #2) > Created attachment 307038 [details] > [PATCH] jfs: Fix sanity check in dbMount > > Better yet, please try this patch. Tried the patch and it fixed the problem on both tested machines.
(In reply to Dave Kleikamp from comment #2) > Created attachment 307038 [details] > [PATCH] jfs: Fix sanity check in dbMount > > Better yet, please try this patch. Works for me as well.
Fixed upstream by commit 67373ca8404f ("jfs: Fix sanity check in dbMount"). It should work its way into the stable trees soon.