Re: kernel: failed: cg 5, cgp: 0xd11ecd0d != bp: 0x63d3ff1d

From: Chris H <bsd-lists_at_BSDforge.com>
Date: Tue, 20 Feb 2018 18:27:17 -0800
On Tue, 20 Feb 2018 12:39:53 +0100 <gljennjohn_at_gmail.com> said

> On Mon, 19 Feb 2018 14:18:15 -0800
> "Chris H" <bsd-lists_at_BSDforge.com> wrote:
> 
> > I'm seeing a number of messages like the following:
> > kernel: failed: cg 5, cgp: 0xd11ecd0d != bp: 0x63d3ff1d
> > 
> > and was wondering if it's anything to be concerned with, or whether
> > fsck(8) is fixing them.
> > This began to happen when the power went out on a new install:
> > FreeBSD dns0 12.0-CURRENT FreeBSD 12.0-CURRENT #0: Wed Dec 13 06:07:59 PST
> > 2017
> > root_at_dns0:/usr/obj/usr/src/amd64.amd64/sys/DNS0 amd64
> > which hadn't yet been hooked up to the UPS.
> > I performed an fsck in single user mode upon power-up. Which ended with the
> > mount points being masked CLEAN. I was asked if I wanted to use the JOURNAL.
> > I answered Y.
> > FWIW the systems are UFS2 (ffs) have gpart labels, and were newfs'd thusly:
> > newfs -U -j
> > 
> > Thank you for all your time, and consideration.
> > 
> 
> fsck fixes these errors only when the user does NOT use the journal.
> You should re-do the fsck.
This doesn't seem quite right. That is; fsck(8) /should/ fix it when soft journaling
is enabled. Otherwise the -j option, to newfs(8) and journaling have no value.
OTOH you are indeed correct in that "falling through" will correct any errors. I
used that option after submitting this question. But there /does/ appear to be a
regression. As this has never been the case in earlier versions of FreeBSD. fe;
imposing the same conditions on an 11, or 9.3 system does NOT exhibit this problem.
I literally pulled the plug on 2 systems (1 _at_11, and 1 _at_9.3) and fsck(8) using
the journal happily fixed the errors, without any latter fallout as described in
this message.

Thank you very much Gary, for taking the time to reply!

--Chris
> 
> -- 
> Gary Jennejohn
Received on Wed Feb 21 2018 - 01:27:18 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:41:15 UTC