Bug 2413547
| Summary: | rpm --checksig cannot run in parallel to dnf reinstall | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Christoph Karl <pampelmuse> |
| Component: | rpm | Assignee: | Packaging Maintenance Team <packaging-team-maint> |
| Status: | CLOSED UPSTREAM | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | low | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 43 | CC: | igor.raits, mdomonko, packaging-team-maint, pmatilai |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | --- | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2025-11-18 14:46:51 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
|
Description
Christoph Karl
2025-11-08 14:20:26 UTC
Do the signatures actually check out if that parallel 'dnf reinstall bash' is not done? Is the find/checksig command run as a regular user or root? What errors is the signature checking getting (try adding -v to the --checksig command) Yes, all signatures are OK without 'dnf reinstall bash'. find/checksig is done as regular user, dnf as root. I am still trying to reproduce this with rpm --checksig -v I get the following with -v:
OK run:
./g/golang-github-elithrar-simple-scrypt-devel-1.3.0-23.fc43.noarch.rpm:
Header OpenPGP V4 RSA/SHA256 signature, key fingerprint: c6e7f081cf80e13146676e88829b606631645531: OK
Header SHA256 digest: OK
Payload SHA256 digest: OK
Not OK run: (with parallel dnf reinstall):
./g/golang-github-elithrar-simple-scrypt-devel-1.3.0-23.fc43.noarch.rpm:
Header OpenPGP V4 RSA/SHA256 signature, key ID 829b606631645531: NOKEY
Header SHA256 digest: OK
Payload SHA256 digest: OK
It seem this problem is only sporadic.
Right. This would be related to transaction and/or database locking. The reinstall needs an exclusive lock for a while, and a regular user doesn't have the permission to do db-level locking so there's always going to be issues with concurrent user queries. But in this case I suspect it's the transaction lock which the keyring read momentarily grabs, and getting that will fail while the reinstall transaction is in progress. So whenever xargs decides to spin a new rpm command, there's a race with the reinstall process. The keyring read should arguably wait for the lock instead of just giving up and failing (there should be an error message about this somewhere in your output), but this case probably runs into the heuristic that it only waits for the lock on interactive use (when stdin is a tty, which it isn't here). So there's a bug (or a few) in there quite clearly, what we can do about it is less clear. Thanks for the report though. I'll move this ticket upstream because this is not Fedora specific. Thank you very much for your effort. Looking forward what upstream will tell about this issue. I'm the upstream devel lead, so see above :D |