From nobody Wed Feb 15 17:40:51 2023 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 4PH53B4191z3qc6w for ; Wed, 15 Feb 2023 17:41:10 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic308-55.consmr.mail.gq1.yahoo.com (sonic308-55.consmr.mail.gq1.yahoo.com [98.137.68.31]) (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 4PH53B1gdgz40Xj for ; Wed, 15 Feb 2023 17:41:09 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1676482867; bh=VeeYkNV+8y45TGYGDTE8BC1qvFu15obe5jKVWrddiC8=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=UDZUYphyQPTI0h92CciOZxZG/QRUPiINr10lbkWWAtuLWh9unHUNcogk+Rv2zC3KYQrWusnylzMk5jlMU1G8I2n4x7GXAo6M8IRGnI89DO+52/ULXgUUKvbp5qQEE/hY09RdWPcYfaMMxZvjEDdGndn+xzSlBIvEAsryFT1VZVvvWBlu7bGN2SNAOIKvGrtpJMeVUlLDuCvnjIqiHyyDj0TKAaa+CI9isyrKnjAscqxcBtBQzh1lNp3bPGs5BpBxAtGnc6q4z3LwpJPa8syjJq0OxuHG4l2kVxE/F1kjtcY4MnkuWqdWmncNjpAOIk3SHoNxpqVDJyzI6C6k5UfkVA== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1676482867; bh=2xMaSQ/zkLmh/dnNo1H6dP8wLOYj6Hr3KNjks3yZj6w=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=KEf6f0VEwkzrvsGk3Tqcnrubcz6pSdp+TYSr/WR8YcTE3u/ayL+UJn/acxNwM5YJtktopsbEpKBN8Wy26aIO9ToviNPXJYQntw0LB1JlkSoiXueeFn7kL8IbLFH7nducK6tIgaLZ5/QdvQcclQG+AXH22VLJXWzyDpourXB6lZBo7XpwlzCg6VzM+H4ar/3hneI4/Ok3b7pivWPEccbYVnfYVLUH8BzgLbJ40qY+Ny8LKrw2KLm9v/7KFq+UbDVly5pHGZNpahbsUrrzgzqu11dxJegbAbj0Gma9uR2y+m5SoYZU4S4qDFKpUE7SzQUa2YDak6RvjrLX5qP7yxuyoA== X-YMail-OSG: 6uymPpAVM1ky_1D4Yo3BmBh.l3TUHG9Y8LP_2GTOov83VBVFfTZNa3rS.lGKstX .kb3U8MFTBc.1jwrW.mYFOsLEg4DpbVNJWIsgWFS.LNgy7CSC2cOoRRjmY6PosdALbwy9OnfgMnb HNnodj9yVQ3PLXUkc2p_BwgG2K68I2HdOnvOSyeoGcCExyw65ccs9sjA_FUgUBmEUoaNg_AWUUev xonEXsMcGB2HyH5WpxxNAiMaMwab7K8jdIJaTOM9iaJNh47vp3SoCk1GevVhqkZ3ZzyF7lKz8JcB zkzpc1V2y9dt7LKs.y.ZEUyxDlL9EvdwglwOHaSQuupcD8BSlvVvi.PUvhdQ7BjHgtJ6EfeP6PTF O87UX_lhzOXckhCdAPwI.f.QUTGypE8FnbGlc9Ccwj9IfA93AAyu3fBaV2bVf7qN8Qa5D7D7veDK eJjyJNGQlfyZGScKFPUDbnCvXlrMhdHErzJv4DAmyyfXO6UCdxFoB1cuUe_i7Q8K2PaRMiJQfjz7 ElMsQCqtFmYxNqie8nTyk5hsRsFqqyUTORejhw5gPVjiVjjtihFKY4E5tZfBDnQrdSrH503_WmF1 m5u3597QmtfStNt8wg3tuvVB.uy.R0s9LYHxH.sYEUJAzegXoDZtZ82qlz30ZEiPASzRqTBnj1tz h4NM.w26.duXJn18zUnE1FJi8ZB2j8IO94FNPyXvc8tkr9wAYYweHDswyeWxWpQYGVaU9hpmTa5x jn476g9p6L1sZ_iWF6PxLE2nx21mkGCgT07IL3SXA1vuPGGTRbhDywBYOgE.sNGJl3.wpfNH2f2G TAie9pVYhb0jdoBLaBGhFWkqO3JZZY2fSjc4cI_CuO8CFTOAfabB2dRCNMFZtsz0AN_2xx_kDBUF uX0MJS5acCHZXojlVa0LzFBAvPBBdijQumdFzE.LYP0Tc2fzej6Wwq9dftBKsDVW0vrhAvE1Uh7W DUwQYdQ5i30hIz72oro2NnY1Gjg6B1yX7orNjqUdsp682en2c89rMcPa6dm7ESXCS5G8u.qVtB4J HR.azkxxDxY0t.1xdDkwwgXtHP0e74EKWjZazLscCvqz1jyhY7M617OKwy9F8a6c9CnVjynLdMNp jP5_z.o8cRAc.h.A7V_IIEHeG9HphTgA68wFCm0Q.L.wPEeTXBSVhGVfg0DQfhmazbPCMUxfxQZ9 GkqukkDwcbIhBq8TkQwi0uxXMski3QsFD2BpqKhoDDS4Do7FwQrcvj4YPDW17Do1V_AgTwgmudFJ jj08k5QdSCLxpREwU4hbfiFplXJFPtLC0wCBKR6fd0kOUtnrb6Hn0QeA8PHMvJbw9rX5a9UPw5eG 2morTYaCiLv8JOncTwPkQQGK.vcG.xGg7gJ3OuP7NnPK9xN93vXOjeptD4bI1w6kduI6Ar4IbS3i Awhvv3Nbz4rAPNRw1NSRM6BGbBu7GGgc15RmXX6i_qnP7guWWOBfTgew7sXeW0chZCbv8uQMmw3N qS3IhJsQRrmk5C1SmG.s2E7T.pxbCWfypDRGiEjcJT5N9a_yeNYv8f5dyE1TawNdd2LbA5fW3mRt rfsAmp1_KBvufeR2TYI97k3v9K2Q3uJmtvDjt4LRVQ3bui0kGhitMQHZhXaw7RQyZjtL.RoBV43K uruyUMkvypWTEB0atoljbSs5V1zXnsNNxBKHaa4RdBI6VeoN8ELahxp68JvEAYKCtofY5vMGD_b9 9EEh6addPIFFk18yIclAnPIvY25il6hb1C5DrRJfVX4v6UFLy47jHLqhxCiMn0ercCpaO_E7Y58k qoK7wpo5cB53U5U8jZooL0Xf1yiGy7eW_MdGcrj1Adj3gv5wKRqiAZw_GbsM0so0fNzYm6INjHr. 3hviIBQX2JafrlbROIHO50VlciP2m6K2BQ2C.WrIK32hZ7.TKq.Pgr8htUoIG.AGXYUgWCPD2MKT AvTeGZC1pBvfe5949CSWcDIuqBAVASj8g3fxClZYeegXdzZw6gFlC7fyHv_tppxzmQJodKRtz28P m7y4VmsN5vQTL6sqkWxrWDeUllo2MNyMg8X.WA9vaP2jO03h4yYfvN3n_GKtVdwW0jpzD_fM82dZ YUQxyWQj__FCHXfUBAgL0o.xZc2bAK.Su02VTDNhxjTIcOG8lBS1bCrm1vwQJBGN9xpOXckCJnyf 3nRivo7n_iPdu5TNI3Q3tC0GFpusuq2O1RLJRqYWOYmbOsh4F2gjxqvsKjGVb5.o6GvKGeYAcfe6 8Zr8_lD89RgaO1sLlxKXslUD32zcnvfUPYsBXFjWV6.P81YmpVpG.08qohf1w_mHUzzFDd.U4W0U - X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic308.consmr.mail.gq1.yahoo.com with HTTP; Wed, 15 Feb 2023 17:41:07 +0000 Received: by hermes--production-bf1-57c96c66f6-bbrmg (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 94d80fbc7439a567606e34e00156c5e4; Wed, 15 Feb 2023 17:41:04 +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 16.0 \(3731.300.101.1.3\)) Subject: Re: fsck segfaults on rpi3 running 13-stable (and on 14-CURRENT analyzing the same file system that resulted from the 13-STABLE crash) From: Mark Millard In-Reply-To: <20230215154424.GA34278@www.zefox.net> Date: Wed, 15 Feb 2023 09:40:51 -0800 Cc: freebsd-arm@freebsd.org Content-Transfer-Encoding: 7bit Message-Id: References: <20230212191308.GA21535@www.zefox.net> <20230212195324.GB21535@www.zefox.net> <03840D0B-13D4-4F22-BDAF-2887A4D78BED@yahoo.com> <20230213232519.GD95670@funkthat.com> <20230214161415.GA28276@www.zefox.net> <20230214183827.GG95670@funkthat.com> <20230214210601.GA28959@www.zefox.net> <20230214232746.GI95670@funkthat.com> <20230215154424.GA34278@www.zefox.net> To: bob prohaska X-Mailer: Apple Mail (2.3731.300.101.1.3) X-Rspamd-Queue-Id: 4PH53B1gdgz40Xj X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N On Feb 15, 2023, at 07:44, bob prohaska wrote: > On Tue, Feb 14, 2023 at 03:27:46PM -0800, John-Mark Gurney wrote: >> >> In this case, an inode's mtime is wildly incorrect. Here is a simple >> patch that will let it get farther, BUT, it doesn't necessarily mean >> that the kernel can properly handle the mtime: >> diff --git a/sbin/fsck_ffs/inode.c b/sbin/fsck_ffs/inode.c >> index 82338f4f8c08..d0892a822dc5 100644 >> --- a/sbin/fsck_ffs/inode.c >> +++ b/sbin/fsck_ffs/inode.c >> @@ -1311,7 +1311,10 @@ prtinode(struct inode *ip) >> printf("SIZE=%ju ", (uintmax_t)DIP(dp, di_size)); >> t = DIP(dp, di_mtime); >> p = ctime(&t); >> - printf("MTIME=%12.12s %4.4s ", &p[4], &p[20]); >> + if (p == NULL) >> + printf("MTIME=invalid "); >> + else >> + printf("MTIME=%12.12s %4.4s ", &p[4], &p[20]); >> } (The above probably has more whitespace changes than what you started with.) >> void > > I tried to apply the patch with > root@www:/usr/src # patch -p1 < fsck.patch > Hmm... Looks like a unified diff to me... > The text leading up to this was: > -------------------------- > |index 82338f4f8c08..d0892a822dc5 100644 > |--- a/sbin/fsck_ffs/inode.c > |+++ b/sbin/fsck_ffs/inode.c > -------------------------- > Patching file sbin/fsck_ffs/inode.c using Plan A... > Hunk #1 failed at 1311. > 1 out of 1 hunks failed--saving rejects to sbin/fsck_ffs/inode.c.rej > Hmm... Ignoring the trailing garbage. > done My guess is the following is the type of issue. Looking in my /usr/main-src/sbin/fsck_ffs/inode.c I see that the original file has a leading tab instead of spaces. The following mostly ignores the 1st column that should have a space, -, or + in the diff output for the file-content lines. It is mostly about the text after the first column. So, if you have spaces instead after the first column for the lines that start with a space, those lines will not match, leading to a rejection for the context matching done by patch. It is common for E-mail based text to end up with whitespace not preserved, especially leading whitespace. So patches received that way commonly need adjustment to get back the original whitespace structure. Copying and pasting text from a web browser window can have its own whitespace-not-preserved issues. Sometimes it can be easier to hand edit the original file and then confirm the edit via looking at a git diff and seeing if it looks like the original patch. In part, this is because unchanged lines can be left alone instead of needing whitespace adjustments in a mangled patch. For the new lines, the "+" lines can sometimes be copied/pasted and the leading "+" removed. Especially true if the whitespace details on those lines do not really matter for a temporary purpose. (Otherwise: adjust the whitespace afterwards.) === Mark Millard marklmi at yahoo.com