manifests: add udisks2 so fwupd can work as expected

[Rolv-Apneseth]

fwupd relies on udisks2 to detect + mount ESPs. Let's add it since it no longer requires Python, and it allows fwupd to work as expected on FCOS (for non-RAID systems).

Part of the work for coreos/fedora-coreos-tracker#1623, and related to coreos/bootupd#1138.

Previous breakdown of size + added packages: coreos/fedora-coreos-tracker#1623 (comment)

[Rolv-Apneseth]

Seems like a transitive dep is causing the CI to fail, is that expected?

[2026-08-21T13:42:15.926Z] Exception: found unlocked RPM in strict mode: (none)	nspr-4.39.0-3.fc44.x86_64	nspr-4.39.0-3.fc44	nspr-4.39.0-3.fc44.x86_64	nspr-4.39.0-3.fc44

[dustymabe]

hmm not sure..

but you should be able to do a local build and copy the lockfile from builds/latest/x86_64/manifest-lock.generated.x86_64.json into place over manifest-lock.x86_64.json I think.

[Rolv-Apneseth]

Konflux failed with:

404, message='Not Found', url='https://kojipkgs.fedoraproject.org/repos-dist/coreos-pool/latest/x86_64/Packages/l/libatasmart-0.19-32.fc44.x86_64.rpm'

That's just the first indirect dependency, so I assume others would fail too. Is there some gap with how indirect/transitive deps are added into our package pool for Konflux?

[jbtrystram]

Konflux failed with:

404, message='Not Found', url='https://kojipkgs.fedoraproject.org/repos-dist/coreos-pool/latest/x86_64/Packages/l/libatasmart-0.19-32.fc44.x86_64.rpm'

That's just the first indirect dependency, so I assume others would fail too. Is there some gap with how indirect/transitive deps are added into our package pool for Konflux?

yeaaah so this is caused by how we hacked hermetic builds to work. Long story short, this package is not yet tagged into coreos-pool and will only be when this PR merges. So until then, hermetic build won't work.

@joelcapitao I think this has caused confusion multiples times already, so we should find a way to turn off hermetic builds on PRs that edit the lockfiles. There's probably some one-cel expression and patch magic we can do to achieve that.
Or disable hermetic on PRs altogether if we can't make it work. (but i don't like that much)

[dustymabe]

LGTM

[joelcapitao]

yeaaah so this is caused by how we hacked hermetic builds to work. Long story short, this package is not yet tagged into coreos-pool and will only be when this PR merges. So until then, hermetic build won't work.
@joelcapitao I think this has caused confusion multiples times already, so we should find a way to turn off hermetic builds on PRs that edit the lockfiles. There's probably some one-cel expression and patch magic we can do to achieve that.

This is a "not-yet-tagged-in-coreos-pool" issue but is the first time we hit this variant IIRC. In that case, we're adding a new set of packages. In the previous case c.f. coreos/fedora-coreos-tracker#2155, it was a race condition.
As we designed the Konflux hermetic build logic to rely only on the manifest lockfiles i.e we basically derive manifest lockfiles -> hermeto lockfiles, the next time I think we better have to 'abuse' on the override/fast-track mechanism:

1. in the PR, add the new set of packages in the manifest-lock.overrides.yaml. This will run the -override pipeline which download the RPMs in overrides/rpm c.f. https://gitlab.com/fedora/bootc/tekton-catalog/-/blob/27e2f87bc193815dbd7e7daac0299b3fcefd0b8c/tasks/prepare-build-context/prepare-build-context.yaml#L171
2. once the PR merged, the packages will be tagged, the classic on-push pipeline will pull it from the repo, and the build will continue
3. the Remove graduated overrides GH Action will remove them from manifest-lock.overrides.yaml during the next iteration

WDYT ?

[jbtrystram]

WDYT ?

Ah yeah, good idea! Sounds good