Error: database libpod root directory (staticdir) does not match our libpod root directory (staticdir) #20872
Comments
|
Same on Fedora 39 Silverblue (I guess it’s expected since it affects Kinoite 39). |
|
What is the value of $HOME? |
|
Going through the git log #20088 looks like the only think which touched this area (although I cannot say for sure it caused this until I can reproduce). |
|
|
Yeah I think the issue is because of this, previously we did not expand the symlink and now we do. Thus our db logic thinks you changed the config and errors out. |
|
Does it work if you set |
|
We can probably fix this in the logic for checking the current config against the DB - eval symlinks on both paths (the one in the DB and the one we're trying to use) and compare the final paths. We'd need fixes for both Bolt and SQLite that way though |
|
reproducer on a not rpm-ostree system: |
Unfortunately I cannot test for now, I’ve rolled back my system (it’s my workstation). However, if I understand correctly, you’re now pretty sure this issue is due to symlink expansion and me confirming it doesn’t seem to be needed anymore. |
When Podman starts, it checks a number of critical runtime paths against stored values in the database to make sure that existing containers are not broken by a configuration change. We recently made some changes to this logic to make our handling of the some options more sane (StaticDir in particular was set based on other passed options in a way that was not particularly sane) which has made the logic more sensitive to paths with symlinks. As a simple fix, handle symlinks properly in our DB vs runtime comparisons. The BoltDB bits are uglier because very, very old Podman versions sometimes did not stuff a proper value in the database and instead used the empty string. SQLite is new enough that we don't have to worry about such things. Fixes containers#20872 Signed-off-by: Matt Heon <mheon@redhat.com>
|
#20874 to fix |
When Podman starts, it checks a number of critical runtime paths against stored values in the database to make sure that existing containers are not broken by a configuration change. We recently made some changes to this logic to make our handling of the some options more sane (StaticDir in particular was set based on other passed options in a way that was not particularly sane) which has made the logic more sensitive to paths with symlinks. As a simple fix, handle symlinks properly in our DB vs runtime comparisons. The BoltDB bits are uglier because very, very old Podman versions sometimes did not stuff a proper value in the database and instead used the empty string. SQLite is new enough that we don't have to worry about such things. Fixes containers#20872 Signed-off-by: Matt Heon <mheon@redhat.com>
When Podman starts, it checks a number of critical runtime paths against stored values in the database to make sure that existing containers are not broken by a configuration change. We recently made some changes to this logic to make our handling of the some options more sane (StaticDir in particular was set based on other passed options in a way that was not particularly sane) which has made the logic more sensitive to paths with symlinks. As a simple fix, handle symlinks properly in our DB vs runtime comparisons. The BoltDB bits are uglier because very, very old Podman versions sometimes did not stuff a proper value in the database and instead used the empty string. SQLite is new enough that we don't have to worry about such things. Fixes containers#20872 Signed-off-by: Matt Heon <mheon@redhat.com>
When Podman starts, it checks a number of critical runtime paths against stored values in the database to make sure that existing containers are not broken by a configuration change. We recently made some changes to this logic to make our handling of the some options more sane (StaticDir in particular was set based on other passed options in a way that was not particularly sane) which has made the logic more sensitive to paths with symlinks. As a simple fix, handle symlinks properly in our DB vs runtime comparisons. The BoltDB bits are uglier because very, very old Podman versions sometimes did not stuff a proper value in the database and instead used the empty string. SQLite is new enough that we don't have to worry about such things. Fixes containers#20872 Signed-off-by: Matt Heon <mheon@redhat.com>
When Podman starts, it checks a number of critical runtime paths against stored values in the database to make sure that existing containers are not broken by a configuration change. We recently made some changes to this logic to make our handling of the some options more sane (StaticDir in particular was set based on other passed options in a way that was not particularly sane) which has made the logic more sensitive to paths with symlinks. As a simple fix, handle symlinks properly in our DB vs runtime comparisons. The BoltDB bits are uglier because very, very old Podman versions sometimes did not stuff a proper value in the database and instead used the empty string. SQLite is new enough that we don't have to worry about such things. Fixes containers#20872 Signed-off-by: Matt Heon <mheon@redhat.com>
|
#20874 is still open. Is there a work-around? I tried to change HOME, but with no success. |
How did you change home? I set my home in /etc/passwd file. Also had to delete the containers folder in .local/share to reset the db config after I took backups of my container. |
When Podman starts, it checks a number of critical runtime paths against stored values in the database to make sure that existing containers are not broken by a configuration change. We recently made some changes to this logic to make our handling of the some options more sane (StaticDir in particular was set based on other passed options in a way that was not particularly sane) which has made the logic more sensitive to paths with symlinks. As a simple fix, handle symlinks properly in our DB vs runtime comparisons. The BoltDB bits are uglier because very, very old Podman versions sometimes did not stuff a proper value in the database and instead used the empty string. SQLite is new enough that we don't have to worry about such things. Fixes containers#20872 Signed-off-by: Matt Heon <mheon@redhat.com>
|
Setting Then set |
|
Looks like I timed it well to run into this.
Have just tried with the following file to no luck Have tried both combinations of home paths. |
|
Looks pile it is now complaining about volume path, also in containers.conf
(I think named volume_path but not sure?). Same procedure for the new error
but different key in containers.conf basically.
…On Sat, Dec 2, 2023 at 11:34 Ellis Kenyő ***@***.***> wrote:
Looks like I timed it well to run into this.
Setting static_dir in containers.conf is more likely to work. If your
error message is:
Error: database libpod root directory (staticdir) "/home/<user>/.local/share/containers/storage/libpod" does not match our libpod root directory (staticdir) "/var/home/<user>/.local/share/containers/storage/libpod": database configuration mismatch
Then set static_dir to the "database libpod root directory" (in this case
/home/<user>/.local/share/containers/storage/libpod)
Have just tried with the following file to no luck
image.png (view on web)
<https://github.com/containers/podman/assets/2872862/a69e326a-76ad-40c0-8281-6e6ac4a92072>
Have tried both combinations of home paths.
—
Reply to this email directly, view it on GitHub
<#20872 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AB3AOCFNHXPU3P7MGHWJ2LTYHNKC7AVCNFSM6AAAAABAC7ZUHKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQMZXGE4TOMZRGU>
.
You are receiving this because you were assigned.Message ID:
***@***.***>
|
Perfect! That works for podman at least For future finders my file looks like Now trying to access existing containers with distrobox I get an error like But I'm happy to take this elsewhere if it's not directly related to podman 😄 EDIT: Managed to rescue, turns out it was SELinux. Turning it off but not fully disabled allowed me to carry on using my old containers; thanks @mheon you're a life-saver 😄 |
When Podman starts, it checks a number of critical runtime paths against stored values in the database to make sure that existing containers are not broken by a configuration change. We recently made some changes to this logic to make our handling of the some options more sane (StaticDir in particular was set based on other passed options in a way that was not particularly sane) which has made the logic more sensitive to paths with symlinks. As a simple fix, handle symlinks properly in our DB vs runtime comparisons. The BoltDB bits are uglier because very, very old Podman versions sometimes did not stuff a proper value in the database and instead used the empty string. SQLite is new enough that we don't have to worry about such things. Fixes containers#20872 Signed-off-by: Matt Heon <mheon@redhat.com>
includes workaround for containers/podman#20872
includes workaround for containers/podman#20872
When Podman starts, it checks a number of critical runtime paths against stored values in the database to make sure that existing containers are not broken by a configuration change. We recently made some changes to this logic to make our handling of the some options more sane (StaticDir in particular was set based on other passed options in a way that was not particularly sane) which has made the logic more sensitive to paths with symlinks. As a simple fix, handle symlinks properly in our DB vs runtime comparisons. The BoltDB bits are uglier because very, very old Podman versions sometimes did not stuff a proper value in the database and instead used the empty string. SQLite is new enough that we don't have to worry about such things. Fixes containers#20872 Signed-off-by: Matt Heon <mheon@redhat.com>
|
Thank you very much! In my environment, there was no directory, not even containers.conf, but if I create the directory and file, it should be OK. |
|
I couldn't reproduce this on my Fedora 39 Silverblue: rishi@fedora:~$ podman version
Client: Podman Engine
Version: 4.8.0
API Version: 4.8.0
Go Version: go1.21.4
Built: Tue Nov 28 10:58:32 2023
OS/Arch: linux/amd64
rishi@fedora:~$
rishi@fedora:~$ echo $HOME
/var/home/rishi
rishi@fedora:~$ ... but clearly a lot of people can. Based on these two comments, I think this affects those who have been upgrading their installations in-place for a while. I usually reinstall once every year, and I remember that we changed the default value of |
Just changing the $HOME seems to not be enough. Perhaps there's a config file somewhere that I can edit? It's also strange it didn't happen after the rebase but just another version update... |
|
|
Does that workaround have any long-term consequences, or can we safely apply it temporarily until the fix lands? |
|
There are no consequences even after the fix lands. The two paths are symlinked together, we're just forcing another version be used when doing database checks. |
|
Oh good, thanks for explaining! |
|
I rebased from Fedora 39 Kinoite to Rawhide Kinoite to do some testing and this affects my ability to run a toolbox: |
github-actions
bot
added
the
locked - please file new issue/PR
Issue Description
Starting with version 4.8.0, I get the error below.
I'm on Fedora Kinoite 39. No problems with version 4.7.2.
Steps to reproduce the issue
Steps to reproduce the issue
Describe the results you received
Describe the results you expected
Container should start normally.
podman info output
Podman in a container
No
Privileged Or Rootless
Rootless
Upstream Latest Release
Yes
Additional environment details
Running of bare metal.
Additional information
None.
The text was updated successfully, but these errors were encountered: