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

On 2022-Oct-17, at 12:30, Mark Millard <[email protected]> wrote:

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

The above was for issue #0.

> 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

Looks like main [so: 14] has this fixed in:

libexec/rc/rc.d/growfs

so it probably needs an MFC. Not a snapshot
handling specific issue, as it turns out.
[Glen might have been the wrong choice.]

> 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 guess, a different way of going at the overall
issue #1 question is: If 64 KiByte alignment is
okay for the freebsd-ufs area, should the other
two also be using 64 KiByte alignment instead of
1 MiByte alignment?

What I'm checking on is the lack of uniformity.
I'm not really trying to be the one picking among
the various uniform alternatives if uniformity is
appropriate.

[Why I did not notice this lack of uniformity back
during the alignment investigation, I do not know.]

===
Mark Millard
marklmi at yahoo.com