Partition can't be mounted at boot but can be mounted by....

[Bluey_the_dog]

Dear all,
I'm in the process of building a new machine. The partitions are formatted jfs. I initially installed the latest gentoo-kernel-bin, I set up fstab and a whole lot of other stuff, rebooted the machine and all was good. All the partitions mounted etc.

I personally don't like initramfs so installed the latest source kernel, dropped the .config from the -bin kernel into the source kernel dir and went through converting from modules to builtin. After the drudgery of doing this, I recompiled, took the bzImage, dropped it into my /efi dir and rebooted. Refind sees the kernel and I can select it and it boots. Now though, during the boot, /home is no longer mounted, an error is thrown. The boot completes but the contents of /home are not there. The error is, and it's the same as to whether it be via booting or as root and issuing a mount command:

Code: Select all

bluey_new /mnt # mount -tjfs /dev/nvme1n1p4 /home
mount: /home: wrong fs type, bad option, bad superblock on /dev/nvme1n1p4, missing codepage or helper program, or other error.
       dmesg(1) may have more information after failed mount system call.

It does not matter if I include -tjfs or -t jfs or not at all, the error is the same.

Now the really frustrating thing is that the root partition is ALSO jfs and it boots fine. I'm sitting here ssh'd into the new machine from my old, pulling example code/errors etc off the new for this post.

To the best of my knowledge, the partition isn't broken. I have also booted the new machine with two live sticks, sysrescuecd & the gentoo live stick I originally built the machine from and I can manually mount the /home partition to something under /mnt. As the partition is empty, I have also deleted the partition and recreated via the sysrescuecd stick, still the problem persists.

It took a few shutdowns/reboots before I noticed this problem and during this time, I deleted the -bin kernel. In frustration, after going through the kernel config thingy many times looking for error's, I've reinstalled the -bin kernel, rebooted and /home is now there. I know it is the /home partition and not the /home from the root partition as I touched a file, fred.txt, into the root of /home when I had it mounted via sysrescuecd and I can see it. I have not changed fstab, I can reboot, boot the source kernel - no /home. Reboot, select -bin and /home is there. Rinse and repeat.

The error says to look in dmesg for possible causes - I've looked and there is nothing. On the other hand, looking back through dmesg, I did see that ntfs3 has tried to mount the root partition:

Code: Select all

[    4.323070] md: Autodetecting RAID arrays.
[    4.323355] md: autorun ...
[    4.323623] md: ... autorun DONE.
[    4.332969] ntfs3: nvme1n1p3: Primary boot signature is not NTFS.
[    4.333252] ntfs3: nvme1n1p3: try to read out of volume at offset 0x617ffffe00
[    4.334359] VFS: Mounted root (jfs filesystem) readonly on device 259:4.
[    4.334861] devtmpfs: mounted

ntfs3 is there because this machine will become dual boot, Win10 on one stick, Gentoo on another and I want to be able to access stuff on the Win10 drive from Gentoo but at the moment, the Win10 stick does not get a mention at all in fstab so as to why ntfs3 is trying to mount stuff I have no idea. I've just noticed the RAID stuff - I don't have any RAID stuff set up.

If any one has any thoughts as to why the kernel would mount one instance of jfs and then not the second, those ideas would be greatly appreciated. I think my next steps will be getting rid of the RAID stuff, trying to work out why ntfs3 is trying to mount stuff and then finally might reformat the /home partition as ext4 and see if the problem persists.

Thanks for any thoughts,
Andrew

Code: Select all

PARTUUID=aaaa   /efi          vfat        umask=0077      0 2
PARTUUID=bbbb   /             jfs         noatime         0 1
PARTUUID=cccc   none          swap        sw              0 0
PARTUUID=dddd   /home         jfs         noatime         0 2

[pingtoo]

Bluey_the_dog,

Can you share output of

Code: Select all

lsblk -f -o+partuuid

So we can better understand your system's storage condition.

[grknight]

trying to work out why ntfs3 is trying to mount stuff

Unless rootfstype= (in this case jfs) is specified on the kernel command-line, the kernel will guess at the type and try, possibly all, different types of known filesystems until it succeeds or gives up.

[Bluey_the_dog]

pingtoo,
Please see the following:

Code: Select all

bluey_new / # lsblk -f -o+partuuid
NAME        FSTYPE  FSVER            LABEL                 UUID                                 FSAVAIL FSUSE% MOUNTPOINTS PARTUUID
sda                                                                                                                        
└─sda1      vfat    FAT32            RESCUE1001            6AF3-C562                                                       000ed0e8-01
sdb                                                                                                                        
└─sdb1      iso9660 Joliet Extension Gentoo-amd64-20240929 2024-09-29-18-06-10-00                                          
nvme1n1                                                                                                                    
├─nvme1n1p1 vfat    FAT32                                  7691-7F8C                             908.1M    11% /efi        6e441ee8-0a94-bf4d-b0cb-1a46da42b8cf
├─nvme1n1p2 swap    1                                      d4c79af4-b3fb-434d-afcb-857fd3cbbd72                [SWAP]      2049128f-235c-7e43-bf88-06053bc84391
├─nvme1n1p3 jfs                                            2231353c-3e31-4f5d-a581-a6a67869f3c8  346.6G    11% /           cd935bd1-b2a6-46cf-b41b-e2c09eb1e3f0
└─nvme1n1p4 jfs                                            499e792d-1849-496e-bca7-97f11e424998                            c3854b72-8b7a-4981-acd8-ad0fd7bbb500
nvme0n1                                                                                                                    
├─nvme0n1p1 vfat    FAT32                                  8C91-93D1                                                       f4803482-31f0-4e3e-83f6-359e2d62c768
├─nvme0n1p2                                                                                                                81644e2b-6c39-47c7-b624-fc525894f54f
├─nvme0n1p3                                                                                                                9ea5c7aa-0145-4920-98c3-db9ea5b8a22b
├─nvme0n1p4 ntfs                                           20B4AB7BB4AB51D8                                                65b2ef03-c30f-4f64-b734-ae5ec0b1a0f2
└─nvme0n1p5 ntfs                                           6C324175324144F4                                                51657c0d-b98e-4171-90b2-89e4ad7e788b

