From nobody Sun Feb 12 16:53:33 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 4PFD794qlWz3q52Q for ; Sun, 12 Feb 2023 16:53:09 +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 4PFD791Kgkz3N5N for ; Sun, 12 Feb 2023 16:53:08 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Authentication-Results: mx1.freebsd.org; none Received: from www.zefox.net (localhost [127.0.0.1]) by www.zefox.net (8.16.1/8.15.2) with ESMTPS id 31CGrXw0021359 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Sun, 12 Feb 2023 08:53:33 -0800 (PST) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.16.1/8.15.2/Submit) id 31CGrXk1021358; Sun, 12 Feb 2023 08:53:33 -0800 (PST) (envelope-from fbsd) Date: Sun, 12 Feb 2023 08:53:33 -0800 From: bob prohaska To: Mark Millard Cc: freebsd-arm@freebsd.org Subject: Re: fsck segfaults on rpi3 running 13-stable Message-ID: <20230212165333.GB19401@www.zefox.net> References: <20230211224057.GA17805@www.zefox.net> <9DC74DD9-9AA1-4822-B425-217AAC7DB3F5@yahoo.com> <20230212043524.GA19401@www.zefox.net> <984314A1-FF42-4F92-A212-6BC0D85CB630@yahoo.com> 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: <984314A1-FF42-4F92-A212-6BC0D85CB630@yahoo.com> X-Rspamd-Queue-Id: 4PFD791Kgkz3N5N X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:7065, ipnet:50.1.16.0/20, country:US] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N On Sat, Feb 11, 2023 at 09:21:29PM -0800, Mark Millard wrote: > On Feb 11, 2023, at 20:35, bob prohaska wrote: > > > On Sat, Feb 11, 2023 at 06:57:41PM -0800, Mark Millard wrote: > >> On Feb 11, 2023, at 14:40, bob prohaska wrote: > >> > >>> While running buildworld on a Pi3 running 13-stable the machine > >>> panic'd. On restart using the previous kernel fsck failed with a > >>> segfault, which repeated when the disk was moved to a -current Pi3. > >>> > >> > >> Did it produce a *.core file? > >> > > > > The 13-current host, looking at the 13-stable disk, reports > > root@www:~ # savecore -C -v /dev/da1s2b > > checking for kernel dump on device /dev/da1s2b > > mediasize = 2147483648 bytes > > sectorsize = 512 bytes > > magic mismatch on last dump header on /dev/da1s2b > > 14-CURRENT? > Yes. > For system crash dumps, they may need to be handled by the same > type of system that produced them. (Thus the "magic mismatch"?) > > However, I was not actually after that in my question. I > was after fsck crash file(s), not system crash information. > (Also useful, just for different purposes.) > > > I was not after the original system crash information > in my question. I was after what might have been recorded > when fsck was run and failed. > > So, since you ran a fsck under 14(?)-CURRENT, the file > system for 14(?)-CURRENT might have a *.core file from > the fsck run. (Unsure for fsck.core vs. fsck_ffs.core > as the file name.) This is on a non-corrupted file > system. I was avoiding trying to look at files from > a corrupted file system. > Ahh! found it. -rw------- 1 root wheel 119074816 Feb 11 20:02 fsck_ffs.core It's been placed in http://www.zefox.net/~fbsd/rpi3/ > > This presumes that you have the time to wait vs. having > to quickly just start over after quickly taking a > riskier route if it fails. Time isn't an issue at all, in fact the system is expendable. Mostly I brought the problem up out of surprise that what looked like a routine panic on 13-stable could result in seemingly un-fixable file system damage. In the meantime I'll try updating the 14-current system to see if that makes a difference. Thanks for your help! bob prohaska