Hmm, I provided a fix for ( https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=245907) and it appears to have created a spiderweb of breakage - as noted by jhb and chs (in commit 84768d114951e88288024f09d4beae0956c3cf21).
I’ll have some time to dig into this in the next day or two. In the meantime, the best idea I have for an immediate fix is to revert the aforementioned commit and commit f190f9193bc10a8193c87e0a02fa91400e4eb159, then apply/test the patch found at: https://bugs.freebsd.org/bugzilla/attachment.cgi?id=225092&action=diff If there’s any input or suggestions, let me know. Thanks, Rob On Thursday, May 27, 2021, John Baldwin <j...@freebsd.org> wrote: > On 5/21/21 1:38 PM, Kirk McKusick wrote: > >> The branch main has been updated by mckusick: >> >> URL: https://cgit.FreeBSD.org/src/commit/?id=f190f9193bc10a8193c8 >> 7e0a02fa91400e4eb159 >> >> commit f190f9193bc10a8193c87e0a02fa91400e4eb159 >> Author: Kirk McKusick <mckus...@freebsd.org> >> AuthorDate: 2021-05-21 20:41:40 +0000 >> Commit: Kirk McKusick <mckus...@freebsd.org> >> CommitDate: 2021-05-21 20:42:37 +0000 >> >> Fix fsck_ufs segfaults with gjournal (SU+J) >> The segfault was being hit in ckfini() (sbin/fsck_ffs/fsutil.c) >> while attempting to traverse the buffer cache to flush dirty buffers. >> The tail queue used for the buffer cache was not initialized before >> dropping into gjournal_check(). Move the buffer initialization >> earlier >> so that it has been done before calling gjournal_check(). >> > > This appears to have broken fsck in at least some use cases. On my rpi > I get this error trying to boot: > > Setting hostid: 0x4ce29432. > Starting file system checks: > fsck_ufs: Initial malloc(-1515870811) failed > fsck_ufs: Initial malloc(-1515870811) failed > Automatic file system check failed; help! > ERROR: ABORTING BOOT (sending SIGTERM to parent)! > > The amount being passed to malloc() is malloc junk: > > (gdb) p/x -1515870811 > $1 = 0xa5a5a5a5 > > The i386 CI jobs in jenkins have been failing with the same error recently > as well. > > I guess this means sblock isn't fully initialized by sblock_init()? At > least > not enough to set fs_bsize? Hmm, perhaps readsb() is what sets fs_bsize? > > -- > John Baldwin > _______________________________________________ dev-commits-src-main@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/dev-commits-src-main To unsubscribe, send any mail to "dev-commits-src-main-unsubscr...@freebsd.org"
