From owner-freebsd-current@FreeBSD.ORG Sat Nov 1 17:03:03 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1EF6EE33; Sat, 1 Nov 2014 17:03:03 +0000 (UTC) Received: from smtp.des.no (smtp.des.no [194.63.250.102]) by mx1.freebsd.org (Postfix) with ESMTP id CF740C7D; Sat, 1 Nov 2014 17:03:02 +0000 (UTC) Received: from nine.des.no (smtp.des.no [194.63.250.102]) by smtp-int.des.no (Postfix) with ESMTP id 5F87FAFAB; Sat, 1 Nov 2014 17:03:01 +0000 (UTC) Received: by nine.des.no (Postfix, from userid 1001) id A971C10A82; Sat, 1 Nov 2014 18:03:03 +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> <86tx2j6k6j.fsf@nine.des.no> <1414858202.17308.214.camel@revolution.hippie.lan> Date: Sat, 01 Nov 2014 18:03:03 +0100 In-Reply-To: <1414858202.17308.214.camel@revolution.hippie.lan> (Ian Lepore's message of "Sat, 01 Nov 2014 10:10:02 -0600") Message-ID: <86h9yi7t14.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 17:03:03 -0000 Ian Lepore writes: > Dag-Erling Sm=C3=B8rgrav writes: > > 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. > And what about devices that are not connected to a network? They still get entropy from interrupts and disk I/O. > Oh well, I'm sure I'll be able to find some hacks to undo whatever > y'all have done now, and we'll just have to carry them as local diffs > forever. How about you take a ****ing chill pill and read what I wrote earlier: this is a regression which we will try to fix. But the bottom line is that the entropy has to come from *somewhere* and if whatever dinky device you're playing with doesn't provide any, that's not our fault. Buy http://www.amazon.com/dp/0833030477 and type it in, or something. We're engineers, not magicians. (or maybe you can do something constructive, like write code to harvest entropy from background noise in ADCs, unused WiFi / 4G / BT radios or whatever else is available and submit a patch) DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no