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

On Mon, Oct 17, 2022 at 12:30:40PM -0700, Mark Millard wrote:
> [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?
> 

I am going to have to defer to our resident experts on this, to be
honest.

Glen