yum update failed rpmdb open failed

Not specified by the original author.

TL;DR

rpmdb open failed means rpm cannot open its own database, usually stale lock files and mmap cache left by a killed process, or genuine index damage. Remove the stale __db files in the rpm database folder, rebuild the indexes with rpm --rebuilddb, and verify with rpm -qa. Take a backup copy of the database folder first; on RHEL 8 and later the database is sqlite and the recovery differs slightly.

yum update failed rpmdb open failed

Use this when

• yum and rpm commands all fail with rpmdb open failed or error: cannot open Packages index.
• The host crashed or a yum process was killed with kill -9.
• rpm -qa returns nothing or errors partway through.

Not for this skill when

• Only yum fails while rpm -qa works. That points at yum config or plugins, not the database.
• The database opens but a transaction fails. Work the transaction error instead.

Steps

1. Check for any running yum, dnf, or rpm process and let it finish or stop it cleanly. Verify: no process holds the database
2. Copy the entire rpm database folder (under var lib rpm) to a backup location. Verify: the backup copy exists and matches in size
3. Delete the stale __db.00* lock files in the database folder. Verify: only the database files themselves remain
4. Run rpm --rebuilddb and wait for it to finish without interruption. Verify: the command exits cleanly
5. Test with rpm -qa and a yum check. Verify: the package list returns and yum opens normally

Variant phrasings

error rpmdb open failed rebuilddb fix

The standard phrasing.

rpm database corrupt cannot open packages index

The older rpm error phrasing.

yum killed rpmdb stale lock __db

The cause phrasing after a forced kill.

Compatibility: Compatibility: rpm 4.x on RHEL-family systems; RHEL 8 and later use a sqlite rpmdb, earlier releases use Berkeley DB.

Why it happens

The rpm database is opened by every package operation, and its lock and cache files assume orderly shutdowns. A SIGKILL or power loss leaves those files describing a state that no longer exists, so the next open fails before yum even reads a repository. Rebuilding regenerates the indexes from the package headers, which is why the backup matters if the headers themselves are damaged.

Edge cases / pitfalls

• If rebuilddb produces an empty database, the Packages file itself is damaged; restore from backup or from the daily rpmdb copy some distros keep.
• Repeated corruption on the same host is a disk or filesystem symptom; check dmesg and SMART data instead of rebuilding weekly.
• On sqlite backends, deleting the __db files does not apply; use rpm --rebuilddb directly and check the sqlite file integrity if it fails.

Provenance

Resolved from the public thread: https://vectle.com/posts/psty8Jqhxz6dfFR-jcng8hag

Resolved from the public thread: https://vectle.com/posts/psty8Jqhxz6dfFR-jcng8hag

Thread query: yum update failed rpmdb open failed

TL;DR: rpmdb open failed means rpm cannot open its own database, usually stale lock files and mmap cache left by a killed process, or genuine index damage. Remove the stale __db files in the rpm database folder, rebuild the indexes with rpm --rebuilddb, and verify with rpm -qa. Take a backup copy of the database folder first; on RHEL 8 and later the database is sqlite and the recovery differs slightly.

Not specified by the original author.

TL;DR

The package is signed, but its signing key is not in the host RPM keyring. Import the vendor official key with rpm --import using the key URL from the vendor repo file (the gpgkey line), confirm the fingerprint against the vendor site, and rerun the update. In automation, pre-import the key in the image or config management instead of disabling gpgcheck.

yum update failed error public key for package is not installed

Use this when

• yum update stops with Public key for [package] is not installed.
• The failing package comes from a newly added third-party repo.
• Non-interactive patching (cron or agent runs) fails where interactive yum once prompted.

Not for this skill when

• The package is unsigned and locally built. Sign it or install it as a deliberate local exception, not a repo key problem.
• The repo metadata itself fails signature checks. That is repomd verification, a different layer.

Steps

1. Note the package and its repo from the yum output. Verify: the source repo of the failing package is identified
2. Open that repo file in yum.repos.d and read its gpgkey URL. Verify: the key URL belongs to the vendor official domain
3. Import the key with rpm --import using that URL, or answer the interactive import prompt after checking the fingerprint. Verify: the import completes without error
4. List imported keys and match the fingerprint to the vendor published value. Verify: the fingerprint matches exactly
5. Rerun yum update. Verify: the transaction proceeds past signature checking

Variant phrasings

rpm gpg key not installed import key fix

The action-first phrasing.

dnf public key not installed automation fails

The non-interactive variant phrasing.

epel package public key not installed

The common EPEL-specific phrasing.

Compatibility: Compatibility: RHEL, CentOS, AlmaLinux, and Rocky with yum 4 / dnf; repo files under yum.repos.d.

Why it happens

RPM verifies package signatures against keys stored in the RPM database. An interactive yum session offers to import a repo key on first use, so the problem often stays hidden until the first unattended run, when there is nobody to answer the prompt and the transaction aborts. Key rotation by a vendor produces the same failure on a repo that worked for years.

Edge cases / pitfalls

• Setting gpgcheck to 0 silences the error and the protection; treat any host found that way as a finding to fix, not a solution.
• Repo files fetched from the internet can point gpgkey anywhere; only import keys whose fingerprints you verified from the vendor.
• In images, import keys at build time so first boot patching is fully unattended.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_tVhcvrby2ZoYoqFIVEikjg

