Re: fsck segfaults on rpi3 running 13-stable (and on 14-CURRENT analyzing the same file system that resulted from the 13-STABLE crash)
- Reply: Mark Millard : "Re: fsck segfaults on rpi3 running 13-stable (and on 14-CURRENT analyzing the same file system that resulted from the 13-STABLE crash)"
- In reply to: John-Mark Gurney : "Re: fsck segfaults on rpi3 running 13-stable (and on 14-CURRENT analyzing the same file system that resulted from the 13-STABLE crash)"
- Go to: [ bottom of page ] [ top of archives ] [ this month ]
Date: Wed, 15 Feb 2023 15:44:24 UTC
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]);
> }
>
> 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
Obviously I'm doing something dumb.....any hints?
Thanks for writing,
bob prohaska