From nobody Sun Jun 26 02:22:26 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 82A1C8A6523 for ; Sun, 26 Jun 2022 02:22:44 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic303-23.consmr.mail.gq1.yahoo.com (sonic303-23.consmr.mail.gq1.yahoo.com [98.137.64.204]) (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 4LVvlQ6BlCz3LTl for ; Sun, 26 Jun 2022 02:22:42 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1656210154; bh=cW5Zjl5sGtwkL5NVhoX9bnhPD7BzgC0Kae4ndRn1p5I=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=Xu477silS8ti2s3cpyedH+ijnuIJfJa5Y5wuYX5csMFzSU91LVLwv6pCtRXDxJYALp7f0Idd20FEzAyRw8hHEjrtJRfuUTbxkzAlL1SLwEt7Sr0Mh2bIXewc9MF1FCkCk0bGvQjTgG3wpYQ1IkWjV45tmYj91jAWp4CFe1X6w9OrNknSUbmz07baKS0v3hteGjRXNUhLf4yySrOylrRwU/8iRjTJvAhgh2irZM/1fCEiMZE0QKbxquApHDkoAcGZqNJS9+O6MAXJ1OQkhtmJcXU9OP+NXpWqnFFJt8n8xK5IJYNEu3UCkiUjE0B+ShB7Xxbd/saNp4FqqFZd3MpSeg== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1656210154; bh=Nl/7e8fHal2E/smr2cD4JXZduhnaCIakNrG5hqcD4zN=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=ms3uXTGidYlHIlPO30eT1kyZ8rN0DkHMf6VXlODn+mIQWq5rGSsQE7ijtH6QYNTlJSaN/W2v1LtH7T76V0T+9/OSr/YD4HT2pHg/0Es5mg/sXkqmBhsO6djKR7VKp9CC1joLh1M7mlWvJ2spOEojiAU+EOc7r+CH49cl3g7OvChqT46sYMSAbKxRBbWgpCQd2DIy5McoDtpVHYPVMInWM4rVHlGt7Y1dFWlJU+zZWqFP6HFIKipL52Nj2I2Iou8S65egwjtgFrS5pgzGMRrnLYonpnWUcGlPMkUkndAoKyCg0SUJehO/Tu9yGfLCUEK9+/18RZWc+mhKwOWLJFz/3Q== X-YMail-OSG: eP5IkIEVM1k84BsBoOA3Q_t13Pt2dnZcPJQX7iIsQdasMS9lftZ5klnAuCvPLCq xdPcE.lKiNWOJi1RSUi0AJ6IfbXBX1gU5ZiMRppkefG6gZ0R9FrIQRE5vToLFIq1AjtFlSad.32P D19TwdH0oa5krK12MFKcwBbVha4qr2wJlkcefQXVybBSW1VOngcsn12jr5FIDWCH25IbUrd.Zi57 YDPiefjRJxUh4C6IeC.ixCEexq3MRIq2f5JuQbDS5S5HhT4XFYklk2dE4MV68mHLDC4qSm9snBF8 dO.2FUYYCyE8d8M0Xf_lfLmL6WwpfmZu5Sz7kYc.Bm_OkbCPYdcdYc5zOW.nibxp52ZExTqyJils 7cC_0JCw4tftYSH28E00s3MyceyhINGas2PMmdw2P6jGEideL2kdISnPDzBQv6KCtEi7Ja_klgW3 clAT6Jk.udDAUdd8Suw5XE1MbMJ45vrqvC86Gre4ZpWBoIucZecdafeRMxx6cJqdsTDmkBokXTCn uXbWohCJfZKnt6QrLgH.bVAUENH42zx.UIL2z_WzS4ujzyJbD2rYm5cu9SQ2HzMO6ykBfLlkyIeb gJpNcSuJQt0RBvgFmYHsgbOaB9rjDkOTCzGoVdQXj4e9XMry7aR3JR0aZgFJNXte2QFgnMKHcBcg YRD5vf_yBgyipnOVI.HI7eBHWcL8f9yrpSv8vQIqEK17bL1NiRcsTDH5S2hzTuO_WFWrRiuON06h xQCsibZ8EsUgiuQrXZdI.L6cywOZZBYbA16d9MPo1KnVLP_Lmp3K0RAjQmpm_VLfaYNKjLTc9Fdu hby1ZEoU.yb5bsb6XdvXdrvS_TqfoRsGi1LkoAGQgU5c51pnuPCI5Wpc2PsMNOwa0uHp8aJcUyiU Y4wYcs4KMjqs_fsKiEaeZva7lSEcTo1_d7ZXYw3NHxHhMmc_Q.jfW_VDaUaYOfTnaHmYEbjRKcFR JLSq0tNwfKBqkZ1IIo88_2y6I8ApQi.FhdBzy2bqGklGrHiOK742cjIV4EXb049Aq9ROF_iFRYoF 6ewN2jtOGLLylCZ.cMjVJKwhmLP2auIzphScENLhRx6A8bHLlRzN37uBm_Wss8SCS7OS8aaA..0E LA9uBIgUN1Beef.w.HLyC2eR10rEiqLDJhGUpwerSA1toh0kln3hOb4qxmPZo4wNSc8UxXSMgUcA DVyaeBQV2KOGcH1F9vdUYRyg03SPMsSZj5vAeD1w_1hU51EjVtJmjhJ8QGmkXQwxYgN604xR1pIA cwUdROE2fHRGF2mun6X_MkLoNbOSUiiZieNd92uPOtuWivc7KBnv0.mTUxJz34bmskxp.FRh2YCs EOFp3B_W7c1zqjrY1AizFDO39Y_pjyaJatLS7T4bao4ebJjSIgyrCs23MT7F0RSSmM8_t7VeU2m4 VqnaNhV7OsvTSkIyXVK2dOxrjAidILwLdekigfXDM8yi9HVbOc6Lx_SJSC4yK8FamHLMtuVA8uB7 0lqJKrQ.sFGLpXkv5xmz86TnGwKkgG5jd_GQexaGnB_XFmnQaLpJ08m2CfJHZUZtpuxVpV5Y4eeS BLZ8dHl49rz1ebrxlw.M5fr9sCyv1Ra3x40Ne4c0fthchIRFYlq964vxePJLV9iVSvReA1mE0c4v bULgNmZMhVKRAtzHfTNHn5XVbwpdv.gRcp9EGYbjyvW5O2XKe8g64Og3DR8IriKrS7od50DQfkCu eIV0znuWJvQWZ9j6A5NW7BO2ZC2GGBJ97EBxXMZDjDomvltgQC9OvTQYESQs4Yz3NNpeyduOdZ0_ XyrR_mSNYk9DwW1WZt6nLb1.Fg.jfVo8GUcABtVo7JSj_tU4s1JEhSfoWm_G5mLMpEhaGz4FTsoW fVhyVuuzXsryJUpiLG_ehCUR3jR03yWyyP.slML4lkA3sJUMBZSPQu.svU7I2GAKjh05ageX50ai U6BVvjWp3ERl9rFLFs20tqQNjDw0XIll3XK9l6_J9PAsZWj.33Yx4Y3WWlfm7LaKHF0NS7EL.2t. V7wrCJTfhbsaj.Ub01sy89Zwk4mtLuUUJQLCNDuzKGe615M519RU3_gJsNR9iCIxr1q9Ign.U9AB fcAPGJHRZ7nyhzeDOZE48M77a9qakH2D7sBJxt6ytUXHBalCsNSIGU.PQ.XWHkNOywBf2E52fYUK lWJIzozzwWBNLMZdWC9AKn9KygZnDEkjNkyzLAG9geJs29eu6mkxledNYn2_nCrfz5k53HPy2xcd Y8STvhYgUAmxrY6NmpoE7RhdInQNu2JyqYgFinKQZwqidNPqq7ftaPUn.A1QxbjjyuB.Zwsba2_. mD6WoD.rouyhdxb5Hsz97YI021UWF8fUc3Qrdye0PHGIw3rwgjTAr2203T0HTot0m9P7kE_kvW0W WrTREADQTXQ-- X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic303.consmr.mail.gq1.yahoo.com with HTTP; Sun, 26 Jun 2022 02:22:34 +0000 Received: by hermes--production-bf1-7f5f59bd5b-wjb4g (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID de57950bcf6ef793c7bf20e773ed1593; Sun, 26 Jun 2022 02:22:29 +0000 (UTC) Content-Type: text/plain; charset=us-ascii 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: Mountroot problems on RPi3/aarch64 From: Mark Millard In-Reply-To: <20220625215119.GA17770@www.zefox.net> Date: Sat, 25 Jun 2022 19:22:26 -0700 Cc: Free BSD , "mckusick@freebsd.org" Content-Transfer-Encoding: quoted-printable Message-Id: References: <20220602045202.GA44686@www.zefox.net> <1B845A0C-EDDC-407C-96A8-AAF4E92C2A4D@yahoo.com> <20220613153325.GA12588@www.zefox.net> <50CE21C4-CBE5-4ECB-A27E-42B7AAF71822@yahoo.com> <20220619042225.GA2267@www.zefox.net> <3458F90E-CFC9-4B91-8C4A-DD5788239172@yahoo.com> <20220621192448.GA1874@www.zefox.net> <54365257-9DA2-4058-9354-B5D76E7AAC70@yahoo.com> <47AFE262-8425-4A4D-A425-41CF39AA381E@yahoo.com> <20220625215119.GA17770@www.zefox.net> To: bob prohaska X-Mailer: Apple Mail (2.3654.120.0.1.13) X-Rspamd-Queue-Id: 4LVvlQ6BlCz3LTl X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=Xu477sil; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.64.204 as permitted sender) smtp.mailfrom=marklmi@yahoo.com X-Spamd-Result: default: False [-1.78 / 15.00]; TO_DN_EQ_ADDR_SOME(0.00)[]; TO_DN_SOME(0.00)[]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; DKIM_TRACE(0.00)[yahoo.com:+]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-0.998]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; NEURAL_SPAM_SHORT(0.72)[0.715]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.64.204:from]; MLMMJ_DEST(0.00)[freebsd-arm]; RCVD_COUNT_TWO(0.00)[2] X-ThisMailContainsUnwantedMimeParts: N On 2022-Jun-25, at 14:51, bob prohaska wrote: > On Thu, Jun 23, 2022 at 06:43:24PM -0700, Mark Millard wrote: >> There is another checkin to main for superblock handling: >>=20 >> QUOTE >> The branch main has been updated by mckusick: >>=20 >> URL: = https://cgit.FreeBSD.org/src/commit/?id=3D50dc4c7df4156863148e6a9609c03e85= 2e2aeb35 >>=20 >=20 > Here's the tail of the boot transcript: >=20 > Root mount waiting for: CAM > da0 at umass-sim0 bus 0 scbus0 target 0 lun 0 > da0: Fixed Direct Access SPC-4 SCSI device > da0: Serial Number 12345678D558 > da0: 40.000MB/s transfers > da0: 953869MB (1953525168 512 byte sectors) > da0: quirks=3D0x2 > UFS2 superblock failed: fs->fs_csaddr (806456) !=3D cgdmin(fs, 0) = (5056) I'm not UFS/FFS implementation literate but I can show what I see when I look up some of the related source code. Looking up cgdmin leads to sys/ufs/ffs/fs.h material: /* * Cylinder group macros to locate things in cylinder groups. * They calc filesystem addresses of cylinder group data structures. */ #define cgbase(fs, c) (((ufs2_daddr_t)(fs)->fs_fpg) * (c)) . . . #define cgdmin(fs, c) (cgstart(fs, c) + (fs)->fs_dblkno) /* 1st = data */ . . . #define cgstart(fs, c) = \ ((fs)->fs_magic =3D=3D FS_UFS2_MAGIC ? cgbase(fs, c) : = \ (cgbase(fs, c) + (fs)->fs_old_cgoffset * ((c) & = ~((fs)->fs_old_cgmask)))) =46rom the cgdmin(fs, 0) I learn that the cgbase(fs, 0) involved is 0 (i.e., zero). =46rom that, looking at what cgstart(fs, 0) would be leads to concluding that: (fs)->fs_old_cgoffset * ((c) & ~((fs)->fs_old_cgmask)) is in use and ends up being 5056. =46rom that I see that: (fs)->fs_magic =3D=3D FS_UFS2_MAGIC is false. But the messages produced via: CHK(fs->fs_csaddr, !=3D, cgdmin(fs, 0), %jd); implies that the code did validate the (fs)->fs_magic value and it passed. For reference: # grep MAGIC /usr/main-src/sys/ufs/ffs/fs.h #define FS_UFS1_MAGIC 0x011954 /* UFS1 fast filesystem magic = number */ #define FS_UFS2_MAGIC 0x19540119 /* UFS2 fast filesystem magic = number */ #define FS_BAD_MAGIC 0x19960408 /* UFS incomplete newfs magic = number */ #define CG_MAGIC 0x090255 #define cg_chkmagic(cgp) ((cgp)->cg_magic =3D=3D CG_MAGIC) ((fs)->fs_magic =3D=3D FS_UFS2_MAGIC ? cgbase(fs, c) : = \ =46rom the code structure and messaging I infer that: (fs)->fs_magic =3D=3D FS_UFS1_MAGIC or the code would have done: } else { /* Bad magic number, so assume not a superblock */ return (ENOENT); } without producing the messaging. Why it would be a UFS1 file system that was created originally, I do not know. > UFS2 superblock failed: fs->fs_csaddr (806456) !=3D cgdmin(fs, 0) = (5056) > UFS2 superblock failed: fs->fs_csaddr (806456) !=3D cgdmin(fs, 0) = (5056) > UFS2 superblock failed: fs->fs_csaddr (806456) !=3D cgdmin(fs, 0) = (5056) > UFS2 superblock failed: fs->fs_csaddr (806456) !=3D cgdmin(fs, 0) = (5056) > Mounting from ufs:/dev/da0s2a failed with error 22; retrying for 3 = more seconds > UFS2 superblock failed: fs->fs_csaddr (806456) !=3D cgdmin(fs, 0) = (5056) > UFS2 superblock failed: fs->fs_csaddr (806456) !=3D cgdmin(fs, 0) = (5056) > UFS2 superblock failed: fs->fs_csaddr (806456) !=3D cgdmin(fs, 0) = (5056) > UFS2 superblock failed: fs->fs_csaddr (806456) !=3D cgdmin(fs, 0) = (5056) > UFS2 superblock failed: fs->fs_csaddr (806456) !=3D cgdmin(fs, 0) = (5056) > UFS2 superblock failed: fs->fs_csaddr (806456) !=3D cgdmin(fs, 0) = (5056) > UFS2 superblock failed: fs->fs_csaddr (806456) !=3D cgdmin(fs, 0) = (5056) > UFS2 superblock failed: fs->fs_csaddr (806456) !=3D cgdmin(fs, 0) = (5056) > UFS2 superblock failed: fs->fs_csaddr (806456) !=3D cgdmin(fs, 0) = (5056) > UFS2 superblock failed: fs->fs_csaddr (806456) !=3D cgdmin(fs, 0) = (5056) > UFS2 superblock failed: fs->fs_csaddr (806456) !=3D cgdmin(fs, 0) = (5056) > UFS2 superblock failed: fs->fs_csaddr (806456) !=3D cgdmin(fs, 0) = (5056) > UFS2 superblock failed: fs->fs_csaddr (806456) !=3D cgdmin(fs, 0) = (5056) > UFS2 superblock failed: fs->fs_csaddr (806456) !=3D cgdmin(fs, 0) = (5056) > UFS2 superblock failed: fs->fs_csaddr (806456) !=3D cgdmin(fs, 0) = (5056) > UFS2 superblock failed: fs->fs_csaddr (806456) !=3D cgdmin(fs, 0) = (5056) > UFS2 superblock failed: fs->fs_csaddr (806456) !=3D cgdmin(fs, 0) = (5056) > UFS2 superblock failed: fs->fs_csaddr (806456) !=3D cgdmin(fs, 0) = (5056) > UFS2 superblock failed: fs->fs_csaddr (806456) !=3D cgdmin(fs, 0) = (5056) > UFS2 superblock failed: fs->fs_csaddr (806456) !=3D cgdmin(fs, 0) = (5056) > UFS2 superblock failed: fs->fs_csaddr (806456) !=3D cgdmin(fs, 0) = (5056) > UFS2 superblock failed: fs->fs_csaddr (806456) !=3D cgdmin(fs, 0) = (5056) > UFS2 superblock failed: fs->fs_csaddr (806456) !=3D cgdmin(fs, 0) = (5056) > UFS2 superblock failed: fs->fs_csaddr (806456) !=3D cgdmin(fs, 0) = (5056) > UFS2 superblock failed: fs->fs_csaddr (806456) !=3D cgdmin(fs, 0) = (5056) > UFS2 superblock failed: fs->fs_csaddr (806456) !=3D cgdmin(fs, 0) = (5056) > UFS2 superblock failed: fs->fs_csaddr (806456) !=3D cgdmin(fs, 0) = (5056) > UFS2 superblock failed: fs->fs_csaddr (806456) !=3D cgdmin(fs, 0) = (5056) > UFS2 superblock failed: fs->fs_csaddr (806456) !=3D cgdmin(fs, 0) = (5056) > UFS2 superblock failed: fs->fs_csaddr (806456) !=3D cgdmin(fs, 0) = (5056) > Mounting from ufs:/dev/da0s2a failed with error 22: Invalid fstype. >=20 > Loader variables: > vfs.root.mountfrom=3Dufs:/dev/da0s2a > vfs.root.mountfrom.options=3Drw >=20 > Manual root filesystem specification: > : [options] > Mount using filesystem > and with the specified (optional) option list. >=20 > eg. ufs:/dev/da0s1a > zfs:zroot/ROOT/default > cd9660:/dev/cd0 ro > (which is equivalent to: mount -t cd9660 -o ro /dev/cd0 /) >=20 > ? List valid disk boot devices > . Yield 1 second (for background tasks) > Abort manual input >=20 > mountroot>=20 >=20 > Rebooting using a kernel of: >=20 > FreeBSD 14.0-CURRENT #74 main-n255816-e26ef41f799: Wed May 25 15:05:14 = PDT 2022 > bob@www.zefox.org:/usr/obj/usr/src/arm64.aarch64/sys/GENERIC arm64 >=20 > stops in single user with: > Root mount waiting for: CAM > da0 at umass-sim0 bus 0 scbus0 target 0 lun 0 > da0: Fixed Direct Access SPC-4 SCSI device > da0: Serial Number 12345678D558 > da0: 40.000MB/s transfers > da0: 953869MB (1953525168 512 byte sectors) > da0: quirks=3D0x2 > Warning: no time-of-day clock registered, system time will not be set = accurately > Dual Console: Serial Primary, Video Secondary > Setting hostuuid: 30303030-3030-3030-3064-626136386435. > Setting hostid: 0x5cd40a6a. > Starting file system checks: > UFS2 superblock failed: fs->fs_csaddr (806456) !=3D cgdmin(fs, 0) = (5056) > Cannot find file system superblock > UFS2 superblock failed: fs->fs_csaddr (806456) !=3D cgdmin(fs, 0) = (5056) > Cannot find file system superblock > Warning! Some of the devices might not be available; retrying > Restarting file system checks: > UFS2 superblock failed: fs->fs_csaddr (806456) !=3D cgdmin(fs, 0) = (5056) > Cannot find file system superblock > UFS2 superblock failed: fs->fs_csaddr (806456) !=3D cgdmin(fs, 0) = (5056) > Cannot find file system superblock > Unknown error 3; help! > ERROR: ABORTING BOOT (sending SIGTERM to parent)! > 2022-06-25T14:23:46.792050-07: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 > root@:/ #=20 >=20 > However, simply exiting the single-user shell seems to bring up > normal multi-user operation.=20 >=20 > Network connectivity remains sporadic, but is much helped by an = outgoing > ping process.=20 >=20 > Could it be significant that this filesystem was created on June 4, = 2020? June 4 is after: 2022-05-27: Do comprehensive UFS/FFS superblock integrity checks when = reading a superblock. 2022-06-01: Two bug fixes to UFS/FFS superblock integrity checks when = reading a superblock. but before: 2022-06-11: Bug fix to UFS/FFS superblock integrity checks when reading = a superblock. (and before the later additions of messages about superblock failure = details). But I can not tell what the status of the system was that created the apparently problematical file system. It could be much older for all I know. None of these messages suggest code changes to creating UFS file systems, just to validation. I will note that the 2022-05-27 check-in does report: QUOTE . . . Although it appears in only one place, the new code will apply to the kernel modules and (through libufs) user applications that read in superblocks. END QUOTE This gets into why the older kernel behaves differently when used with the newer world and why there are messages from the newer world code even with the older kernel. Of course, none of these notes provide any solutions, just background information. =3D=3D=3D Mark Millard marklmi at yahoo.com