Re: CURRENT: WARNING! r273914 leaves filesystems in inconsistent/corrupted condition!

On Sat, 01 Nov 2014 15:21:48 +0100
Dag-Erling Sm$B".(Brgrav <des_at_des.no> wrote:

> Tomoaki AOKI <junchoon_at_dec.sakura.ne.jp> writes:
> > Dag-Erling Sm$B".(Brgrav <des_at_des.no> writes:
> > > Manfred Antar <null_at_pozo.com> writes:
> > > > Then for some reason /var started to being mounted mfs.  [...]  If
> > > > I have varmfs="NO" and cleanvar_enable="NO" everything works fine.
> > > Not really.  The default for varmfs is AUTO, which mounts a memory
> > > file system on /var if, after mounting all "early" file systems,
> > > /var is not writeable.
> > For me, Manfred's workaround actually helped.
> 
> It helped that particular issue, more or less by accident.  It was not
> in any way a correct fix or even a correct workaround.
> 
> > In single user mode, actual /var (in root partition) appears as
> > before.  So there can be some mis-ordering within rc scripts.
> > (Remounting of / is delayed? Check for /var too early?)
> 
> Exactly right; the check for a writeable /var occurred before / was
> mounted r/w, so it mounted an mfs instead.  Xin fixed this in r273919.

Looks fixed now, but what confused me is that r273919 modifies
etc/rc.d/geli.
I've not configured GELI neither in head VM nor stable/10 host.

And what MORE confused me are that...
  *In first reboot (after installworld and mergemaster) at r273922,
   mfsvar problem appeared. (/var/db/ports looked empty.)
   At the moment, r273619:OK -> r273876:NG -> r273902:NG -> r273922:NG.

  *Manfred's workaround helped in following reboot [no other change].
   (And sent my previous mail.)

  *Noticed that r273919 should fix above by your reply, backed out
   Manfred's workaround [no other change] and rebooted, can't reproduce
   the mfsvar problem anymore!
   (With some rebooting test, and updating to r273958.)


> > For me, [unblocking /dev/random] takes nearly 2 minutes each boot
> > after r273872.  No specific rc.conf setting for it.
> 
> That means we're not getting enough entropy during early boot, or we're
> underestimating the amount of entropy we're getting.  We added entropy
> harvesting to device_attach() about a year ago, which in most cases
> provides enough entropy to unblock /dev/random before we even run
> init(8).

Confirmed r273957 and r273958 fixes this. Thanks!

> 
> DES
> -- 
> Dag-Erling Sm$B".(Brgrav - des_at_des.no
> _______________________________________________
> freebsd-current_at_freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscribe_at_freebsd.org"

-- 
Tomoaki AOKI    junchoon_at_dec.sakura.ne.jp