Re: fsck segfaults on rpi3 running 13-stable

On Feb 12, 2023, at 08:53, bob prohaska <[email protected]> wrote:
> 
> 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/

But the debugger inforation/symbols from your system are
needed to get symbolic results from that file. My instance
of main is not going to be a match.

You need to be the one getting the backtrace from your
system.

>> 
>> 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. 

If you already did, it is too late to use the fsck_ffs.core
file unless you can revert and accurately reproduce the
original 14-CURRENT so its symbols/debugger information
can be used.


===
Mark Millard
marklmi at yahoo.com