RE: git: 0a6e34e950cd - main - Fix size differences between architectures of the UFS/FFS CGSIZE macro value.

Reply: Mark Millard : "Re: git: 0a6e34e950cd - main - Fix size differences between architectures of the UFS/FFS CGSIZE macro value."
Go to: [ bottom of page ] [ top of archives ] [ this month ]

From: Mark Millard <marklmi_at_yahoo.com>
Date: Thu, 01 Jun 2023 03:30:15 UTC

In a context of:

# uname -apKU
FreeBSD CA72_UFS 14.0-CURRENT FreeBSD 14.0-CURRENT #90 main-n261544-cee09bda03c8-dirty: Wed Mar 15 20:25:49 PDT 2023     root@CA72_16Gp_ZFS:/usr/obj/BUILDs/main-CA72-nodbg-clang/usr/main-src/arm64.aarch64/sys/GENERIC-NODBG-CA72 arm64 aarch64 1400082 1400082

(so: over a month older), I tried mounting the USB3 media that had been
produced via:

FreeBSD-14.0-CURRENT-arm64-aarch64-ROCK64-20230525-baef3a5b585f-263139.img

being dd'd to the media (so: the .img has a recently produced UFS file
system). baef3a5b585f was the last commit to main on 2023-May-25
(UTC), well after the 2023-May-15 commit of 0a6e34e950cd .

The result was:

# mount -onoatime /dev/gpt/rootfs /mnt
UFS2 superblock failed: CGSIZE(fs) (32776) > fs->fs_bsize (32768)
mount: /dev/gpt/rootfs: Invalid fstype: Invalid argument

Note that the size difference is: 8.

I expect that an amd64 context produced the ufs file system that
is in the official snapshot's .img file. But I do not know what
specific kernel/world combination was in use in that context.

I tried the same for dd'ing:

FreeBSD-14.0-CURRENT-arm-armv7-GENERICSD-20230518-743516d51fa7-263002.img

to USB3 media and trying to mount the UFS file system. (So: a week
older .img file.)

The result was the same:

# mount -onoatime /dev/da1s2a /mnt
UFS2 superblock failed: CGSIZE(fs) (32776) > fs->fs_bsize (32768)
mount: /dev/da1s2a: Invalid fstype: Invalid argument


I'll note that these 2 USB3 media booted themselves just fine before
I tried this "try moutning via older system" activity.

===
Mark Millard
marklmi at yahoo.com