F44 Change Proposal: Podman6 [SelfContained]

Project Discussion Change Proposals
, ,
1

Podman6

Wiki

Announced

This is a proposed Change for Fedora Linux.
This document represents a proposed Change. As part of the Changes process, proposals are publicly announced in order to receive community feedback. This proposal will only be implemented if approved by the Fedora Engineering Steering Committee.

Summary :open_book:

This proposal introduces Podman 6.0, a new major version of the container management tool, into Fedora 44. This update includes significant API and CLI breaking changes, new functionality, and the final removal of deprecated components including slirp4netns, cgroups v1, and the BoltDB backend.

Owner :open_book:

Detailed Description :open_book:

This change will update the podman package to version 6.0, which incorporates several major architectural changes and finalizes previously announced deprecations.

Key technical changes include:
Removal of Deprecated Code: The code for several deprecated components will be fully removed.

  • slirp4netns: Replaced by Pasta, which became the default rootless networking option in Podman 5.0.
  • CgroupsV1: Podman 6.0 will no longer support cgroups v1; all related code and tests will be removed.
  • BoltDB: The BoltDB database backend, replaced by SQLite as the default in Podman 4.8, will be removed. A deprecation notice has been added to Podman 5.7 to warn users. Users should first upgrade to Podman 5.8 first (will be release on all active Fedora releases) and reboot before upgrading to Podman 6 to ensure migration. Refer to [ BoltDB Database Migration this blog post] for details on BoltDB to SQLite migration.
  • ā€“network-cmd-path: This option, only used by slirp4netns, will also be removed.
    Configuration File Rework: A significant redesign of configuration file handling will be implemented to address long-standing confusion between remote clients (Windows/Mac) and the server. This will likely involve a client/server approach to containers.conf and unifying the parsing logic for containers.conf and storage.conf.

Netavark Enhancements: The Netavark network backend will remove support for iptables favoring nftables which has been the default since Fedora 41, consolidate the network create logic into Netavark itself, and change internal structures to preserve the network order for containers. This will impact only the users who manually configured iptables.

New Conmon: A new version of conmon is being evaluated to address several user enhancements and improvements.

Feedback :open_book:

Benefit to Fedora :open_book:

Modernization and Maintenance: Aligns Fedora with the latest container technologies by removing legacy, unmaintained, or superseded components like slirp4netns, cgroupsv1, BoltDB. This reduces maintenance overhead, technical debt, and attack surface.

Improved User Experience: The configuration file rework will resolve significant confusion for users, especially those on Windows and macOS, by clarifying client vs. server settings and normalizing configuration file parsing.

Enhanced Networking: Finalizing the move to Netavark and removing iptables support simplifies the networking stack and aligns with Fedoraā€™s modern defaults (nftables).

Scope :open_book:

  • Proposal owners: The Podman maintainers will be responsible for updating the podman package, managing associated dependency changes (like conmon), and ensuring the new version builds and runs correctly in Fedora 44. They will also manage the upstream changes in netavark and common.
  • Other developers: Maintainers of buildah and skopeo will likely need to adapt to the new configuration file parsing logic, which could require a major version bump for those tools. The podman-py maintainers will need to verify compatibility with the new configuration system. These are maintained by the same team of maintainers as Podman and they are on board with this change. These changes would likely need to additionally be coordinated with CoreOS and Image Mode developers.
  • Release engineering: N/A (not a System Wide Change)
  • Policies and guidelines: N/A (not needed for this Change)
  • Trademark approval: N/A (not needed for this Change)

Upgrade/compatibility impact :open_book:

This is a major version update with several breaking changes.

  • Users on systems still using CgroupsV1 will no longer be supported.
  • Users who have not migrated their database from BoltDB to SQLite will find their container state unusable after the upgrade.
  • Networking configurations relying on slirp4netns will no longer function. Users must be using Netavark and Pasta (which are the defaults in Podman 5).
  • Existing containers.conf files may need to be migrated or split to accommodate the new client/server configuration logic.

Early Testing (Optional) :open_book:

N/A

How To Test :open_book:

No special hardware is required (other than an x86_64 or aarch64 machine).

Install the new podman 6.0 package on a fresh Fedora 44 system.

Verify that basic container lifecycle works (run, stop, rm, ps, inspect).

Verify that networking functions correctly using the default Netavark (root) and Pasta (rootless) backends.

Test upgrading from Fedora 43 with Podman 5.x. Verify that existing SQLite databases are read correctly and containers still run.

User Experience :open_book:

Users will benefit from a cleaner, more maintainable codebase with removed legacy components. The configuration file improvements will reduce confusion for users working with remote Podman clients on Windows and macOS. Users still relying on deprecated components (slirp4netns, cgroups v1, BoltDB) will need to migrate to the supported alternatives before upgrading.

