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