Hi Drew,
On 2022-08-01 20:44, Drew Moseley wrote:
On 7/26/22 9:17 AM, drew.mose...@gmail.com wrote:
From: Drew Moseley <d...@moseleynet.net>
The systemd-udev-settle service is listed as obsolete and does in
some cases result in a significant boot time. Replace that with
"after systemd-modules-load" to allow the random source hardware
to be loaded in the proper sequence.
Before this change:
Startup finished in 4.025s (kernel) + 2min 13.236s (userspace) =
2min 17.262s
multi-user.target reached after 2min 8.153s in userspace
After this change:
Startup finished in 3.956s (kernel) + 13.294s (userspace) = 17.250s
multi-user.target reached after 9.522s in userspace
Signed-off-by: Drew Moseley <d...@moseleynet.net>
---
meta/recipes-support/rng-tools/rng-tools/rngd.service | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/meta/recipes-support/rng-tools/rng-tools/rngd.service
b/meta/recipes-support/rng-tools/rng-tools/rngd.service
index 568686e80e..e818cfcf78 100644
--- a/meta/recipes-support/rng-tools/rng-tools/rngd.service
+++ b/meta/recipes-support/rng-tools/rng-tools/rngd.service
@@ -3,7 +3,7 @@ Description=Hardware RNG Entropy Gatherer Daemon
DefaultDependencies=no
After=systemd-udev-settle.service
Before=sysinit.target shutdown.target
-Wants=systemd-udev-settle.service
+After=systemd-modules-load.service
Conflicts=shutdown.target
[Service]
Hi Khem, Claudius,
Any thoughts on this change? Obviously I cannot verify if the original
hardware combination issue is resolved and unfortunately it sounds like
you cannot either but I'm using this successfully to work around the
delayed boots I was seeing here.
Well as I said, `systemd-modules-load.service` just waits until all
statically configured modules are loaded, however not until the
`/dev/hwrng` device node is available. `systemd-udev-settle.service`
waits until all udev rules are applied, and that means it includes
loading of all dynamically loaded modules as well as executing code that
creates symlinks, etc.
Instead of waiting for modules to be loaded, that might be unrelated or
waiting for all (mostly unrelated) udev rules to be settled, I think
waiting directly for the `/dev/hwrng` device node might be more explicit
and specific.
regards,
Claudius
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#168769):
https://lists.openembedded.org/g/openembedded-core/message/168769
Mute This Topic: https://lists.openembedded.org/mt/92626958/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
