Date: Mon, 17 Oct 2022 12:59:08 -0700 From: Mark Millard <marklmi@yahoo.com> To: Glen Barber <gjb@FreeBSD.org> Cc: freebsd-arm <freebsd-arm@freebsd.org>, Warner Losh <imp@bsdimp.com> Subject: Re: Snapshot stable/13-n252734-56533712694 first boot "gpart: arg0 'ufs/rootfs': Invalid argument"; also, an alignment question . . . Message-ID: <2287A7D8-8866-4481-A8C7-072B2C380B0C@yahoo.com> In-Reply-To: <3DA3BC90-D234-4B37-9125-E7A70F16DD08@yahoo.com> References: <3DA3BC90-D234-4B37-9125-E7A70F16DD08@yahoo.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 2022-Oct-17, at 12:30, Mark Millard <marklmi@yahoo.com> wrote:
> [While the example is an aarch64 context, the issue should be
> more general.]
The above was for issue #0.
> Issue #0:
>=20
> After dd'ing:
>=20
> FreeBSD-13.1-STABLE-arm64-aarch64-RPI-20221014-56533712694-252734.img
>=20
> to the USB3 media booting got a notice:
>=20
> gpart: arg0 'ufs/rootfs': Invalid argument
>=20
> Showing some context:
>=20
> . . .
> 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:
> . . .=20
>=20
> It looks like the line in question in /etc/rc.d/growfs is:
>=20
> gpart commit "$rootdev"
>=20
> where the prior code:
>=20
> FSTYPE=3D$(mount -p | awk '{ if ( $2 =3D=3D "/") { print $3 =
}}')
> FSDEV=3D$(mount -p | awk '{ if ( $2 =3D=3D "/") { print $1 }}')
> case "$FSTYPE" in
> ufs)
> rootdev=3D${FSDEV#/dev/}
> ;;
>=20
> assigned rootdev based on:
>=20
> For FSTYPE:
> # mount -p | awk '{ if ( $2 =3D=3D "/") { print $3 }}'
> ufs
>=20
> For FSDEV:
> # mount -p | awk '{ if ( $2 =3D=3D "/") { print $1 }}'
> /dev/ufs/rootfs
>=20
> So: ufs/rootfs
>=20
> 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?).
>=20
> Whatever the cause, gpart is rejecting the ufs/rootfs
> notation.
>=20
>=20
>=20
> Issue #1 (unsure of the intent, so checking):
>=20
> # gpart show
> =3D> 63 468862065 da0 MBR (224G)
> 63 1985 - free - (993K)
> 2048 102400 1 fat32lba [active] (50M)
> 104448 468757680 2 freebsd (224G)
>=20
> =3D> 0 468757680 da0s2 BSD (224G)
> 0 128 - free - (64K)
> 128 468757552 1 freebsd-ufs (224G)
>=20
> Reviewing the alignments (one is differently
> aligned than the others):
>=20
> The first is good:
>=20
> 2048 102400 1 fat32lba [active] (50M)
>=20
> aligns to 512*2048 =3D=3D 1 MiByte.
>=20
> The second is likely good:
>=20
> 104448 468757680 2 freebsd (224G)
>=20
> aligns to 512*104448 =3D=3D 51 MiByte, so a 1 MiByte multiple
> as the alignment.
>=20
> But the 3rd is less aligned (the freebsd-ufs line):
>=20
> 104448 468757680 2 freebsd (224G)
>=20
> =3D> 0 468757680 da0s2 BSD (224G)
> 0 128 - free - (64K)
> 128 468757552 1 freebsd-ufs (224G)
>=20
> aligns to 512*104448 + 512*128 but 512*128 is a
> 64 KiByte offset, so: 51 MiByte + 64 KiByte.
>=20
> 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.]
=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?2287A7D8-8866-4481-A8C7-072B2C380B0C>