Re: git: 1dfcff294e44 - main - release: increase IMAGE_SIZE for arm, arm64, riscv [odd alignment for SBC images]
- Reply: Mark Millard : "Re: git: 1dfcff294e44 - main - release: increase IMAGE_SIZE for arm, arm64, riscv [odd alignment for SBC images]"
- In reply to: Mark Millard : "Re: git: 1dfcff294e44 - main - release: increase IMAGE_SIZE for arm, arm64, riscv [odd alignment for SBC images]"
- Go to: [ bottom of page ] [ top of archives ] [ this month ]
Date: Sat, 30 Jul 2022 03:42:44 UTC
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 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 root@releng1.nyi.freebsd.org)
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