Date: Wed, 10 Aug 2022 20:22:43 -0700 From: Mark Millard <marklmi@yahoo.com> To: "Dr. Rolf Jansen" <rj@cyclaero.com> Cc: freebsd-arm <freebsd-arm@freebsd.org>, Warner Losh <imp@bsdimp.com>, "Rodney W. Grimes" <freebsd-rwg@gndrsh.dnsmgr.net>, Ed Maste <emaste@freebsd.org>, Glen Barber <gjb@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: <82C4CD12-A9F2-4DEB-86BB-1D12FF21DEE3@yahoo.com> In-Reply-To: <619709DF-C1B6-4B86-A6A3-A8F66090F92A@cyclaero.com> References: <A1AA705B-531D-45A2-9A1F-89F759550D3A@yahoo.com> <EA1CDEC5-A29E-43C5-9437-050CDBEC2233@freebsd.org> <619709DF-C1B6-4B86-A6A3-A8F66090F92A@cyclaero.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 2022-Aug-10, at 16:01, Dr. Rolf Jansen <rj@cyclaero.com> wrote: > 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, If I gather right, this is some sort of personal setup of FreeBSD 13.1-RELEASE . For example, release/tools/arm.subr uses: chroot ${CHROOTDIR} newfs -U -L rootfs /dev/${mddev}s2a No attempt to create a ufs/SYSTEM label that I see. (The gpart output above does not show ufs/SYSTEM at all.) As stands, I can not compare/contrast the command sequences used vs. the results across the examples. > 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. >=20 > 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. 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. 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. > I tend to believe now, that we don=E2=80=99t see a bug when rootfsa = besides rootfs appears, but a mostly unknown feature. 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. > 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. 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. I did get an off-list E-mail asking about the issue and why I had my hypothesis. My hope is that the person ends up being someone else looking into the problem(s). They likely would have significant relevant background knowledge. =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?82C4CD12-A9F2-4DEB-86BB-1D12FF21DEE3>