Date: Thu, 1 Jun 2023 12:41:07 -0700 From: Mark Millard <marklmi@yahoo.com> To: Kirk McKusick <mckusick@mckusick.com>, dev-commits-src-main@freebsd.org Subject: Re: git: 0a6e34e950cd - main - Fix size differences between architectures of the UFS/FFS CGSIZE macro value. Message-ID: <C585AC7A-60C8-4725-83CC-69DCBB707E55@yahoo.com> In-Reply-To: <C22B85FB-142A-4C45-93E0-6BC08C4C3361@yahoo.com> References: <11C9086D-A74B-4718-8872-8482AA5C3340@yahoo.com> <C22B85FB-142A-4C45-93E0-6BC08C4C3361@yahoo.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On May 31, 2023, at 20:52, Mark Millard <marklmi@yahoo.com> wrote: > On May 31, 2023, at 20:30, Mark Millard <marklmi@yahoo.com> wrote: >=20 >> In a context of: >>=20 >> # 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/arm6= 4.aarch64/sys/GENERIC-NODBG-CA72 arm64 aarch64 1400082 1400082 >>=20 >> (so: over a month older), I tried mounting the USB3 media that had = been >> produced via: >>=20 >> = FreeBSD-14.0-CURRENT-arm64-aarch64-ROCK64-20230525-baef3a5b585f-263139.img= >>=20 >> 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 . >=20 > My original notes are poorly ordered. I should have noted > that the media had also been booted prior to this "try > mouting on an older system" activity. That activity includes > a growfs. So the media was no longer exactly as it had been > when the .img was generated. >=20 >> The result was: >>=20 >> # mount -onoatime /dev/gpt/rootfs /mnt >> UFS2 superblock failed: CGSIZE(fs) (32776) > fs->fs_bsize (32768) >> mount: /dev/gpt/rootfs: Invalid fstype: Invalid argument >>=20 >> Note that the size difference is: 8. >>=20 >> 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. >>=20 >> I tried the same for dd'ing: >>=20 >> = FreeBSD-14.0-CURRENT-arm-armv7-GENERICSD-20230518-743516d51fa7-263002.img >>=20 >> to USB3 media and trying to mount the UFS file system. (So: a week >> older .img file.) >=20 > Again: I'd also booted the media prior to this "try mouting > on an older system" activity. Again that activity includes a > growfs. >=20 >> The result was the same: >>=20 >> # mount -onoatime /dev/da1s2a /mnt >> UFS2 superblock failed: CGSIZE(fs) (32776) > fs->fs_bsize (32768) >> mount: /dev/da1s2a: Invalid fstype: Invalid argument >>=20 >>=20 >> I'll note that these 2 USB3 media booted themselves just fine before >> I tried this "try moutning via older system" activity. >>=20 >=20 In order to eliminate growfs, in the older context I dd'd FreeBSD-13.2-STABLE-arm-armv7-GENERICSD-20230601-cf3a76018cad-255472.img to a USB drive and tried to mount the ufs partition right afterwards. The console got the message: UFS2 superblock failed: CGSIZE(fs) (32776) > fs->fs_bsize (32768) never having booted that media. I'll note that the mount command itself (in a ssh session) looked like: # mount -onoatime /dev/da0s2a /mnt mount: /dev/da0s2a: Invalid fstype: Invalid argument So the type of problem is not clear from just the ssh session text. =3D=3D=3D Mark Millard marklmi at yahoo.com
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?C585AC7A-60C8-4725-83CC-69DCBB707E55>