From nobody Fri Feb 17 23:25:37 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 4PJSbL6bp6z3rwPB for ; Fri, 17 Feb 2023 23:25:18 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (www.zefox.net [50.1.20.27]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "www.zefox.com", Issuer "www.zefox.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4PJSbK5tDrz3Dr2 for ; Fri, 17 Feb 2023 23:25:17 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Authentication-Results: mx1.freebsd.org; dkim=none; spf=none (mx1.freebsd.org: domain of fbsd@www.zefox.net has no SPF policy when checking 50.1.20.27) smtp.mailfrom=fbsd@www.zefox.net; dmarc=none Received: from www.zefox.net (localhost [127.0.0.1]) by www.zefox.net (8.16.1/8.15.2) with ESMTPS id 31HNPbZ5046237 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Fri, 17 Feb 2023 15:25:38 -0800 (PST) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.16.1/8.15.2/Submit) id 31HNPb7U046236; Fri, 17 Feb 2023 15:25:37 -0800 (PST) (envelope-from fbsd) Date: Fri, 17 Feb 2023 15:25:37 -0800 From: bob prohaska To: Mark Millard Cc: freebsd-arm@freebsd.org 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) Message-ID: <20230217232537.GA46176@www.zefox.net> References: <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> <20230215190856.GA34665@www.zefox.net> 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 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Spamd-Result: default: False [-1.10 / 15.00]; AUTH_NA(1.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-0.998]; MID_RHS_WWW(0.50)[]; WWW_DOT_DOMAIN(0.50)[]; MIME_GOOD(-0.10)[text/plain]; FREEMAIL_TO(0.00)[yahoo.com]; MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org]; ASN(0.00)[asn:7065, ipnet:50.1.16.0/20, country:US]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; MIME_TRACE(0.00)[0:+]; RCVD_COUNT_THREE(0.00)[3]; RCVD_TLS_LAST(0.00)[]; FROM_HAS_DN(0.00)[]; ARC_NA(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_NA(0.00)[no SPF record]; DMARC_NA(0.00)[zefox.net]; MID_RHS_MATCH_FROM(0.00)[] X-Rspamd-Queue-Id: 4PJSbK5tDrz3Dr2 X-Spamd-Bar: - X-ThisMailContainsUnwantedMimeParts: N On Wed, Feb 15, 2023 at 11:39:13AM -0800, Mark Millard wrote: > On Feb 15, 2023, at 11:08, bob prohaska wrote: > > > On Wed, Feb 15, 2023 at 09:40:51AM -0800, Mark Millard wrote: > >> > >> 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. > > > > Replacing spaces with tabs allowed patch to find the > > location, but it still fails with > > patch: **** malformed patch at line 5: printf("SIZE=%ju ", (uintmax_t)DIP(dp, di_size)); > > My guess is that when you made the adjustment to have > the tabs, the leading space was also removed on this > line. The first column is not part of the original > text but is instead a directive to the tool. The > missing space would be that directive and it needs to > be there. So: > > printf("SIZE=%ju ", (uintmax_t)DIP(dp, di_size)); > > The space indicates to use the reset of the line just > for context identification. > > Of course, since I've no access the file to check my > hypothesis, it is just a guess. > > > Editing by hand looks like a good way to drive myself crazy 8-) Turns out to be true, but not in the manner expected. Editing in the changes by hand seems to have worked, in that fsck_ffs recompiled and no longer segfaults when examining the -stable filesystem. However, repeated runs of fsck continue to emit errors starting with root@www:/usr/src # fsck -y /dev/da1s2d ** /dev/da1s2d ** Last Mounted on /usr ** Phase 1 - Check Blocks and Sizes 7912408300994173476 BAD I=69393345 4313599915630302063 BAD I=69393345 -4473632163892877928 BAD I=69393345 8068741989830080453 BAD I=69393345 .... This continues through a succession of I values, ending with ..... 3857159125896022134 BAD I=74682090 -4354179704011695453 BAD I=74682090 7611175298055105740 BAD I=74682090 3985638883347136889 BAD I=74682090 -2495754894521232470 BAD I=74682090 7739654885841380823 BAD I=74682090 ** Phase 2 - Check Pathnames ** Phase 3 - Check Connectivity ** Phase 4 - Check Reference Counts LINK COUNT FILE I=69316035 OWNER=root MODE=100644 SIZE=36680 MTIME=Feb 11 12:06 2023 COUNT 2 SHOULD BE 1 ADJUST? yes BAD/DUP FILE I=69393345 OWNER=root MODE=100644 SIZE=720896 MTIME=Jul 22 23:00 2022 CLEAR? yes fsck_ffs: cglookup: out of range cylinder group 175966913 root@www:/usr/src It's unclear whether the patch is preventing fsck from repairing the filesystem, or the problems are inherently beyond fixing. Repeated fsck runs seem to just reproduce the same output. There's no prompt to re-run fsck. Thanks to both Marks for the patch and essential help it making it stick. If anything else is worth trying I'm game, there's little to lose. bob prohaska