Bug 2120346

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 ***