Dependencies :open_book:

N/A (not a System Wide Change)

Contingency Plan :open_book:

  • Contingency mechanism: N/A (not a System Wide Change)
  • Contingency deadline: N/A (not a System Wide Change)
  • Blocks release? No

Documentation :open_book:

N/A (Upstream documentation will be provided with the 6.0 release)

Release Notes :open_book:

Podman has been updated to major version 6.0. This release finalizes the removal of support for slirp4netns, cgroups v1, and the BoltDB database backend. Users must be on Netavark, Pasta, cgroups v2, and SQLite, respectively. Configuration file handling for remote clients has been significantly refactored, which may require user migration.

Last edited by @alking 2025-12-15T20:48:45Z

Last edited by @alking 2025-12-15T20:48:45Z

Mediawiki development environment with docker - how do I run with podman?
Podman 5.7 & BoltDB to SQLite migration
2

How do you feel about the proposal as written?

  • Strongly in favor
  • In favor, with reservations
  • Neutral
  • Opposed, but could be convinced
  • Strongly opposed
0 voters

If you are in favor but have reservations, or are opposed but something could change your mind, please explain in a reply.

We want everyone to be heard, but many posts repeating the same thing actually makes that harder. If you have something new to say, please say it. If, instead, you find someone has already covered what youā€™d like to express, please simply give that post a :heart: instead of reiterating. You can even do this by email, by replying with the heart emoji or just ā€œ+1ā€. This will make long topics easier to follow.

Please note that this is an advisory ā€œstraw pollā€ meant to gauge sentiment. It isnā€™t a vote or a scientific survey. See About the Change Proposals category for more about the Change Process and moderation policy.

3

One question about this: Do you know whether podman-desktop supports or plans to support podman 6 out of the box by the time F44 releases? GitHubā€™s search isnā€™t the best and searching for ā€œPodman 6ā€ yields lots of results because of the standalone ā€œ6ā€ and I canā€™t find any when searching for ā€œpodman6ā€.

This leads me to believe that this change proposal might potentially break podman-desktop which is fine because itā€™s not in the official Fedora repos.

However, itā€™d be good to know so that I can hold back on enabling F44 for my copr until podman-desktop is known to support podman 6

4 
Users should first upgrade to Podman 5.8 first

Do you plan to check this by some preinstall scriptlet or similar? I know the upgrade instructions say you should have a fully updated system before you do a major release upgrade but, users being users, you never know.

5

And is it (upgrade to 5.8 first) a should, or a must. While it sounds like a must, the wording does not say that. If it is a must, then there is a need for guardrails to protect against installing 6.0 if boltdb is still being used (for whatever reason).

6

This change proposal has now been submitted to FESCo with ticket #3530 for voting.

To find out more, please visit our Changes Policy documentation.

7

podman-desktop uses the remote API to talk to us via the podman socket. There might be minor API changes here and there but nothing big so I would assume it should work without changes generally. But I donā€™t maintain podman-desktop so I am not sure what their plans are regarding the podman 6 update.

8

I am not sure how we could check this in a script. The biggest issue is podman works per user basis meaning each user has their own db and thus must perform the migration at some point before the update. If a script would need to check this we would need to walk all users on every system which seems totally unreasonable.

And with that said the act of updating is not enough, you must reboot and then run any podman command to trigger the migration for the user as which you run the command. So if you do not have a podman command in the auto start (i.e. no quadlets or something else) then you need to run the podman manually and that for every user who is actually using podman and still on boltdb.

As for ā€œmustā€ be on 5.8 not really, because if you are already on sqlite you donā€™t have to do anything. And like said above there would not really be a sane check to see if any user on the system is still on boltdb so I donā€™t see how we would prevent the 6.0 upgrade in such case.
I think what we must do is to ensure podman 6 errors our if boltdb is still there and then the user must do the migration themselves (i.e. podman system reset or downgrade back to 5.8)

1 Like
9

Just to be clearā€¦ is Fedora 44 going to have both podman 5.8 and podman 6.0 as packages?

Hereā€™s the scenario Iā€™m concerned about.. People with podman 5.7 installed right now in Fedora 42 & 43, do an upgrade to Fedora 44 and get podman 6ā€¦ what are the steps we need to document in the Fedora 44 release notes they can use to mitigate? Weā€™ll need to document something.

1 Like
10

This is not an acceptable condition, since we support N-2 upgrades. We need this to be handled automatically somehow.

1 Like
11

No

That means they upgrade from an old fedora version without doing all available updates first. podman 5.8 will be released in early February and should land in all active fedora releases soon after. So f42 & f43 will contain 5.8 by the time the beta would release.

12

f42 will also be on podman 5.8 by then so would that not be enough?

13

Alsoā€¦

