Re: fsck segfaults on rpi3 running 13-stable

On Feb 12, 2023, at 09:21, Mark Millard <marklmi@yahoo.com> wrote:

> On Feb 12, 2023, at 08:53, bob prohaska <fbsd@www.zefox.net> wrote:
>> 
>> On Sat, Feb 11, 2023 at 09:21:29PM -0800, Mark Millard wrote:
>>> On Feb 11, 2023, at 20:35, bob prohaska <fbsd@www.zefox.net> wrote:
>>> 
>>>> On Sat, Feb 11, 2023 at 06:57:41PM -0800, Mark Millard wrote:
>>>>> On Feb 11, 2023, at 14:40, bob prohaska <fbsd@www.zefox.net> 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.
> 

I was too focused on the specific, already existing
fsck_ffs.core file.

If you update 14-CURRENT and it produces a new fsck_ffs.core
file, you can just use that new one under the new 14-CURRENT
to try to get a backtrace.

No need to revert in that case. Sorry for the earlier noise.


===
Mark Millard
marklmi at yahoo.com