From nobody Sat Jul 30 03:42:44 2022 X-Original-To: dev-commits-src-main@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 4LvqwK6rbKz4X1gY for ; Sat, 30 Jul 2022 03:42:57 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic302-20.consmr.mail.gq1.yahoo.com (sonic302-20.consmr.mail.gq1.yahoo.com [98.137.68.146]) (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 4LvqwJ5y7xz428X for ; Sat, 30 Jul 2022 03:42:56 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1659152574; bh=pn2+NuIluOXck3UaUnvHyEIm2teRlVU1aw4jYW0Wot4=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=CtAz+0c/W1S/cCfVZm3b3mtF8d55uuxHi0Dc3QLqlN76z+tkxi1RdzmEN25iuyPSxCOgyqNoVQK6I2jI7JyCJvHvgamjBBdX8WVCgepAh7F+7yMe8pGTOVK4Ovw2EgSiFeBE8DKBw+xe46/L9/WNMFE/iTBXYta+J6FYIkYee4NhJqDZ/zucvXbHLT5Ig9SZJNjS2+yhNUQf+6XW0PzBkS8VacaPh0DHdCU/oHGcOm/SEHOWE4vAQ1Z6gonPy2bYhUTTWSPljZSNFCM3LsRvkAun+wZNx5wZvQAg7sGpK0j75jORLHrHs8v/05HNKp3kccTrKksmG3ox53ZjcRwYzg== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1659152574; bh=mASN6zA6BcPKDrKlH+pcFl2JZwuJuEHvz6T6NbDQJMx=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=M0c6lPF7Yx/KVKccKBmjmgPMdfwAEcho1BDdcSCaYuxgjJKmLoj3X2ZqTvgT7odNtYUUnXJg24dGSYIsFPfUNp+cFGehjErDIU+cwp1FD1ZM8vZiDnI2vKS6HW0COuzMaWQWbqoM26s65THO+ZUoOBLCsQF2DrfbmK/XoRoMlZO4InjYMOIbTJnr2LRAuXPWYn2o9JvqciFB/tpYOP5fYLfK+Jor2+gAI6f6OvBsJ4b3d4JV7sNuvHMN4ddOxAt0Ncd53AjkSYIGN1ALN9+JzXafxdWhaNhZgu3pjBzmEIlNzagOjcj+KwDnlyydTzL6UWSJsM+psrWTNzuCJs65aQ== X-YMail-OSG: Qi0Dci8VM1k7swTxCBX_DEbTGs5VpTvzhtBVOrDlQczDH.JmnWPuXLpB3cOfDrT A0wveSbA_7b4TvkNmEg31CtYKPcODwdwnomdiE7uiuMXEV3RLa4W2wcGm9OIbxcLLZXhzYFKO2fy WLrFXHcxZhqER9LMJSum0c9rXh3X8azSzyN41jRz6Qmsa1f0P_P063y5CSSuo.bp6qhV.es2ULSl WzARbe5DoHNo064KXlnN8OABxBhHyGHVCAyIH_qDpt3qWCkMwWlO0NPeV86rin_s9p4JBopSVH7o L6G_ojawogWxtxv9O8sFVrxk7y44NnQrHTvINRW8F1uiPN876x4HINDxIOObcg4TDgHKkkKk2bIf Im00cJ8xd5cJv9oMS.l4JpqZEjqS7qtUn6IhZ4zxNkjL0SlR1ZZjKyp7M2JhIXJDJ0c7X_vwsgvS M67HIR9Xk9zdo9T8WxenjHY3XaT3SYNWyf9CHAYoQXwA.kUi7fa7WCi4fldfX8gXzQte_YDas2f5 1rYjMxTrIT.Q5pfjqKTzU7y0NwpexzFkzCvAuSXdC9Fa_GTC68ymE.GXdUTnYTHVbyNNOw5BM30Q l1Gs4ULdGXhvooJG8BTOqYmSWRTOPXelvKaAEdP0CRhCCM6VZjrjDL9i6m0fN7oWd2KuQbUfIZYY 7QEgVLQIu9GKfQk09us.2dp1GQZxgvt0s5bEMJuQvSioDsU_Jqoo35gaSLeCquG5h1dqV311X3GG 7p00Lbmu9hzRlzm0IlFNyUkOfM_FZusi8vDe7sXLdcY6Sr8A2XWp5POgY7sFu1X4_PCatZA6Wzo7 j_bC1FZpkhqjFwk6dE8XUP2zbIhbXPWR2MzrEw9mNUPlygBg8aV.1HDS5rWE_RGaSkpJysJqhhBE .qshHt5poJbFpV7tf4UkIVRNHqe421otS63aStUdvE7JDzhgkR5dDxw0QHAuPTpCqgbZFGofWS5c FZ1zwxTCFBmS69VEYa8MmSwwly_m1PuWPb9oejwko4y13x85O8W15CiZSOEzWrra8zT6zS9Yqy61 _x34RHbd5iGSAUGm.y2rpzPw0hiHq8NkowGxtQwOwXgb654.PR..vpick5qT6UFMD89S74zjy.rs wKBPYjOhZ_yTMNvWvNKjLFjZkTPGZORsO0iEwkz5D9CoRI.rIINtBqn9Tpmkraml3PgRvl1bIUuo 31_4f_yvD_fuiQKzApeaCfflSMsqm2GAWB1wEaI6ilQ03JCp1tMryjDq0_z2C9H12tkSoQnxJy.x xrqyCIz8IVArNjGClC2TLg9Ws2rZmuAQYN6KJrzOhtAtB1pJt7GGtdEyiDBME_sKIGaPP_XYntUV fHqNFAMvJQvS1xutEUn444OaEpeVnvWoROaEWaphO8qmzProeI_7Sf97_LdrpD6xvsCVcadmWUap KLCjjMLg8ZLmTDVa_z6kOQC_taSIRp9zXw2ByeZmEnXy8HPsYp68kAFeYGdwrP7l_wgBb1C7qnmo Jedxcr9g4hS.hVgK.8AuBSI8HzS9mlojv7VtXAuN5aCdsuHtiIfY26nY6iDDlWvdIf0HseuYEwwi EPZOvUbY5u8ogAf7WGosj7YFIl1aGbdqNaYXs0f1vLbj7e7XcTsUYEPeQCMz9UUC5n9uXcIOYbhN PYcaTMmWgy0A7Io0cjadCzSrARCoIFFfU1YLn7QIeUxqZFhGbIz8GkBOShDRBl_eYnWVRB1Z5Yxv ZaSldtgri5nr3QzaQVDZmW.s3opH2mmSgv2YJ_LfZ0sezFsZ4xq6uy8wCkR3oWtfBFsh2yHyPhT4 FiIeItzq2BMyaWOn5vLlUPqqvw3ywNS222AuDSeOYmiN3jj667TuKXgHki1wi9xrSASIh6kBoRwv A7aSCudeXx0Ge2mrEvBMyFNH2nniGErjPU8fSZrOwneuWOp5J4d6D0SQH1NcyIXeRV6bEF2XiNE_ moGkD33xDwsd2Nzi7w1g2bOLO6_gbI64hLYIDmujONuyfC2T.F51.oT5j9oRUucKyXWGCDXDDt3d _8xFWvg885OgXSWtJ4AlTrgUfM_lE0i1T7xa9zwFACuH_oaAYDsLkTPj9q.qwu9c.7C14G6dHMSN xuasEFuU_HEJJfYkHeIVZaHtiLJ.dhu8Jb7S3RDV7iiTJmHxYo_CGWtPJqA.cfX0z6lfavp3m8ZJ ICHd7xQ67VZeclvB.TAY5nPXiwwBUzGSu90a6eAyH7w0s1uiyvPYwLzOCEpohaO_TksgqucPUe.G enxovi4g1V5KsfY6UL6kOCg9uWURf5CvWZIDALHg2EymS0XLJN_2173U5_P4EHrepOfWmu7_tzen BQtXMb.WrsCPmL6cNffwv8CDkqYp_23xD X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic302.consmr.mail.gq1.yahoo.com with HTTP; Sat, 30 Jul 2022 03:42:54 +0000 Received: by hermes--production-bf1-99ddd9c9c-vpswh (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID c8a0e52e3bde3a5ed38abe4ae1bb1b61; Sat, 30 Jul 2022 03:42:48 +0000 (UTC) Content-Type: text/plain; charset=us-ascii List-Id: Commit messages for the main branch of the src repository List-Archive: https://lists.freebsd.org/archives/dev-commits-src-main List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-dev-commits-src-main@freebsd.org X-BeenThere: dev-commits-src-main@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\)) Subject: Re: git: 1dfcff294e44 - main - release: increase IMAGE_SIZE for arm, arm64, riscv [odd alignment for SBC images] From: Mark Millard In-Reply-To: <7E1AE740-FA45-4889-BD70-8EABB0725B39@yahoo.com> Date: Fri, 29 Jul 2022 20:42:44 -0700 Cc: Warner Losh , Ed Maste , "Rodney W. Grimes" , dev-commits-src-main@freebsd.org, "Dr. Rolf Jansen" , freebsd-arm Content-Transfer-Encoding: quoted-printable Message-Id: <3BF6B9DD-26DF-4C82-B2CE-E460D94F6C95@yahoo.com> References: <16906DFD-286B-4D59-9438-CA9CD9026C55@yahoo.com> <202207171708.26HH81bA062303@gndrsh.dnsmgr.net> <20220719204245.GL30607@FreeBSD.org> <20220729204943.GT30607@FreeBSD.org> <7E1AE740-FA45-4889-BD70-8EABB0725B39@yahoo.com> To: Glen Barber X-Mailer: Apple Mail (2.3654.120.0.1.13) X-Rspamd-Queue-Id: 4LvqwJ5y7xz428X X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b="CtAz+0c/"; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.68.146 as permitted sender) smtp.mailfrom=marklmi@yahoo.com X-Spamd-Result: default: False [-3.38 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.99)[-0.990]; NEURAL_HAM_MEDIUM(-0.89)[-0.893]; MV_CASE(0.50)[]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; MIME_GOOD(-0.10)[text/plain]; ARC_NA(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; RCVD_VIA_SMTP_AUTH(0.00)[]; FROM_HAS_DN(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_TLS_LAST(0.00)[]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; RCVD_IN_DNSWL_NONE(0.00)[98.137.68.146:from]; RCVD_COUNT_THREE(0.00)[3]; FREEMAIL_FROM(0.00)[yahoo.com]; TO_DN_SOME(0.00)[]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; DKIM_TRACE(0.00)[yahoo.com:+]; FROM_EQ_ENVFROM(0.00)[]; RCPT_COUNT_SEVEN(0.00)[7]; MIME_TRACE(0.00)[0:+]; MLMMJ_DEST(0.00)[dev-commits-src-main@freebsd.org] X-ThisMailContainsUnwantedMimeParts: N On 2022-Jul-29, at 20:11, Mark Millard wrote: > On 2022-Jul-29, at 19:56, Mark Millard wrote: >=20 >> On 2022-Jul-29, at 13:49, Glen Barber wrote: >>=20 >>> On Wed, Jul 20, 2022 at 10:08:20AM -0700, Mark Millard wrote: >>>> Would it seem appropriate to use a week (this week?) to do all >>>> the snapshot builds with the builders all set to have >>>> kern.geom.part.mbr.enforce_chs=3D0 and see what breaks, if = anything? >>>> (Sort of a snapshot exp run.) >>>>=20 >>>> More than just the SBC images might be involved for >>>> kern.geom.part.mbr.enforce_ch consequences, for all I know. >>>>=20 >>>=20 >>> Hey, Mark. >>>=20 >>> New snapshots for 13 and 14 are up now. Is it possible for you to = check >>> if the issues you had run into are indeed resolved, after setting >>> kern.geom.part.mbr.enforce_chs=3D0 on the builders? >>>=20 >>=20 >> Well, it is a mix, I think (unsure). >>=20 >> I started with: >>=20 >> # dd = if=3DFreeBSD-13.1-STABLE-arm64-aarch64-RPI-20220729-db2eff1cff8-251976.img= of=3D/dev/da0 conv=3Dsync,fsync bs=3D1m status=3Dprogress >> 5222957056 bytes (5223 MB, 4981 MiB) transferred 21.027s, 248 MB/s >> 5120+0 records in >> 5120+0 records out >> 5368709120 bytes transferred in 21.816899 secs (246080301 bytes/sec) >>=20 >> I plugged the USB3 SSD into an old 8 GiByte RPi4B and it booted. >>=20 >> . . . >> Starting file system checks: >> /dev/ufs/rootfs: FILE SYSTEM CLEAN; SKIPPING CHECKS >> /dev/ufs/rootfs: clean, 499417 free (1153 frags, 62283 blocks, 0.1% = fragmentation) >> Growing root partition to fill device >> random: randomdev_wait_until_seeded unblock wait >> random: randomdev_wait_until_seeded unblock wait >> random: unblocking device. >> GEOM_PART: ufs/rootfs was automatically resized. >> Use `gpart commit ufs/rootfs` to save changes or `gpart undo = ufs/rootfs` to revert them. >> da0s2 resized >> super-block backups (for fsck_ffs -b #) at: >> 11524224, 12804672, 14085120, 15365568, 16646016, 17926464, 19206912, >> . . . >>=20 >> But, after logging in: >>=20 >> root@generic:~ # gpart show >> =3D> 63 468862065 da0 MBR (224G) >> 63 1985 - free - (993K) >> 2048 102400 1 fat32lba [active] (50M) >> 104448 468757680 2 freebsd (224G) >>=20 >> root@generic:~ # gpart show -p >> =3D> 63 468862065 da0 MBR (224G) >> 63 1985 - free - (993K) >> 2048 102400 da0s1 fat32lba [active] (50M) >> 104448 468757680 da0s2 freebsd (224G) >>=20 >> So 1985 and 2048 are there, as intended. >>=20 >> But no explicit da0s2 BSD or da0s2a freebsd-ufs shows up >> in gpart show's output. >>=20 >> I wonder if this is because of a lack of a distinct >> starting offset vs. the BSD. For example, the old 2016 >> and 2079 alignment had showed: >>=20 >> =3D> 0 468757737 da0s2 BSD (224G) >> 0 57 - free - (29K) >> 57 468757680 da0s2a freebsd-ufs (224G) >>=20 >> where the 57 was, appearently, for alignment. May be now >> the distance from the da0s2 to da0s2a is zero and so >> BSD and its contained da0s2a is not now shown? >>=20 >> I've yet to try the 14-CURRENT. >>=20 >=20 > It did not survive a simple reboot test: >=20 > . . . > FreeBSD/arm64 EFI loader, Revision 1.1 >=20 > Command line arguments: loader.efi > Image base: 0x39b08000 > EFI version: 2.90 > EFI Firmware: Das U-Boot (rev 8226.1024) > Console: efi (0x1000) > Load Path: /efi\boot\bootaa64.efi > Load Device: = /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/UsbClass(0x0,0x0,0x9,0x0,0x3)= /UsbClass(0x1e91,0xa2a5,0x0,0x0,0x0)/HD(1,0x01,0,0x800,0x19000) > Trying ESP: = /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/UsbClass(0x0,0x0,0x9,0x0,0x3)= /UsbClass(0x1e91,0xa2a5,0x0,0x0,0x0)/HD(1,0x01,0,0x800,0x19000) > Setting currdev to disk1p1: > Trying: = /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/UsbClass(0x0,0x0,0x9,0x0,0x3)= /UsbClass(0x1e91,0xa2a5,0x0,0x0,0x0)/HD(2,0x01,0,0x19800,0x1bf0acb0) > Setting currdev to disk1p2: > ERROR: cannot open /boot/lua/loader.lua: no such file or directory. >=20 >=20 > Type '?' for a list of commands, 'help' for more detailed help. > OK lsdev > disk devices: > disk0: 60258304 X 512 blocks (removable) > disk1: 468862128 X 512 blocks > disk1s1: DOS/Windows > disk1s2: FreeBSD > disk1s2a: FreeBSD UFS > http: (unknown) > net devices: > net0: > OK ls =20 > / > d EFI > d dtb > README > u-boot.bin > armstub8.bin > armstub8-gic.bin > bootcode.bin > fixup_cd.dat > fixup_db.dat > fixup_x.dat > fixup.dat > LICENCE.broadcom > start_cd.elf > start_db.elf > start_x.elf > start.elf > fixup4.dat > fixup4cd.dat > fixup4db.dat > fixup4x.dat > start4.elf > start4cd.elf > start4db.elf > start4x.elf > bcm2710-rpi-2-b.dtb > bcm2710-rpi-3-b.dtb > bcm2710-rpi-3-b-plus.dtb > bcm2711-rpi-4-b.dtb > config.txt > d overlays > OK show > COLUMNS=3D200 > LINES=3D60 > autoboot_delay=3DNO > boot_serial=3DYES > console=3Defi > currdev=3Ddisk1s1: > efi-version=3D2.90 > efi_com_port=3D0 > efi_com_speed=3D9600 > hint.smbios.0.mem=3D0x39c2e000 > interpret=3DOK > loaddev=3Ddisk1s1: > prompt=3D${interpret} > script.lang=3Dlua > smbios.bios.reldate=3D04/01/2022 > smbios.bios.vendor=3DU-Boot > smbios.bios.version=3D2022.04 > smbios.chassis.maker=3DUnknown > smbios.chassis.type=3DDesktop > smbios.planar.maker=3DUnknown > smbios.planar.product=3DUnknown Product > smbios.socket.enabled=3D1 > smbios.system.maker=3DUnknown > smbios.system.product=3DUnknown Product > smbios.system.serial=3D100000007151395e > smbios.system.uuid=3D30303031-3030-3030-3731-353133393565 > smbios.version=3D3.0 > twiddle_divisor=3D16 >=20 > So definitely not working for a 2nd boot. >=20 14-CURRENT got a different result: a pair of . . . "/dev/ufs/rootfs: Operation not permitted" Setting hostuuid: 30303031-3030-3030-3731-353133393565. Setting hostid: 0xd2468d7e. Starting file system checks: /dev/ufs/rootfs: FILE SYSTEM CLEAN; SKIPPING CHECKS /dev/ufs/rootfs: clean, 601308 free (436 frags, 75109 blocks, 0.0% = fragmentation) Growing root partition to fill device random: randomdev_wait_until_seeded unblock wait random: randomdev_wait_until_seeded unblock wait random: unblocking device. GEOM_PART: ufs/rootfs was automatically resized. Use `gpart commit ufs/rootfs` to save changes or `gpart undo = ufs/rootfs` to revert them. da0s2 resized growfs: /dev/ufs/rootfs: Operation not permitted mount: /dev/ufs/rootfs: Operation not permitted Mounting root filesystem rw failed, startup aborted ERROR: ABORTING BOOT (sending SIGTERM to parent)! 2022-07-29T11:17:56.567464+00:00 - init 1 - - /bin/sh on /etc/rc = terminated abnormally, going to single user mode Enter full pathname of shell or RETURN for /bin/sh:=20 The boot media was set up via: # dd = if=3DFreeBSD-14.0-CURRENT-arm64-aarch64-RPI-20220729-467d3e2e8aa-257025.im= g of=3D/dev/da0 conv=3Dsync,fsync bs=3D1m status=3Dprogress 5187305472 bytes (5187 MB, 4947 MiB) transferred 21.025s, 247 MB/s 5120+0 records in 5120+0 records out 5368709120 bytes transferred in 21.884283 secs (245322600 bytes/sec) The same 8 GiByte RPI4B was used. root@:/ # gpart show =3D> 63 468862065 da0 MBR (224G) 63 1985 - free - (993K) 2048 102400 1 fat32lba [active] (50M) 104448 468757680 2 freebsd (224G) =3D> 0 468757680 ufs/rootfs BSD (224G) 0 10381312 1 freebsd-ufs (5.0G) 10381312 458376368 - free - (219G) root@:/ # gpart show -p =3D> 63 468862065 da0 MBR (224G) 63 1985 - free - (993K) 2048 102400 da0s1 fat32lba [active] (50M) 104448 468757680 da0s2 freebsd (224G) =3D> 0 468757680 ufs/rootfs BSD (224G) 0 10381312 ufs/rootfsa freebsd-ufs (5.0G) 10381312 458376368 - free - (219G) However, in this context: root@:/ # gpart commit ufs/rootfs root@:/ # gpart show =3D> 63 468862065 da0 MBR (224G) 63 1985 - free - (993K) 2048 102400 1 fat32lba [active] (50M) 104448 468757680 2 freebsd (224G) =3D> 0 468757680 ufs/rootfs BSD (224G) 0 10381312 1 freebsd-ufs (5.0G) 10381312 458376368 - free - (219G) =3D> 0 468757680 da0s2 BSD (224G) 0 10381312 1 freebsd-ufs (5.0G) 10381312 458376368 - free - (219G) =3D> 63 468862065 diskid/DISK-00000000000A MBR (224G) 63 1985 - free - (993K) 2048 102400 1 fat32lba [active] = (50M) 104448 468757680 2 freebsd (224G) =3D> 0 468757680 diskid/DISK-00000000000As2 BSD (224G) 0 10381312 1 freebsd-ufs (5.0G) 10381312 458376368 - free - (219G) root@:/ # gpart show -p =3D> 63 468862065 da0 MBR (224G) 63 1985 - free - (993K) 2048 102400 da0s1 fat32lba [active] (50M) 104448 468757680 da0s2 freebsd (224G) =3D> 0 468757680 ufs/rootfs BSD (224G) 0 10381312 ufs/rootfsa freebsd-ufs (5.0G) 10381312 458376368 - free - (219G) =3D> 0 468757680 da0s2 BSD (224G) 0 10381312 da0s2a freebsd-ufs (5.0G) 10381312 458376368 - free - (219G) =3D> 63 468862065 diskid/DISK-00000000000A MBR (224G) 63 1985 - free - (993K) 2048 102400 diskid/DISK-00000000000As1 fat32lba [active] = (50M) 104448 468757680 diskid/DISK-00000000000As2 freebsd (224G) =3D> 0 468757680 diskid/DISK-00000000000As2 BSD (224G) 0 10381312 diskid/DISK-00000000000As2a freebsd-ufs (5.0G) 10381312 458376368 - free - (219G) So it looks like the growfs did not actually happen. The following seems to have gotten me to about the same type of context I got to for 13-STABLE: root@:/ # mount -u / root@:/ # gpart show=20 =3D> 63 468862065 da0 MBR (224G) 63 1985 - free - (993K) 2048 102400 1 fat32lba [active] (50M) 104448 468757680 2 freebsd (224G) root@:/ # exit No suitable dump device was found. Setting hostuuid: 30303031-3030-3030-3731-353133393565. Setting hostid: 0xd2468d7e. Fast boot: skipping disk checks. Growing root partition to fill device da0s2 resized super-block backups (for fsck_ffs -b #) at: 11524224, 12804672, 14085120, 15365568, 16646016, 17926464, 19206912, = 20487360, 21767808, 23048256, 24328704, 25609152, 26889600, 28170048, = 29450496, 30730944, 32011392, 33291840, 34572288, . . . Do a shutdown -r now form of reboot from this context also got: . . . FreeBSD/arm64 EFI loader, Revision 1.1 (Fri Jul 29 09:39:44 UTC 2022 root@releng1.nyi.freebsd.org) Command line arguments: loader.efi Image base: 0x39b02000 EFI version: 2.90 EFI Firmware: Das U-Boot (rev 8226.1024) Console: efi (0x1000) Load Path: /efi\boot\bootaa64.efi Load Device: = /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/UsbClass(0x0,0x0,0x9,0x0,0x3)= /UsbClass(0x1e91,0xa2a5,0x0,0x0,0x0)/HD(1,0x01,0,0x800,0x19000) Trying ESP: = /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/UsbClass(0x0,0x0,0x9,0x0,0x3)= /UsbClass(0x1e91,0xa2a5,0x0,0x0,0x0)/HD(1,0x01,0,0x800,0x19000) Setting currdev to disk1p1: Trying: = /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/UsbClass(0x0,0x0,0x9,0x0,0x3)= /UsbClass(0x1e91,0xa2a5,0x0,0x0,0x0)/HD(2,0x01,0,0x19800,0x1bf0acb0) Setting currdev to disk1p2: ERROR: cannot open /boot/lua/loader.lua: no such file or directory. Type '?' for a list of commands, 'help' for more detailed help. OK lsdev disk devices: disk0: 60258304 X 512 blocks (removable) disk1: 468862128 X 512 blocks disk1s1: DOS/Windows disk1s2: FreeBSD disk1s2a: FreeBSD UFS http: (unknown) net devices: net0: OK ls / d EFI d dtb README u-boot.bin armstub8.bin armstub8-gic.bin bootcode.bin fixup_cd.dat fixup_db.dat fixup_x.dat fixup.dat LICENCE.broadcom start_cd.elf start_db.elf start_x.elf start.elf fixup4.dat fixup4cd.dat fixup4db.dat fixup4x.dat start4.elf start4cd.elf start4db.elf start4x.elf bcm2710-rpi-2-b.dtb bcm2710-rpi-3-b.dtb bcm2710-rpi-3-b-plus.dtb bcm2710-rpi-cm3.dtb bcm2711-rpi-4-b.dtb config.txt d overlays OK show COLUMNS=3D200 LINES=3D60 autoboot_delay=3DNO boot_serial=3DYES console=3Defi currdev=3Ddisk1s1: efi-version=3D2.90 efi_com_port=3D0 efi_com_speed=3D9600 hint.smbios.0.mem=3D0x39c2e000 interpret=3DOK loaddev=3Ddisk1s1: module_verbose=3D2 prompt=3D${interpret} script.lang=3Dlua smbios.bios.reldate=3D04/01/2022 smbios.bios.vendor=3DU-Boot smbios.bios.version=3D2022.04 smbios.chassis.maker=3DUnknown smbios.chassis.type=3DDesktop smbios.planar.maker=3DUnknown smbios.planar.product=3DUnknown Product smbios.socket.enabled=3D1 smbios.system.maker=3DUnknown smbios.system.product=3DUnknown Product smbios.system.serial=3D100000007151395e smbios.system.uuid=3D30303031-3030-3030-3731-353133393565 smbios.version=3D3.0 twiddle_divisor=3D16 So the primary difference seems to be getting the 2 "/dev/ufs/rootfs: Operation not permitted" notices and so getting the: Mounting root filesystem rw failed, startup aborted and such. After the "mount -u /" and exit, things seem similar again. =3D=3D=3D Mark Millard marklmi at yahoo.com