Re: fsck segfaults on rpi3 running 13-stable (and on 14-CURRENT analyzing the same file system that resulted from the 13-STABLE crash)

On Feb 15, 2023, at 07:44, bob prohaska <fbsd@www.zefox.net> wrote:

> On Tue, Feb 14, 2023 at 03:27:46PM -0800, John-Mark Gurney wrote:
>> 
>> In this case, an inode's mtime is wildly incorrect.  Here is a simple
>> patch that will let it get farther, BUT, it doesn't necessarily mean
>> that the kernel can properly handle the mtime:
>> diff --git a/sbin/fsck_ffs/inode.c b/sbin/fsck_ffs/inode.c
>> index 82338f4f8c08..d0892a822dc5 100644
>> --- a/sbin/fsck_ffs/inode.c
>> +++ b/sbin/fsck_ffs/inode.c
>> @@ -1311,7 +1311,10 @@ prtinode(struct inode *ip)
>>        printf("SIZE=%ju ", (uintmax_t)DIP(dp, di_size));
>>        t = DIP(dp, di_mtime);
>>        p = ctime(&t);
>> -       printf("MTIME=%12.12s %4.4s ", &p[4], &p[20]);
>> +       if (p == NULL)
>> +               printf("MTIME=invalid ");
>> +       else
>> +               printf("MTIME=%12.12s %4.4s ", &p[4], &p[20]);
>> }

(The above probably has more whitespace changes
than what you started with.)

>> void
> 
> I tried to apply the patch with 
> root@www:/usr/src # patch -p1 < fsck.patch
> Hmm...  Looks like a unified diff to me...
> The text leading up to this was:
> --------------------------
> |index 82338f4f8c08..d0892a822dc5 100644
> |--- a/sbin/fsck_ffs/inode.c
> |+++ b/sbin/fsck_ffs/inode.c
> --------------------------
> Patching file sbin/fsck_ffs/inode.c using Plan A...
> Hunk #1 failed at 1311.
> 1 out of 1 hunks failed--saving rejects to sbin/fsck_ffs/inode.c.rej
> Hmm...  Ignoring the trailing garbage.
> done

My guess is the following is the type of issue.

Looking in my /usr/main-src/sbin/fsck_ffs/inode.c
I see that the original file has a leading tab
instead of spaces.

The following mostly ignores the 1st column that
should have a space, -, or + in the diff output for
the file-content lines. It is mostly about the text
after the first column.

So, if you have spaces instead after the first column
for the lines that start with a space, those lines
will not match, leading to a rejection for the
context matching done by patch.

It is common for E-mail based text to end up with
whitespace not preserved, especially leading
whitespace. So patches received that way commonly
need adjustment to get back the original whitespace
structure.

Copying and pasting text from a web browser window
can have its own whitespace-not-preserved issues.

Sometimes it can be easier to hand edit the original
file and then confirm the edit via looking at a git
diff and seeing if it looks like the original patch.
In part, this is because unchanged lines can be left
alone instead of needing whitespace adjustments in
a mangled patch. For the new lines, the "+" lines
can sometimes be copied/pasted and the leading "+"
removed. Especially true if the whitespace details
on those lines do not really matter for a temporary
purpose. (Otherwise: adjust the whitespace
afterwards.)

===
Mark Millard
marklmi at yahoo.com