Hi, this sounds familiar to me. Could you check please this one: https://access.redhat.com/solutions/3639751? Anyway, it's very likely not related to dnf itself.

Thank you Jan for the insight. Indeed, the failure has nothing to do with DNF; I had a mount on one of the base directories provided by the filesystems package.

However, DNF does not seem to report the ROOT CAUSE of the failure, even at high logging levels. i.e. just reporting "Error unpacking rpm package" is not helpful. YUM does report the root cause: "unpacking of archive failed on file /media: cpio: lsetfilecon"

If I had seen that, I probably would have figured this out myself.

Hence, maybe we can use this bug to improve DNF error reporting?

Indeed, there have been numerous bug reports on various issues where the biggest problem is that dnf eats up the error message from rpm. Rpm's error messages can be ugly and cryptic as anything, but often vital for actually diagnosing an issue.

Right, we'll look into how this can be improved in dnf4, though it may be challenging to make changes without affecting existing dnf4 clients. However, we'll ensure the situation is improved in dnf5, which will be the default in Fedora 41+. I've already created an upstream dnf5 ticket for that: https://github.com/rpm-software-management/dnf5/issues/1709.

He, I did the same and file dnf5 ticket - https://github.com/rpm-software-management/dnf5/issues/1710

Anyway, dnf4 should show you the rpm error (at least according to my tests it does):


❌1 ❯ sudo dnf upgrade -y
Last metadata expiration check: 0:13:31 ago on Thu 19 Sep 2024 11:09:47 AM CEST.
Dependencies resolved.
=========================================================================================
 Package               Architecture      Version                 Repository         Size
=========================================================================================
Upgrading:
 filesystem            x86_64            3.18-8.fc40             fedora            1.1 M

Transaction Summary
=========================================================================================
Upgrade  1 Package

Total download size: 1.1 M
Downloading Packages:
filesystem-3.18-8.fc40.x86_64.rpm                        3.5 MB/s | 1.1 MB     00:00    
-----------------------------------------------------------------------------------------
Total                                                    2.3 MB/s | 1.1 MB     00:00     
Running transaction check
Transaction check succeeded.
Running transaction test
Transaction test succeeded.
Running transaction
  Running scriptlet: filesystem-3.18-8.fc40.x86_64                                   1/1 
  Preparing        :                                                                 1/1 
  Upgrading        : filesystem-3.18-8.fc40.x86_64                                   1/2 
error: lsetfilecon: (26 /mnt, system_u:object_r:mnt_t:s0) Read-only file system
error: Plugin selinux: hook fsm_file_prepare failed

Error unpacking rpm package filesystem-3.18-8.fc40.x86_64

Failed:
  filesystem-3.18-6.fc39.x86_64               filesystem-3.18-8.fc40.x86_64              

Error: Transaction failed

When I was reproducing it with default dnf4 settings on F40 container, I got the same output as the reporter though...

Interesting. Can you share a reproducer?

Sure. I've basically downloaded some iso file and mount it under /mnt. Then I've tried to update the filesystem package like "dnf upgrade filesystem --releasever 41". And I got just this message "Error unpacking rpm package filesystem-3.18-8.fc40.x86_64".

OK, turned out that the rpm transaction behavior depends on the content of the mounted ISO image.
Images that I used for testing caused that the transaction failed during a scriptlet execution, which is already covered in dnf and the error messages were printed to the user. But with a different ISO (e.g. the one Jan used for testing) the transaction failed during unpacking the rpm and in this case the dnf squirrels the rpm error messages away and the user is not informed.
Will prepare a fix.

PR with the fix: https://github.com/rpm-software-management/dnf/pull/2132

The RPM unpacking error now provides a detailed message.