hello, Ian,
thank you for reporting this. indeed, udevadm call lacks the ConditionVirtualization=!container
guard. i'm posting a fix and i need to wait for Mon to approve this bz from qe side.

Thanks for the detailed testing instructions, making this a real no-brainer.  Just sorry for the delay, people set me NEEDINFO when they need to test bugs, and I then miss real needinfos in between.

Tested. 

# wget http://download.devel.redhat.com/brewroot/work/tasks/2274/38422274/jitterentropy-3.0.2-2.git.409828cf.el9.x86_64.rpm http://download.devel.redhat.com/brewroot/work/tasks/6815/38436815/rng-tools-6.13-5.git.d207e0b6.el9.x86_64.rpm
(...)
2021-08-05 19:14:25 (26.3 MB/s) - ‘jitterentropy-3.0.2-2.git.409828cf.el9.x86_64.rpm’ saved [30933/30933]
2021-08-05 19:14:25 (23.9 MB/s) - ‘rng-tools-6.13-5.git.d207e0b6.el9.x86_64.rpm’ saved [64537/64537]
FINISHED --2021-08-05 19:14:25--
(...)
# dnf -y install jitterentropy*rpm rng-tools*rpm
(...)
Installed:
  jitterentropy-3.0.2-2.git.409828cf.el9.x86_64                                        rng-tools-6.13-5.git.d207e0b6.el9.x86_64
Complete!
# grep Condition /usr/lib/systemd/system/rngd.service /usr/lib/systemd/system/rngd-wake-threshold.service
/usr/lib/systemd/system/rngd.service:ConditionVirtualization=!container
/usr/lib/systemd/system/rngd-wake-threshold.service:ConditionVirtualization=!container
# dnf -y erase jitterentropy rng-tools
(...)
[root@hpe-z220-03 ~]# rm -f jitterentropy*rpm rng-tools*rpm

(In reply to Vilém Maršík from comment #5)
> Thanks for the detailed testing instructions, making this a real no-brainer.
> Just sorry for the delay, people set me NEEDINFO when they need to test
> bugs, and I then miss real needinfos in between.

thanks, Vilem, much appreciated!
yes, communications are suboptimal sometimes, i hope we will overcome this.

Thanks for the fix. I have the same problem but the fix does not help me.

I have el8 running on a server. The server does not have systemd-udevd running (not needed and therefore removed by standard hardening procedure). This means that the command

   udevadm trigger --sysname-match=hw_random --settle

also hangs indefinitely.

I propose to change the solution to include all cases in which we know beforehand that udevadm cannot run successfully. Not all of these cases are related to virtualisation.

Perhaps one could use a test like

    # systemctl is-active systemd-udevd
    inactive

Alternatively we could check whether the --timeout option to udevadm could help in these cases (a more simple solution perhaps)?

Alas, no:

    # man udevadm | grep timeout
       -t, --timeout=SECONDS
       -t, --timeout=seconds

    # udevadm trigger --timeout=10 --sysname-match=hw_random --settle
    trigger: unrecognized option '--timeout=10'

Apparently the --timeout parameter is not accepted for the trigger subcommand :-(


It would be good to have a solution.  On one server I had one dnf-automatic process run for several weeks before I noticed the block.  This has potential security implications because no new updates were installed while the (unimportant) post-install blocked rpmdb indefinitely.

(In reply to Ned from comment #9)
> Thanks for the fix. I have the same problem but the fix does not help me.

hi, Ned, thanks for the bug report. the scripts were reworked to un-tie rng-tools from udevadm + other minor fixes.
unfortunately, it will take some time for fixes to reach RHEL releases, so i can provide you a candidate build of
rng-tools with fixes for you version of RHEL if needed.

Dear Vladis,
Many thanks, I have a workaround for the moment.  Looking forward to the proper solution!
Best regards,
Ned