Fedora Account System
Red Hat Associate
Red Hat Customer
Created attachment 1906980 [details] Screenshot of the messages This is pretty much a cosmetic bug, but there's probably something a bit wrong with how Anaconda logs the final actions during a Fedora install. The context is a text-mode networked kickstart install of Fedora 36 (also observed on earlier versions), but that might not be important. If I happen to look at the screen towards the end of the "running package scripts" phase, I see several dozen lines (about 35 in all) that all say: Configuring atmel-firmware.noarch This is also recorded in /var/log/anaconda/anaconda.log after the install: 15:24:47,793 INF modules.payloads.payload.dnf.transaction_progress: Configuring (running scriptlet for): atmel-firmware-1.3-26.fc36.noarch 1642629507 660ff2d9c7c9169a4a60ba20850fa3c20b9d7d4b6f784c38f7c1b0308578f1d8 15:24:54,442 INF modules.payloads.payload.dnf.transaction_progress: Configuring (running scriptlet for): atmel-firmware-1.3-26.fc36.noarch 1642629507 660ff2d9c7c9169a4a60ba20850fa3c20b9d7d4b6f784c38f7c1b0308578f1d8 This clearly can't be what's actually going on, given that atmel-firmware doesn't in fact have any scripts. You can also see this happening at the end of the unrelated bug 1846750 (2 years ago) in this BZ.
Ian, thank you for the report. I checked and: - atmel-firmware has no scriptlets [1] - anaconda logs these messages [2][3] only when dnf reports a scriptlet is running [4] I can't see a way to reconcile these two statements, yet they both appear to be true on their own. DNF, do you have any idea what could be happening there? [1] https://src.fedoraproject.org/rpms/atmel-firmware/blob/rawhide/f/atmel-firmware.spec [2] https://github.com/rhinstaller/anaconda/blob/master/pyanaconda/modules/payloads/payload/dnf/transaction_progress.py#L113 [3] https://github.com/rhinstaller/anaconda/blob/f36-release/pyanaconda/modules/payloads/payload/dnf/transaction_progress.py#L113 [4] https://dnf.readthedocs.io/en/latest/api_callback.html#dnf.callback.TransactionProgress.progress
Those "mystery scriptlets" would likely be file triggers from some other package. As file triggers can involve any number of packages, they are executed in the context of the package owning the trigger. Which may either be something in the same transaction or something already installed, but as the context here is initial installation with anaconda, it's necessarily always from the same transaction. At the end of initial install, a whole number of file triggers run and while some could trigger on atmel-firmware, most of them would have nothing to do with it. This seems to be dnf misreporting the context in these cases, and is quite easily reproduceable: [root@localhost ~]# dnf -y reinstall atmel-firmware Dependencies resolved. ================================================================================ Package Architecture Version Repository Size ================================================================================ Reinstalling: atmel-firmware noarch 1.3-26.fc36 fedora 157 k Transaction Summary ================================================================================ Total download size: 157 k Installed size: 711 k Downloading Packages: atmel-firmware-1.3-26.fc36.noarch.rpm 606 kB/s | 157 kB 00:00 -------------------------------------------------------------------------------- Total 188 kB/s | 157 kB 00:00 Running transaction check Transaction check succeeded. Running transaction test Transaction test succeeded. Running transaction Preparing : 1/1 Reinstalling : atmel-firmware-1.3-26.fc36.noarch 1/2 Cleanup : atmel-firmware-1.3-26.fc36.noarch 2/2 Running scriptlet: atmel-firmware-1.3-26.fc36.noarch 2/2 Verifying : atmel-firmware-1.3-26.fc36.noarch 1/2 Verifying : atmel-firmware-1.3-26.fc36.noarch 2/2 Reinstalled: atmel-firmware-1.3-26.fc36.noarch Complete! [root@localhost ~]# rpm -q --scripts --triggers --filetriggers atmel-firmware [root@localhost ~]# Running it with 'rpm --reinstall -vv ...' reveals these are glibc triggers: D: running post-transaction scripts D: %transfiletriggerin(glibc-common-2.35-15.fc36.x86_64): scriptlet start D: %transfiletriggerin(glibc-common-2.35-15.fc36.x86_64): execv(/bin/sh) pid 917133 D: Plugin: calling hook scriptlet_fork_post in selinux plugin D: setexecfilecon: (/bin/sh, rpm_script_t) + /sbin/ldconfig D: %transfiletriggerin(glibc-common-2.35-15.fc36.x86_64): waitpid(917133) rc 917133 status 0 D: %transfiletriggerpostun(glibc-common-2.35-15.fc36.x86_64): scriptlet start D: %transfiletriggerpostun(glibc-common-2.35-15.fc36.x86_64): execv(/bin/sh) pid 917135 D: Plugin: calling hook scriptlet_fork_post in selinux plugin D: setexecfilecon: (/bin/sh, rpm_script_t) + /sbin/ldconfig D: %transfiletriggerpostun(glibc-common-2.35-15.fc36.x86_64): waitpid(917135) rc 917135 status 0 So dnf is misreporting the scriptlet context here, and this would of course "leak" to anaconda too which dnf for the heavy lifting. This isn't the first time this is reported, and there were a bug or two in rpm as well, but this appears to be entirely on dnf side.
Thank you for the report. dnf is indeed wrong here. This is a known issue to us and we track it in a duplicate bz: https://bugzilla.redhat.com/show_bug.cgi?id=1724779 We have a bunch of failing tests here: https://github.com/rpm-software-management/ci-dnf-stack/blob/master/dnf-behave-tests/dnf/scriptlets.feature This will be fixed in the new version dnf5: https://github.com/rpm-software-management/dnf5 - it is still work in progress though so it will take some time until resolved. *** This bug has been marked as a duplicate of bug 1724779 ***