Icannot say what this is, never happen before. boot run at some lines after openrc and start to produce that "restore state" what goes and goes, I try to find where it stops but it didnt. I had to kill it.
When it was running that piece it was impossible to make notis of keyboard, dead. So it was switch off. Dmesg gave data of boot of livecd, that run without problem. Thats going on a week, computer out of use Livecd and try. Kernel 5.3.0 > 5.3.7 gcc 9.20 and so on.
boot openrccrng init done running restore state
Message
boot openrccrng init done running restore state
Is it better to look where you put your feets than put your feets to where you look?
sama suomeksi: Onko parempi katsoa mihin astuu kuin astua mihin katsoo?
sama suomeksi: Onko parempi katsoa mihin astuu kuin astua mihin katsoo?
Fishing on to litle more and find that rc-status --servicel
going with livecd to chroot and using rc-status --servicelist gave same result direct after enter gome that restore status some hundred times. So I think that problem stays there somewhere after " caching service dependencies" but I cant find witch one. If i play a litle more with ctrl s prints out: 1364.735... random crng init done.
I am continuing fishing. ?
I am continuing fishing. ?
Is it better to look where you put your feets than put your feets to where you look?
sama suomeksi: Onko parempi katsoa mihin astuu kuin astua mihin katsoo?
sama suomeksi: Onko parempi katsoa mihin astuu kuin astua mihin katsoo?
There's a new option in the kernel starting with line 5.2 (I think - not sure) called: Trust the CPU manufacturer to initialize Linux's CRNG (CONFIG_RANDOM_TRUST_CPU). Can also be toggled with a boot parameter: random.trust_cpu=on/off
The short story is: turns out you can hack a machine easier if you have access to the way that machine generates random entropy. /dev/random|urandom. So now, we can switch either way.
The behavior you see here is your kernel not trusting CPU random entropy. If you trust your cpu/machine just toggle random.trust_cpu=on or CONFIG_RANDOM_TRUST_CPU=y and crng will init almost instantly.
The short story is: turns out you can hack a machine easier if you have access to the way that machine generates random entropy. /dev/random|urandom. So now, we can switch either way.
The behavior you see here is your kernel not trusting CPU random entropy. If you trust your cpu/machine just toggle random.trust_cpu=on or CONFIG_RANDOM_TRUST_CPU=y and crng will init almost instantly.
- NeddySeagoon
- Administrator
- Posts: 56078
- Joined: Sat Jul 05, 2003 9:37 am
- Location: 56N 3W
After all the CPU exploits from the last few years how can you trust it with anything
Especially something as crucial to security as your source of random numbers?
/dev/random blocks on lack of entropy and in used for crypto keys and the like.
/dev/urandom does not block but as not as 'good' a source of randomness.
Especially something as crucial to security as your source of random numbers?
/dev/random blocks on lack of entropy and in used for crypto keys and the like.
/dev/urandom does not block but as not as 'good' a source of randomness.
Regards,
NeddySeagoon
Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail.
NeddySeagoon
Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail.
restore state
I found a answer from one post 2011: culprit was Alsasound and its mixer levels. Alsasound conf and dont copy levels at start was right medicin. So I am an happy Gentoo user, again. In general I am very soddisfat with it. Thanks to al off you.
Is it better to look where you put your feets than put your feets to where you look?
sama suomeksi: Onko parempi katsoa mihin astuu kuin astua mihin katsoo?
sama suomeksi: Onko parempi katsoa mihin astuu kuin astua mihin katsoo?