Do we know if any of the image based outputs have podman baked-in? My initial upgrade mitigation question is from a workstation user pov.. but If there are any image based outputs out there that have podman baked into the image, they probably should think about how this impacts users there and possible mitigation.

14

only for users who do the podman update while on f42.
I do not think we require systems to be fully updated before upgrading.

And by require i meanā€¦ the tooling doesnt force you to apply updates. At best, applying updates is a ā€˜best practiseā€™ and its not something ā€˜requiredā€™ via engineering controls.

You have to assume there will be f42 and f43 users out there who are upgrading directly from stock releases. And those users need a mitigation pathway documented to get themselves unstuck. If that means building podman 5.8 in a "you-didnā€™t-apply-updates-firstā€™ copr repo that we can link to in known regressions section of the release notesā€¦ that would be seem to me to be a reasonable worst case backstop if something more clever canā€™t be created.

15

Good to know, thanks for clarifying! Iā€™ll ask upstream about their plans regarding podman 6 but if itā€™s only minor API changes, it shouldnā€™t have any significant impact, hopefully

16

The crux of it is that thereā€™s no way to enforce stepwise upgrades. We just recently had a problem with PostgreSQL upgrades from F42 to F43 because of issues like this, so itā€™s something Iā€™m explicitly watching out for now.

17

I should actually add more color to this..
I actually expect there will be people who do this set of operations:

  1. Start from an operational F40 or F41 system that is end of life.. maybe with all updates applied maybe not.
  2. upgrade F42 or F43 and apply no updates
  3. upgrade to F44.

Thatā€™s a real path that Fedora live upgrade tooling allows. I know because I have a stack of old laptops that I pulled from and did that sort of thing to to live upgrade up to F43. And I still have a couple of laptops in the pile I can do that to for F44.

18

IMHO the approach to deprecation / migration is rather flawed.

The deprecation note added in 5.7 has been effectively unactionable by users for the lifetime of F43, given the lack of any data migration script or and the blog instruction to use a ā€œ-migrate-dbā€ option which does not yet exist.

IOW, users have had little choice but to ignore this warning, eg Iā€™ve had to add export SUPPRESS_BOLTDB_WARNING=aaaaaargh to bashrc to stop this warning message that I canā€™t action, polluting all my toolbox sessions.

Even if Podman 5.8 is now shipped as an update in F43, it still appears to be relying on users to notice that this podman 5.8 RPM arrived (in the middle of 1,000 other RPM updates), and trigger the automatic upgrade, or manually upgrade. This feels like wishful thinking to me.

IMHO we canā€™t rely on users migrating off BoltDb before the upgrade to F44, and there needs to be some way to trigger migration when already on F44. Ideally automated, but at minimum a reasonable manual process users can be pointed to when they get into this situation. Given the heavy usage of containers it is not acceptable to expect users to throw away all container state and start from scratch.

1 Like
19

The migration triggers if you use the podman binary the first time after boot. I would expect that to be somewhat normal user behavior if one is using podman. Yes it might not cover anybody if you never rebooted or run podman before the system upgrade.

As for how a user can recover if they did not migrate before the 6.0 update then so far the only option would be podman system reset. I know that is not exactly a nice option because that also deletes all containers, images and the named volumes.

Practically speaking we want the boltdb code gone for maintenance reasons so it doesnā€™t seem appealing to keep that code around in podman. That said I guess nothing would prevent anyone from extracting that code into a separate binary and offer that as additional rpm to have something nicer for users. But that is not something I would have time for and I am not sure if someone else from the Podman team would.

Unfortunately it is unclear to us how many users would be affected. We have no telemetry data to know what percentage of users are still on boltdb. Our assumption is that most users are on sqlite as that has been the default for over two years at this point. So the question is how many people used podman before that and upgraded their system in place. And how many of them then also skip the 5.8 update logic. It is hard to know that, I do agree it would be good if we can offer them something better than run podman system reset.

20

Is my request for a copr with 5.8 built for F44 out of the question? Even if its 1 personā€¦ that gives that 1 person a way to downgrade do the migration and then back up to 6?

Obviously a stand a lone migration tool that could be shipped in F44 would be the better option. There has to be a reasonable way to package that migration code in a way that could be documented in the release notes on how to make use of.

If it helps I can make sure I have a freshly installed F43 laptop with podman as part of a live demonstration on how easy it is to live update Fedora ready to roll and have it fall over to greater embarrassment with no mitigation path. Do you want me trying to live recompile an F43 podman 5.8 for F44 as part of a the live release party? Sounds like fun to me. maybe thatā€™s an indication I was a bad choice for this gig. But hey here we are.

But seriously.. something packaged and documented that allows people to back out of this without having to attempt the srpm recompile would beā€¦minimal viable.

1 Like