Description of problem: It seems that the change at [1] related to [2] has started to run "udevadm trigger --sysname-match=hw_random --settle" in the rpm post script. I do not think this is safe to run in a container. We run an image build process inside a docker container and dnf has started going into a infinite hang. Upon investigation it's waiting on "udevadm trigger --sysname-match=hw_random --settle". --- └─dnf /usr/bin/dnf -v -y install lsof grubby git-core initscripts which redhat-lsb-core sudo python3-policycoreutils cloud-utils-growpart selinux-policy-targeted NetworkManager kernel python3 dhcp-client ... └─sh /var/tmp/rpm-tmp.rZ2cHF 1 └─udevadm trigger --sysname-match=hw_random --settle --- This dnf run is installing --- 2021-06-24 00:32:01.584 | > rng-tools x86_64 6.8-5.el8 baseos 60 k --- When I run the udevadmin settle command inside the container, it just hangs, as is happening from the dnf call. I have to admit my knowledge of udev interactions inside a container is minimal. This has started affecting us after [3] was pulled into centos-8-stream. I note that the service doesn't appear to run if containerised [4] (ConditionVirtualization=!container) so I feel like this udevadm should be behind a similar check in the post script to avoid this package getting installed and hanging the installation process. [1] https://gitlab.com/redhat/centos-stream/rpms/rng-tools/-/commit/e5f8325b42bfcea2e9064ee709423e5779228413 [2] https://bugzilla.redhat.com/show_bug.cgi?id=1965318 [3] https://git.centos.org/rpms/rng-tools/c/76ff02e1942a201bdd9a3bf415768d9b28f27810?branch=c8s [4] https://gitlab.com/redhat/centos-stream/rpms/rng-tools/-/blob/c9s/rngd.service#L3
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