From nobody Thu Aug 11 03:22:43 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 4M3BvX3xqsz4Y7LP for ; Thu, 11 Aug 2022 03:22:48 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic306-21.consmr.mail.gq1.yahoo.com (sonic306-21.consmr.mail.gq1.yahoo.com [98.137.68.84]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4M3BvX281Tz3v4R for ; Thu, 11 Aug 2022 03:22:48 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1660188165; bh=fxmdVH7koVaHYWWA6ERWNM0IfgnKS44T7eTTx6nUC1g=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=OFazpqKFIdUuamO6yR3bTP3ZTaeecvlUimZcw6fffoBVn7FDMdhX8oa4/QCk1upFJ9KdUNAlpKeRUNdxzOoARdWrYdXWA4K7mPDurKcZ1S0gMT399B9+8wDywEppdJvOTlIElBirPC0IZUH+VjZzHkgAhc4tX4vM4CUe0MLwsRvc4uglkb8xWprJ0O5342hz37kXqzNJgl85R1i2uXiwaFlcvJK3Scf72ecsv438/hzcWkCscCCm0u83q5yGu70tRIwMVG93KKdSIX0THNP4nFzY/wdQ0Z/pifCjwGgc/gzpQtUWjI4IcG+WCD/3RnptYwDwd9xsMdmkmEsJv2w3dw== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1660188165; bh=px+gA3WqItrNcHn0mM3c6aNEHXbdWpdwOwsKFOl13QM=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=ElNbQzhGyX9Wjmvg4M6jD57fWdMsr8KTckMAxfsyPs2D3wUiucACHulv7Cb0CY+yvRD2sfTRJJzMlFUR/CmixPM7yrLlwW08OlU97TlDdudRJeRyX+ADSQw1yspUyo4duU4dfBrjgHRbjW8CEEGquhwzNfCARTdPg43JO6K78I5pa9WgTTpU0w4vAR8gFwnAUaGmmJLs+VcQDh2XeRxEh9CYN2pPoy+xBc3T7e7E9QsvDWmjf9ACXGpN3KW2LH7gOHszBwjzR6x14pB7zWg309rWCkffKuK9bQZMvF2xqhzT58007dJd0cBk4Hb66E4kSyq13dYlfvrsXJvbKXXXeQ== X-YMail-OSG: ahp0iX4VM1kpbNWtIP15TKBCZ8Y7nFrVdH7pzWNQrYIhBZOhLrrWpSEg2JYv10i HLTwgBBcwp2o8A7TCGyIefado73aej5jLy6z6TJNNrX2cI2ZpcnZVX8hWqwZU3w9h0RC9Q9ftynr dm8NOZhKgYYN.8a.FDvVOIO28jJg2Xj9z3iTIbSue3_v3.aEy9xsDgXWrbA5fxRiEew5OX5yeJjK trgWm6Q4NKLzvHA4dNf1nOuzmNi2nTdosJNwOz6qcCCwXmMwNEPPq.jNltoKpwzrkzEmu_Uob2k9 ygCM7SWYOhQ6a8xPWMLyCHhJW2wQdHdlmj.hfG08mYotQPgSVg1UAI4kVuUPI8pP8cHWk1ytRpfG Db9cAc..KmH4EENwRb6CMoo.cUk5wbhPDD6jKkJTrKtLHWD3V5Y3Yqju1HAkjcx.XIZ0LipAAxv9 adlbL29mbLOZOYTli.Gfa6SotUH3XVCmsznvHdTIminaMaZTS6CEVJ3vO8N3q42alWDeZQCerO7b lBoMYjLS0V86.tiUob5dsqBVHik_zDXrJwziIh4IyXK8uO3gHNaK3NL1jF.YRrkiHLcMtwaFrOPn 1IKrAhWPWa48jfj9uJfKPnScslVD.KTB_ZT64etZfR3EYavGuiYs2wuFdGInoAV7VD0tLMUvXV0v mrQYXlEV0X2S7Y8aONQHIKIQ361LWjwPWHrC4Qr9PGsWj54g6zFX2WibzAxjG7PEFABhHKI6MbPH RtS.2XXeWmhQtocDBqM9zzj53sz8iZVN9ojt9OpU8y6BjpTwg3d6F1YEJb_AAom4X_PFGlkkfo6y Fet7jU9pdzNMGyxhbdP1PpzUKBPM_5zl.SVA_Wpu1imhC2iGQCwCmnsutKLwu2gvsUuFBFr6U_vy ibmEJE5Qy0YPEIS_D_PKG8yp6VBWFbzvzY7bbqa18ahckKKRDjOOaukjZ_vO9ScmiaFG0DFc4IP5 EUzY.eS7yIMKTiTCSJxZSAU5QBRKFSZ72euUyLYeNcfJulUb750QaiCjxPnu7JLil6bVopHXLSDO g54BrvAkzZRhTJxirHmQhqf8rrBCSQnFIfkKiFNJ6tq8cXmfhvmjb7kPYoHLUwt8KeVmGKOpTDeO K54m7osycWSZCepOBBL4H7uo1TVRMmWIklxe9GKvBg6UnFfof3OsmTUSiZf5oZ1rUCEgDOqQA2.3 gUealIeAIaNVe0XkV76LFYo4RQmntWKxE35rZxJ_6RR2x8TNuavArXoEUEBbsqOXSO75Qm.BCKGr JMRQYa2ljeHsDkX5hjLxGPWoy945EwIPmIa8f2jjt92Bz84Ny0t99g_3ykj9fAjH_oGd1EAHgET_ rjt4lztdVp1DULaE94kU9Vjv5dElMYwojqBAyp5gDIyhv3KUl.JV4Xa1KE4s5wWsXnhTaE.09RKc Thsi7wOKxGm5Blj_Jfr.7w2ujVzodYfmqWt4bj793BoI4spAn1zcwb4scDS9c78clUBeUspkw7fq FQfaFMVY46NviIkO8fXP6a7orEBIrVy7cyz.3IizcvdNHKx.BsyhaYwthENaG9GT3BAqAQ18pZlE bcQ95DWVTYHCkn6ZypwwEaDCLnkTxXehnpfplHIS5BOxqopSbfwSbTURf_NzdG1At6XfAXz0AyOS qzUg9FC5oGH.5CE7p3hlsSVxRBimu8fRUn90TVsRlBxMXErk.aZQsTDJ.xbowdMemwBuEzTd_iBu tl_ppEqMrQOi.DkG4ABxZHza2.Gau6mcSePYwig9J1nwTjhu0hqOV0UMnpVa0D.Fo0T32EpkDG6F lu3tyQH1JMYrmp4ItIRpXNaEhSHiUGbfr5ZkndzjndZpHoXPA00JNuDisyRkES2UqWM8mFDSTIF0 lo_j5oHIz7NagnAU1tbO61EsDPE6l1g2o95Ct0Qk61Ociu9ZC0bp32w7xsGFRT9u5vTedVAPsMGI DUg5_RSIVLGnlRGJ8bLYP5t_g8HWIG3CyYS6dtmpMtdns9F1xmYsXpP7ySEr.1cDfiZWGbZvIC3V kP.VXY.jTEQyED8N4TR1Rw2MboXTwykAiyl1WGCSWT5rbrd_eNXc2FwGRfCwlJ7k2eV__9PoBlSd lgP1uU24hy.TwdB_uxqNsgqJXhU5v.w15uLpOYUVvOY.h26oWNjPMpX8rlo3A1J1yrDYR.RFasKq IyXU8omLWy59mvIv0AwemNBZy0lYUw3pzEajBBCprcbR9UtHeT7tVR2hJtt5IgYdX2JeBEaY.XGT AH3eo_W9UpVXqbEe81FzuPzil_Q1mbDkW67FUVVDS93EcyAAco94uwyioff_4NixS5xv3E.Io5gR 6IkWo X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic306.consmr.mail.gq1.yahoo.com with HTTP; Thu, 11 Aug 2022 03:22:45 +0000 Received: by hermes--production-gq1-686964ccb6-kqxvm (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 6e5cb75874fd46ce280505b819ebcdce; Thu, 11 Aug 2022 03:22:43 +0000 (UTC) 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 14.0 \(3654.120.0.1.13\)) 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: Mark Millard In-Reply-To: <619709DF-C1B6-4B86-A6A3-A8F66090F92A@cyclaero.com> Date: Wed, 10 Aug 2022 20:22:43 -0700 Cc: freebsd-arm , Warner Losh , "Rodney W. Grimes" , Ed Maste , Glen Barber Content-Transfer-Encoding: quoted-printable Message-Id: <82C4CD12-A9F2-4DEB-86BB-1D12FF21DEE3@yahoo.com> References: <619709DF-C1B6-4B86-A6A3-A8F66090F92A@cyclaero.com> To: "Dr. Rolf Jansen" X-Mailer: Apple Mail (2.3654.120.0.1.13) X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Rspamd-Queue-Id: 4M3BvX281Tz3v4R 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 On 2022-Aug-10, at 16:01, Dr. Rolf Jansen 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