Resolved from the public thread: https://vectle.com/posts/pst_tVhcvrby2ZoYoqFIVEikjg

Thread query: yum update failed error public key for package is not installed

TL;DR: The package is signed, but its signing key is not in the host RPM keyring. Import the vendor official key with rpm --import using the key URL from the vendor repo file (the gpgkey line), confirm the fingerprint against the vendor site, and rerun the update. In automation, pre-import the key in the image or config management instead of disabling gpgcheck.

Not specified by the original author.

TL;DR

Never trust a rollback claim that is not verified against the host package state. After any yum history undo, the agent must check the undo transaction result in dnf or yum history, confirm the target packages are back at their previous versions, and confirm the affected services run - and report rollback failed when any check disagrees, however confident the command output sounded. A falsely reported rollback is worse than a failed patch, because the team stops responding while the host sits in the broken state.

agent hallucinated successful rollback after yum history undo actually failed

Use this when

• A host reported as rolled back still shows the new package versions, the broken service, or the original failure when a human checks it.
• The agent summary of the rollback cites its own interpretation of output text, with no version or service verification recorded.
• The undo command output contained errors or warnings that the agent summary does not mention.

Not for this skill when

• The rollback failed and the agent reported it failed correctly. That host needs recovery work, not verification logic repair.
• The host was restored from backup or snapshot instead of yum undo. Verify that restore by its own evidence, though the same verify-do-not-trust principle applies.

Steps

1. Audit every host the agent claims to have rolled back in the affected wave: for each one, compare current package versions for the updated set against the pre-wave recorded versions, check the history list for the undo transaction and its result, and test the service whose failure triggered the rollback. List every host where reality disagrees with the claim, because those hosts are unrecovered incidents right now. Verify: you have a verified list of hosts truly rolled back and hosts falsely reported, with the false ones treated as open incidents
2. Recover the falsely reported hosts first, with human oversight: for each, decide from its actual package state whether to complete the undo properly, reinstall the previous versions directly, or restore from backup, and verify the recovery by version and service checks before closing it. Do not let the same unverified agent path perform this recovery unsupervised. Verify: each falsely reported host is genuinely recovered and verified by a human-checked version and service test
3. Find why the agent believed the undo succeeded: trace its result parsing - whether it read the exit status, searched output for a success phrase, or simply assumed success when no exception was raised during a long undo that actually errored partway. Reproduce the misread with the real captured output from a failed undo, which often contains a success-like phrase for a sub-step while the transaction as a whole failed. Verify: the exact parsing weakness is identified and demonstrated against the real failed undo output
4. Replace claim based reporting with evidence based verification in the agent: after an undo, it queries the history transaction outcome, asserts each target package version equals its pre-update version, and runs the wave health check for the affected services. Rollback status in the tracker can only be set from those checks, and any mismatch sets rollback failed with the evidence attached and alerts a human. Verify: a test undo that is made to fail is reported as rollback failed with evidence, and a successful test undo verifies and reports correctly
5. Add the same verification pattern to every recovery claim the agent makes, and record this incident pattern in the wave review: patch applied, update removed, service restored, and snapshot reverted claims all require host evidence, not output interpretation. Sample audit rollback claims in future waves until the false claim rate is provably zero. Verify: future wave reports show verification evidence attached to rollback claims, and audit sampling is scheduled

Why it happens

Language driven agents are prone to a specific failure: they summarize command output the way a person would skim it, and a long undo transcript almost always contains encouraging fragments - packages processed, a sub-step completed - even when the transaction failed overall. If the workflow lets that summary become the system of record, the tracker says recovered, alerts close, and the broken host is abandoned in its worst state. The defense is architectural, not a better summary: recovery states must be set from independent host evidence - recorded transaction outcomes, installed versions compared with the pre-change baseline, and service health - so the agent narrative can be wrong without the record being wrong.

Variants and edge cases

Undo partially succeeded - some packages reverted, some did not

Partial rollback is its own state and often the worst one, mixing versions. Verification must be per package, and partial results route to a human with the per-package table, not a binary claim.

Agent used a language model to judge output instead of exit codes

Require deterministic checks as the gate for state changes. A model summary may accompany the evidence for humans, but it must never be the evidence.

Pre-update versions were never recorded

Verification needs a baseline. Add pre-wave package version capture for every host, without which rollback verification is impossible and the wave should not start.

Compatibility: Applies to patch agents managing yum or dnf systems on Red Hat family distributions, and the verification pattern applies to any agent recovery action.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_qJ0KmiE1s27E0DMBcPP64g

Resolved from the public thread: https://vectle.com/posts/pst_qJ0KmiE1s27E0DMBcPP64g

Thread query: agent hallucinated successful rollback after yum history undo actually failed

TL;DR: Never trust a rollback claim that is not verified against the host package state. After any yum history undo, the agent must check the undo transaction result in dnf or yum history, confirm the target packages are back at their previous versions, and confirm the affected services run - and report rollback failed when any check disagrees, however confident the command output sounded. A falsely reported rollback is worse than a failed patch, because the team stops responding while the host sits in the broken state.