From nobody Sun Jun 26 02:43:58 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 B33BE86178C for ; Sun, 26 Jun 2022 02:44:14 +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 4LVwDF2gkJz3NZT for ; Sun, 26 Jun 2022 02:44:13 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1656211445; bh=TpJ17wmNizI7N6AGSfiCfj89EQgxk8Ph7AQA0veYqn0=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=OFVLgpYzOgEKHNHd33O7Yz7HtZ7SZitrXxT3kBM18ezz4xrFfOniwAnP+iS4qzRUv78CZKSF/kBk5ghqXxNHxlDtR0/0YxsSmX/805ALW6710GNOOzN1LJa4KanKyIovp8tbQvW4H/749Q+QyzlWN7JbRTK29wmzTc1Q7tF4V1ysQFGK9YB35QLAYG3mKXPv22JMmYlFFQtwwqszzobYGjWqVd/w0d4+9Z8CTZKnnElhvuDy1Pwq7Tgqw+5zu4Y2ZCBVWX3Ix5aYRhDXwPErvU9K1coFjCu3r7NeWRTDw+2TkbGKZtr5AvNau0yPJ3m52cd+B8lGVNqiNPecYjW7fw== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1656211445; bh=Ti8So17vmG7Eghi+dAzAE+u+ac9t5i5SC4YOJE8PP1n=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=knTdIp5sNCscdsH8YdbXc8/vRpOKzzACAgLCAazTt1Bkjc9ReTjwNKvYLZiCYnXoF8ZMeZZSyst+ojUxOCtsNk0bEEIej9iMCgHaB2dGTbKd6jeOc7gTAd1ZTy6KnolcFbW+lcVd6LSXdh3NahmPZguwy/WlLPw70vMTCEEPxiv98Jel8w49lVRGSevMu2CZmD1iSTBm2rG9a1MMuhl7JUVmsytxEXAjR2GeIJgrS013Gwp1hiFAThOtKAKz3GlpBKvgIy1RNhZmauJP2m+ykGCT8caR102yLm7a5P0XYFw/70bspmScGaCiJpn0W6fD4AyYPqua6NubPVCg+7ZJng== X-YMail-OSG: j0OqX6AVM1nSENbny4tetr18yHUbib8iGaDUJsnhfmmeoVd2015FZg_Hp3Kl7FE navrkfP5bnk0XfREGCdWR2bBz_5fs4YOw46BXWr25pD8bf1EiO.XKjx6VqwLiodiwpqSiG6H_am9 v96LS7RopEY.8YTmvkx4nwomIC3wPNlirKBBv8HsadqwsA8NY.AeQsVxaxJplrX2askdeej0taTX IrpWx2rWclK1Rc_AZHCHPx5lBBLZh.QqXD6a_6QcdzlGhdi9Ce08muokCnNJ0XhFoz40syF5C0v9 UPrm3aCEaQwBMAPz7Blc2TQawRgPyXfgczju.p._CzzEv5n_PRB43jBUE6Tamj8BFA4l.tzSKBcR tSaI.Ch2UiVzm.m6TVQXpCVED7IBpZcor6cQQhvB17fnBWm4EGS3qwY6Az._K_hre4jsnr2cgDT1 QoOsFf0a6XPRbAg5mAp20r23rgjGRWuqm8a1HbR2yRx3JeSr6rCbm2nlDZNQoV0rAb785yNVqi6H 66D9JBGO0o8bUqGuPuafNUbaYlh1aXxt5WiowCrGkzp6rqiafwucRlMGLeGwWVWs8yCgwccaWdSW 1zWd6kgAPy3O3DFiGfYjmxV6VDOXCz1ZXr.OSEnBXgAgmfDIgoKp9607oXwNUhcFb2JjrpXN_kzj L3CreSoGsX9ER1khpUW8lb1X85ga.4DC6zBGMqeyRBiNNqq3cPalIWS.iv8nK1SMtChXQVY6sqfg _6uQckZd7m0_KBkWQgp5kqVd7SH284qbMAqk4dLqPcoW.AC6qZzdkBlr65q.GmWzJI8RIVnVJxFn .dkqpkA2Vfr8xMnnrAvcuyX1Q4tkwq3748wHnHqfP3DzUm6xg4WigWyesJAlz_adkiDHlL17nWZ. hx83Vxtc_O8qr5cxB3JJXlFIxfymnMMNSQeydqNrOQDQB5JYG6mbn9fA.NY.Y.ycpsLiX_7J0Cym capVZ12pksnQg0pAGpIeK4udMVAmB07w17J957QJl32OkyJ64H5UDlRfCF1_77Wos8nUUVrifFHV HS4OBoF9HXE85hB187S4yfIMLOP7bvXzcUrqVq70OsPu_osczNE5JJrzV5G8Czt14zhCjFpuMfFu U.RmHuMm1nVsZUkf84upYYIxqzaJl52QX8yCO6ykkvHXLqcoIQZGvUhgQqYizMFb0izf2GQBAwfC FzixmRMxPG2VwTUM0_xwAUlBPDHFWHo7vjtorap7zb_ybhlZ7qhgMv17GOiymHgH3TTtTJhzYqK4 d_h8QxQL1OX.JAEKJaf_f93RjIGEnopqUL1eftD9nqRJe2hjinFTqjq74H.VTHQHYRVnFirbiz3. YMI1Gyb8VHh_aihu_D5DEKz.V0AHTqYhJyL3PIqv40nlNAr87gM7piqgmIPKccSkBN9ChGGccAHq wjuYXECTRFLJgendKI7F67ZXDzzTUrHjH2hWGoxWw962SDqN2vRPqRm1.5fNuGbIzbviPGZJLP2u Amfs_iDFeHpWgVeOLyUVnYIw4aLUpYfDOUcHtIsglxkM3D0E3agpVLWAew8Zg2eG8j_KRgKDdLol krgse9JetLnjr5MEzpCHHCBsCwiy1lTNRtYwQsA_KE9_F8poTOWKBuASi0rQzZY.Au6AYSZahCOS hZaOVFjNbtq46BYuoNJ7ylGnZd1HjxaUMMzHvF8sZ_zNYydk_k030ONcGEgoR2L2k19CNzSZ1x57 DSwJLMM7umeslfyvKwW9QGgON.5KSlHcBGK4xYVSHDuUMRyAQPys_XdrnrDMoeu63q_0g.d7iaRo BQiCx9S2u3RO9Y7WD00zvpaiZQFmUQSu8Cd_5mnZ5thjESdG4Gdu9KF9pKxtBvqGsJNg1je_12MP 7xxbtl6NDKsN_3hJdIvf9MeSq1Yf_xbYgIvw3B2sg7ETIcOmYkbxfzx7iInM0TJXFcwb9Ife0pmc 60w73T2PAhKODDyrLriDUgaRwh9Wvd4sHfivSw2_flm8l2VE9NU8.6zzbfJUUTYi8HmkLbD72AiS h6687fOzfAX.Fwt_1WcISLkm_FOAuqv_hxDBShPDUvAfpwPP646CajHJa5UbmdbzIyqoEaLovEaK IUHoza.uxVVWmrTsQFvxvenfMy13XHqu6Y_kAkQa3H2BgLE5ReRiggyLiYRxqHn3A8rS3pzZBGZ7 3DJxaAkMxNXQhUFWYHkU.uzcwd6F_CVcBVsxJaYtfemNTbACbx_.y6XunbMBTHxtdlz.YQjM8RMT iBqG3aYO3tV3nObCGm5t8W23wvn11WC5S3Anu_j7UJYdRvAMZvxy7VjVV7qd2dh04yEmAm0U0V4V lsxN5Vze_WQyIq1k2Tigz9gNMicOfoL3ErMQbduOlBT_VL75m0yh2tjH685bZDAjILD12AMzJkIT HiNv2RN9BpFk- X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic302.consmr.mail.gq1.yahoo.com with HTTP; Sun, 26 Jun 2022 02:44:05 +0000 Received: by hermes--production-bf1-7f5f59bd5b-l2zks (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID fd5683d4a2ec2a47caa246cd8c30d3ca; Sun, 26 Jun 2022 02:44:00 +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: Date: Sat, 25 Jun 2022 19:43:58 -0700 Cc: Free BSD , "mckusick@freebsd.org" Content-Transfer-Encoding: quoted-printable Message-Id: <962A2166-BEB2-443A-A01D-1617F7D8AF49@yahoo.com> 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: 4LVwDF2gkJz3NZT X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=OFVLgpYz; 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.50 / 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]; NEURAL_HAM_SHORT(-1.00)[-1.000]; 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_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.68.146:from]; MLMMJ_DEST(0.00)[freebsd-arm]; RCVD_COUNT_TWO(0.00)[2] X-ThisMailContainsUnwantedMimeParts: N On 2022-Jun-25, at 19:22, Mark Millard wrote: > On 2022-Jun-25, at 14:51, bob prohaska wrote: >=20 >> 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) >=20 > 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: >=20 > /* > * 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)))) >=20 > =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: >=20 > (fs)->fs_old_cgoffset * ((c) & ~((fs)->fs_old_cgmask)) >=20 > is in use and ends up being 5056. This was wrong: (fs)->fs_dblkno provided the 5056. See later below after the "JUNK" text block. JUNK FROM MISTAKE: > =46rom that I see that: >=20 > (fs)->fs_magic =3D=3D FS_UFS2_MAGIC >=20 > is false. >=20 > But the messages produced via: >=20 > CHK(fs->fs_csaddr, !=3D, cgdmin(fs, 0), %jd); >=20 > implies that the code did validate the (fs)->fs_magic > value and it passed. For reference: >=20 > # 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) : = \ >=20 > =46rom the code structure and messaging I infer that: >=20 > (fs)->fs_magic =3D=3D FS_UFS1_MAGIC >=20 > or the code would have done: >=20 > } else { > /* Bad magic number, so assume not a superblock */ > return (ENOENT); > } >=20 > without producing the messaging. >=20 > Why it would be a UFS1 file system that was created originally, > I do not know. END JUNK FROM MISTAKE. When I looked at the messaging code for CHK to see why it reported UFS2 I see: printf("UFS%d superblock failed: %s (" #fmt ") %s %s (" = \ #fmt ")\n", fs->fs_magic =3D=3D FS_UFS1_MAGIC ? 1 : = 2, \ #lhs, (intmax_t)lhs, #op, #rhs, (intmax_t)rhs); = \ but that implies that fs->fs_magic did not hold the value FS_UFS1_MAGIC . Looking back I see that I incorrectly attributed the: (fs)->fs_dblkno value to: (fs)->fs_old_cgoffset * ((c) & ~((fs)->fs_old_cgmask)) End result: The file system is UFS2 with (fs)->fs_magic =3D=3D = FS_UFS2_MAGIC . Ultimately: fs->fs_csaddr !=3D (fs)->fs_dblkno seems to be the failure condition for this UFS2 context [given the 0 in cgdmin(fs, 0)]. I've no clue about the implications. >> 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? >=20 > June 4 is after: >=20 > 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. >=20 > but before: >=20 > 2022-06-11: Bug fix to UFS/FFS superblock integrity checks when = reading a superblock. >=20 > (and before the later additions of messages about superblock failure = details). >=20 > 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. >=20 > None of these messages suggest code changes to creating UFS file > systems, just to validation. >=20 > I will note that the 2022-05-27 check-in does report: >=20 > 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 >=20 > 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. >=20 >=20 > Of course, none of these notes provide any solutions, just > background information. >=20 =3D=3D=3D Mark Millard marklmi at yahoo.com