Snapshot stable/13-n252734-56533712694 first boot "gpart: arg0 'ufs/rootfs': Invalid argument"; also, an alignment question . . .

[While the example is an aarch64 context, the issue should be
more general.]


Issue #0:

After dd'ing:

FreeBSD-13.1-STABLE-arm64-aarch64-RPI-20221014-56533712694-252734.img

to the USB3 media booting got a notice:

gpart: arg0 'ufs/rootfs': Invalid argument

Showing some context:

. . .
Setting hostuuid: 30303031-3030-3030-3265-373238346338.
Setting hostid: 0xd2f9b0de.
Starting file system checks:
/dev/ufs/rootfs: FILE SYSTEM CLEAN; SKIPPING CHECKS
/dev/ufs/rootfs: clean, 498385 free (1281 frags, 62138 blocks, 0.1% fragmentation)
Growing root partition to fill device
random: randomdev_wait_until_seeded unblock wait
random: randomdev_wait_until_seeded unblock wait
random: unblocking device.
GEOM_PART: da0s2 was automatically resized.
  Use `gpart commit da0s2` to save changes or `gpart undo da0s2` to revert them.
da0s2 resized
da0s2a resized
gpart: arg0 'ufs/rootfs': Invalid argument
super-block backups (for fsck_ffs -b #) at:
. . . 

It looks like the line in question in /etc/rc.d/growfs is:

        gpart commit "$rootdev"

where the prior code:

        FSTYPE=$(mount -p | awk '{ if ( $2 == "/") { print $3 }}')
        FSDEV=$(mount -p | awk '{ if ( $2 == "/") { print $1 }}')
        case "$FSTYPE" in
        ufs)
                rootdev=${FSDEV#/dev/}
                ;;

assigned rootdev based on:

For FSTYPE:
# mount -p | awk '{ if ( $2 == "/") { print $3 }}'
ufs

For FSDEV:
# mount -p | awk '{ if ( $2 == "/") { print $1 }}'
/dev/ufs/rootfs

So: ufs/rootfs

I'd guess that the problem is that after the gpart resize -i . . .
activities the label ufs/rootfs is no longer effective for
gpart (until the growfs -y completes?).

Whatever the cause, gpart is rejecting the ufs/rootfs
notation.



Issue #1 (unsure of the intent, so checking):

# gpart show
=>       63  468862065  da0  MBR  (224G)
         63       1985       - free -  (993K)
       2048     102400    1  fat32lba  [active]  (50M)
     104448  468757680    2  freebsd  (224G)

=>        0  468757680  da0s2  BSD  (224G)
          0        128         - free -  (64K)
        128  468757552      1  freebsd-ufs  (224G)

Reviewing the alignments (one is differently
aligned than the others):

The first is good:

       2048     102400    1  fat32lba  [active]  (50M)

aligns to 512*2048 == 1 MiByte.

The second is likely good:

     104448  468757680    2  freebsd  (224G)

aligns to 512*104448 == 51 MiByte, so a 1 MiByte multiple
as the alignment.

But the 3rd is less aligned (the freebsd-ufs line):

     104448  468757680    2  freebsd  (224G)

=>        0  468757680  da0s2  BSD  (224G)
          0        128         - free -  (64K)
        128  468757552      1  freebsd-ufs  (224G)

aligns to 512*104448 + 512*128 but 512*128 is a
64 KiByte offset, so: 51 MiByte + 64 KiByte.

This is not 1 MiByte aligned but is 64 KiByte aligned.
Is that the intended alignment for the freebsd-ufs
area?

===
Mark Millard
marklmi at yahoo.com