Date: Fri, 29 Jul 2022 23:03:31 -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: <83383E16-29B2-4181-B666-B0A9C4D5451A@yahoo.com> In-Reply-To: <3B32D8E3-A436-4CF6-8CCB-6798EC7F50DC@yahoo.com> 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> <AA836971-668D-49A4-B9ED-8DC5B3C84085@yahoo.com> <7E1AE740-FA45-4889-BD70-8EABB0725B39@yahoo.com> <3BF6B9DD-26DF-4C82-B2CE-E460D94F6C95@yahoo.com> <3B32D8E3-A436-4CF6-8CCB-6798EC7F50DC@yahoo.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 2022-Jul-29, at 22:09, Mark Millard <marklmi@yahoo.com> wrote:
> On 2022-Jul-29, at 20:42, Mark Millard <marklmi@yahoo.com> wrote:
>=20
>> On 2022-Jul-29, at 20:11, Mark Millard <marklmi@yahoo.com> wrote:
>>=20
>>> On 2022-Jul-29, at 19:56, Mark Millard <marklmi@yahoo.com> wrote:
>>>=20
>>>> On 2022-Jul-29, at 13:49, Glen Barber <gjb@FreeBSD.org> wrote:
>>>>=20
>>>>> 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
>>>>=20
>>>> Well, it is a mix, I think (unsure).
>>>> . . .
>=20
> I got a little more evidence about the type of problem,
> I think. (Not that I know the interpretation to give
> the evidence.)
>=20
> Instead of booting the 13-STABLE media I put it into a
> booted system to look at it:
>=20
> =3D> 63 468862065 da0 MBR (224G)
> 63 1985 - free - (993K)
> 2048 102400 da0s1 fat32lba [active] (50M)
> 104448 468757680 da0s2 freebsd (224G)
>=20
> =3D> 0 468757680 da0s2 BSD (224G)
> 0 10381312 da0s2a freebsd-ufs (5.0G)
> 10381312 458376368 - free - (219G)
>=20
> (I've ignored ufs/rootfs ufs/rootfsa, ufsid/* above.)
>=20
> Compare/contrast:
>=20
> # growfs /dev/da0s2a
> growfs: unable to read superblock: Input/output error
>=20
> # growfs /dev/ufs/rootfs
> growfs: requested size 224GB is equal to the current filesystem size =
224GB
>=20
> # mount -noatime /dev/da0s2 /mnt
> # umount /mnt
> # mount -noatime /dev/da0s2a /mnt
> g_vfs_done():da0s2a[READ(offset=3D5920980992, length=3D8192)]error =3D =
5
> mount: /dev/da0s2a: Input/output error
>=20
> # gpart resize -i 1 /dev/da0s2
>=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 468757680 1 freebsd-ufs (224G)
>=20
> # gpart show -p
> . . .
> =3D> 63 468862065 da0 MBR (224G)
> 63 1985 - free - (993K)
> 2048 102400 da0s1 fat32lba [active] (50M)
> 104448 468757680 da0s2 freebsd (224G)
>=20
> =3D> 0 468757680 da0s2 BSD (224G)
> 0 468757680 da0s2a freebsd-ufs (224G)
>=20
> # mount -noatime /dev/da0s2a /mnt
> # umount /mnt
>=20
> After that I can again use it to boot the 8GiByte RPi4B.
>=20
> But, having booted itself, it shows . . .
>=20
> 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)
>=20
> 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)
>=20
> So, again, no da0s2 BSD or da0s2a freebsd-ufs .
> (Unlike gpart show on the normal-boot main [so: 14]
> system.)
>=20
> After shutting down and plugging into the normal-boot
> system . . .
>=20
> glabel list on the normal-boot system with the USB3
> SSD plugged in shows:
>=20
> Geom name: da0s1
> Providers:
> 1. Name: msdosfs/MSDOSBOOT
> Mediasize: 52428800 (50M)
> Sectorsize: 512
> Stripesize: 0
> Stripeoffset: 1048576
> Mode: r0w0e0
> secoffset: 0
> offset: 0
> seclength: 102400
> length: 52428800
> index: 0
> Consumers:
> 1. Name: da0s1
> Mediasize: 52428800 (50M)
> Sectorsize: 512
> Stripesize: 0
> Stripeoffset: 1048576
> Mode: r0w0e0
>=20
> Geom name: da0s2
> Providers:
> 1. Name: ufsid/62e358b6cff37c76
> Mediasize: 240003932160 (224G)
> Sectorsize: 512
> Stripesize: 0
> Stripeoffset: 53477376
> Mode: r0w0e0
> secoffset: 0
> offset: 0
> seclength: 468757680
> length: 240003932160
> index: 0
> Consumers:
> 1. Name: da0s2
> Mediasize: 240003932160 (224G)
> Sectorsize: 512
> Stripesize: 0
> Stripeoffset: 53477376
> Mode: r0w0e0
>=20
> Geom name: da0s2
> Providers:
> 1. Name: ufs/rootfs
> Mediasize: 240003932160 (224G)
> Sectorsize: 512
> Stripesize: 0
> Stripeoffset: 53477376
> Mode: r0w0e0
> secoffset: 0
> offset: 0
> seclength: 468757680
> length: 240003932160
> index: 0
> Consumers:
> 1. Name: da0s2
> Mediasize: 240003932160 (224G)
> Sectorsize: 512
> Stripesize: 0
> Stripeoffset: 53477376
> Mode: r0w0e0
>=20
> while the gpart show -p on that system lists:
>=20
> =3D> 63 468862065 da0 MBR (224G)
> 63 1985 - free - (993K)
> 2048 102400 da0s1 fat32lba [active] (50M)
> 104448 468757680 da0s2 freebsd (224G)
>=20
> =3D> 0 468757680 da0s2 BSD (224G)
> 0 468757680 da0s2a freebsd-ufs (224G)
>=20
> =3D> 0 468757680 ufsid/62e358b6cff37c76 BSD (224G)
> 0 468757680 ufsid/62e358b6cff37c76a freebsd-ufs (224G)
>=20
> =3D> 0 468757680 ufs/rootfs BSD (224G)
> 0 468757680 ufs/rootfsa freebsd-ufs (224G)
>=20
> Having managed to expand da0s2a seems better, but
> it is still odd, including the mismatch in what
> the self-booting 13-STABLE shows via gpart show
> vs. what the normal-boot shows. The normal-boot
> is of (line manually split for readability):
>=20
> # uname -apKU
> FreeBSD CA72_16Gp_ZFS 14.0-CURRENT FreeBSD 14.0-CURRENT #59
> main-n256584-5bc926af9fd1-dirty: Wed Jul 6 18:10:52 PDT 2022
> =
root@CA72_16Gp_ZFS:/usr/obj/BUILDs/main-CA72-nodbg-clang/usr/main-src/arm6=
4.aarch64/sys/GENERIC-NODBG-CA72
> arm64 aarch64 1400063 1400063.
. . .
So I tried plugging in the 14-CURRENT media into the
RPi4B while it was booted from the 13-STABLE media.
root@generic:~ # gpart show
. . .
=3D> 63 468862065 da1 MBR (224G)
63 1985 - free - (993K)
2048 102400 1 fat32lba [active] (50M)
104448 468757680 2 freebsd (224G)
=3D> 0 468757680 da1s2 BSD (224G)
0 10381312 1 freebsd-ufs (5.0G)
10381312 458376368 - free - (219G)
=3D> 63 468862065 diskid/DISK-00000000000A MBR (224G)
63 1985 - free - (993K)
2048 102400 1 fat32lba [active] =
(50M)
104448 468757680 2 freebsd (224G)
=3D> 0 468757680 ufsid/62e3bdbe47334896 BSD (224G)
0 10381312 1 freebsd-ufs (5.0G)
10381312 458376368 - free - (219G)
=3D> 0 468757680 diskid/DISK-00000000000As2 BSD (224G)
0 10381312 1 freebsd-ufs (5.0G)
10381312 458376368 - free - (219G)
So: BSD and freebsd-ufs visible.
root@generic:~ # gpart resize -i1 /dev/da1s2
da1s2a resized
root@generic:~ # gpart show
. . .
=3D> 63 468862065 da1 MBR (224G)
63 1985 - free - (993K)
2048 102400 1 fat32lba [active] (50M)
104448 468757680 2 freebsd (224G)
=3D> 0 468757680 da1s2 BSD (224G)
0 468757680 1 freebsd-ufs (224G)
=3D> 63 468862065 diskid/DISK-00000000000A MBR (224G)
63 1985 - free - (993K)
2048 102400 1 fat32lba [active] =
(50M)
104448 468757680 2 freebsd (224G)
=3D> 0 468757680 diskid/DISK-00000000000As2 BSD (224G)
0 468757680 1 freebsd-ufs (224G)
Note that ufsid/* disappeared.
So only the boot media seems to stop with:
=3D> 63 468862065 da0 MBR (224G)
63 1985 - free - (993K)
2048 102400 1 fat32lba [active] (50M)
104448 468757680 2 freebsd (224G)
(no BSD or freebsd-ufs or such).
Unfortunately, the 14-CURRENT media seems to consistently get:
. . .
WARNING: WITNESS option enabled, expect reduced performance.
Trying to mount root from ufs:/dev/ufs/rootfs [rw]...
ugen0.2: <vendor 0x2109 USB2.0 Hub> at usbus0
uhub1 on uhub0
uhub1: <vendor 0x2109 USB2.0 Hub, class 9/0, rev 2.10/4.21, addr 1> on =
usbus0
uhub1: 4 ports with 4 removable, self powered
Root mount waiting for: usbus0
Root mount waiting for: usbus0
uhub_reattach_port: port 3 reset failed, error=3DUSB_ERR_TIMEOUT
uhub_reattach_port: device problem (USB_ERR_TIMEOUT), disabling port 3
mountroot: waiting for device /dev/ufs/rootfs...
Mounting from ufs:/dev/ufs/rootfs failed with error 19.
Loader variables:
vfs.root.mountfrom=3Dufs:/dev/ufs/rootfs
vfs.root.mountfrom.options=3Drw
Manual root filesystem specification:
<fstype>:<device> [options]
Mount <device> using filesystem <fstype>
and with the specified (optional) option list.
eg. ufs:/dev/da0s1a
zfs:zroot/ROOT/default
cd9660:/dev/cd0 ro
(which is equivalent to: mount -t cd9660 -o ro /dev/cd0 /)
? List valid disk boot devices
. Yield 1 second (for background tasks)
<empty line> Abort manual input
mountroot>=20
This is independent of if I use initial_turbo=3D60 or
force_turbo=3D1 in the RPi4B's config.txt . (These
avoid variability in the actual timeout time frames
in the early activity.)
However, my normal use of main [so: 14] is not via
WITNESS/invariants or such but the snapshot build
is. So I might not have noticed and this might not
be new for WITNESS/invariants main-kernels.
As stands, 13.1-STABLE is my better test context.
=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?83383E16-29B2-4181-B666-B0A9C4D5451A>