On Sat, 01 Nov 2014 15:21:48 +0100
Dag-Erling Sm〓rgrav <d...@des.no> wrote:
> Tomoaki AOKI <junch...@dec.sakura.ne.jp> writes:
> > Dag-Erling Sm〓rgrav <d...@des.no> writes:
> > > Manfred Antar <n...@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
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
Confirmed r273957 and r273958 fixes this. Thanks!
> Dag-Erling Sm〓rgrav - d...@des.no
> email@example.com mailing list
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Tomoaki AOKI junch...@dec.sakura.ne.jp
firstname.lastname@example.org mailing list
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"