Lost of the policy.json and registries.conf file after reinstall podman

Bug #2085790 reported by Alan Moore
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
golang-github-containers-common (Ubuntu)
New
Undecided
Unassigned
golang-github-containers-image (Ubuntu)
New
Undecided
Unassigned
libpod (Ubuntu)
New
Undecided
Unassigned

Bug Description

In oracular, fresh install of podman provides `libpod.conf networks/ policy.json registries.conf registries.conf.d/ systemd/` under /etc/containers/
But if you remove the podman with `sudo apt purge podna && sudo apt autoremove` (with container folder removed) then reinstall the podman back, it now only has `libpod.conf networks/ registries.conf.d/ systemd/` which causes problem to resolve the short name

ProblemType: Bug
DistroRelease: Ubuntu 24.10
Package: podman 5.0.3+ds1-5ubuntu1
ProcVersionSignature: Ubuntu 6.11.0-9.9-generic 6.11.0
Uname: Linux 6.11.0-9-generic x86_64
ApportVersion: 2.30.0-0ubuntu4
Architecture: amd64
CasperMD5CheckMismatches: ./casper/initrd
CasperMD5CheckResult: fail
CurrentDesktop: ubuntu:GNOME
Date: Mon Oct 28 18:01:13 2024
InstallationDate: Installed on 2024-09-29 (29 days ago)
InstallationMedia: Ubuntu 24.10 "Oracular Oriole" - Beta amd64 (20240919)
ProcEnviron:
 LANG=en_US.UTF-8
 PATH=(custom, no user)
 SHELL=/bin/bash
 TERM=xterm-256color
 XDG_RUNTIME_DIR=<set>
SourcePackage: libpod
UpgradeStatus: No upgrade log present (probably fresh install)

Revision history for this message
Alan Moore (wqian) wrote :
Revision history for this message
Alan Moore (wqian) wrote (last edit ):

Solution:

sudo apt purge golang-github-containers*

then rm the conffile

sudo rm -r /etc/containers

sudo apt install podman

Creata and edit the file /etc/subuid and /etc/subgid ( replace the username with current user) :

/etc/subuid

username:100000:65536

/etc/subgid

username:100000:65536

The run `podman system migrate`

Alan Moore (wqian)
no longer affects: ubuntu
Revision history for this message
Seth Arnold (seth-arnold) wrote :

My guess is: sudo apt purge podna && sudo apt autoremove

'autoremove' won't *purge* packages, it just uninstalls packages. That invokes dpkg's machinery to track "conffiles" (or is it "config files"? I can't remember.) If dpkg sees that an admin has removed a conffile then it will not install that conffile again when the package is reinstalled later: the admin wanted it gone, so it is gone.

This may be the better path forward than comment #2:

sudo apt-get --yes reinstall -o Dpkg::Options::="--force-confnew" -o Dpkg::Options::="--force-confmiss podman # or whatever package name

I prefer purging packages vs uninstalling packages: I only ever use apt autoremove to clean up after old kernels, which mostly doesn't have this problem.)

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.