[Bug 218986] random harvesting on older i386 causing boot failure
bugzilla-noreply at freebsd.org
bugzilla-noreply at freebsd.org
Mon May 1 06:35:14 UTC 2017
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=218986
Bug ID: 218986
Summary: random harvesting on older i386 causing boot failure
Product: Base System
Version: 11.0-STABLE
Hardware: i386
OS: Any
Status: New
Severity: Affects Some People
Priority: ---
Component: kern
Assignee: freebsd-bugs at FreeBSD.org
Reporter: dewayne at heuristicsystems.com.au
Created attachment 182205
--> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=182205&action=edit
VIA C3 dmesg.boot verbose
Using a build process that is successful on amd64 and i386 boxes with
FreeBSD 11.0-STABLE FreeBSD 11.0-STABLE #0 r317498M: Fri Apr 28 03:52:30 AEST
2017 root at hathor:/110007/P/C3/sys i386 1100512 1100512
The same usb drive was inserted into VIA C7 (i386) processor and booted as
expected. With the older VIA C3 boxes the system stopped somewhere between
kernel and init.
The sequence of booting: bios, da0 was recognised, loader, kernel were
successful and the memory filesystem was loaded. However, the harvestor is
unable to complete its work and impacts the recognition of da0 (usb), refer
enclosed dmesg. Around the 300-310 second mark, the "random: unblocking
device" kicked in.
Ultimately this is a workaround, in loader.conf
kern.cam.boot_delay="320000"
It seems that
random: harvesting attach, 8 bytes (4 bits) from umass0
causes the booting sequence to block. Without the delay, the usb is loaded but
can't proceed with the handover from the kernel. My guess is that init isn't
started (I've placed logging into /etc/rc to see if that starts, it doesn't).
I know that kern.random.harvest.mask is picked up via sysctl.conf, the value
there is 256, for SWI and CACHED; however we also tried a value of 0 in
loader.conf. This didn't help :(
>From the verbose boot log, it seems that very many devices (all?) are harvested
for entropy during the boot. Unfortunately the umass device doesn't seem to
want to play.
This is a slow 800MHz system with 1G memory which acts as a firewall device.
It is a reliable old plug (workhorse) and we test it last, as its been the
least problematic.
I've included a "boot -v" log as it may shed further light.
--
You are receiving this mail because:
You are the assignee for the bug.
More information about the freebsd-bugs
mailing list