On a server running fedora F43 with the updates-testing repository enabled, I’ve updated to podman 5.7.0 (rpm file podman-5.7.0~rc1-1.fc43.x86_64). Whenever I run a podman command, I now get a warning:
“The deprecated BoltDB database driver is in use. This driver will be removed in the upcoming Podman 6.0 release in mid 2026. It is advised that you migrate to SQLite to avoid issues when this occurs. Set SUPPRESS_BOLTDB_WARNING environment variable to remove this message.”
My searching hasn’t yet found a step by step guide as to how to migrate from BoltDB to SQLite. Is this process documented anywhere?
General gist would be to export the data from BoltDB as CSV or JSON and the import that into sqlite. I’ve no idea what BoltDB supports as export formats, but at a basic level, straight SQL could be used.
We (Podman) do not (yet?) have a official guide to migrate. The general way to do that is to run podman system reset which deletes everything and then the next command will create/use the sqlite backend.
Most likely there will be no automatic migration so removing and recreating the resources will be required. Botldb is not a SQL based database so there is no trivial migration.
While a migration command/script could likely be written spending time on that has not been prioritized in our team so I would not count on waiting for that. Though if someone wants to contribute that I would suggest to reach out to us on github upstream
Thanks for the response (and apologies it’s taken so long for me to reply).
podman-system-reset — Podman documentation suggests system reset really does delete everything (including volumes that, at least in my case, have data in them that I wouldnt want to recreate). I don’t mind having to redownload the containers and recreate the various pods and networks, but is there a way to preserve the volumes during the ‘“migration”?
The volume metadata is part of the db so they will be lost and deleted by reset. The only thing you can do is to manually move the contents of your volume dir, e.g. ~/.local/share/containers/storage/volumes/, where the data is stored somewhere else not under the storage dir, then run system reset and move the dir back in. Then you still have to recreate the volumes with the right names and other options they used but it will pick up the underlying data if the name matches.
So you’re saying that the podman database migration (which will be necessary before podman 6.0 arrives) basically forces you to recreate all containers and volumes from scratch? Wow.
If, say, you had installed paperless-ngx as a podman pod ( GitHub - jdoss/ppngx: Podman + Paperless NGX ) and had several thousand tagged documents in a podman volume, is the official advice to just delete that volume and recreate it, re-import the documents and spend many happy hours re-tagging all the documents? That doesnt really sound like a “migration”
Like I wrote above already the db only hold the metadata, you can move the volume data dir out and after the reset back in and recreate the volumes with the same names that should pick it up.
If you have the extra storage you can also use podman volume export and then afterwards import though that would be quite slow for large volumes.
To be clear here I am not saying I like this, I merely describe the situation as it is today. A migration command/script would of course be nice but someone needs to spend the time to write and test that and at least this quarter it was not prioritized in the team. So if anyone likes to see that I would encourage them to contribute upstream. (At the very least start by filling a proper feature request for it).
Because frankly we have no idea how many people are still on boltdb, sqlite was made the default 2 years ago so the assumption on our end is that most people are already on the sqlite backend.
I’ve been upgrading my Fedora for many releases and I’ve used podman for > 2 years, so yeah, I’m still on boltdb (never heard of it before yesterday when the warning appeared).
I can’t say how many people are like me, but there is surely some amount of podman users who haven’t reinstalled in the last two years.
I’m not trying to shoot the messenger, and appreciate you taking the time to explain the situation.
The assumption that the default has been sqlite for 2 years so very few people will be impacted seems a little suspect to me.
My biggest concern is that adding a warning message telling impacted users to migrate to sqlite without telling them how to migrate to sqlite isnt overly helpful.
FYI - You can view the contents of the boltdb store
go install github.com/boltdb/bolt/...@latest
go get github.com/boltdb/bolt
see - https://github.com/chilts/boltdb-dump
I wasn’t able to get: go get -u github.com/chilts/boltdb-dump to work so I copied the boltdb-dump.go and executed go run bolddb-dump.go got the following:
go run boltdb-dump2.go ~/.local/share/containers/storage/libpod/bolt_state.db
[all-ctrs]
[allPods]
[allVolumes]
7dc4b0472fd9c3f702fac150a59c6508ba5cb9faf0c680b3a62059ae83460aeb
7dc4b0472fd9c3f702fac150a59c6508ba5cb9faf0c680b3a62059ae83460aeb
[ctr]
[exec]
[exit-code]
7937ba26476b510a4bc7a771cbaa9a72a223ac30c8a8b4940b6a4c8dbc2c0fa9
137
[exit-code-time-stamp]
7937ba26476b510a4bc7a771cbaa9a72a223ac30c8a8b4940b6a4c8dbc2c0fa9
2025-11-24T11:08:30.427111839-08:00
[id-registry]
[name-registry]
[ns-registry]
[pod]
[runtime-config]
graph-driver-name
overlay
graph-root
/home/daveo/.local/share/containers/storage
os
linux
run-root
/run/user/1000/containers
static-dir
/home/daveo/.local/share/containers/storage/libpod
tmp-dir
/run/user/1000/libpod/tmp
volume-path
/home/daveo/.local/share/containers/storage/volumes
[vol]
[7dc4b0472fd9c3f702fac150a59c6508ba5cb9faf0c680b3a62059ae83460aeb]
config
{"name":"7dc4b0472fd9c3f702fac150a59c6508ba5cb9faf0c680b3a62059ae83460aeb","lockID":3,"labels":{},"volumeDriver":"local","mountPoint":"/home/daveo/.local/share/containers/storage/volumes/7dc4b0472fd9c3f702fac150a59c6508ba5cb9faf0c680b3a62059ae83460aeb/_data","createdAt":"2025-06-03T14:28:40.35862037-07:00","isAnon":true,"uid":0,"gid":0,"size":0,"inodes":0,"mountlabel":"system_u:object_r:container_file_t:s0:c489,c669"}
state
{"mountCount":0,"notYetMounted":true,"notYetChowned":true,"uidChowned":1000,"gidChowned":1000}
[vol-dependencies]
bdd9f5f7e8964ef43742d7c050d63c11c1d1758d9836e3875928f46fa7e3a452
bdd9f5f7e8964ef43742d7c050d63c11c1d1758d9836e3875928f46fa7e3a452
[volume-ctrs]
I can confirm that a migration path is needed. I use podman both on my work and personal laptops for development, and I have a good list of container volumes allowing me to switch quickly between projects.
Both laptops have around 3 years, still relevant for development, and have boltdb as podman backend.
I’m not even looking at some servers that could be impacted as well (especially coreos type of server that auto update, the automated switch to podman 6.0 will require manual intervention).
Probably, most people using podman since more than 2 years are impacted in one way or another.
Hi! Longtime podman user . I always tried to stay up-to-date, but it looks like I missed one of my home systems and this issue just hit me by surprise.
I have no volumes or long-running containers, but I do have critical (to me) local images. Here’s my recipe for preserving those images:
$ for i in $(podman images --format '{{.Repository}}:{{.Tag}}');do f=$(echo $i | sed 's;[/:];-;g'); podman save -o $f.tgz $i;done
...
$ podman system reset ! yes this was very scary and I had to rm -rf stuff as root
...
$ for i in *.tgz;do podman load -i $i;done
I do agree that a migration path would be welcome. This was an unwanted surprise to me, and quite possibly to other longtime users.
Thanks for all your continuing work on this wonderful tool!
podman user and red hatter here, so I can chime in that this change is an inconvenience for sure as I have a lot of containers running, and the fact that the usual strategy of “podman reset” blows away all the images, meaning I have to rebuild the local-only ones or save them out to a registry somewhere and re-get them, this is all a pretty big bump. But this is just my local home stuff plus some CI for my OSS projects, I’ll manage, but I think this is going to be a big deal for a lot of people. I think an easier migration path is going to be needed and im sure in a few weeks there will be more turnkey guides to how to do this here.
I’ve neen using Fedora since the first release of Red Hat and podman since the first release in Fedora too. I have plenty of machines running pods and I don’t thik it’s advisable to just update without an automatic migration path,. This is exactly what Fedora has to provide to the community and I am sure they will.
No migration path would mean I stay on the 5.x version for a very long time. I have hundreds of volumes and hundreds of different pods/containers. Sure, the podman team doesn’t owe me anything as I am a free user, so I am not really complaining (well, at least until this change hits RHEL).
So in such case if all containers, pod, volumes are removed you could just rm the old boltdb file. And then the next command should create the sqlite db.
. I always tried to stay up-to-date, but it looks like I missed one of my home systems and this issue just hit me by surprise.