fsck this shit

[jdelisle]

Nothing like making a good first-impression, right?

On Wed, Jun 3, 2020 at 3:22 PM Jan Bramkamp <crest at rlwinm.de> wrote:

>
> On 03.06.20 22:18, Thomas Mueller wrote:
> > from goatshit54108 at national.shitposting.agency:
> >
> >> Once upon a time, the power ran out, and then...
> >> ** SU+J Recovering /dev/<...>
> >> ** Reading 33554432 byte journal from inode 4.
> >> ** Building recovery table.
> >> ** Resolving unreferenced inode list.
> >> ** Processing journal entries.
> >> fsck: /dev/<...>: Segmentation fault
> > GAAAY.
> >
> >> OK, let's check the core dump... oh, wait... tough luck. Fortunately,
> subsequent runs of fsck ended up likewise, so I was able to get a core dump
> by re-executing fsck while being inside a TMPFS-backed directory. (On the
> other hand, unfortunately, fsck was never able to replay the journal.)
> Furthermore, I saved the .sujournal file, but saving the contents of the
> whole filesystem was beyond my resources. (It would have been adequate to
> use a tool that collected (only) the blocks that fsck read before
> segfaulting (thus constructing a small test case), but no such tool was at
> hand.)
> >> Before running "fsck -y" (because I had no other options) I looked at
> "fsck -n" to see whether a particular, large file would get idiotically
> removed as part of "fixing" the filesystem. This routine is prompted by (1)
> personal experiences of files getting lost or truncated to 0 length, and
> (2) past reports of disasterous behaviors involving soft updates, such as
> untouched (read-only) files getting lost; "lost" means not even relinked to
> /lost+found or anything. And wouldn't ya know it, fsck did ask whether to
> remove something that had an unambiguously large size (to be exact, IIRC:
> "DUP ... REMOVE?", whatever that means). That's it, either (a) remove the
> file, or (b) stay dirty; take it or leave it. It's not like there was some
> 3rd option to relink the file to /lost+found. After "fsck -y", the file
> disappeared without a trace. GAAAAAAAAAY.
> >
> >> The fsck_ffs (or fsck_ufs) file was the one distributed with the
> 12.1-RELEASE, the one with the SHA3-256 checksum of
> 447592ae05dc7829823901700bb90940968cae006719964d39b1212bb312d164. Let's see
> the backtrace:
> >> * thread #1, name = 'fsck_ufs', stop reason = signal SIGSEGV
> >>     * frame #0: 0x0000000000219d93 fsck_ffs`blk_free(bno=10692928,
> mask=0, frags=134643471) at suj.c:653:34
> >>       frame #1: 0x000000000021a481 fsck_ffs`ino_trunc(ino=5296913,
> size=134610944) at suj.c:1547:3
> >>       frame #2: 0x0000000000216fee fsck_ffs`suj_check [inlined]
> cg_adj_blk(sc=0x0000000801574540) at suj.c:1788:5
> >>       frame #3: 0x0000000000216fc3 fsck_ffs`suj_check [inlined]
> cg_apply at suj.c:1900
> >>       frame #4: 0x0000000000216fa5
> fsck_ffs`suj_check(filesys="/dev/<...>") at suj.c:2737
> >>       frame #5: 0x000000000020ef54 fsck_ffs`main [inlined]
> checkfilesys(filesys="/dev/<...>") at main.c:427:9
> >>       frame #6: 0x000000000020ef07 fsck_ffs`main(argc=1,
> argv=0x00007fffffffec48) at main.c:205
> >>       frame #7: 0x000000000020810f fsck_ffs`_start(ap=<unavailable>,
> cleanup=<unavailable>) at crt1.c:76:7
> >> Some analysis:
> > (snip)
> >
> > I have had times when fsck_ffs from FreeBSD didn't succeed, but fsck_ffs
> from NetBSD did succeed.  That was on a FreeBSD installation, but I also
> had/have NetBSD installed.
> >
> > I use GPT with no traditional BSD disklabels, so FreeBSD and NetBSD can
> read and write each other's partitions.
> >
> > I ran "host national.shitposting.agency", and got
> >
> > national.shitposting.agency has address 52.11.159.5
> > national.shitposting.agency mail is handled by 20 mx2.cock.li.
> > national.shitposting.agency mail is handled by 10 mx1.cock.li.
> >
> > so the domain really exists.
> Yes as you can see in the MX records its run by a bunch of well known
> racists and faschists who also brought us nice domains like
> hitler.rocks, nigge.rs. nuke.africa and rape.lol.
> _______________________________________________
> freebsd-fs at freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-fs
> To unsubscribe, send any mail to "freebsd-fs-unsubscribe at freebsd.org"
>