Date: Fri, 29 Jul 2022 19:56:18 -0700 From: Mark Millard <marklmi@yahoo.com> To: Glen Barber <gjb@FreeBSD.org> Cc: Warner Losh <imp@bsdimp.com>, Ed Maste <emaste@freebsd.org>, "Rodney W. Grimes" <freebsd-rwg@gndrsh.dnsmgr.net>, dev-commits-src-main@freebsd.org, "Dr. Rolf Jansen" <freebsd-rj@cyclaero.com>, freebsd-arm <freebsd-arm@freebsd.org> Subject: Re: git: 1dfcff294e44 - main - release: increase IMAGE_SIZE for arm, arm64, riscv [odd alignment for SBC images] Message-ID: <AA836971-668D-49A4-B9ED-8DC5B3C84085@yahoo.com> In-Reply-To: <20220729204943.GT30607@FreeBSD.org> References: <16906DFD-286B-4D59-9438-CA9CD9026C55@yahoo.com> <202207171708.26HH81bA062303@gndrsh.dnsmgr.net> <CAPyFy2D1aBe8h4kq=RqCR2tkEiEXh_pHNEqaAnW7tk9-HxCmBQ@mail.gmail.com> <20220719204245.GL30607@FreeBSD.org> <CANCZdfoABLggPQgDeCZ5FzYCf8243kvr-p8Bj5_JGNnEszGHBw@mail.gmail.com> <D630043D-6EAC-4216-A046-910DB64F8B4A@yahoo.com> <20220729204943.GT30607@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 2022-Jul-29, at 13:49, Glen Barber <gjb@FreeBSD.org> wrote:
> On Wed, Jul 20, 2022 at 10:08:20AM -0700, Mark Millard wrote:
>> Would it seem appropriate to use a week (this week?) to do all
>> the snapshot builds with the builders all set to have
>> kern.geom.part.mbr.enforce_chs=3D0 and see what breaks, if anything?
>> (Sort of a snapshot exp run.)
>>=20
>> More than just the SBC images might be involved for
>> kern.geom.part.mbr.enforce_ch consequences, for all I know.
>>=20
>=20
> Hey, Mark.
>=20
> New snapshots for 13 and 14 are up now. Is it possible for you to =
check
> if the issues you had run into are indeed resolved, after setting
> kern.geom.part.mbr.enforce_chs=3D0 on the builders?
>=20
Well, it is a mix, I think (unsure).
I started with:
# dd =
if=3DFreeBSD-13.1-STABLE-arm64-aarch64-RPI-20220729-db2eff1cff8-251976.img=
of=3D/dev/da0 conv=3Dsync,fsync bs=3D1m status=3Dprogress
5222957056 bytes (5223 MB, 4981 MiB) transferred 21.027s, 248 MB/s
5120+0 records in
5120+0 records out
5368709120 bytes transferred in 21.816899 secs (246080301 bytes/sec)
I plugged the USB3 SSD into an old 8 GiByte RPi4B and it booted.
. . .
Starting file system checks:
/dev/ufs/rootfs: FILE SYSTEM CLEAN; SKIPPING CHECKS
/dev/ufs/rootfs: clean, 499417 free (1153 frags, 62283 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: ufs/rootfs was automatically resized.
Use `gpart commit ufs/rootfs` to save changes or `gpart undo =
ufs/rootfs` to revert them.
da0s2 resized
super-block backups (for fsck_ffs -b #) at:
11524224, 12804672, 14085120, 15365568, 16646016, 17926464, 19206912,
. . .
But, after logging in:
root@generic:~ # gpart show
=3D> 63 468862065 da0 MBR (224G)
63 1985 - free - (993K)
2048 102400 1 fat32lba [active] (50M)
104448 468757680 2 freebsd (224G)
root@generic:~ # gpart show -p
=3D> 63 468862065 da0 MBR (224G)
63 1985 - free - (993K)
2048 102400 da0s1 fat32lba [active] (50M)
104448 468757680 da0s2 freebsd (224G)
So 1985 and 2048 are there, as intended.
But no explicit da0s2 BSD or da0s2a freebsd-ufs shows up
in gpart show's output.
I wonder if this is because of a lack of a distinct
starting offset vs. the BSD. For example, the old 2016
and 2079 alignment had showed:
=3D> 0 468757737 da0s2 BSD (224G)
0 57 - free - (29K)
57 468757680 da0s2a freebsd-ufs (224G)
where the 57 was, appearently, for alignment. May be now
the distance from the da0s2 to da0s2a is zero and so
BSD and its contained da0s2a is not now shown?
I've yet to try the 14-CURRENT.
=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?AA836971-668D-49A4-B9ED-8DC5B3C84085>