Re: git: 1dfcff294e44 - main - release: increase IMAGE_SIZE for arm, arm64, riscv [odd alignment for SBC images]
Mark Millard <[email protected]>
| Newsgroups | gmane.os.freebsd.devel.arm |
|---|---|
| Message-ID | <[email protected]> |
On 2022-Jul-29, at 22:09, Mark Millard <[email protected]> wrote: > On 2022-Jul-29, at 20:42, Mark Millard <[email protected]> wrote: > >> On 2022-Jul-29, at 20:11, Mark Millard <[email protected]> wrote: >> >>> On 2022-Jul-29, at 19:56, Mark Millard <[email protected]> wrote: >>> >>>> On 2022-Jul-29, at 13:49, Glen Barber <[email protected]> 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