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 05:09:43 UTC
On 2022-Jul-29, at 20:42, Mark Millard <marklmi@yahoo.com> wrote:
> 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 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