Re: fsck segfaults on rpi3 running 13-stable

On Sat, Feb 11, 2023 at 09:21:29PM -0800, Mark Millard wrote:
> On Feb 11, 2023, at 20:35, bob prohaska <[email protected]> wrote:
> 
> > On Sat, Feb 11, 2023 at 06:57:41PM -0800, Mark Millard wrote:
> >> On Feb 11, 2023, at 14:40, bob prohaska <[email protected]> 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