when mock host is fc37+ any el9 chroot is missing the rpmdb in /var/lib/rpm as symlink to sysimage is never written.

[prymar56]

Short description of the problem

rpmdb location is according to the mock host (/usr/lib/sysimage/rpm), but el9 still uses /var/lib/rpm

Output of rpm -q mock

mock-3.1-1.fc36.noarch

Steps to reproduce issue

1. mock -r alma+epel-9-x86_64 --init
2. ls -al /var/lib/mock/alma+epel-9-x86_64/root/var/lib/rpm -> /dev/null
3. ls -al /usr/lib/sysimage/rpm -> sqlite*
4. mock -r alma+epel-9-x86_64 --chroot 'rpm -qa | wc -l;' -> fails, returns 0

Any additional notes

This won't matter until user shells into the chroot or runs `mock -r mychroot --chroot 'some rpm cmd;'

[prymar56]

Once the chroot is available in /var/lib/mock, this command will workaround the problem: mock -r alma+epel-9-x86_64 --chroot 'cd /var/lib/; if [ -d rpm ]; then rm -rf rpm/ ; fi; ln -s /usr/lib/sysimage/rpm rpm ;'

I prefer a patch to mock sources that checks for rpmdb in both places if it exists in sysimage.

[xsuchy]

Indeed. On my F37:

 ls -ld /var/lib/rpm
lrwxrwxrwx. 1 root root 26  7. kvě 21.45 /var/lib/rpm -> ../../usr/lib/sysimage/rpm
$ ls /usr/lib/sysimage/rpm
rpmdb.sqlite  rpmdb.sqlite-shm  rpmdb.sqlite-wal

I think we may create /usr/lib/sysimage/rpm and symlink /var/lib/rpm to it. It should be safe to do that everytime. Even for older chroots.

[praiskup]

Is this F37+? I can not reproduce the behavior on my F36.

[praiskup]

$ ls -al /var/lib/mock/alma+epel-9-x86_64/root/var/lib/rpm
total 6460
drwxr-xr-x.  2 root root     120 May 18 05:44 .
drwxr-xr-x. 11 root root     220 Oct 10 10:47 ..
-rw-r--r--.  1 root root 6582272 Oct 10 10:47 rpmdb.sqlite
-rw-r--r--.  1 root root   32768 Oct 10 10:47 rpmdb.sqlite-shm
-rw-r--r--.  1 root root       0 Oct 10 10:47 rpmdb.sqlite-wal
-rw-r--r--.  1 root root       0 Oct 10 10:47 .rpm.lock
$ ls -al /usr/lib/sysimage/rpm
total 254344
drwxr-xr-x. 2 root root      4096 Aug  5 15:38 .
drwxr-xr-x. 3 root root      4096 Aug  9 15:57 ..
-rw-r--r--. 1 root root 260403200 Oct 10 08:43 rpmdb.sqlite
-rw-r--r--. 1 root root     32768 Oct 10 10:37 rpmdb.sqlite-shm
-rw-r--r--. 1 root root         0 Oct 10 08:43 rpmdb.sqlite-wal
-rw-r--r--. 1 root root         0 Mar 22  2022 .rpm.lock
$ mock -r alma+epel-9-x86_64 --chroot 'rpm -qa | wc -l;'
INFO: mock.py version 3.1 starting (python version = 3.10.7, NVR = mock-3.1-1.git.3448.b1ebac9.fc36)...
Start(bootstrap): init plugins
INFO: tmpfs initialized
INFO: selinux enabled
INFO: compress_logs: initialized
Finish(bootstrap): init plugins
Start: init plugins
INFO: tmpfs initialized
INFO: selinux enabled
INFO: compress_logs: initialized
Finish: init plugins
INFO: Signal handler active
Start: run
Start(bootstrap): chroot init
INFO: mounting tmpfs at /var/lib/mock/alma+epel-9-x86_64-bootstrap/root.
INFO: reusing tmpfs at /var/lib/mock/alma+epel-9-x86_64-bootstrap/root.
INFO: calling preinit hooks
INFO: enabled root cache
INFO: enabled package manager cache
Start(bootstrap): cleaning package manager metadata
Finish(bootstrap): cleaning package manager metadata
INFO: enabled HW Info plugin
Mock Version: 3.1
INFO: Mock Version: 3.1
Finish(bootstrap): chroot init
Start: chroot init
INFO: mounting tmpfs at /var/lib/mock/alma+epel-9-x86_64/root.
INFO: reusing tmpfs at /var/lib/mock/alma+epel-9-x86_64/root.
INFO: calling preinit hooks
INFO: enabled root cache
INFO: enabled package manager cache
Start: cleaning package manager metadata
Finish: cleaning package manager metadata
INFO: enabled HW Info plugin
Mock Version: 3.1
INFO: Mock Version: 3.1
Finish: chroot init
INFO: Running in chroot: ['rpm -qa | wc -l;']
Start: chroot ['rpm -qa | wc -l;']
190
Finish: chroot ['rpm -qa | wc -l;']

