Date: Sun, 2 Nov 2014 15:12:59 +0900 From: Tomoaki AOKI <junchoon@dec.sakura.ne.jp> To: freebsd-current@freebsd.org Cc: des@des.no Subject: Re: CURRENT: WARNING! r273914 leaves filesystems in inconsistent/corrupted condition! Message-ID: <20141102151259.1e135f590be192b4c3e75983@dec.sakura.ne.jp> In-Reply-To: <86y4rv6lxf.fsf@nine.des.no> References: <20141031202045.2e02f4a3.ohartman@zedat.fu-berlin.de> <86a94c9bn3.fsf@nine.des.no> <545402C9.4070901@fgznet.ch> <201410312231.s9VMVsT1002148@pozo.com> <86fve392uy.fsf@nine.des.no> <20141101153554.77a4a7e4cef7bfe2b9486e89@dec.sakura.ne.jp> <86y4rv6lxf.fsf@nine.des.no>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, 01 Nov 2014 15:21:48 +0100 Dag-Erling Sm〓rgrav <des@des.no> wrote: > Tomoaki AOKI <junchoon@dec.sakura.ne.jp> writes: > > Dag-Erling Sm〓rgrav <des@des.no> writes: > > > Manfred Antar <null@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〓rgrav - des@des.no > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" -- Tomoaki AOKI junchoon@dec.sakura.ne.jp
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20141102151259.1e135f590be192b4c3e75983>