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 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 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.
> 

14-CURRENT got a different result: a pair of . . .
"/dev/ufs/rootfs: Operation not permitted"

Setting hostuuid: 30303031-3030-3030-3731-353133393565.
Setting hostid: 0xd2468d7e.
Starting file system checks:
/dev/ufs/rootfs: FILE SYSTEM CLEAN; SKIPPING CHECKS
/dev/ufs/rootfs: clean, 601308 free (436 frags, 75109 blocks, 0.0% 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
growfs: /dev/ufs/rootfs: Operation not permitted
mount: /dev/ufs/rootfs: Operation not permitted
Mounting root filesystem rw failed, startup aborted
ERROR: ABORTING BOOT (sending SIGTERM to parent)!
2022-07-29T11:17:56.567464+00:00 - init 1 - - /bin/sh on /etc/rc terminated abnormally, going to single user mode
Enter full pathname of shell or RETURN for /bin/sh: 


The boot media was set up via:

# dd if=FreeBSD-14.0-CURRENT-arm64-aarch64-RPI-20220729-467d3e2e8aa-257025.img of=/dev/da0 conv=sync,fsync bs=1m status=progress
  5187305472 bytes (5187 MB, 4947 MiB) transferred 21.025s, 247 MB/s
5120+0 records in
5120+0 records out
5368709120 bytes transferred in 21.884283 secs (245322600 bytes/sec)

The same 8 GiByte RPI4B was used.

root@:/ # gpart show
=>       63  468862065  da0  MBR  (224G)
         63       1985       - free -  (993K)
       2048     102400    1  fat32lba  [active]  (50M)
     104448  468757680    2  freebsd  (224G)

=>        0  468757680  ufs/rootfs  BSD  (224G)
          0   10381312           1  freebsd-ufs  (5.0G)
   10381312  458376368              - free -  (219G)

root@:/ # 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   ufs/rootfs  BSD  (224G)
          0   10381312  ufs/rootfsa  freebsd-ufs  (5.0G)
   10381312  458376368               - free -  (219G)


However, in this context:

root@:/ # gpart commit ufs/rootfs
root@:/ # gpart show
=>       63  468862065  da0  MBR  (224G)
         63       1985       - free -  (993K)
       2048     102400    1  fat32lba  [active]  (50M)
     104448  468757680    2  freebsd  (224G)

=>        0  468757680  ufs/rootfs  BSD  (224G)
          0   10381312           1  freebsd-ufs  (5.0G)
   10381312  458376368              - free -  (219G)

=>        0  468757680  da0s2  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  diskid/DISK-00000000000As2  BSD  (224G)
          0   10381312                           1  freebsd-ufs  (5.0G)
   10381312  458376368                              - free -  (219G)

root@:/ # 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   ufs/rootfs  BSD  (224G)
          0   10381312  ufs/rootfsa  freebsd-ufs  (5.0G)
   10381312  458376368               - free -  (219G)

=>        0  468757680   da0s2  BSD  (224G)
          0   10381312  da0s2a  freebsd-ufs  (5.0G)
   10381312  458376368          - free -  (219G)

=>       63  468862065    diskid/DISK-00000000000A  MBR  (224G)
         63       1985                              - free -  (993K)
       2048     102400  diskid/DISK-00000000000As1  fat32lba  [active]  (50M)
     104448  468757680  diskid/DISK-00000000000As2  freebsd  (224G)

=>        0  468757680   diskid/DISK-00000000000As2  BSD  (224G)
          0   10381312  diskid/DISK-00000000000As2a  freebsd-ufs  (5.0G)
   10381312  458376368                               - free -  (219G)

So it looks like the growfs did not actually happen.

The following seems to have gotten me to about the
same type of context I got to for 13-STABLE:

root@:/ # mount -u /
root@:/ # gpart show 
=>       63  468862065  da0  MBR  (224G)
         63       1985       - free -  (993K)
       2048     102400    1  fat32lba  [active]  (50M)
     104448  468757680    2  freebsd  (224G)
root@:/ # exit
No suitable dump device was found.
Setting hostuuid: 30303031-3030-3030-3731-353133393565.
Setting hostid: 0xd2468d7e.
Fast boot: skipping disk checks.
Growing root partition to fill device
da0s2 resized
super-block backups (for fsck_ffs -b #) at:
 11524224, 12804672, 14085120, 15365568, 16646016, 17926464, 19206912, 20487360, 21767808, 23048256, 24328704, 25609152, 26889600, 28170048, 29450496, 30730944, 32011392, 33291840, 34572288,
. . .

Do a shutdown -r now form of reboot from this context also got:

. . .
FreeBSD/arm64 EFI loader, Revision 1.1
(Fri Jul 29 09:39:44 UTC 2022 [email protected])

   Command line arguments: loader.efi
   Image base: 0x39b02000
   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
    bcm2710-rpi-cm3.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:
module_verbose=2
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 the primary difference seems to be getting the 2
"/dev/ufs/rootfs: Operation not permitted" notices
and so getting the:

Mounting root filesystem rw failed, startup aborted

and such. After the "mount -u /" and exit, things
seem similar again.

===
Mark Millard
marklmi at yahoo.com
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.