On Sat, Feb 9, 2019 at 7:19 PM James Bottomley <james.bottom...@hansenpartnership.com> wrote: > > On Sat, 2019-02-09 at 18:04 +0100, Mikael Pettersson wrote: > > 4.20 and earlier kernels boot fine on my Sun Blade 2500 (UltraSPARC > > IIIi), but the 5.0-rc kernels consistently experience a 5 minute > > delay > > late during boot, after enabling networking but before allowing user > > logins. E.g. 5.0-rc5 dmesg has: > > > > [Fri Feb 8 17:13:17 2019] random: dbus-daemon: uninitialized urandom > > read (12 bytes read) > > [Fri Feb 8 17:18:14 2019] random: crng init done > > I've had the same problem on several of my test systems. Are you sure > it's not this bug report: > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=912087 > > ? > > The solution for me was to install the haveged package which does > active entropy gathering during boot and can make /dev/urandom > available much earlier.
Thanks for the hint, I'll look into using haveged on this machine. > > > During this interval the machine answers pings but won't allow user > > logins either on the console or over the network. > > > > A git bisect identified commit > > f664a3cc17b7d0a2bc3b3ab96181e1029b0ec0e6 > > Author: Jens Axboe <ax...@kernel.dk> > > Date: Thu Nov 1 16:36:27 2018 -0600 > > > > scsi: kill off the legacy IO path > > > > as the point where this 5m delay was introduced. > > I think the reason for this is that the block mq path doesn't feed the > kernel entropy pool correctly, hence the need to install an entropy > gatherer for systems that don't have other good random number sources. That does sound plausible, I admit I didn't even consider the possibility that the old block I/O path also was an entropy source. /Mikael