[xsuchy]

I think you need to have rpm 4.18 for that (which has been backported to F36 too)

[praiskup]

F36 is still on rpm 4.17.1.

[praiskup]

I must be missing something. I've upgraded my box to F37 (off-topic, but F36 => F37 like a charm!):

rpm-4.18.0-1.fc37.x86_64
mock-3.1-1.git.3447.7859429.fc37.noarch

And I see:

$ mock -r alma+epel-9-x86_64 --scrub=all && mock -r alma+epel-9-x86_64 --chroot 'rpm -qa | wc -l;'
...
INFO: Running in chroot: ['rpm -qa | wc -l;']
Start: chroot ['rpm -qa | wc -l;']
190
Finish: chroot ['rpm -qa | wc -l;']

[xsuchy]

I tried:

# mock -r alma+epel-9-x86_64 --init
# ls -ld /var/lib/mock/alma+epel-9-x86_64/root/var/lib/rpm 
drwxr-xr-x. 2 root root 4096 18. kvě 05.44 /var/lib/mock/alma+epel-9-x86_64/root/var/lib/rpm

i.e. the directory is not a symlink and contains the right data.

Cannot reproduce.

[xsuchy]

I just went through our code and we delete /var/lib/rpm/* and we create /var/lib/rpm/ if it does not exists. But we never symlink it. I am really curious how you may get symlink to /dev/null :(

[praiskup]

Just a blind idea, if I turn bootstrap off (--no-bootstrap-chroot), the RPM from F37 installs the EL9 chroot correctly - but then the RPM from EL9 isn't able to read the database (rpm -qa is empty, e.g.). rpm --rebuilddb doesn't help. This is though a low priority issue - the bootstrap is intentionally ON to avoid such problems.

[prymar56]

apologies, I should mention that my bootstrap flag is off, almost always.

On 10/12/22, Pavel Raiskup @.***> wrote:

Just a blind idea, if I turn bootstrap off (--no-bootstrap-chroot), the RPM from F37 installs the EL9 chroot correctly - but then the RPM from EL9 isn't able to read the database (rpm -qa is empty, e.g.). rpm --rebuilddb doesn't help. This is though a low priority issue - the bootstrap is intentionally ON to avoid such problems.

-- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/mock/issues/980#issuecomment-1275954412 You are receiving this because you authored the thread.

Message ID: @.***>

[praiskup]

OK, I'm closing this. The host's RPM stack is "too new" - it is expected that the database is not readable by the older RPM stack "in chroot". The bootstrap feature is here exactly for this; enabled default for quite some time. Patches are welcome, but this is a low-prio issue for our team and we don't have time for it (especially considering that the build itself shouldn't touch rpm database, for reentrancy problems).