Bug 218986 - random harvesting on older i386 causing boot failure
Summary: random harvesting on older i386 causing boot failure
Status: Closed Works As Intended
Alias: None
Product: Base System
Classification: Unclassified
Component: kern (show other bugs)
Version: 11.0-STABLE
Hardware: i386 Any
: --- Affects Some People
Assignee: freebsd-bugs (Nobody)
Keywords: regression
Depends on:
Reported: 2017-05-01 06:35 UTC by dewayne
Modified: 2020-07-04 21:55 UTC (History)
0 users

See Also:

VIA C3 dmesg.boot verbose (6.16 KB, application/x-xz)
2017-05-01 06:35 UTC, dewayne
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description dewayne 2017-05-01 06:35:14 UTC
Created attachment 182205 [details]
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@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

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.
Comment 1 dewayne 2020-07-04 21:55:13 UTC
There is a delay in 
GENERIC:options  SCSI_DELAY=5000 
Along with a variable kern.cam.boot_delay in /boot/loader.conf avoids the problem described. Given that this is old/slow equipment, this is the correct course.