Arch Linux

See [1] this is expected behavior on a low entropy system which does not use any other means to add entropy.

[1] https://github.com/systemd/systemd/commit/26ded55709947d936634f1de0f43dcf88f594621

Edit:
Options to seed the entropy pool:
If the system uses systemd-boot that can use a random-seed to seed the entropy-pool
haveged
the kernel parameter random.trust_cpu=on if the CPU supports RDRAND

Thanks for the link, but I didn't get it all.

Do you have an idea to reduce the start-up time of the service?

Bootloader: grub
CPU: Intel i5-4210M 4th Gen Core Processor

System is using grub and I believe has RDRAND so the second and third options in my edit are hopefully applicable:
For haveged see [1]
For the kernel parameter see [2] for how to set it and [3] for documentation on what random.trust_cpu=on does

[1] https://wiki.archlinux.org/index.php/Haveged
[2] https://wiki.archlinux.org/index.php/Kernel_parameters
[3] https://www.kernel.org/doc/Documentation/admin-guide/kernel-parameters.txt

The 'random.trust_cpu=on' parameter works.
However, are there no security issues to use it?

Thank you.

There is lots of discussion on trusting RDRAND for you to research.
haveged is an alternative if you trust that more. rngd [1] supports other hardware RNGs if you perfer that.

[1] https://wiki.archlinux.org/index.php/Rng-tools

Ok, thanks.

Adding the 'random.trust_cpu=on' parameter doesn't work for me. I've downgraded all my essential systemd pkgs on my system back to version 242.84-2 and have been running that since the release of 243.0-1.
Start jobs always run at boot time for 'Load/Save Random Seed' and remounting of my drives stall at boot time for about 5 seconds, or so. This behavior only happens in 243.0-1.

`systemd-analyze blame` reflects this change with 'systemd-random-seed.service' being the last service to launch (at 8.758s), whereas before the service was one of the first launched (at around 5-6ms).

@I_am_normal Did you enable random.trust_cpu=on because the system supports RDRAND?
What about the other options that have been mentioned?
Are you expecting upstream to revert this behavior? Have you contacted upstream about the issue?

No, not expecting anything really. Just wanted to leave what I have been experiencing with this bug in particular and was a bit curious as to what was going on. But as you noted earlier, there looks to be quite a bit of discussion surrounding the topic.

I'm using an intel chip which does have the flag 'rdrand' in /proc/cpuinfo, so I assume it is supported.
I have not tried Haveged. Nor have I contacted upstream. I will look into both, though. Thanks

Could you please include the output from journalctl for a boot with random.trust_cpu=on as an attachment.

I was mistaken apparently. With Systemd 243.0-1, *and* the parameter set, I still get a start job upon boot, but not for random seed anymore. Only one waiting for the system to remount my drives. So setting random.trust=on does fix *part* of whatever problem I am having. The system is still hanging at boot, but no longer is it pointing to random seed. Maybe services are tripping over each other when trying to initialize, or something- idk.
Anyways, I attached 3 files.
One booting Systemd-243.0-1 with parameter set.
One booting Systemd-243.0-1 NO parameter set.
And one file showing what a 'normal' boot looks like running the downgraded systemd-242.84.2 NO parameter set.
Thanks again.

ATTENTION /!\:
After a discussion on irc, I was advised not to enable the `random.trust_cpu=on` option because of the security risk. Hopefully a viable solution will be found quickly by the systemd devs.
It's better to wait for this one.

Thank you for the heads up @T0t0

@Toto could you please attach the log of that discussion.
Please also link to the upstream systemd bug report.

@loqs: What exactly do you want me to do?

For the discussion on irc, the entropy created by intel CPU is not sure. There is a risk of decryption apparently. See on the net for more details.

If you do not have a log then you can not attach it. Thank you for the summary.

On the upstream bug report my point is for the systemd developers to find a viable
solution the developers have to be aware of the issue to which a solution is expected.
As per the commit message from [1] the blocking until the random pool is initialized
is a deliberate change. Without an upstream change and without using RDRAND. I have
already suggested two other methods to add entropy to the pool. As an alternative
the service could be disabled which in itself may be a security risk. [2] covers
more on the systemd random seed use in v243.

[1] https://github.com/systemd/systemd/commit/26ded55709947d936634f1de0f43dcf88f594621
[2] https://systemd.io/RANDOM_SEEDS

For the irc discussion, I can't provide it because I use the kiwiirc.com site. I opened an issue on github.
https://github.com/systemd/systemd/issues/13602
The alternatives you offered me are not much better. I'm thinking of Haveged (see the documentation).

I was playing with my cloud Arches and stumbled on this. Processor random generator (using RDRAND) is only part of the process.
Detailed explanation:
https://askubuntu.com/questions/1070433/will-ubuntu-enable-random-trust-cpu-in-the-kernel-and-what-would-be-the-effect
Some more on the subject:
https://wiki.debian.org/BoottimeEntropyStarvation

https://github.com/systemd/systemd/issues/13602#issuecomment-539486178
Can this be closed now? As has now been repeated by upstream this is intended behavior.

Hi,

the topic can be closed.
Thanks.