As per discussion in #2905, reopening now.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2355#issuecomment-1943636423
You are receiving this because you are subscribed to this thread.
Message ID:
Reopened #2355.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2355#event-11800812040
You are receiving this because you are subscribed to this thread.
Message ID:
___
Rpm-maint mailing
Closed #2355 as completed.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2355#event-11165589193
You are receiving this because you are subscribed to this thread.
Message ID:
___
Rpm-maint
Anyway, it turns out this is not something we'll want to handle explicitly in
the RPM code as it's really OverlayFS-specific. I'll close the ticket now.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2355#issuecomment-1842511015
You
Oh... Indeed. Dunno what I was thinking. The correct workaround is this:
```
# cd /usr/lib/sysimage
# cp -r rpm rpm.temp # copy-up onto the upper layer
# mv rpm.temp rpm # move back to the original path so RPM can find it
# rpmdb --rebuilddb
```
Thanks for noticing!
--
Reply to this email
> FTR, the `mv(1)` command works around this by simply recursively copying the
> directory and removing the old one. Therefore, the workaround is as simple as
> doing:
>
> ```
> # cd /usr/lib/sysimage
> # cp -r rpm rpmold.1
> # rm -rf rpm
> # rpmdb --rebuilddb
> ```
these workaround steps make
FTR, the `mv(1)` command works around this by simply recursively copying the
directory and removing the old one. Therefore, the workaround is as simple as
doing:
```
# cd /usr/lib/sysimage
# cp -r rpm rpmold.1
# rm -rf rpm
# rpmdb --rebuilddb
```
--
Reply to this email directly or view it on
Related: https://github.com/rpm-software-management/rpm/pull/1754
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2355#issuecomment-1384170308
You are receiving this because you are subscribed to this thread.
Message ID:
Oh, right, right. The reason I encountered this issue in the first place is
that my lower tree contained an rpmdb, in fact, which was just a result of a
`dnf --installroot` call that populated it earlier. Indeed, removing it
afterwards (before creating per-test overlays) is what needs to be
Indeed. This is related to #1580.
> > Edit: hmm, in the test-suite case it should already be "pure upper" I think?
>
> Not really - the filesystem tree used by a test case is our "lower". Copying
> the database manually (outside of the container) to the "upper" directory
> should do the trick,
Just for future reference and/or any confused onlookers - the "test cases" we
mentioned above are in fact a WIP that's not on master yet. For those, the
"make the database a pure upper" workaround does the job, however for the usual
podman/docker use case, the issue remains.
--
Reply to this
> Yup, I know smile It's just that the original copy-up (`touch ...`) trick
> (also used by `dnf-plugin-ovl`) doesn't help in this `rename()` case. I
> wonder if something changed in the overlayfs implementation recently or
> whether it was always the case. Anyway,
Heh, to reply to myself:
Of
> Yep, this is the same old, many reports exist in various places.
Yup, I know :smile: It's just that the original copy-up (`touch ...`) trick
(also used by `dnf-plugin-ovl`) doesn't help in this `rename()` case. I wonder
if something changed in the overlayfs implementation recently or whether
Yep, this is the same old, many reports exist in various places.
For the purposes of the test-suite, can we not make the rpmdb a "pure upper"
directory. Move the underlying directory away to start with and then put it in
place from the upper layer?
--
Reply to this email directly or view it
Note that the `touch /var/lib/sysimage/rpm/*`
([formerly](https://fedoraproject.org/wiki/Changes/RelocateRPMToUsr)
`/var/lib/rpm/*` ), also discussed in
https://github.com/radiasoft/containers/issues/91), doesn't help.
--
Reply to this email directly or view it on GitHub:
Running `rpmdb --rebuilddb` in a Fedora 37 podman container results in the
following error:
```
error: failed to replace old database with new database!
error: replace files in /usr/lib/sysimage/rpm with files from
/usr/lib/sysimage/rpmrebuilddb.12 to recover
```
Investigating further with
16 matches
Mail list logo
