Re: fsck segfaults on rpi3 running 13-stable
Date: Sun, 12 Feb 2023 17:21:20 UTC
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. === Mark Millard marklmi at yahoo.com