Date: Thu, 11 Aug 2022 11:22:53 -0300 From: "Dr. Rolf Jansen" <freebsd-rj@cyclaero.com> To: freebsd-arm <freebsd-arm@freebsd.org> Cc: Mark Millard <marklmi@yahoo.com> 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: <F466F020-40C8-4983-82CB-02B95A80ADAA@cyclaero.com> In-Reply-To: <82C4CD12-A9F2-4DEB-86BB-1D12FF21DEE3@yahoo.com> References: <A1AA705B-531D-45A2-9A1F-89F759550D3A@yahoo.com> <EA1CDEC5-A29E-43C5-9437-050CDBEC2233@freebsd.org> <619709DF-C1B6-4B86-A6A3-A8F66090F92A@cyclaero.com> <82C4CD12-A9F2-4DEB-86BB-1D12FF21DEE3@yahoo.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> Am 11.08.2022 um 00:22 schrieb Mark Millard <marklmi@yahoo.com>:
>=20
> On 2022-Aug-10, at 16:01, Dr. Rolf Jansen <rj@cyclaero.com> wrote:
>=20
>> I just a BeagleBone Black which was in my drawer for more than a year =
or so. I partitioned the internal flash (here mmcsd1) manually some =
years ago. The u-boot stuff was still quite tiny at that time. Now look =
what I found:
>>=20
>> =3D> 63 62410689 mmcsd0 MBR (30G)
>> 63 25 - free - (13K)
>> 88 102312 1 fat32lba [active] (50M)
>> 102400 62308352 2 freebsd (30G)
>>=20
>> =3D> 0 62308352 mmcsd0s2 BSD (30G)
>> 0 56623104 1 freebsd-ufs (27G)
>> 56623104 5685248 2 freebsd-swap (2.7G)
>>=20
>> =3D> 63 7471041 mmcsd1 MBR (3.6G)
>> 63 961 - free - (481K)
>> 1024 15360 1 fat32lba [active] (7.5M)
>> 16384 7454720 2 freebsd (3.6G)
>>=20
>> =3D> 0 7454720 mmcsd1s2 BSD (3.6G)
>> 0 7454720 1 freebsd-ufs (3.6G)
>>=20
>> =3D> 0 7454720 ufsid/5c9c24b911822409 BSD (3.6G)
>> 0 7454720 1 freebsd-ufs (3.6G)
>>=20
>> =3D> 0 7454720 ufs/system BSD (3.6G)
>> 0 7454720 1 freebsd-ufs (3.6G)
>>=20
>> ls -l /dev/ufs
>>=20
>> crw-r----- 1 root operator 0x6a Aug 10 17:52 system
>> crw-r----- 1 root operator 0x56 Aug 10 17:52 SYSTEM
>> crw-r----- 1 root operator 0x6d Aug 10 17:52 systema
>>=20
>> The BBB has been booted from a new SD card with FreeBSD 13.1-RELEASE =
on /dev/ufs/SYSTEM,
>=20
> If I gather right, this is some sort of personal setup of
> FreeBSD 13.1-RELEASE . For example, release/tools/arm.subr
> uses:
>=20
> chroot ${CHROOTDIR} newfs -U -L rootfs /dev/${mddev}s2a
>=20
> No attempt to create a ufs/SYSTEM label that I see.
>=20
> (The gpart output above does not show ufs/SYSTEM at all.)
>=20
> As stands, I can not compare/contrast the command sequences
> used vs. the results across the examples.
I don=E2=80=99t use system scripts for partitioning, formatting, =
labelling installation
1. Partitioning using gpart, here a SD card via an external USB reader =
on da0:
gpart destroy -F da0
gpart create -s MBR da0
gpart add -b 88 -s 102312 -t fat32lba da0
gpart add -t freebsd da0
gpart create -s BSD da0s2
gpart add -s 56623104 -t freebsd-ufs da0s2
gpart add -t freebsd-swap da0s2
Note, the size of the FAT32 boot partition has been chosen to match =
exactly what=E2=80=99s on the distribution images. Then the base of 88 =
is mandatory so the BSD payload partition may start on a perfectly =
aligned boundary of 102400=C2=B7512kByte =3D 102400=C2=B7512 =3D =
52428800 byte. Perfectly, because this base is 4k-, 8k-, 16k-, 32k-, =
64k-, 128k-, 256k-, 512k-, 1M-, 2M-aligned. It only stops being perfect, =
in case somebody needs 4M-alignment.
2. Formatting and labelling
newfs -njU -L SYSTEM /dev/da0s2a
glabel label -v SWAP /dev/da0s2b
3. Installation - here from the ARMv7 SD card image, but it does work =
almost the same for any of the other ARM images as well:
mdconfig -a -u 0 -t vnode -f =
FreeBSD-14.0-CURRENT-arm-armv7-GENERICSD-20220805-e24c5c60d72-257129.img
a) for the FAT32 boot partition, dd does the installation and labeling =
in one breath:
dd if=3D/dev/md0s1 of=3D/dev/da0s1 bs=3D512k
b) File system cloning from the SD card image to the freebsd-ufs volume =
using my tool sysutils/clone (s. also https://github.com/cyclaero/clone:
mount -o noatime /dev/md0s2a /media
mount -o noatime /dev/da0s2a /mnt
clone -x .sujournal /media /mnt
c) edit /mnt/etc/fstab:
/dev/ufs/SYSTEM / ufs rw,noatime =
0 1
/dev/label/SWAP none swap sw =
0 0
/dev/msdosfs/MSDOSBOOT /boot/msdos msdosfs rw,noatime =
0 0
tmpfs /tmp tmpfs rw,mode=3D1777,size=3D50m =
0 0
d) disable growfs in /etc/rc.conf
This looks a little bit more involved than just calling a script. After =
all it takes a few minutes more than by a script, and in case something =
goes wrong, then I know whom to blame, namely me :-)
The benefit is, that I end up with a journaled FS and a swap partition.
>> and /dev/ufs/SYSTEMa does not exist here. While I see /dev/ufs/system =
and /dev/ufs/systema for the some years old freebsd-ufs slice on the =
internal flash.
The internal flash is too tiny for adding a swap volume, so the whole =
BSD slice was used for the UFS volume. And actually this difference gave =
rise to - hmm..., wait a moment.
>> The BBB starts without problems from the internal flash once I remove =
the SD card.
>>=20
>> I just partitioned another SD card without the swap partition, and =
after applying newfs -njU -L rootfs dev/da0s2a, I see /dev/ufs/rootfs =
and /dev/ufs/rootfsa. Both can be mounted and work without problems.
>=20
> Interesting that the swap partition vs. not makes such a difference
> in what labels show up, referencing where. Being strictly after the
> freebsd-ufs area (if your example gpart output above applies), that
> complicates interpreting things. Just start-offset-in-BSD aliasing
> is not going to be an explanation for that, for sure.
Exactly, and in a previous message you stated already:
>> Am 09.08.2022 um 15:55 schrieb Mark Millard <marklmi@yahoo.com>:
>>=20
>> I really doubt that using kern.geom.part.mbr.enforce_chs=3D1 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.
My finding support your view. Only it seems now, that we may choose on =
how to make the volume distinct from the slice, namely both or either of =
offset and size. =20
> FYI:
> I booted the original test snapshot. But after its initial activity,
> the following reboot attempts could not complete. I sent a messy
> series of list messages from exploring/learning for this, including
> a sequence of adjustments that eventually got things to back to
> booting.
>=20
>> I tend to believe now, that we don=E2=80=99t see a bug when rootfsa =
besides rootfs appears, but a mostly unknown feature.
>=20
> My test case got boot failures --after the initial boot appeared
> to work and basically operate. No later boot attempt completed
> until I'd made adjustments. Testing of my "move the freebsd-ufs
> offset to be distinct" hypothesis is expected to be set up in
> this week's snapshot builds. But it may well end up not be any
> sort of final test fixing all the issues --or even identifying
> them all. Time will tell.
Well, I can only tell that my systems boot fine, either with or without =
the second ufs/<label>a. For example I can mount the UFS volume on the =
internal flash of the BBB by either label:
mount -o noatime /dev/ufs/system /mnt
unmount /mnt
mount -o noatime /dev/ufs/systema /mnt
Both commands result in mounting the very UFS system volume on mount =
point /mnt. No visible differences. Up to now, I never paid attention to =
this, and in /etc/fstab on the internal flash, only /dev/ufs/system is =
referenced, I never imagined that there could be the label =E2=80=9Esystem=
a".
>> If this disturbs somehow, growfs could perhaps be enhanced to either =
leave some space at the end of slice 2 or optionally add a =
swap-partition of size X. Both measures would effectively prevent the =
additional label rootfsa.
>=20
> There is the possibility that the week's snapshot test will
> end up having ufs/rootfs referencing *s2a like it should
> but that there are still problems observed. That is one of
> the reasons for doing the test: trying to isolate separate
> problems if things still are not working well overall after
> the change.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?F466F020-40C8-4983-82CB-02B95A80ADAA>