A systems administrator installs a simple package, but the Linux system returns the following error: rpmdb . To verify if there is a problem in the RPM database, the systems administrator runs the…

Question

Exhibit

Options

• Acd/var/lib/rpm; rpm --rebuilddb ; rm -f _db*; yum clean all
• Bcd/var/lib/rpm; rpm -qd; rpm --rebuilddb; yum clean all
• Ccd/var/lib/rpm; rpm -qa; rm -f _db*; yum clean all
• Dcd/var/lib/rpm; rm -f _db*; rpm --rebuilddb; yum clean all

• A
  3% (1)
• B
  7% (2)
• C
  17% (5)
• D
  73% (22)

Explanation

When the RPM database is corrupted, the proper recovery sequence is: (1) navigate to /var/lib/rpm where the database files live, (2) remove the corrupted lock/database files using 'rm -f _db*', (3) rebuild the database with 'rpm --rebuilddb', and (4) clean the yum cache with 'yum clean all'. Order matters critically here. Option A incorrectly runs --rebuilddb BEFORE removing the corrupt _db* files, meaning the rebuild may fail or use corrupted data. Option B uses 'rpm -qd' (which lists documentation files) as a diagnostic step, which is irrelevant to repair. Option C uses 'rpm -qa' (list all packages) before removing files but never rebuilds the database. Only option D follows the correct sequence: remove corrupted files first, then rebuild, then clean.

No community discussion yet for this question.