From nobody Thu Aug 11 14:22:53 2022 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4M3TYM1M5bz4Xy1W for ; Thu, 11 Aug 2022 14:23:03 +0000 (UTC) (envelope-from freebsd-rj@cyclaero.com) Received: from mo4-p00-ob.smtp.rzone.de (mo4-p00-ob.smtp.rzone.de [81.169.146.161]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "*.smtp.rzone.de", Issuer "TeleSec ServerPass Class 2 CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4M3TYL74Lbz3KqW for ; Thu, 11 Aug 2022 14:23:02 +0000 (UTC) (envelope-from freebsd-rj@cyclaero.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1660227778; s=strato-dkim-0002; d=cyclaero.com; h=To:References:Message-Id:Cc:Date:In-Reply-To:From:Subject:Cc:Date: From:Subject:Sender; bh=wdAOBtkRcb3rtT1/bCElFXgIw1y91c7b94vSvldX1zc=; b=My5inXuNNzSrEzbW3nI/D/EfDjuygZN+br+CE835V561SklnBhrWy7q2scUNh3eTOK EkLVEF7Sijsg2l85yWz9DW2IYf9mtTIGS8TeWYOJbN1YK2O8P+58xcNBSuwrPRsSSfNY A/bZm/+v5sH9k5hp0flFpcyjIwFfWJmHMYnzafujSQ0kHC3ZjeSNj34Ana+O2xgGw1DA BPIRxLlvsLYuR06qEk4ONtElpJTcQQBNEodE3ZrWGbS4oFcct42RKAYFyNfJNtGYJIB6 5phR2+yKWhCP+O9KS4a8bIhh/ZRyyuq2Jwd6G9n1FKdtqJVKgLed66cv8/uaUyUp0uQZ yySA== X-RZG-AUTH: ":O2kGeEG7b/pS1F2rRHW2isrKl4DV03XBEi+I6ZuztdvN9wS3wFGySS4Lw+ldTBio08NTPnK5bNCibgxfnBg=" X-RZG-CLASS-ID: mo00 Received: from mail.obsigna.com by smtp.strato.de (RZmta 47.47.0 AUTH) with ESMTPSA id q0201fy7BEMwAZZ (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256 bits)) (Client did not present a certificate); Thu, 11 Aug 2022 16:22:58 +0200 (CEST) Received: from rolf-mini.obsigna.com (unknown [177.188.53.90]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.obsigna.com (Postfix) with ESMTPSA id 31CD463969; Thu, 11 Aug 2022 16:22:56 +0200 (CEST) Content-Type: text/plain; charset=utf-8 List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.15\)) Subject: Re: Looks like the arm 20220805 snapshots are still odd, so probably kern.geom.part.mbr.enforce_chs=0 was still in use From: "Dr. Rolf Jansen" In-Reply-To: <82C4CD12-A9F2-4DEB-86BB-1D12FF21DEE3@yahoo.com> Date: Thu, 11 Aug 2022 11:22:53 -0300 Cc: Mark Millard Content-Transfer-Encoding: quoted-printable Message-Id: References: <619709DF-C1B6-4B86-A6A3-A8F66090F92A@cyclaero.com> <82C4CD12-A9F2-4DEB-86BB-1D12FF21DEE3@yahoo.com> To: freebsd-arm X-Mailer: Apple Mail (2.3445.104.15) X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Rspamd-Queue-Id: 4M3TYL74Lbz3KqW X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N > Am 11.08.2022 um 00:22 schrieb Mark Millard : >=20 > On 2022-Aug-10, at 16:01, Dr. Rolf Jansen 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 : >>=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/