Bug 1815991
Summary: | can't update named volume path | ||
---|---|---|---|
Product: | Red Hat Enterprise Linux 8 | Reporter: | jajeon |
Component: | podman | Assignee: | Jindrich Novy <jnovy> |
Status: | CLOSED ERRATA | QA Contact: | atomic-bugs <atomic-bugs> |
Severity: | high | Docs Contact: | |
Priority: | unspecified | ||
Version: | 8.1 | CC: | bbaude, dornelas, dwalsh, jligon, jnovy, kanderso, lsm5, mheon, tsweeney, ypu |
Target Milestone: | rc | ||
Target Release: | 8.2 | ||
Hardware: | All | ||
OS: | All | ||
Whiteboard: | |||
Fixed In Version: | podman-1.9.3 and newer | Doc Type: | If docs needed, set a value |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2020-07-21 15:31:55 UTC | Type: | Bug |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: | |||
Bug Depends On: | |||
Bug Blocks: | 1186913, 1793607 |
Comment 1
Daniel Walsh
2020-03-23 12:52:48 UTC
To expand a bit: This is a protection to prevent accidental corruption of Podman's state. If there were any volumes present when this directory was changed, the volumes (and all their contents) would be lost as we changed to the new directory, and any containers using them could be pointing to the wrong directory. We require that changes to core Podman paths be done in company with a reset of Podman's state to ensure that such things do not happen. There is there no "reset" command available from podman. ># podman system reset >Error: unrecognized command `podman system reset` >Try 'podman system --help' for more information. Is there any other way to change named volume path? If this is to prevent accidental corruption, what is the reason of having configuration file? Also, if that's the reason, why allowing anonymous volume change by just modifying configuration file? -- for root user ># grep root /etc/containers/storage.conf | grep -v '#' >runroot = "/vol1" >graphroot = "/vol1" -- for rootless >$ grep root ~/.config/containers/storage.conf > runroot = "/tmp/run-1001" > graphroot = "/home/t1/test" Ok the version of podman you have is before that was added. rm -rf ~/.local/share/containers ~/.config/containers Should be close the the equivalent. I think path that you provided is for rootless user. Customer is trying to update "volume_path" from /usr/share/containers/libpod.conf which is "root" user. The directories would be /var/lib/containers/storage and /var/run/libpod then. Addressing earlier comments - the configuration file can be used for initial configuration of critical paths, but unfortunately cannot be used to change said paths once Podman has been run and containers created without a serious risk of non-intuitive breakage of containers, hence the error you've seen here. There is a potential improvement where we could allow rewrite of these paths if and only if no containers, pods, and volumes were present on the host (as the user running Podman, at least) which would eliminate the need for complete removal of directories of `podman system reset` I was able to update "volume_path" after removing bolt_state.db file. Could you check this is good enough or I need to remove all the files under /var/lib/containers/storage and /var/run/libpod. # podman images Error: Could not get runtime: database volume path "/var/lib/containers/storage/volumes" does not match our volume path "/test": database configuration mismatch # rm /var/lib/containers/storage/libpod/bolt_state.db rm: remove regular file '/var/lib/containers/storage/libpod/bolt_state.db'? y # podman images REPOSITORY TAG IMAGE ID CREATED SIZE # podman info |grep -i vol VolumePath: /test Can you let me know when "podman system reset" will be available? I was able to find the github PR as below. https://github.com/containers/libpod/pull/4558 However, version that I'm using is the latest available version from RHEL8 repository. https://access.redhat.com/downloads/content/rhel---8/x86_64/7441/podman/1.6.4-2.module+el8.1.1+5363+bf8ff1af/x86_64/fd431d51/package We release new versions of Podman every 12 weeks. The 1.6.4 is being released now for RHEL8.2 Which means we will update the next release in the summer. RHEL 8.2.1 release. Will probably be podman 1.8.2 or newer. Removing the boltdb database is sufficient so long as there are no containers and no volumes on the system when it is removed. Otherwise, you will end up with shadow containers/volumes that prevent the names of the old volumes and containers from being reused, and that cannot be easily removed. Fixed in rhel8.2.1 release I believe. Assigning to Jindrich just in case there's any packaging needs, but as this was in Podman 1.14.9, I don't believe there's anything further necessary. Test with podman-1.9.3-2.module+el8.2.1+6867+366c07d6.x86_64. "podman system reset" makes the volume path be update based on the libpod.conf. So set this to verified. Details: # podman system reset WARNING! This will remove: - all containers - all pods - all images - all build cache Are you sure you want to continue? [y/N] y # podman info |grep volume volumePath: /test Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHSA-2020:3053 |