On Thu, Feb 3, 2022 at 3:35 AM Claudius Heine <ch@denx.de> wrote:

On 2022-02-02 17:26, Kyle Russell wrote:
> Thanks, Claudius.
>
> On Wed, Feb 2, 2022 at 8:08 AM Claudius Heine <ch@denx.de
> <mailto:ch@denx.de>> wrote:
>
> Hi Kyle,
>
> On 2022-02-02 13:38, Kyle Russell wrote:
> > Is this the correct approach? Even the
> systemd-udev-settle.service man
> > pages recommends not using its service. Were the kernel modules
> really
> > not loaded when rngd started? Or is the original problem just a
> matter
> > of waiting for sufficient entropy?
>
> IIRC, the rngd could not find any random source device node (/dev/hwrng
> in that case), so the service failed to start.
>
>
> If /dev/hwrng didn't exist, this feels like the original problem was a
> misconfigured
> kernel or module that wasn't being loaded properly.

Yes, however it is a timing issue. The module was loaded properly at
bootup, however at the time rngd was started the module was not loaded
yet and thus the service fails to start. If it would be delayed until
the module is loaded everything would be fine.

It does not happen if the module is compiled into the kernel or if a
initramfs is used which loads the module (I think). I our case it
happend with the caam module as an external module loaded on boot from
the real root file system.

> The patch you are commenting on only adds `Wants` weak dependency to
> make sure `systemd-udev-settle.service` is pulled in to the job queue,
> the `After` ordering rule was already there.
>
>
> Correct. Just because an `After` exists does not mean the service gets
> pulled into
> the job queue, so prior to this change no other service was causing the
> deprecated
> systemd-udev-settle.service to be run during boot. But now, every
> device including
> openssh (which has a default PACKAGECONFIG option for rng-tools) now depends
> on this deprecated service, which may cause unexpected boot delays.
>
> So changing this service file to be triggered by a udev event or maybe
> wrap it in a script, which makes sure the right modules are loaded and
> device nodes are available, could be an improvement, but it would be
> out
> of scope of this patch IMO.
>
>
> I'm more curious whether this change should be reverted from upstream.
> It seems
> like a drop-in file could have been applied to your distro instead of
> adding a dependency
> on a deprecated service for all openssh users.

This patch just adds a missing entry into the service file. If you have
solved the described issue in some way and can revert this patch and
remove the `Wants=systemd-udev-settle.service` then you can also remove
the `After=systemd-udev-settle.service` at the same time and at that
point you can just remove both of those entries directly in the patch
that solved the timing issue.

I agree that `systemd-udev-settle.service` should probably not be used
anymore, however that file already used it in a non-functional way and
all this patch did was make it fulfill its intended function.

In retrospect I probably should have tried to find a way to remove the
usage of `systemd-udev-settle.service` completely, when I looked into
the issue, however all this patch in essence does is revive dead code,
which was already in place.

Also I think at that time I couldn't find a more precise instrument in
systemds massive toolbox to delay the start of rngd and services that
should be started in succession until the just the hardware random
generator device is ready and `After=systemd-udev-settle.service` was
already there. I guess some `ExecStartPre=` script which delays the
start until the conditions are met could be implemented, but that seems
a bit hackish.

regards,
Claudius