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

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 started with:
> 
> # dd if=FreeBSD-13.1-STABLE-arm64-aarch64-RPI-20220729-db2eff1cff8-251976.img of=/dev/da0 conv=sync,fsync bs=1m status=progress
>  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
> =>       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 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:
> 
> =>        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.
> 

It did not survive a simple reboot test:

. . .
FreeBSD/arm64 EFI loader, Revision 1.1

   Command line arguments: loader.efi
   Image base: 0x39b08000
   EFI version: 2.90
   EFI Firmware: Das U-Boot (rev 8226.1024)
   Console: efi (0x1000)
   Load Path: /efi\boot\bootaa64.efi
   Load Device: /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/UsbClass(0x0,0x0,0x9,0x0,0x3)/UsbClass(0x1e91,0xa2a5,0x0,0x0,0x0)/HD(1,0x01,0,0x800,0x19000)
Trying ESP: /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/UsbClass(0x0,0x0,0x9,0x0,0x3)/UsbClass(0x1e91,0xa2a5,0x0,0x0,0x0)/HD(1,0x01,0,0x800,0x19000)
Setting currdev to disk1p1:
Trying: /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/UsbClass(0x0,0x0,0x9,0x0,0x3)/UsbClass(0x1e91,0xa2a5,0x0,0x0,0x0)/HD(2,0x01,0,0x19800,0x1bf0acb0)
Setting currdev to disk1p2:
ERROR: cannot open /boot/lua/loader.lua: no such file or directory.


Type '?' for a list of commands, 'help' for more detailed help.
OK lsdev
disk devices:
    disk0:    60258304 X 512 blocks (removable)
    disk1:    468862128 X 512 blocks
      disk1s1: DOS/Windows
      disk1s2: FreeBSD
        disk1s2a: FreeBSD UFS
http: (unknown)
net devices:
    net0:
OK ls   
/
 d  EFI
 d  dtb
    README
    u-boot.bin
    armstub8.bin
    armstub8-gic.bin
    bootcode.bin
    fixup_cd.dat
    fixup_db.dat
    fixup_x.dat
    fixup.dat
    LICENCE.broadcom
    start_cd.elf
    start_db.elf
    start_x.elf
    start.elf
    fixup4.dat
    fixup4cd.dat
    fixup4db.dat
    fixup4x.dat
    start4.elf
    start4cd.elf
    start4db.elf
    start4x.elf
    bcm2710-rpi-2-b.dtb
    bcm2710-rpi-3-b.dtb
    bcm2710-rpi-3-b-plus.dtb
    bcm2711-rpi-4-b.dtb
    config.txt
 d  overlays
OK show
COLUMNS=200
LINES=60
autoboot_delay=NO
boot_serial=YES
console=efi
currdev=disk1s1:
efi-version=2.90
efi_com_port=0
efi_com_speed=9600
hint.smbios.0.mem=0x39c2e000
interpret=OK
loaddev=disk1s1:
prompt=${interpret}
script.lang=lua
smbios.bios.reldate=04/01/2022
smbios.bios.vendor=U-Boot
smbios.bios.version=2022.04
smbios.chassis.maker=Unknown
smbios.chassis.type=Desktop
smbios.planar.maker=Unknown
smbios.planar.product=Unknown Product
smbios.socket.enabled=1
smbios.system.maker=Unknown
smbios.system.product=Unknown Product
smbios.system.serial=100000007151395e
smbios.system.uuid=30303031-3030-3030-3731-353133393565
smbios.version=3.0
twiddle_divisor=16

So definitely not working for a 2nd boot.


===
Mark Millard
marklmi at yahoo.com