Description of problem: Podman is completly broken on Silverblue. I did not do anything, but just tried to use podman. It throws me the error shown below or is just stuck and does not continue. Version-Release number of selected component (if applicable): podman version 2.1.1 ostree://fedora:fedora/33/x86_64/silverblue Version: 33.20201207.0 (2020-12-07T01:04:03Z) How reproducible: Always. Steps to Reproduce: Run podman login or basically any other command. Actual results: $ podman login … ERRO[0000] User-selected graph driver "vfs" overwritten by graph driver "overlay" from database - delete libpod local files to resolve Expected results: No error? Additional info: I did not change anything. I've set `REGISTRY_AUTH_FILE`, but that should not affect the whole system. Podman could be used a few months ago. I did not test it in the meantime, but now everything fails. So I've obviously looked that up and found e.g. this: https://github.com/containers/podman/issues/7501 https://github.com/containers/podman/issues/7396 Nothing helped. E.g. I could delete (move) ~/.local/share/containers, but of course I 1. don't want to loose all my container and b) it actually sometimes shows a different behaviour: When I simply run a "podman ps" it shows me an empty terminal. It get's stuck. No output, nothing. It also does not exist though (unless I Ctrl+C it, of course.) Also tried configuring ~/.config/containers/storage.conf, but I don't know what to set there. Just work as usual in Silverblue. I don't know or care what storage driver you use. :D Even toolbox fails fundamentally: toolbox list Error: failed to get the Podman version Unfortunately podman info --debug is also broken. (Does not output anything/does not exist) Only podman -v works.
Reported upstream: https://github.com/containers/podman/issues/8705 Funnily even `podman version` does not work, while `podman -v` does.
Also opened discussion in Fedora commmunity forum: https://discussion.fedoraproject.org/t/podman-broken-on-silverblue-podman-complains-about-overwritten-graph-driver-and-wants-libpod-to-be-deleted/25403?u=rugk BTW, I can see it re-creates the $HOME/.local/share/containers dir when I start it though. Actually, only one file is created though: $HOME/.local/share/containers/storage/libpod/bolt_state.db
Oh after a system upgrade and reboot, that included an update of podman: ``` podman 2:2.1.1-12.fc33 -> 2:2.2.1-1.fc33 podman-plugins 2:2.1.1-12.fc33 -> 2:2.2.1-1.fc33 ``` I now get a slightly different error message: ``` $ podman version ERRO[0000] 'overlay' is not supported over extfs at "/var/home/rugk/.local/share/containers/storage/overlay" Error: kernel does not support overlay fs: 'overlay' is not supported over extfs at "/var/home/rugk/.local/share/containers/storage/overlay": backing file system is unsupported for this graph driver ``` Note this still seems to be the default option. Also funny, if I rerun this, I only get the error message (no `ERRO[0000]` is displayed anymore (which is useless anyway and I don't even get what this tries to tell me TBH. Looks like the strange and useless error codes you know from Windows :stuck_out_tongue_winking_eye:): ``` $ podman version Error: kernel does not support overlay fs: 'overlay' is not supported over extfs at "/var/home/rugk/.local/share/containers/storage/overlay": backing file system is unsupported for this graph driver ```
Changing the settings fixes that. `~/.config/containers/storage.conf` needs to be like this: ``` [storage] driver = "overlay" [storage.options] mount_program = "/usr/bin/fuse-overlayfs" ``` However, something seems to be changed in the latest Silverblue version, as this error likely should not happen by default. So maybe you want to change the default config?
That file should just not be there, which is the default. The problem was having that file in the homedir in the first place and that file not declaring the driver
The bug initially happened **without any file** IIRC. But I see now that if I remove that file, it does work too. If I just comment **all lines** in the file with # it does show an error though, which is very unexpected.
Well the default behaviour is only executed if there is no storage.conf in the users homedir. The thought is, if the user creates storage.conf in their homedir, then they should create the storage.conf fully. If they don't specify a driver, we will default to "overlay" but we will not define any additional storage options, including mount_program.