Skip to main content ↑ ↓
Topic: Long pause at "Initializing random number generator" (Read 4249 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Re: Long pause at "Initializing random number generator"

Reply #15 –
/dev/urandom has two different implentations a BSD one and a Linux one where the BSD one can block as it loads and the Linux impementation in theory can not.  I've seen booting slowdown with /dev/urandam building random bits from the physcial feedback of the hardware.  It is designed to do that and the security of cryptography for which openssl might be only one client, depends on it functioning correctly.

It seems wrongheaded to not update openssh and openssl because /dev/urandom is doing what it is supposed to do.  It is held up for 20 minute, then there might be a problem.

If you wan to really root this out you need to find all the packages that own /dev/urandom but installing them and uninstalling packlages willynillie to see how it affects the boot is not as rational as it seems, especially since you are likely to make an error and mess something up unintentionally, or deal with packages that step on each other in unexpected ways.

Re: Long pause at "Initializing random number generator"

Reply #16 –
Keeping openssl at the previous version breaks pacman in the stable repo now, so look out for that:
IgnorePkg   = openssl
$ sudo pacman -Syyu
pacman: /usr/lib/libssl.so.1.1: version `OPENSSL_1_1_1' not found (required by /usr/lib/libcurl.so.4)

Re: Long pause at "Initializing random number generator"

Reply #17 –
Installing the newer openssl fixed pacman, but openssl still causes the long 1m20sec boot hang.
Code: [Select]
rm'ing that openssl lib breaks sudo, so I mounted the artix / from elsewhere to have a separate shell to fix this.

openssl has a single conf file, back this up if it's been modified as it's about to get overwritten :

/etc/ssl/openssl.cnf

$ sudo mount /dev/sda? /mnt
$ sudo mkdir /tmp/oldssl
$ sudo tar -xvJf /mnt/var/cache/pacman/pkg/openssl-1.1.0.i-1-x86_64.pkg.tar.xz -C /tmp/oldssl | tee -a old-openssl-pkg-file-list.txt
Remove .files from list:
$ sed '/^\./ d' < old-openssl-pkg-file-list.txt > output-old-openssl-pkg-file-list.txt
$ mkdir latest-openssl
$ tar -xvJf /mnt/var/cache/pacman/pkg/openssl-1.1.1-1-x86_64.pkg.tar.xz -C latest-openssl/
Next command is inefficient & slow to complete:
$ for i in $(cat output-old-openssl-pkg-file-list.txt); do sudo rm /mnt/$i; done
$ sudo cp -r latest-openssl/* /mnt/

Then boot into artix and (re)install the latest openssl with pacman to get the database correct.
$ sudo pacman -U --overwrite=* /var/cache/pacman/pkg/openssl-1.1.1-1-x86_64.pkg.tar.xz
Or you could probably use pacman remotely from an iso etc. instead of this method.

Re: Long pause at "Initializing random number generator"

Reply #18 –
Installing haveged, haveged-openrc and enabling it did not help. Also it does not always hang at the random number generator line, so that is only a coincidence. Perhaps as mrbrklyn suggests, this isn't openssl, but something that depends on it and it doesn't work with the new version. There is nothing logged by syslog-ng as the hang occurs before it starts. I tried using ALT F* but there are no logins on the other ttys at this point, so there's no shell to see what's running during the hang either.

Re: Long pause at "Initializing random number generator"

Reply #19 –
 ;)  :D  ;D
I've got rid of the boot hang by disabling a bunch of non-essential services, then I re-enabled them to find out which one it was:
Code: [Select]
$ sudo rc-update delete syslog-ng
 * service syslog-ng removed from runlevel default
The winner was syslog-ng, that's what causes the long pause with the latest openssl version. There was a kind of a clue in the boot logs too, as they show syslog-ng being started fairly early during boot, before the hang, but the first time stamps in everything.log are after the long pause.
I also found a totally useless service I had enabled - netmount, I have no netmounts. So there's another useful find today.

Re: Long pause at "Initializing random number generator"

Reply #20 –
Because logging is not important?

Re: Long pause at "Initializing random number generator"

Reply #21 –
Quote from: ####### – on
;)  :D  ;D
I've got rid of the boot hang by disabling a bunch of non-essential services, then I re-enabled them to find out which one it was:
Code: [Select]
$ sudo rc-update delete syslog-ng
 * service syslog-ng removed from runlevel default
The winner was syslog-ng, that's what causes the long pause with the latest openssl version. There was a kind of a clue in the boot logs too, as they show syslog-ng being started fairly early during boot, before the hang, but the first time stamps in everything.log are after the long pause.
I also found a totally useless service I had enabled - netmount, I have no netmounts. So there's another useful find today.


logging is an essential service

Re: Long pause at "Initializing random number generator"

Reply #22 –
I advice you to use some logging service.

Re: Long pause at "Initializing random number generator"

Reply #23 –
I am hoping removing the syslog-ng service might also resolve the random boot failures, they became much more frequent with the incompatible syslog-ng / openssl versions that caused the hang. I have had none since, but it will take a long while to confirm this. Personally I have dmesg, xorg, wtmp,  rc.log, and that will suffice for a while, it's a much better solution than ignoring openssl. Disabling the syslog-ng service means if a newer version is installed as an update I will see that, and can try it again easily. But if you must have logging then try another logger like metalog, rsyslog from the AUR, or socklog with runit.
There is no syslog in the base install - it's not essential to system operation, just a useful source of information on occasion.
I said the 'netmount' service was useless (to me personally, after I read the init script carefully) not syslog, anyway.  ;D
 

Re: Long pause at "Initializing random number generator"

Reply #24 –
To anyone who might ever read this thread in the future, NEVER run a system without system logging