Re: git: 1dfcff294e44 - main - release: increase IMAGE_SIZE for arm, arm64, riscv [odd alignment for SBC images]

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.



FYI: for 8 GiBye RPi4B's I add at the end of the config.txt :

#
# Local addition that avoids USB3 SSD boot failures that look like: 
#   uhub_reattach_port: port ? reset failed, error=USB_ERR_TIMEOUT 
#   uhub_reattach_port: device problem (USB_ERR_TIMEOUT), disabling port ? 
initial_turbo=60 

I also comment out the hdmi_safe=1 line. (Assigning 0 instead
also works.) But it is rare that I have video plugged in so
I'd not normally notice the problems that hdmi_safe=1 can lead
to.

===
Mark Millard
marklmi at yahoo.com