It's pretty bog standard. Probably the only "whacky" thing is the use of jfs. You can see the Win10 stick there as well, but as I mentioned above, this does not appear in fstab.

[Bluey_the_dog]

grknight
I've placed rootfstype=jfs in the kernel command line, via refind, and hey presto, that error has now disappeared. This tip probably also explains why my older machine, also both partitions jfs, would have:

Older machine dmesg

Code: Select all

[    3.546403] exFAT-fs (nvme0n1p3): invalid boot record signature
[    3.546743] exFAT-fs (nvme0n1p3): failed to read boot sector
[    3.547017] exFAT-fs (nvme0n1p3): failed to recognize exfat type

in basically the same posi within dmesg. I will have to add the same line to it when I'm finished later tonight and see how it goes.

Unfortunately the main problem persists.

Thanks,
Andrew

[pingtoo]

Bluey_the_dog,

Have you try with just mount without type? i.e.

Code: Select all

mount /dev/nvme1n1p4 /home

And if failed again, what error message you got? And if anything related to /dev/nvme1n1p4 show in dmesg?

Also have you try with fsck?

Code: Select all

fsck -p /dev/nvme1n1p4

(please check dmesg also if fsck also failed)

[Bluey_the_dog]

Pingtoo,
With respect to the mount command, as I mentioned in the original post, I've tried all three and they give the same result - refer above for the error message.

For fsck:

Code: Select all

bluey_new / # fsck -p /dev/nvme1n1p4
fsck from util-linux 2.40.2
fsck.jfs version 1.1.15, 04-Mar-2011
processing started: 10/9/2024 2:21:29
The current device is:  /dev/nvme1n1p4
Block size in bytes:  4096
Filesystem size in blocks:  133827584
**Phase 0 - Replay Journal Log
Filesystem is clean.
bluey_new / # 

fsck was the first thing I though of when I spotted the error. As the partition had not mounted, I ran it from the install. I then ran it from the above mentioned live sticks. I then ran it again after I had deleted and recreated the partition. Every time I would get the same result, a clean filesystem.

[Goverp]

Dear all,
I'm in the process of building a new machine. The partitions are formatted jfs. ...

Interesting choice. Sadly, AFAIK, JFS is virtually unmaintained these days. There were discussions last year of starting to deprecate it in the Linux kernel. Nothing actually wrong with it as a filesystem, and with the benefit of being decidedly leaner and healthier than some full-fat filesystems, but it never gained much usage outside of its original IBM AIX and OS/2 birthplace.

