Date: Fri, 29 Jul 2022 22:09:43 -0700 From: Mark Millard <marklmi@yahoo.com> To: Glen Barber <gjb@FreeBSD.org> Cc: Warner Losh <imp@bsdimp.com>, Ed Maste <emaste@freebsd.org>, "Rodney W. Grimes" <freebsd-rwg@gndrsh.dnsmgr.net>, dev-commits-src-main@freebsd.org, "Dr. Rolf Jansen" <freebsd-rj@cyclaero.com>, freebsd-arm <freebsd-arm@freebsd.org> Subject: Re: git: 1dfcff294e44 - main - release: increase IMAGE_SIZE for arm, arm64, riscv [odd alignment for SBC images] Message-ID: <3B32D8E3-A436-4CF6-8CCB-6798EC7F50DC@yahoo.com> In-Reply-To: <3BF6B9DD-26DF-4C82-B2CE-E460D94F6C95@yahoo.com> References: <16906DFD-286B-4D59-9438-CA9CD9026C55@yahoo.com> <202207171708.26HH81bA062303@gndrsh.dnsmgr.net> <CAPyFy2D1aBe8h4kq=RqCR2tkEiEXh_pHNEqaAnW7tk9-HxCmBQ@mail.gmail.com> <20220719204245.GL30607@FreeBSD.org> <CANCZdfoABLggPQgDeCZ5FzYCf8243kvr-p8Bj5_JGNnEszGHBw@mail.gmail.com> <D630043D-6EAC-4216-A046-910DB64F8B4A@yahoo.com> <20220729204943.GT30607@FreeBSD.org> <AA836971-668D-49A4-B9ED-8DC5B3C84085@yahoo.com> <7E1AE740-FA45-4889-BD70-8EABB0725B39@yahoo.com> <3BF6B9DD-26DF-4C82-B2CE-E460D94F6C95@yahoo.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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:
>=20
>> On 2022-Jul-29, at 19:56, Mark Millard <marklmi@yahoo.com> wrote:
>>=20
>>> On 2022-Jul-29, at 13:49, Glen Barber <gjb@FreeBSD.org> wrote:
>>>=20
>>>> 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=3D0 and see what breaks, if =
anything?
>>>>> (Sort of a snapshot exp run.)
>>>>>=20
>>>>> More than just the SBC images might be involved for
>>>>> kern.geom.part.mbr.enforce_ch consequences, for all I know.
>>>>>=20
>>>>=20
>>>> Hey, Mark.
>>>>=20
>>>> 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=3D0 on the builders?
>>>>=20
>>>=20
>>> 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:
=3D> 63 468862065 da0 MBR (224G)
63 1985 - free - (993K)
2048 102400 da0s1 fat32lba [active] (50M)
104448 468757680 da0s2 freebsd (224G)
=3D> 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=3D5920980992, length=3D8192)]error =3D 5
mount: /dev/da0s2a: Input/output error
# gpart resize -i 1 /dev/da0s2
# gpart show
. . .
=3D> 63 468862065 da0 MBR (224G)
63 1985 - free - (993K)
2048 102400 1 fat32lba [active] (50M)
104448 468757680 2 freebsd (224G)
=3D> 0 468757680 da0s2 BSD (224G)
0 468757680 1 freebsd-ufs (224G)
# gpart show -p
. . .
=3D> 63 468862065 da0 MBR (224G)
63 1985 - free - (993K)
2048 102400 da0s1 fat32lba [active] (50M)
104448 468757680 da0s2 freebsd (224G)
=3D> 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
=3D> 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
=3D> 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:
=3D> 63 468862065 da0 MBR (224G)
63 1985 - free - (993K)
2048 102400 da0s1 fat32lba [active] (50M)
104448 468757680 da0s2 freebsd (224G)
=3D> 0 468757680 da0s2 BSD (224G)
0 468757680 da0s2a freebsd-ufs (224G)
=3D> 0 468757680 ufsid/62e358b6cff37c76 BSD (224G)
0 468757680 ufsid/62e358b6cff37c76a freebsd-ufs (224G)
=3D> 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/arm6=
4.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:=20
# uhub_reattach_port: port ? reset failed, error=3DUSB_ERR_TIMEOUT=20
# uhub_reattach_port: device problem (USB_ERR_TIMEOUT), disabling port =
?=20
initial_turbo=3D60=20
I also comment out the hdmi_safe=3D1 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=3D1 can lead
to.
=3D=3D=3D
Mark Millard
marklmi at yahoo.com
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3B32D8E3-A436-4CF6-8CCB-6798EC7F50DC>