From nobody Wed Aug 10 23:02:57 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 4M357n485pz4Z2vD for ; Wed, 10 Aug 2022 23:03:01 +0000 (UTC) (envelope-from freebsd-rj@cyclaero.com) Received: from mo4-p01-ob.smtp.rzone.de (mo4-p01-ob.smtp.rzone.de [85.215.255.52]) (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 4M357m36JNz3Kqs for ; Wed, 10 Aug 2022 23:03:00 +0000 (UTC) (envelope-from freebsd-rj@cyclaero.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1660172578; s=strato-dkim-0002; d=cyclaero.com; h=Message-Id:In-Reply-To:To:References:Date:Subject:From:Cc:Date:From: Subject:Sender; bh=Y/t4JuS2ANjEbllIW70tRRq3VYAZpnepCepxk8CX9gI=; b=Bae09qfQwlxUZF8Ejr3pu8EUAQ078b1ccoilREo9yXDSlPGFXkD7s04BG3ACWD8qoj +q57dNn1DycUYhn0hyxN8M+3D1Kbfk8DiSMFW+1KdQlnUMKGzbpuknfbVv3stxY8w6xl v8Ph5O4eQ/gKPSqSsTvq5gg3g09UkRSnlW4MgkbZwAl3tf4pAnsWXC6PYnRXdFwElzzM T4ic5PAtVvzt1GyO7lwIngKsFjOirAT3aSabfUdPbQoDz+Xu58nrknICHUi/oeZhiPO1 /spAXQ8kyIKbWk0XYCm/8oEqjBYmpNDZ0Izq8P3UaLzIsfDqSFT5ZiXUV3O4XKBPp56a x9JQ== 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 q0201fy7AN2w6Wo (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256 bits)) (Client did not present a certificate) for ; Thu, 11 Aug 2022 01:02:58 +0200 (CEST) Received: from rolf-mini.obsigna.com (unknown [177.188.53.38]) (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 CB18A63B4E for ; Thu, 11 Aug 2022 01:02:57 +0200 (CEST) From: "Dr. Rolf Jansen" Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable 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 Date: Wed, 10 Aug 2022 20:02:57 -0300 References: To: freebsd-arm In-Reply-To: Message-Id: X-Mailer: Apple Mail (2.3445.104.15) X-Rspamd-Queue-Id: 4M357m36JNz3Kqs X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=pass header.d=cyclaero.com header.s=strato-dkim-0002 header.b=Bae09qfQ; dmarc=none; spf=pass (mx1.freebsd.org: domain of freebsd-rj@cyclaero.com designates 85.215.255.52 as permitted sender) smtp.mailfrom=freebsd-rj@cyclaero.com X-Spamd-Result: default: False [-2.00 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; FROM_NAME_HAS_TITLE(1.00)[dr]; NEURAL_HAM_SHORT(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ip4:85.215.255.0/24:c]; R_DKIM_ALLOW(-0.20)[cyclaero.com:s=strato-dkim-0002]; MIME_GOOD(-0.10)[text/plain]; FROM_EQ_ENVFROM(0.00)[]; ASN(0.00)[asn:6724, ipnet:85.215.255.0/24, country:DE]; RCVD_IN_DNSWL_NONE(0.00)[85.215.255.52:from]; MIME_TRACE(0.00)[0:+]; MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org]; TO_MATCH_ENVRCPT_ALL(0.00)[]; ARC_NA(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; TO_DN_ALL(0.00)[]; FROM_HAS_DN(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; DKIM_TRACE(0.00)[cyclaero.com:+]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org]; RCPT_COUNT_ONE(0.00)[1]; DMARC_NA(0.00)[cyclaero.com]; RCVD_TLS_ALL(0.00)[]; MID_RHS_MATCH_FROM(0.00)[] X-ThisMailContainsUnwantedMimeParts: N 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: =3D> 63 62410689 mmcsd0 MBR (30G) 63 25 - free - (13K) 88 102312 1 fat32lba [active] (50M) 102400 62308352 2 freebsd (30G) =3D> 0 62308352 mmcsd0s2 BSD (30G) 0 56623104 1 freebsd-ufs (27G) 56623104 5685248 2 freebsd-swap (2.7G) =3D> 63 7471041 mmcsd1 MBR (3.6G) 63 961 - free - (481K) 1024 15360 1 fat32lba [active] (7.5M) 16384 7454720 2 freebsd (3.6G) =3D> 0 7454720 mmcsd1s2 BSD (3.6G) 0 7454720 1 freebsd-ufs (3.6G) =3D> 0 7454720 ufsid/5c9c24b911822409 BSD (3.6G) 0 7454720 1 freebsd-ufs (3.6G) =3D> 0 7454720 ufs/system BSD (3.6G) 0 7454720 1 freebsd-ufs (3.6G) ls -l /dev/ufs 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 The BBB has been booted from a new SD card with FreeBSD 13.1-RELEASE on = /dev/ufs/SYSTEM, 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 BBB starts without problems from the internal flash once I remove = the SD card. 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. I tend to believe now, that we don=E2=80=99t see a bug when rootfsa = besides rootfs appears, but a mostly unknown feature. 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. > Am 07.08.2022 um 16:32 schrieb Glen Barber : >=20 > Correct, it was set to =E2=80=9C0=E2=80=9D for these builds. >=20 > I honestly do not have any idea where the problems you are seeing are = creeping in. >=20 > Should it be set back to =E2=80=9C1=E2=80=9D? I=E2=80=99m not sure = how to proceed otherwise. >=20 > Glen > Sent from my phone. > Please excuse my brevity and/or typos. >=20 >> On Aug 7, 2022, at 12:10 AM, Mark Millard wrote: >>=20 >> =EF=BB=BFThe oddities look like indicated below. >>=20 >> # mdconfig -u md1 -f = FreeBSD-14.0-CURRENT-arm64-aarch64-RPI-20220805-e24c5c60d72-257129.img >> # gpart show >> . . . >>=20 >> =3D> 63 10485697 md1 MBR (5.0G) >> 63 1985 - free - (993K) >> 2048 102400 1 fat32lba [active] (50M) >> 104448 10381312 2 freebsd (5.0G) >>=20 >> =3D> 0 10381312 md1s2 BSD (5.0G) >> 0 10381312 1 freebsd-ufs (5.0G) >>=20 >> =3D> 0 10381312 ufsid/62ed01f3345560d8 BSD (5.0G) >> 0 10381312 1 freebsd-ufs (5.0G) >>=20 >> =3D> 0 10381312 ufs/rootfs BSD (5.0G) >> 0 10381312 1 freebsd-ufs (5.0G) >>=20 >> So: ufs/rootfs apparently identifies the BSD instead of the >> freebsd-ufs . Same for the ufsid/* . This leads to: >>=20 >> # gpart show -p=20 >> . . . >>=20 >> =3D> 63 10485697 md1 MBR (5.0G) >> 63 1985 - free - (993K) >> 2048 102400 md1s1 fat32lba [active] (50M) >> 104448 10381312 md1s2 freebsd (5.0G) >>=20 >> =3D> 0 10381312 md1s2 BSD (5.0G) >> 0 10381312 md1s2a freebsd-ufs (5.0G) >>=20 >> =3D> 0 10381312 ufsid/62ed01f3345560d8 BSD (5.0G) >> 0 10381312 ufsid/62ed01f3345560d8a freebsd-ufs (5.0G) >>=20 >> =3D> 0 10381312 ufs/rootfs BSD (5.0G) >> 0 10381312 ufs/rootfsa freebsd-ufs (5.0G) >>=20 >> freebsd-ufs has the unexpected label: ufs/rootfsa >>=20 >> # ls -Tld /dev/ufs/* >> crw-r----- 1 root operator 0x6c Aug 6 20:19:58 2022 = /dev/ufs/rootfs >> crw-r----- 1 root operator 0x6e Aug 6 20:19:58 2022 = /dev/ufs/rootfsa >>=20 >> Things were actually set up for ufs/rootfs naming as the >> identification of the freebsd-ufs content, per the >> release/tools/arm.subr commands ( from last month's >> main-n256584-5bc926af9fd1 ): >>=20 >> if [ "${PART_SCHEME}" =3D "MBR" ]; then >> chroot ${CHROOTDIR} gpart add -t '!12' -a 512k -s = ${FAT_SIZE} ${mddev} >> chroot ${CHROOTDIR} gpart set -a active -i 1 ${mddev} >> 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} newfs -U -L rootfs /dev/${mddev}s2a >> fi >>=20 >> Note that the newfs command references /dev/${mddev}s2a instead >> of /dev/${mddev}s2 but the rootfs label ends up referencing >> /dev/${mddev}s2 . >>=20 >> Is having "0 10381312" for the md*s2 and for the md*s2a a >> fundamental problem? Does freebsd-ufs ( a.k.a. md*s2a ) need >> to be moved to a different (non-zero) offset inside BSD? >>=20 >> Or is this a different kind of bug? >>=20 >> I'll not repeat the kinds of explorations that I reported last >> week unless someone wants to request something. >>=20 >> =3D=3D=3D >> Mark Millard >> marklmi at yahoo.com >>=20 >=20 >=20