From owner-freebsd-current@FreeBSD.ORG Sat Nov 1 14:59:31 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A267073C; Sat, 1 Nov 2014 14:59:31 +0000 (UTC) Received: from smtp.des.no (smtp.des.no [194.63.250.102]) by mx1.freebsd.org (Postfix) with ESMTP id 60352EFA; Sat, 1 Nov 2014 14:59:30 +0000 (UTC) Received: from nine.des.no (smtp.des.no [194.63.250.102]) by smtp-int.des.no (Postfix) with ESMTP id 576D4AE1B; Sat, 1 Nov 2014 14:59:30 +0000 (UTC) Received: by nine.des.no (Postfix, from userid 1001) id 9760A10A6F; Sat, 1 Nov 2014 15:59:32 +0100 (CET) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Ian Lepore Subject: Re: CURRENT: WARNING! r273914 leaves filesystems in inconsistent/corrupted condition! 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> <1414852431.17308.210.camel@revolution.hippie.lan> Date: Sat, 01 Nov 2014 15:59:32 +0100 In-Reply-To: <1414852431.17308.210.camel@revolution.hippie.lan> (Ian Lepore's message of "Sat, 01 Nov 2014 08:33:51 -0600") Message-ID: <86tx2j6k6j.fsf@nine.des.no> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: Tomoaki AOKI , freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Nov 2014 14:59:31 -0000 Ian Lepore writes: > Dag-Erling Sm=C3=B8rgrav writes: > > 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). > And I vaguely remember being promised that things like that would > NEVER happen, even on systems with little or no entropy available > during early startup (which describes quite nicely the embedded > systems we build at work). I think you misremember. It is impossible to guarantee that the system will always have enough entropy right from the start. Servers, desktops and laptops will be fine, but embedded systems and VMs might not be able to unblock until they've seen some network traffic or loaded a chunk of pre-generated entropy (which is what /etc/rc.d/random does). This is especially true for embedded systems that don't have enumerable buses and rely on fdt(4) to create the device tree at boot time. VMs have the additional problem of divergence between clones: if you clone a VM, all clones will start out with the exact same state and won't diverge until they've all reseeded after gathering entropy independently of eachother. I don't really know how to solve this. One possibility, assuming you have guest additions installed and that they can tell you that you've been suspended, is to block on resume. It won't help VMs that were cloned while shut down, but they should diverge to some extent during boot. DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no