[SOLVED] Error: rpmdb open failed

[jmacdougca]

Code: Select all

rpmdb -rebuilddb

Code: Select all

rpmdb: only one major mode may be specified

I moved

Code: Select all

/var

to a lvm

Code: Select all

nvmeVg

and when I

Code: Select all

yum update

I get

Code: Select all

error: db5 error(11) from dbenv->open: Resources temporarily unavailable
error: cannot open Packages index using db5 - Resources temporarily unavailable (11)
error: cannot open Packages database in /var/lib/rpm
CRITICAL:yum.main:

When I run

Code: Select all

yum clean headers

I get the same error above.
So I looked in

Code: Select all

 /var/lib/rpm

and saw

Code: Select all

contains Basenames Conflictname __db.001 Dirnames Group Installtid Name Obsoletename Packages Providename Requirename Sha1header Sigmd5 Triggername

then

Code: Select all

mv __db.001 /tmpRpm

directory and ran

Code: Select all

rpmdb -rebuilddb

and got

Code: Select all

rpmd: only one major mode may be speficied

I posted on unix.stackechange before posting here and tried researching the Google Abyss as well.

[sml]

It's a GNU-style option, use double-dash: rpmdb --rebuilddb

[jmacdougca]

Thanks that got me to the next step.
Originally /var was 50G. When I moved /var to nvmeVg I increased the size with

Code: Select all

lvextend -L+25G /dev/mapper/nvmeVg-var

then tried

Code: Select all

rpmdb --rebuild

then got

Code: Select all

error: failed to create directory /var/lib/rpmrebuilddb.21957: No space left on device

Odd...Something process must be creating a log or something taking up space so I increase another +25G and boom right away /var is 100% full. So surely some log process I am thinking must be taking up all the space.

[TrevorH]

How did you copy the data and do you still have the original because it sound like something went wrong and you should start over. Your rpm database should not be corrupted just by moving it to a different device/filesystem.

[jmacdougca]

This is the best answer I can provide.

So what I did, was make a Logical Volume on nvmeVg, then formatted and mounted it on a temporary mount point, (note, that I was in single-user mode (aka recovery mode) at the time), then I copied the data in

Code: Select all

/var

, then stored on

Code: Select all

/

, to the new logical volume... after that, I removed the stuff in the original copy of

Code: Select all

/var

(it was like 25g). then mounted the new logical volume on

Code: Select all

/var

, and adjusted

Code: Select all

/etc/fstab

Another colleague suggested I restart. I do have a backup. I don't mind continuing the repair path as I am learning alot but wise enough to pivot if needed.

[TrevorH]

If you copied all the files to a temporary mount point then all the selinux contexts will have been reassigned and will be wrong based on the location they were when you ran the copy. Run restorecon -RFV /var to fix them all. Though that still doesn't explain why the rpm db is corrupted.

[jlehtone]

Note: https://docs.centos.org/en-US/centos/in ... scheme-x86 writes:

If /usr or /var is partitioned separately from the rest of the root volume, the boot process becomes much more complex because these directories contain components critical to it. In some situations, such as when these directories are placed on an iSCSI drive or an FCoE location, the system can either be unable to boot, or it can hang with a Device is busy error when powering off or rebooting.

This limitation only applies to /usr or /var, not to directories below them. For example, a separate partition for /var/www will work without issues.

[jmacdougca]

Thanks. I have SELinux set to permissive intentionally for the time being.

I notice "lsblk" /var is 125G at block level. but "df -t" /var is 50G because its a partition file system. I have to put a bigger block device same size partition

So I

Code: Select all

resizefs /dev/nvmeVg/var/

which removed the disk space issue. and successfully rebuilt using

Code: Select all

rpmdb --rebuilddb

*dances like no ones watching*