Fedora Account System
Red Hat Associate
Red Hat Customer
Description of problem: Creating an ostree with systemd-257.3-7.fc42 fails with a duplicate license: error: Installing packages: Checkout systemd-shared-257.3-7.fc42.x86_64: Hardlinking d0/4aeda8d2b7d098413d777e6fe5c0333ceddd97d3d43ba28803178b7a388929.file to LICENSE.LGPL2.1: File exists This was previous fixed: https://src.fedoraproject.org/rpms/systemd/pull-request/118 Version-Release number of selected component (if applicable): systemd-257.3-6+ How reproducible: Everytime, logs: https://kojipkgs.fedoraproject.org//work/tasks/9311/129349311/runroot.log Koji task: https://koji.fedoraproject.org/koji/taskinfo?taskID=129349311
My guess is that it got introduced with https://src.fedoraproject.org/rpms/systemd/c/eba17216783bac0e531a29ad3ac330147ed31d95
So the issue has raised again with that change, the previous fix that Paul mentioned can't be used in this case. The problem is that files that are identical (via a sha checksum) can be included in multiple rpms which is what happens with some of the licenses in the systemd packages: $ rpm -qf /usr/share/licenses/systemd/LICENSE.LGPL2.1 systemd-libs-257.3-6.fc42.aarch64 systemd-shared-257.3-6.fc42.aarch64 $ rpm -qf /usr/share/licenses/systemd/MIT.txt systemd-shared-257.3-6.fc42.aarch64 systemd-257.3-6.fc42.aarch64 We can remove the license files if a dependency that it pulls in for the package set also ships the license which is what we did in the last fix. The issue this time is that systemd-libs and systemd-shared are independent libraries with no cross dependencies (AKA one doesn't link against/depend on the other) so as a result they both need to ship the license. The real bug here is in ostree/bootc as it should be able to handle this completely valid rpm usecase. It could also be worked around in a couple of ways (although it's a bit of a game of whack-a-mole): 1) create a systems-licenses and move them to there and add appropriate deps 2) the licenses could go in /usr/share/licenses/<sub-package-name> so they're not actually in the same location 3) some other similar sort of thing
Yeah, can we fix this in ostree/bootc? Systemd has this general logic in various places that if it's trying to atomically replace a file, and the target exists and the contents are identical to the temporary copy, it'll discard the temporary copy without raising fuss. We can fix this in systemd through some hack like moving or renaming the file, but it's bound to happen again and again.
During installation, a license file (LICENSE.LGPL2.1) is being added twice—once it’s already present, and then the build system tries to hardlink it again, causing the error.
I will bring this to the ostree/bootc team Tomorrow.
This is likely an rpm-ostree bug. Removing the `install-langs` entry in the manifest makes this go away. Related issue: https://github.com/coreos/rpm-ostree/issues/2656
Removing `install-langs` did not work for me. Removing `ima: true` did.
> Removing `ima: true` did. That's the complexity here, I think the IMA signatures generated at build time of the RPMs are different, and for RPM the IMA support is a plugin and I bet that doesn't figure into its conflict detection. There's related things around SELinux labeling and hardlinks. But for how we do ostree, we compare extended attributes in a uniform way and that's where the conflict comes from. Anyways we can clearly fix this; I guess we could special case the IMA xattr and just allow one of them to "win" arbitrarily. But are you actually using that IMA support today?
> But are you actually using that IMA support today? Yes, we do have users, we've had some bug reports and I'm aware of people that have been using it.
> We can remove the license files if a dependency that it pulls in for the package set also ships the license which is what we did in the last fix. The issue this time is that systemd-libs and systemd-shared are independent libraries with no cross dependencies (AKA one doesn't link against/depend on the other) so as a result they both need to ship the license. AIUI systemd-shared is an implementation detail of having systemd, and so while logically systemd-shared doesn't actually depend on systemd-libs, there shouldn't be a problem in adding a Requires: systemd-libs to the systemd-shared package, and shipping the license file in systemd-libs right? A different fix here is - it's unclear to me why the IMA signatures are different if the file content is otherwise identical (and to be clear this is just a theory, it needs confirmation). I guess I'd say the status quo on this for me is that I don't think having just RPM IMA signatures is really compelling and I think it'd be more useful to build a story around tooling that allows injecting IMA signatures universally into a container image build, ensuring that non-RPM content is supported equally well. I also think composefs is a stronger security story than IMA and that's what we should be aiming towards. I'm personally unlikely to drop other things going on and work on changing rpm-ostree for this, but I would help review patches.
This message is a reminder that Fedora Linux 42 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora Linux 42 on 2026-05-13. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a 'version' of '42'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, change the 'version' to a later Fedora Linux version. Note that the version field may be hidden. Click the "Show advanced fields" button if you do not see it. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora Linux 42 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora Linux, you are encouraged to change the 'version' to a later version prior to this bug being closed.
Fedora Linux 42 entered end-of-life (EOL) status on 2026-05-27. Fedora Linux 42 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora Linux please feel free to reopen this bug against that version. Note that the version field may be hidden. Click the "Show advanced fields" button if you do not see the version field. If you are unable to reopen this bug, please file a new report against an active release. Thank you for reporting this bug and we are sorry it could not be fixed.