Re: git: 1dfcff294e44 - main - release: increase IMAGE_SIZE for arm, arm64, riscv [odd alignment for SBC images]
Date: Sat, 30 Jul 2022 06:03:31 UTC
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:
>
>> On 2022-Jul-29, at 20:11, Mark Millard <marklmi@yahoo.com> wrote:
>>
>>> On 2022-Jul-29, at 19:56, Mark Millard <marklmi@yahoo.com> wrote:
>>>
>>>> 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=0 and see what breaks, if anything?
>>>>>> (Sort of a snapshot exp run.)
>>>>>>
>>>>>> More than just the SBC images might be involved for
>>>>>> kern.geom.part.mbr.enforce_ch consequences, for all I know.
>>>>>>
>>>>>
>>>>> Hey, Mark.
>>>>>
>>>>> 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=0 on the builders?
>>>>>
>>>>
>>>> Well, it is a mix, I think (unsure).
>>>> . . .
>
> I got a little more evidence about the type of problem,
> I think. (Not that I know the interpretation to give
> the evidence.)
>
> Instead of booting the 13-STABLE media I put it into a
> booted system to look at it:
>
> => 63 468862065 da0 MBR (224G)
> 63 1985 - free - (993K)
> 2048 102400 da0s1 fat32lba [active] (50M)
> 104448 468757680 da0s2 freebsd (224G)
>
> => 0 468757680 da0s2 BSD (224G)
> 0 10381312 da0s2a freebsd-ufs (5.0G)
> 10381312 458376368 - free - (219G)
>
> (I've ignored ufs/rootfs ufs/rootfsa, ufsid/* above.)
>
> Compare/contrast:
>
> # growfs /dev/da0s2a
> growfs: unable to read superblock: Input/output error
>
> # growfs /dev/ufs/rootfs
> growfs: requested size 224GB is equal to the current filesystem size 224GB
>
> # mount -noatime /dev/da0s2 /mnt
> # umount /mnt
> # mount -noatime /dev/da0s2a /mnt
> g_vfs_done():da0s2a[READ(offset=5920980992, length=8192)]error = 5
> mount: /dev/da0s2a: Input/output error
>
> # gpart resize -i 1 /dev/da0s2
>
> # 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 468757680 1 freebsd-ufs (224G)
>
> # gpart show -p
> . . .
> => 63 468862065 da0 MBR (224G)
> 63 1985 - free - (993K)
> 2048 102400 da0s1 fat32lba [active] (50M)
> 104448 468757680 da0s2 freebsd (224G)
>
> => 0 468757680 da0s2 BSD (224G)
> 0 468757680 da0s2a freebsd-ufs (224G)
>
> # mount -noatime /dev/da0s2a /mnt
> # umount /mnt
>
> After that I can again use it to boot the 8GiByte RPi4B.
>
> But, having booted itself, it shows . . .
>
> root@generic:~ # gpart show
> => 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
> => 63 468862065 da0 MBR (224G)
> 63 1985 - free - (993K)
> 2048 102400 da0s1 fat32lba [active] (50M)
> 104448 468757680 da0s2 freebsd (224G)
>
> So, again, no da0s2 BSD or da0s2a freebsd-ufs .
> (Unlike gpart show on the normal-boot main [so: 14]
> system.)
>
> After shutting down and plugging into the normal-boot
> system . . .
>
> glabel list on the normal-boot system with the USB3
> SSD plugged in shows:
>
> 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
>
> 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
>
> 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
>
> while the gpart show -p on that system lists:
>
> => 63 468862065 da0 MBR (224G)
> 63 1985 - free - (993K)
> 2048 102400 da0s1 fat32lba [active] (50M)
> 104448 468757680 da0s2 freebsd (224G)
>
> => 0 468757680 da0s2 BSD (224G)
> 0 468757680 da0s2a freebsd-ufs (224G)
>
> => 0 468757680 ufsid/62e358b6cff37c76 BSD (224G)
> 0 468757680 ufsid/62e358b6cff37c76a freebsd-ufs (224G)
>
> => 0 468757680 ufs/rootfs BSD (224G)
> 0 468757680 ufs/rootfsa freebsd-ufs (224G)
>
> 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):
>
> # 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/arm64.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
. . .
=> 63 468862065 da1 MBR (224G)
63 1985 - free - (993K)
2048 102400 1 fat32lba [active] (50M)
104448 468757680 2 freebsd (224G)
=> 0 468757680 da1s2 BSD (224G)
0 10381312 1 freebsd-ufs (5.0G)
10381312 458376368 - free - (219G)
=> 63 468862065 diskid/DISK-00000000000A MBR (224G)
63 1985 - free - (993K)
2048 102400 1 fat32lba [active] (50M)
104448 468757680 2 freebsd (224G)
=> 0 468757680 ufsid/62e3bdbe47334896 BSD (224G)
0 10381312 1 freebsd-ufs (5.0G)
10381312 458376368 - free - (219G)
=> 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
. . .
=> 63 468862065 da1 MBR (224G)
63 1985 - free - (993K)
2048 102400 1 fat32lba [active] (50M)
104448 468757680 2 freebsd (224G)
=> 0 468757680 da1s2 BSD (224G)
0 468757680 1 freebsd-ufs (224G)
=> 63 468862065 diskid/DISK-00000000000A MBR (224G)
63 1985 - free - (993K)
2048 102400 1 fat32lba [active] (50M)
104448 468757680 2 freebsd (224G)
=> 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:
=> 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=USB_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=ufs:/dev/ufs/rootfs
vfs.root.mountfrom.options=rw
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>
This is independent of if I use initial_turbo=60 or
force_turbo=1 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.
===
Mark Millard
marklmi at yahoo.com