Date: Sat, 13 Aug 2022 08:04:41 +0200 From: Nicolas Caillaud <nicolas@lautrecote.org> To: freebsd-arm@freebsd.org Subject: Re: Looks like the arm 20220805 snapshots are still odd, so probably kern.geom.part.mbr.enforce_chs=0 was still in use Message-ID: <2ec46a85-43c8-7a77-bf54-36e50657b7f3@lautrecote.org> In-Reply-To: <20220813003034.GP30607@FreeBSD.org> References: <6AF28022-A8E7-46B3-B64E-99D217E9B6AC@yahoo.com> <0E0083BD-A749-4112-8FDA-62326EA95F8A@freebsd.org> <CAPyFy2AfGxgND-2KaPUy8RnS6MYaxQBnGDPBkz9vDhLekNN%2BbQ@mail.gmail.com> <20220809181513.GG30607@FreeBSD.org> <B1F1DA0E-128A-4778-8EF1-AD8F8F9102C5@yahoo.com> <944D4959-780A-4A45-B8F7-9F3E00741E48@yahoo.com> <20220813003034.GP30607@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
hi all
sorry to "troll", but how can I subscribe to this list ?
thank you very much
Le 13/08/2022 à 02:30, Glen Barber a écrit :
> On Fri, Aug 12, 2022 at 05:16:12PM -0700, Mark Millard wrote:
>> On 2022-Aug-9, at 11:55, Mark Millard <marklmi@yahoo.com> wrote:
>>
>>> On 2022-Aug-9, at 11:15, Glen Barber <gjb@FreeBSD.org> wrote:
>>>
>>>> On Tue, Aug 09, 2022 at 02:06:14PM -0400, Ed Maste wrote:
>>>>> On Sun, 7 Aug 2022 at 18:43, Glen Barber <gjb@freebsd.org> wrote:
>>>>>> Will do. I’ll commit the suggested change to main tomorrow.
>>>>>>
>>>>>> Thank you for your vigilant investigation.
>>>>> Shall I commit the enforce_chs check now?
>>>>> ---
>>>>> commit 6ee7d69e6b526f35789b23ba570025f1c3b39c1a
>>>>> Author: Ed Maste <emaste@FreeBSD.org>
>>>>> Date: Tue Jul 19 16:47:49 2022 -0400
>>>>>
>>>>> release: ensure enforce_chs sysctl is 0
>>>>>
>>>>> We do not want CHS-based alignment for VM or SD card release images.
>>>>>
>>>>> Sponsored by: The FreeBSD Foundation
>>>>>
>>>>> diff --git a/release/tools/arm.subr b/release/tools/arm.subr
>>>>> index 6e4ae731a0b9..01c5303cd4e1 100644
>>>>> --- a/release/tools/arm.subr
>>>>> +++ b/release/tools/arm.subr
>>>>> @@ -62,6 +62,10 @@ umount_loop() {
>>>>> }
>>>>>
>>>>> arm_create_disk() {
>>>>> + if [ $(sysctl -n kern.geom.part.mbr.enforce_chs) != 0 ]; then
>>>>> + return 1
>>>>> + fi
>>>>> +
>>>>> # Create the target raw file and temporary work directory.
>>>>> chroot ${CHROOTDIR} gpart create -s ${PART_SCHEME} ${mddev}
>>>>> if [ "${PART_SCHEME}" = "GPT" ]; then
>>>>>
>>>> Good question. Do we still want to ensure it is set to '0'? I'm a bit
>>>> confused from the back-and-forth on the original thread.
>>>>
>>>> If we do want to ensure it is set to '0', yes, please go ahead.
>>>>
>>> Hopefully this week's experiment with explicitly avoiding BSD
>>> and freebsd-ufs having the same offset inside BSD (avoiding
>>> both offsets being zero) will allow the UFS labeling to work
>>> right: freebsd-ufs being tied to a unique offset inside BSD.
>>>
>>> I really doubt that using kern.geom.part.mbr.enforce_chs=1 to
>>> cause the offsets to be different is reasonable, despite that
>>> it happens to make them distinct: the freebsd-ufs offset is
>>> better controlled explicitly elsewhere.
>>>
>> The experiment with this week's snapshot is working just fine.
>> It is based on the update:
>>
>> QUOTE
>> The branch main has been updated by gjb:
>>
>> URL: https://cgit.FreeBSD.org/src/commit/?id=45add40717c24ef0b5418664fae1718b15a0422b
>>
>> commit 45add40717c24ef0b5418664fae1718b15a0422b
>> Author: Glen Barber <gjb@FreeBSD.org>
>> AuthorDate: 2022-08-08 14:59:29 +0000
>> Commit: Glen Barber <gjb@FreeBSD.org>
>> CommitDate: 2022-08-08 14:59:29 +0000
>>
>> release: fix alignment for arm SoCs
>>
>> MFC after: 3 days
>> Submitted by: Mark Millard
>> Sponsored by: Rubicon Communications, LLC ("Netgate")
>> ---
>> release/tools/arm.subr | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/release/tools/arm.subr b/release/tools/arm.subr
>> index 3dea17339958..25d4640cc26b 100644
>> --- a/release/tools/arm.subr
>> +++ b/release/tools/arm.subr
>> @@ -77,7 +77,7 @@ arm_create_disk() {
>> chroot ${CHROOTDIR} newfs_msdos -L msdosboot -F ${FAT_TYPE} /dev/${mddev}s1
>> chroot ${CHROOTDIR} gpart add -t freebsd ${mddev}
>> chroot ${CHROOTDIR} gpart create -s bsd ${mddev}s2
>> - chroot ${CHROOTDIR} gpart add -t freebsd-ufs -a 64k ${mddev}s2
>> + chroot ${CHROOTDIR} gpart add -t freebsd-ufs -a 64k -b 64k ${mddev}s2
>> chroot ${CHROOTDIR} newfs -U -L rootfs /dev/${mddev}s2a
>> fi
>> END QUOTE
>>
>> This is unlike when the "-b 64k" was not present. This
>> includes rebooting after the initial boot, unlike before.
>> This is for dd'ing to USB3 NVMe SSD media and testing,
>> for both of:
>>
>> FreeBSD-14.0-CURRENT-arm64-aarch64-RPI-20220812-6a70a0c8bfa-257314.img
>> FreeBSD-13.1-STABLE-arm64-aarch64-RPI-20220812-eb2a9b78586-252107.img
>>
>> (The -b use implicitly also changed the size of the freebsd-ufs
>> slice, making it smaller.) For the media growfs is involved in
>> the initial boot.
>>
>> glabel list now shows ufs/rootfs bound to da0s2a and does not
>> show a ufs/rootfsa at all. There is no binding to da0s2 (BSD)
>> shown.
>>
>> # glabel list
>> Geom name: da0s1
>> Providers:
>> 1. Name: msdosfs/MSDOSBOOT
>> Mediasize: 52428800 (50M)
>> Sectorsize: 512
>> Stripesize: 0
>> Stripeoffset: 1048576
>> Mode: r1w1e1
>> secoffset: 0
>> offset: 0
>> seclength: 102400
>> length: 52428800
>> index: 0
>> Consumers:
>> 1. Name: da0s1
>> Mediasize: 52428800 (50M)
>> Sectorsize: 512
>> Stripesize: 0
>> Stripeoffset: 1048576
>> Mode: r1w1e2
>>
>> Geom name: da0s2a
>> Providers:
>> 1. Name: ufs/rootfs
>> Mediasize: 240003866624 (224G)
>> Sectorsize: 512
>> Stripesize: 0
>> Stripeoffset: 53542912
>> Mode: r1w1e1
>> secoffset: 0
>> offset: 0
>> seclength: 468757552
>> length: 240003866624
>> index: 0
>> Consumers:
>> 1. Name: da0s2a
>> Mediasize: 240003866624 (224G)
>> Sectorsize: 512
>> Stripesize: 0
>> Stripeoffset: 53542912
>> Mode: r1w1e2
>>
>> # 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 128 - free - (64K)
>> 128 468757552 da0s2a freebsd-ufs (224G)
>>
>> A difference in behavior is that "gpart show" does not
>> report the ufs/rootfs labeling. For all I know, this
>> could be expected. glabel does show ufs/rootfs .
>>
>> I do not know what would happen if only the size had
>> been made smaller but the starting offset had been left
>> at 0.
>>
>> But the evidence from the "without -b" and "with -b"
>> testing is that having starting offset 0 in BSD
>> and the same size as BSD can be a problem for the
>> freebsd-ufs slice as processed by the initial boot,
>> at least when ufs labeling is in use (here ufs/rootfs).
>>
>> So far, this week's snapshots look good to me for the
>> issue having been avoided but ending up better aligned
>> overall than when kern.geom.part.mbr.enforce_chs=1 was
>> in use.
>>
>> If a larger alignment is needed at some point for
>> freebsd-ufs, adjusting the pair of gpart add arguments
>> "-a 64k -b 64k" should deal with it.
>>
>>
>> Notes:
>>
>> The USB3 NNVMe SSD based testing was with a 8GiByte
>> RPi4B and so does have the addition of:
>>
>> #
>> # 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
>>
>> in the config.txt file that the RPi* firmware uses.
>> (It is for a separate issue --and FreeBSD does not
>> have such in place by default at this time.)
>>
> Mark,
>
> Thank you very much for the detailed information, and of course for
> reporting the problem, and testing variations of the correct behavior.
>
> Glen
>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?2ec46a85-43c8-7a77-bf54-36e50657b7f3>