My mainstream choice would be ext4, or if using SSD/NVMe consider f2fs (niche within pure Linux, but AFAIK heavily used in Android's version of Linux). You'll also see recommendations for XFS and other more sophisticated (a.k.a. more complicated) filesystems.

[pingtoo]

So can you test mount right after fsck?

please test mount with strace and share the output.

if you don't have strace installed, please try emerge -1a dev-debug/strace

Code: Select all

strace -f -o /tmp/mount-jfs

[jburns]

The kernel can mount the root partition because it has the code for mounting it. But it only mounts the root partition.
The gentoo-kernel-bin has an initramfs that contains mount that supports mounting with jfs by the initramfs.
A kernel without an initramfs only mounts the root partition, the other partitions must be mounted by the OS's init process. This needs sys-fs/jfsutils to be installed.

[Bluey_the_dog]

jburns
jsfutils has been installed on the machine for 6 months ie this machine has not been a top priority...

Code: Select all

bluey_new / # eix jfsutils
[I] sys-fs/jfsutils
     Available versions:  1.1.15-r2 {static}
     Installed versions:  1.1.15-r2(18:50:49 04/26/24)(-static)
     Homepage:            http://jfs.sourceforge.net/
     Description:         IBM's Journaling Filesystem (JFS) Utilities
bluey_new / # 
bluey_new / # whereis jfs_mkfs
jfs_mkfs: /usr/bin/jfs_mkfs /usr/share/man/man8/jfs_mkfs.8.bz2
bluey_new / # cd /usr/bin
bluey_new /usr/bin # ls jfs*
jfs_debugfs  jfs_fsck  jfs_fscklog  jfs_logdump  jfs_mkfs  jfs_tune
bluey_new /usr/bin # 

I just checked something on my older machine, one that has been running jfs for years and the utils are in /sbin. I know there was a change a while ago with respects to different bins. Could this be the cause?

[Bluey_the_dog]

People,
Thank you for your help and suggestions, especially grknight with the tip to kill off the error in dmesg, but in my googling to try and find a solution, I've come across a few things[1] that make me thing it's time to move on. I've been using jfs for probably at least 17 years, I was doing an Engineering Masters/PhD at the time and it had benefits for the amount of data I had, but the last comment in the linked bug makes me a bit wary.

So once again, thanks

Andrew

p.s. If someone does know what the problem, please let me know, it would add "closure"


[1] https://bugs.gentoo.org/863905

[pingtoo]

Bluey_the_dog,

It is your prerogative to call it stop, I respect that.

However your last post lead me to think you may misunderstanding something. the jfsutils have nothing to do with fail to mount a jfs file system.

jfs for linux does not require a mount helper to support mounting, so the jfsutils package does not include for example "mount.jfs" binary.

jfs in linux kernel is still supported and I see from code update in past six month.

the bug you see is refer to compiling jfsutils with LTO it is IMO really unnecessary since nobody run fsck/mkfs for jfs all daylong so why bother to optimize to the extreme?

I suspect in your case it is possible kernel missing a code page that is necessary for your environment. But without seeing evidence I cannot conclusive say what is actually happen.

It is very possible even using strace I will not be able to tell exactly where is the problem, but this is one easy step to help understand, if strace step not helping I would suggest you turn on CONFIG_JFS_DEBUG as next step. because the error condition did trapped, so something should be in dmesg but may be it is one that is deep in the code that only when debug message turn on so we can see it.

[Bluey_the_dog]

pingtoo,
I've finally worked out how to use strace, you needed to add the mount command after what you provided:

Code: Select all

bluey_new / # strace -f -o /tmp/mount-jfs mount /dev/nvme1n1p4 /home

I also added debug in the kernel for jfs and after both booting, which failed, and then using the mount command, which also failed, from the strace example above, I got the following in dmesg:

Code: Select all

[  198.514593] jfs_mount: dbMount failed w/rc = -22
[  198.514601] Mount JFS Failure: -22
[  198.514602] jfs_mount failed w/return code = -22

A listing of /tmp/mount-jfs follows. I tried to compare this file from both the old and new machines, both of which have the same jfs partitions. The difference seems to be in, about, the last 20 lines, fsconfig(..........(Invalid argument) for example.

Does this give you any further insight?

Code: Select all

bluey_new / # cat /tmp/mount-jfs 
1859  execve("/usr/bin/mount", ["mount", "/dev/nvme1n1p4", "/home"], 0x7fff8462d898 /* 41 vars */) = 0
1859  brk(NULL)                         = 0x555b39562000
1859  mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f8159f88000
1859  access("/etc/ld.so.preload", R_OK) = -1 ENOENT (No such file or directory)
1859  openat(AT_FDCWD, "/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3
1859  fstat(3, {st_mode=S_IFREG|0644, st_size=104138, ...}) = 0
1859  mmap(NULL, 104138, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7f8159f6e000
1859  close(3)                          = 0
1859  openat(AT_FDCWD, "/usr/lib64/libmount.so.1", O_RDONLY|O_CLOEXEC) = 3
1859  read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\0\0\0\0\0\0\0\0"..., 832) = 832
1859  fstat(3, {st_mode=S_IFREG|0755, st_size=461424, ...}) = 0
1859  mmap(NULL, 463432, PROT_READ, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7f8159efc000
1859  mmap(0x7f8159f06000, 311296, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0xa000) = 0x7f8159f06000
1859  mmap(0x7f8159f52000, 98304, PROT_READ, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x56000) = 0x7f8159f52000
1859  mmap(0x7f8159f6a000, 16384, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x6d000) = 0x7f8159f6a000
1859  close(3)                          = 0
1859  openat(AT_FDCWD, "/usr/lib64/libc.so.6", O_RDONLY|O_CLOEXEC) = 3
1859  read(3, "\177ELF\2\1\1\3\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\300c\2\0\0\0\0\0"..., 832) = 832
1859  pread64(3, "\6\0\0\0\4\0\0\0@\0\0\0\0\0\0\0@\0\0\0\0\0\0\0@\0\0\0\0\0\0\0"..., 784, 64) = 784
1859  fstat(3, {st_mode=S_IFREG|0755, st_size=1937664, ...}) = 0
1859  pread64(3, "\6\0\0\0\4\0\0\0@\0\0\0\0\0\0\0@\0\0\0\0\0\0\0@\0\0\0\0\0\0\0"..., 784, 64) = 784
1859  mmap(NULL, 1964984, PROT_READ, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7f8159d1c000
1859  mmap(0x7f8159d40000, 1413120, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x24000) = 0x7f8159d40000
1859  mmap(0x7f8159e99000, 348160, PROT_READ, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x17d000) = 0x7f8159e99000
1859  mmap(0x7f8159eee000, 24576, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x1d2000) = 0x7f8159eee000
1859  mmap(0x7f8159ef4000, 31672, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x7f8159ef4000
1859  close(3)                          = 0
1859  openat(AT_FDCWD, "/usr/lib64/libblkid.so.1", O_RDONLY|O_CLOEXEC) = 3
1859  read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\0\0\0\0\0\0\0\0"..., 832) = 832
1859  fstat(3, {st_mode=S_IFREG|0755, st_size=375776, ...}) = 0
1859  mmap(NULL, 373696, PROT_READ, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7f8159cc0000
1859  mmap(0x7f8159cc6000, 245760, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x6000) = 0x7f8159cc6000
1859  mmap(0x7f8159d02000, 77824, PROT_READ, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x42000) = 0x7f8159d02000
1859  mmap(0x7f8159d15000, 28672, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x55000) = 0x7f8159d15000
1859  close(3)                          = 0
1859  mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f8159cbe000
1859  arch_prctl(ARCH_SET_FS, 0x7f8159cbeb80) = 0
1859  set_tid_address(0x7f8159cbee50)   = 1859
1859  set_robust_list(0x7f8159cbee60, 24) = 0
1859  rseq(0x7f8159cbf4a0, 0x20, 0, 0x53053053) = 0
1859  mprotect(0x7f8159eee000, 16384, PROT_READ) = 0
1859  mprotect(0x7f8159d15000, 24576, PROT_READ) = 0
1859  mprotect(0x7f8159f6a000, 12288, PROT_READ) = 0
1859  mprotect(0x555b11770000, 4096, PROT_READ) = 0
1859  mprotect(0x7f8159fc4000, 8192, PROT_READ) = 0
1859  prlimit64(0, RLIMIT_STACK, NULL, {rlim_cur=8192*1024, rlim_max=RLIM64_INFINITY}) = 0
1859  munmap(0x7f8159f6e000, 104138)    = 0
1859  getrandom("\xd4\xd7\xe0\xb9\x3a\x35\x8c\x64", 8, GRND_NONBLOCK) = 8
1859  brk(NULL)                         = 0x555b39562000
1859  brk(0x555b39583000)               = 0x555b39583000
1859  openat(AT_FDCWD, "/usr/lib/locale/locale-archive", O_RDONLY|O_CLOEXEC) = 3
1859  fstat(3, {st_mode=S_IFREG|0644, st_size=3394416, ...}) = 0
1859  mmap(NULL, 3394416, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7f8159800000
1859  close(3)                          = 0
1859  getuid()                          = 0
1859  geteuid()                         = 0
1859  readlink("/dev", 0x7ffd29566d90, 1023) = -1 EINVAL (Invalid argument)
1859  readlink("/dev/nvme1n1p4", 0x7ffd29566d90, 1023) = -1 EINVAL (Invalid argument)
1859  newfstatat(AT_FDCWD, "/dev/nvme1n1p4", {st_mode=S_IFBLK|0660, st_rdev=makedev(0x103, 0x5), ...}, 0) = 0
1859  access("/dev/nvme1n1p4", F_OK)    = 0
1859  openat(AT_FDCWD, "/dev/nvme1n1p4", O_RDONLY|O_NONBLOCK|O_CLOEXEC) = 3
1859  fadvise64(3, 0, 0, POSIX_FADV_RANDOM) = 0
1859  fstat(3, {st_mode=S_IFBLK|0660, st_rdev=makedev(0x103, 0x5), ...}) = 0
1859  ioctl(3, BLKGETSIZE64, [548157784064]) = 0
1859  ioctl(3, FDGETFDCSTAT, 0x7ffd29565fe0) = -1 ENOTTY (Inappropriate ioctl for device)
1859  openat(AT_FDCWD, "/sys/dev/block/259:5", O_RDONLY|O_CLOEXEC) = 4
1859  openat(4, "dm/uuid", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
1859  close(4)                          = 0
1859  openat(AT_FDCWD, "/sys/dev/block/259:5", O_RDONLY|O_CLOEXEC) = 4
1859  faccessat2(4, "partition", F_OK, 0) = 0
1859  readlink("/sys/dev/block/259:5", "../../devices/pci0000:00/0000:00"..., 4095) = 79
1859  openat(AT_FDCWD, "/sys/block/nvme1n1/dev", O_RDONLY|O_CLOEXEC) = 5
1859  fstat(5, {st_mode=S_IFREG|0444, st_size=4096, ...}) = 0
1859  read(5, "259:1\n", 4096)          = 6
1859  close(5)                          = 0
1859  close(4)                          = 0
1859  ioctl(3, BLKGETZONESZ, [0])       = 0
1859  ioctl(3, BLKIOOPT, [0])           = 0
1859  ioctl(3, BLKIOMIN, [512])         = 0
1859  lseek(3, 548157718528, SEEK_SET)  = 548157718528
1859  mmap(NULL, 512, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f8159f87000
1859  read(3, "\355\177\0\0\0\0\10\0\0\0\0\0\0\0\0\0\0@\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 512) = 512
1859  mprotect(0x7f8159f87000, 512, PROT_READ) = 0
1859  lseek(3, 548157775872, SEEK_SET)  = 548157775872
1859  mmap(NULL, 512, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f8159f86000
1859  read(3, "\373\177\0\0\0\0\10\0\0\0\0\0\0\0\0\0\0@\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 512) = 512
1859  mprotect(0x7f8159f86000, 512, PROT_READ) = 0
1859  lseek(3, 0, SEEK_SET)             = 0
1859  mmap(NULL, 512, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f8159f85000
1859  read(3, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 512) = 512
1859  mprotect(0x7f8159f85000, 512, PROT_READ) = 0
1859  lseek(3, 4096, SEEK_SET)          = 4096
1859  mmap(NULL, 512, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f8159f84000
1859  read(3, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 512) = 512
1859  mprotect(0x7f8159f84000, 512, PROT_READ) = 0
1859  lseek(3, 548157783552, SEEK_SET)  = 548157783552
1859  mmap(NULL, 512, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f8159f83000
1859  read(3, "\0\0\0\0\0\0\0\0\231yP\321\330\177\0\0\0\0\0\0\0\0\0\0bLU\321\330\177\0\0"..., 512) = 512
1859  mprotect(0x7f8159f83000, 512, PROT_READ) = 0
1859  lseek(3, 548157652480, SEEK_SET)  = 548157652480
1859  mmap(NULL, 512, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f8159f82000
1859  read(3, "\0\0\0\0\0\0\0\0\231yP\321\330\177\0\0\0\0\0\0\0\0\0\0bLU\321\330\177\0\0"..., 512) = 512
1859  mprotect(0x7f8159f82000, 512, PROT_READ) = 0
1859  lseek(3, 4608, SEEK_SET)          = 4608
1859  mmap(NULL, 512, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f8159f81000
1859  read(3, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 512) = 512
1859  mprotect(0x7f8159f81000, 512, PROT_READ) = 0
1859  lseek(3, 2097152, SEEK_SET)       = 2097152
1859  mmap(NULL, 512, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f8159f80000
1859  read(3, "\0 \0\0\0 \0\0\0\200=\0\0\0\0\0\0\1\0\0\10\0\0\0U\0\0\0\4\0\0\0"..., 512) = 512
1859  mprotect(0x7f8159f80000, 512, PROT_READ) = 0
1859  lseek(3, 548156735488, SEEK_SET)  = 548156735488
1859  mmap(NULL, 512, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f8159f7f000
1859  read(3, "\375~\0\0\0\0\10\0\0\0\0\0\0\0\0\0\0@\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 512) = 512
1859  mprotect(0x7f8159f7f000, 512, PROT_READ) = 0
1859  lseek(3, 548157779968, SEEK_SET)  = 548157779968
1859  mmap(NULL, 512, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f8159f7e000
1859  read(3, "\374\177\0\0\0\0\10\0\0\0\0\0\0\0\0\0\0@\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 512) = 512
1859  mprotect(0x7f8159f7e000, 512, PROT_READ) = 0
1859  lseek(3, 512, SEEK_SET)           = 512
1859  mmap(NULL, 512, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f8159f7d000
1859  read(3, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 512) = 512
1859  mprotect(0x7f8159f7d000, 512, PROT_READ) = 0
1859  lseek(3, 1024, SEEK_SET)          = 1024
1859  mmap(NULL, 512, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f8159f7c000
1859  read(3, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 512) = 512
1859  mprotect(0x7f8159f7c000, 512, PROT_READ) = 0
1859  lseek(3, 1536, SEEK_SET)          = 1536
1859  mmap(NULL, 512, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f8159f7b000
1859  read(3, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 512) = 512
1859  mprotect(0x7f8159f7b000, 512, PROT_READ) = 0
1859  lseek(3, 16384, SEEK_SET)         = 16384
1859  mmap(NULL, 512, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f8159f7a000
1859  read(3, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 512) = 512
1859  mprotect(0x7f8159f7a000, 512, PROT_READ) = 0
1859  lseek(3, 32768, SEEK_SET)         = 32768
1859  mmap(NULL, 512, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f8159f79000
1859  read(3, "JFS1\2\0\0\0\310\336\313?\0\0\0\0\0\20\0\0\f\0\3\0\0\2\0\0\t\0\0\0"..., 512) = 512
1859  mprotect(0x7f8159f79000, 512, PROT_READ) = 0
1859  lseek(3, 65536, SEEK_SET)         = 65536
1859  mmap(NULL, 512, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f8159f78000
1859  read(3, "\331{\371\7\0\0\0\0\335;\371\7\0\0\0\0\0\0\0\0\200\0\0\0\1\0\0\0\0\0\0\0"..., 512) = 512
1859  mprotect(0x7f8159f78000, 512, PROT_READ) = 0
1859  lseek(3, 131072, SEEK_SET)        = 131072
1859  mmap(NULL, 512, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f8159f77000
1859  read(3, "\0 \0\0\0 \0\0\0\200\1\0\0\0\0\0\0\1\0\0\10\0\0\0U\0\0\0\4\0\0\0"..., 512) = 512
1859  mprotect(0x7f8159f77000, 512, PROT_READ) = 0
1859  lseek(3, 262144, SEEK_SET)        = 262144
1859  mmap(NULL, 512, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f8159f76000
1859  read(3, "\0 \0\0\0 \0\0\0\200\5\0\0\0\0\0\0\1\0\0\10\0\0\0U\0\0\0\4\0\0\0"..., 512) = 512
1859  mprotect(0x7f8159f76000, 512, PROT_READ) = 0
1859  lseek(3, 524288, SEEK_SET)        = 524288
1859  mmap(NULL, 512, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f8159f75000
1859  read(3, "\0 \0\0\0 \0\0\0\200\r\0\0\0\0\0\0\1\0\0\10\0\0\0U\0\0\0\4\0\0\0"..., 512) = 512
1859  mprotect(0x7f8159f75000, 512, PROT_READ) = 0
1859  lseek(3, 1048576, SEEK_SET)       = 1048576
1859  mmap(NULL, 512, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f8159f74000
1859  read(3, "\0 \0\0\0 \0\0\0\200\35\0\0\0\0\0\0\1\0\0\10\0\0\0U\0\0\0\4\0\0\0"..., 512) = 512
1859  mprotect(0x7f8159f74000, 512, PROT_READ) = 0
1859  lseek(3, 4194304, SEEK_SET)       = 4194304
1859  mmap(NULL, 512, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f8159f73000
1859  read(3, "\0 \0\0\0 \0\0\0\200}\0\0\0\0\0\0\1\0\0\10\0\0\0U\0\0\0\4\0\0\0"..., 512) = 512
1859  mprotect(0x7f8159f73000, 512, PROT_READ) = 0
1859  lseek(3, 3584, SEEK_SET)          = 3584
1859  mmap(NULL, 512, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f8159f72000
1859  read(3, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 512) = 512
1859  mprotect(0x7f8159f72000, 512, PROT_READ) = 0
1859  lseek(3, 7680, SEEK_SET)          = 7680
1859  mmap(NULL, 512, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f8159f71000
1859  read(3, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 512) = 512
1859  mprotect(0x7f8159f71000, 512, PROT_READ) = 0
1859  lseek(3, 15872, SEEK_SET)         = 15872
1859  mmap(NULL, 512, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f8159f70000
1859  read(3, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 512) = 512
1859  mprotect(0x7f8159f70000, 512, PROT_READ) = 0
1859  lseek(3, 32256, SEEK_SET)         = 32256
1859  mmap(NULL, 512, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f8159f6f000
1859  read(3, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 512) = 512
1859  mprotect(0x7f8159f6f000, 512, PROT_READ) = 0
1859  lseek(3, 65024, SEEK_SET)         = 65024
1859  mmap(NULL, 512, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f8159f6e000
1859  read(3, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 512) = 512
1859  mprotect(0x7f8159f6e000, 512, PROT_READ) = 0
1859  lseek(3, 0, SEEK_SET)             = 0
1859  mmap(NULL, 262144, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f8159c7e000
1859  read(3, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 262144) = 262144
1859  mprotect(0x7f8159c7e000, 262144, PROT_READ) = 0
1859  munmap(0x7f8159f6e000, 512)       = 0
1859  munmap(0x7f8159f6f000, 512)       = 0
1859  munmap(0x7f8159f70000, 512)       = 0
1859  munmap(0x7f8159f71000, 512)       = 0
1859  munmap(0x7f8159f72000, 512)       = 0
1859  munmap(0x7f8159f77000, 512)       = 0
1859  munmap(0x7f8159f78000, 512)       = 0
1859  munmap(0x7f8159f79000, 512)       = 0
1859  munmap(0x7f8159f7a000, 512)       = 0
1859  munmap(0x7f8159f7b000, 512)       = 0
1859  munmap(0x7f8159f7c000, 512)       = 0
1859  munmap(0x7f8159f7d000, 512)       = 0
1859  munmap(0x7f8159f81000, 512)       = 0
1859  munmap(0x7f8159f84000, 512)       = 0
1859  munmap(0x7f8159f85000, 512)       = 0
1859  lseek(3, 262144, SEEK_SET)        = 262144
1859  mmap(NULL, 262144, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f8159c3e000
1859  read(3, "\0 \0\0\0 \0\0\0\200\5\0\0\0\0\0\0\1\0\0\10\0\0\0U\0\0\0\4\0\0\0"..., 262144) = 262144
1859  mprotect(0x7f8159c3e000, 262144, PROT_READ) = 0
1859  lseek(3, 548157259776, SEEK_SET)  = 548157259776
1859  mmap(NULL, 262144, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f8159bfe000
1859  read(3, "}\177\0\0\0\0\10\0\0\0\0\0\0\0\0\0\0@\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 262144) = 262144
1859  mprotect(0x7f8159bfe000, 262144, PROT_READ) = 0
1859  lseek(3, 548157521920, SEEK_SET)  = 548157521920
1859  mmap(NULL, 262144, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f8159bbe000
1859  read(3, "\275\177\0\0\0\0\10\0\0\0\0\0\0\0\0\0\0@\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 262144) = 262144
1859  mprotect(0x7f8159bbe000, 262144, PROT_READ) = 0
1859  munmap(0x7f8159f7e000, 512)       = 0
1859  munmap(0x7f8159f82000, 512)       = 0
1859  munmap(0x7f8159f83000, 512)       = 0
1859  munmap(0x7f8159f86000, 512)       = 0
1859  munmap(0x7f8159f87000, 512)       = 0
1859  munmap(0x7f8159f76000, 512)       = 0
1859  ioctl(3, BLKSSZGET, [512])        = 0
1859  openat(AT_FDCWD, "/sys/dev/block/259:1", O_RDONLY|O_CLOEXEC) = 4
1859  readlink("/sys/dev/block/259:1", "../../devices/pci0000:00/0000:00"..., 4095) = 69
1859  newfstatat(AT_FDCWD, "/dev/nvme1n1", {st_mode=S_IFBLK|0660, st_rdev=makedev(0x103, 0x1), ...}, 0) = 0
1859  close(4)                          = 0
1859  openat(AT_FDCWD, "/dev/nvme1n1", O_RDONLY|O_NONBLOCK|O_CLOEXEC) = 4
1859  fadvise64(4, 0, 0, POSIX_FADV_RANDOM) = 0
1859  fstat(4, {st_mode=S_IFBLK|0660, st_rdev=makedev(0x103, 0x1), ...}) = 0
1859  ioctl(4, BLKGETSIZE64, [1000204886016]) = 0
1859  ioctl(4, FDGETFDCSTAT, 0x7ffd29565f40) = -1 ENOTTY (Inappropriate ioctl for device)
1859  openat(AT_FDCWD, "/sys/dev/block/259:1", O_RDONLY|O_CLOEXEC) = 5
1859  openat(5, "dm/uuid", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
1859  close(5)                          = 0
1859  openat(AT_FDCWD, "/sys/dev/block/259:1", O_RDONLY|O_CLOEXEC) = 5
1859  faccessat2(5, "partition", F_OK, 0) = -1 ENOENT (No such file or directory)
1859  openat(5, "dm/uuid", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
1859  close(5)                          = 0
1859  ioctl(4, CDROM_GET_CAPABILITY, 0) = -1 ENOTTY (Inappropriate ioctl for device)
1859  ioctl(4, CDROM_LAST_WRITTEN, 0x7ffd29565f30) = -1 ENOTTY (Inappropriate ioctl for device)
1859  ioctl(4, BLKGETZONESZ, [0])       = 0
1859  ioctl(4, BLKIOOPT, [0])           = 0
1859  ioctl(4, BLKIOMIN, [512])         = 0
1859  lseek(4, 0, SEEK_SET)             = 0
1859  mmap(NULL, 512, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f8159f87000
1859  read(4, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 512) = 512
1859  mprotect(0x7f8159f87000, 512, PROT_READ) = 0
1859  ioctl(4, BLKSSZGET, [512])        = 0
1859  lseek(4, 512, SEEK_SET)           = 512
1859  mmap(NULL, 512, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f8159f86000
1859  read(4, "EFI PART\0\0\1\0\\\0\0\0\2\6\16\317\0\0\0\0\1\0\0\0\0\0\0\0"..., 512) = 512
1859  mprotect(0x7f8159f86000, 512, PROT_READ) = 0
1859  lseek(4, 1024, SEEK_SET)          = 1024
1859  mmap(NULL, 16384, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f8159f82000
1859  read(4, "(s*\301\37\370\322\21\272K\0\240\311>\311;\350\36Dn\224\nM\277\260\313\32F\332B\270\317"..., 16384) = 16384
1859  mprotect(0x7f8159f82000, 16384, PROT_READ) = 0
1859  openat(AT_FDCWD, "/sys/dev/block/259:5", O_RDONLY|O_CLOEXEC) = 5
1859  openat(5, "size", O_RDONLY|O_CLOEXEC) = 6
1859  fcntl(6, F_GETFL)                 = 0x8000 (flags O_RDONLY|O_LARGEFILE)
1859  fstat(6, {st_mode=S_IFREG|0444, st_size=4096, ...}) = 0
1859  read(6, "1070620672\n", 4096)     = 11
1859  close(6)                          = 0
1859  openat(5, "start", O_RDONLY|O_CLOEXEC) = 6
1859  fcntl(6, F_GETFL)                 = 0x8000 (flags O_RDONLY|O_LARGEFILE)
1859  fstat(6, {st_mode=S_IFREG|0444, st_size=4096, ...}) = 0
1859  read(6, "882903040\n", 4096)      = 10
1859  close(6)                          = 0
1859  close(5)                          = 0
1859  close(3)                          = 0
1859  munmap(0x7f8159f80000, 512)       = 0
1859  munmap(0x7f8159f7f000, 512)       = 0
1859  munmap(0x7f8159f75000, 512)       = 0
1859  munmap(0x7f8159f74000, 512)       = 0
1859  munmap(0x7f8159f73000, 512)       = 0
1859  munmap(0x7f8159c7e000, 262144)    = 0
1859  munmap(0x7f8159c3e000, 262144)    = 0
1859  munmap(0x7f8159bfe000, 262144)    = 0
1859  munmap(0x7f8159bbe000, 262144)    = 0
1859  close(4)                          = 0
1859  munmap(0x7f8159f87000, 512)       = 0
1859  munmap(0x7f8159f86000, 512)       = 0
1859  munmap(0x7f8159f82000, 16384)     = 0
1859  readlink("/home", 0x7ffd29566df0, 1023) = -1 EINVAL (Invalid argument)
1859  statx(AT_FDCWD, "/sbin/mount.jfs", AT_STATX_DONT_SYNC|AT_NO_AUTOMOUNT, STATX_TYPE|STATX_MODE|STATX_INO, 0x7ffd29565fe0) = -1 ENOENT (No such file or directory)
1859  statx(AT_FDCWD, "/sbin/fs.d/mount.jfs", AT_STATX_DONT_SYNC|AT_NO_AUTOMOUNT, STATX_TYPE|STATX_MODE|STATX_INO, 0x7ffd29565fe0) = -1 ENOENT (No such file or directory)
1859  statx(AT_FDCWD, "/sbin/fs/mount.jfs", AT_STATX_DONT_SYNC|AT_NO_AUTOMOUNT, STATX_TYPE|STATX_MODE|STATX_INO, 0x7ffd29565fe0) = -1 ENOENT (No such file or directory)
1859  statx(AT_FDCWD, "/usr/sbin/mount.jfs", AT_STATX_DONT_SYNC|AT_NO_AUTOMOUNT, STATX_TYPE|STATX_MODE|STATX_INO, 0x7ffd29565fe0) = -1 ENOENT (No such file or directory)
1859  statx(AT_FDCWD, "/bin/mount.jfs", AT_STATX_DONT_SYNC|AT_NO_AUTOMOUNT, STATX_TYPE|STATX_MODE|STATX_INO, 0x7ffd29565fe0) = -1 ENOENT (No such file or directory)
1859  statx(AT_FDCWD, "/usr/bin/mount.jfs", AT_STATX_DONT_SYNC|AT_NO_AUTOMOUNT, STATX_TYPE|STATX_MODE|STATX_INO, 0x7ffd29565fe0) = -1 ENOENT (No such file or directory)
1859  fsopen("jfs", FSOPEN_CLOEXEC)     = 3
1859  getuid()                          = 0
1859  geteuid()                         = 0
1859  getgid()                          = 0
1859  getegid()                         = 0
1859  prctl(PR_GET_DUMPABLE)            = 1 (SUID_DUMP_USER)
1859  newfstatat(AT_FDCWD, "/run/mount/utab", 0x7ffd29567250, AT_SYMLINK_NOFOLLOW) = -1 ENOENT (No such file or directory)
1859  mkdir("/run/mount", 0755)         = -1 EEXIST (File exists)
1859  newfstatat(AT_FDCWD, "/run/mount/utab", 0x7ffd29567140, 0) = -1 ENOENT (No such file or directory)
1859  newfstatat(AT_FDCWD, "/run/mount", {st_mode=S_IFDIR|0755, st_size=40, ...}, 0) = 0
1859  geteuid()                         = 0
1859  getegid()                         = 0
1859  getuid()                          = 0
1859  getgid()                          = 0
1859  access("/run/mount", R_OK|W_OK)   = 0
1859  fsconfig(3, FSCONFIG_SET_STRING, "source", "/dev/nvme1n1p4", 0) = 0
1859  fsconfig(3, FSCONFIG_CMD_CREATE, NULL, NULL, 0) = -1 EINVAL (Invalid argument)
1859  read(3, 0x7ffd29565050, 8191)     = -1 ENODATA (No data available)
1859  close(3)                          = 0
1859  write(2, "mount: ", 7)            = 7
1859  write(2, "/home: wrong fs type, bad option"..., 119) = 119
1859  write(2, "\n", 1)                 = 1
1859  write(2, "       dmesg(1) may have more in"..., 74) = 74
1859  dup(1)                            = 3
1859  close(3)                          = 0
1859  dup(2)                            = 3
1859  close(3)                          = 0
1859  exit_group(32)                    = ?
1859  +++ exited with 32 +++

[pingtoo]

Bluey_the_dog,

Thanks for providing these information.

Code: Select all

[  198.514593] jfs_mount: dbMount failed w/rc = -22
[  198.514601] Mount JFS Failure: -22
[  198.514602] jfs_mount failed w/return code = -22

helped. The strace output just show the result but not enough information.

I check the dbMount code. it seems to me something is out of range. So how did you create the JFS on that partition? I mean what is the command and arguments? I will need to research to find if there is a command that can dump out the file system information.

BTW, the -22 error is Invalid argument, in dbMount code there are 3 places will return this error. they all about checking inode information for the file system.

[Bluey_the_dog]

pingtoo,
I've created the partition multiple ways. The first time would have been as per The Handbook whilst doing the initial install. I probably did a couple of reformats from the command line subsequently. As well I've done a few command line formats from sysrescue & gentoo sticks and just tonight, Gparted as per the graphical environment in sysrescue.

I think I will grab a few live sticks, sysrescue, gentoo, Arch etc and see if they can all mount the partition. If they can it would say to me that the actual partition is sound and that it is something to do with my config of the kernel.

2:30AM Perth Australia time so I'm off to bed, regards,
Andrew

[pingtoo]

Bluey_the_dog,

No worries take you time. Have a good night sleep

I was just about ask you kernel. is this is on a X86 box or something else? Do your kernel have different page size than 4096?

Yes, it is good idea to use a different livecd to test if that partition work under.

From the source code, it seems to me the meta data content on disk is not right, seems to out of range. so if there is no problem in partition table (no overlaps) and when you create the file system without special arrange, i.e. external journal device or different block size, etc than there is always a chance that part of disk are bad too.

[pingtoo]

Bluey_the_dog,

Just for your information.

I tested on my RPI5 (pagesize 16k)

Code: Select all

root@rpi5 ~ # mkfs.jfs /dev/nbd5 
mkfs.jfs version 1.1.15, 04-Mar-2011
Warning!  All data on device /dev/nbd5 will be lost!

Continue? (Y/N) y
   \

Format completed successfully.

5242880 kilobytes total disk space.
root@rpi5 ~ # mount /dev/nbd5 /mnt/
root@rpi5 ~ # umount /mnt
root@rpi5 ~ # jfs_debugfs /dev/nbd5 
jfs_debugfs version 1.1.15, 04-Mar-2011
%G
Aggregate Block Size: 4096

> dmap

Block allocation map control page at block 16

[1] dn_mapsize:		0x0000013eba5	[9] dn_agheigth:	0
[2] dn_nfree:		0x0000013eae4	[10] dn_agwidth:	2
[3] dn_l2nbperpage:	0		[11] dn_agstart:	341
[4] dn_numag:		80		[12] dn_agl2size:	14
[5] dn_maxlevel:	0		[13] dn_agfree:		type 'f'
[6] dn_maxag:		0		[14] dn_agsize:		16384
[7] dn_agpref:		0		[15] pad:		Not Displayed
[8] dn_aglevel:		0
display_dbmap: [m]odify, [f]ree count, [t]ree, e[x]it > x
> quit

The significant parts are dn_numag, dn_maxag, dn_agperf and dn_l2nbperpage. the dbMount check those three numbers and will return EINVAL if out of range.

BTW, the nbd is 5GB.

[Bluey_the_dog]

pingtoo,
Much frustration at this end. I ran jfs_debugfs as you suggested but nothing stuck out to me

Code: Select all

bluey_new / # jfs_debugfs /dev/nvme1n1p4
jfs_debugfs version 1.1.15, 04-Mar-2011

Aggregate Block Size: 4096

> dmap

Block allocation map control page at block 16

[1] dn_mapsize:         0x00007f97bd9   [9] dn_agheigth:        3
[2] dn_nfree:           0x00007f93bdd   [10] dn_agwidth:        2
[3] dn_l2nbperpage:     0               [11] dn_agstart:        5
[4] dn_numag:           128             [12] dn_agl2size:       20
[5] dn_maxlevel:        1               [13] dn_agfree:         type 'f'
[6] dn_maxag:           0               [14] dn_agsize:         1048576
[7] dn_agpref:          0               [15] pad:               Not Displayed
[8] dn_aglevel:         0
display_dbmap: [m]odify, [f]ree count, [t]ree, e[x]it > x
> q
bluey_new / # jfs_debugfs /dev/sda1
jfs_debugfs version 1.1.15, 04-Mar-2011

Aggregate Block Size: 4096

> dmap

Block allocation map control page at block 16

[1] dn_mapsize:         0x000007328e6   [9] dn_agheigth:        1
[2] dn_nfree:           0x0000073252b   [10] dn_agwidth:        2
[3] dn_l2nbperpage:     0               [11] dn_agstart:        85
[4] dn_numag:           116             [12] dn_agl2size:       16
[5] dn_maxlevel:        0               [13] dn_agfree:         type 'f'
[6] dn_maxag:           0               [14] dn_agsize:         65536
[7] dn_agpref:          0               [15] pad:               Not Displayed
[8] dn_aglevel:         0
display_dbmap: [m]odify, [f]ree count, [t]ree, e[x]it > x
> q

In this you will see the results for the nvme & a standard mem stick formatted to jfs.

Tale of the memory stick
Based upon you using your Pi, I though I would use a simple mem stick. I happened to have some brand new, still in the packaging, 64GB sticks so grabbed one and formatted it on my older machine - the machine that mounts everything correctly. In turn I could mount it in this machine. I then placed the stick in the new machine and tried to mount it - it mounted.
I next thought it could be some sort of bug related to partition tables, dos VS GPT. So I reformatted the stick so that it showed up as GPT and jfs. Mounted in both machines with no problem. GGGRRRRR!!!!!

In rereading your post, the variable names meant nothing to me hence I googled them. dn_numag pops up in a post in the LKML

https://lore.kernel.org/lkml/c9f80af9-4 ... adoo.fr/T/

Considering these patches are only a few weeks ago but I'm assuming 6.11.3, I'm currently using -bin, contains them, but my working machine is 6.2.1, I'm going to grab an older kernel or two and see if that is the problem.

[Bluey_the_dog]

So 6.6.51 -bin mounts

[Bluey_the_dog]

After downloading more kernels in one hour than I have ever done before I can report the following, in the order tested:

All of the tests took place using gentoo-kernel-bin.
A file exists, fred.txt, in the root of the partition that is to be mounted as /home - I look for this file as a quick check and then confirm mount/no mount with mount -l. This is the partition that fails to mount.

6.6.51
Mounts on boot
Manually can mount the /home partition somewhere else
Can mount jfs stick somewhere under /mnt

6.10.12
Mounts on boot
Manually can mount the /home partition somewhere else
Can mount jfs stick somewhere under /mnt

6.10.13
Fails to mount on boot
Manually cannot mount the /home partition somewhere else
Can mount jfs stick somewhere under /mnt

6.10.14
Fails to mount on boot
Manually cannot mount the /home partition somewhere else
Can mount jfs stick somewhere under /mnt

So, assuming I haven't stuffed this up big time in my understanding of what's going on, installing -bin/initramfs etc, it appears that someone managed to get their little pinkies on the jfs code between 6.10.12 & 6.10.13. Now, what do I do????? I'm probably going to grab the 6.10.12 source kernel, use my builtin.config file and see if it works as expected, that is mount the partition, and finish my build of this machine. How to get this fixed in the kernel??????

Andrew

[Hu]

Based on your last post, I checked changes in that range for references to jfs, and found jfs: fix out-of-bounds in dbNextAG() and diAlloc(). This touches dbMount, and adds a new condition under which EINVAL can occur. Does locally reverting that commit help? If yes, what is the value of db_numag on the affected filesystem?

[Bluey_the_dog]

Does locally reverting that commit help?

NFI - and if you aren't Australian, that translates to "No F*****n' Idea". As I said in my posts, I've just grabbed the -bin kernels and run them, nothing to do with configuring/compiling them. Beside it being 6:04AM Saturday morning here in Perth and I'm about to go to bed, how do I go about reverting this change? I've got 35 years C/C++ experience, but I have NEVER done any kernel hacking!!!

I can't give you a value for db_numag, see the above.

Andrew

[Bluey_the_dog]

Hu,
Will the value of db_numag change pre/post reverting the change? Is so, then I will need time to compile and test, as well as info on how to revert. If not, then just refer back a few posts where I have the value - the post to pingtoo at Sat Oct 12, 2024 3:31 am

Andrew

[pingtoo]

Bluey_the_dog

your statement "Manually can mount the /home partition somewhere else" lead me to thinking you are not able to mount it on /home but for unknown reason at same time the same partition can mount somewhere else. Is my understanding correct?

if my understanding is true usually mean there is a process somehow open the /home directory. unusually but possible.

I just notice the /dev/nvme1n1p4 jfs_debugfs report

Code: Select all

...
[4] dn_numag:           128
...

This will cause the EINVAL.

the 128 is >= MAXAG (MAXAG is defined as 128)

Code: Select all

	bmp->db_numag = le32_to_cpu(dbmp_le->dn_numag);
	if (!bmp->db_numag || bmp->db_numag >= MAXAG) {
		err = -EINVAL;
		goto err_release_metapage;
	}

However it is only exist in master branch or v6.12-<rc*>,

on 6.10 tag and 6.11 tag does not have this check

Code: Select all

	bmp->db_numag = le32_to_cpu(dbmp_le->dn_numag);
	if (!bmp->db_numag) {
		err = -EINVAL;
		goto err_release_metapage;
	}

So may be the binary kernel cherry-picked a patch to build.