[BUG] Can't update because of moby-engine

[cthu1hoo]

Receiving the following when trying to run rpm-ostree upgrade today:

$ rpm-ostree upgrade
2 metadata, 0 content objects fetched; 788 B transferred in 2 seconds; 0 bytes content written
Checking out tree 0a1da96... done
Enabled rpm-md repositories: fedora-cisco-openh264 updates fedora copr:copr.fedorainfracloud.org:dawid:better_fonts updates-arch
ive
Importing rpm-md... done
rpm-md repo 'fedora-cisco-openh264' (cached); generated: 2021-09-21T18:07:30Z solvables: 4rpm-md repo 'updates' (cached); generated: 2022-02-13T01:03:20Z solvables: 25830
rpm-md repo 'fedora' (cached); generated: 2021-10-26T05:31:27Z solvables: 65732
rpm-md repo 'copr:copr.fedorainfracloud.org:dawid:better_fonts' (cached); generated: 2021-08-11T16:31:43Z solvables: 27
rpm-md repo 'updates-archive' (cached); generated: 2022-02-13T02:11:51Z solvables: 27882
Resolving dependencies... done
Checking out packages... done
error: Checkout moby-engine-20.10.12-1.fc35.x86_64: Hardlinking 29/7d5d48b6f27d1565342a19fd409449d0f47db0f843b2d83368adabf744639
a.file to Dockerfile.5.gz: File exists

Looking here, I don't think there were any updates for moby-engine recently which might've caused this.

Should I remove the override, and try to add it back, after reboot? Thanks in advance for any help.

[travier]

rpm-ostree status would help us understand your issue.

[cthu1hoo]

I've uninstalled moby-engine for the time being because podman-compose is good enough for my needs but this issue is likely caused by both moby-engine and containers-common providing /usr/share/man/man5/Dockerfile.5.gz:

1. https://koji.fedoraproject.org/koji/rpminfo?rpmID=28794373 ctrl-f Dockerfile.5.gz

$ rpm -qf /usr/share/man/man5/Dockerfile.5.gz
containers-common-1-41.fc35.noarch

I guess upstream needs to deal with this somehow. My personal issue is fixed, so I'm going to close this.

[rapgenic]

this issue is likely caused by both moby-engine and containers-common providing /usr/share/man/man5/Dockerfile.5.gz:

Could this be reopened? I have the same problem and I have come to the same conclusion. At the moment I've just pinned the previous working deployment, but I cannot move forward.

I have tried to install both containers-common and moby-engine in a toolbox with no problems, so I believe that this is specifically a Silverblue issue, also because looking at the containers-common changelog, it seems that this should be handled by default on package installation (see changelog section of https://koji.fedoraproject.org/koji/buildinfo?buildID=1911700)

$ rpm-ostree status output if this is useful:

State: idle
Deployments:
  fedora:fedora/35/x86_64/silverblue
                   Version: 35.20220214.0 (2022-02-14T01:10:46Z)
                BaseCommit: 088605cb701d24fed9a0325f7484f5057531244a0d5e29555da0cc0a6b59bbb1
              GPGSignature: Valid signature by 787EA6AE1147EEE56C40B30CDB4639719867C58F
                      Diff: 41 upgraded, 3 removed, 2 added
       RemovedBasePackages: firefox 97.0-1.fc35
           LayeredPackages: code-insiders google-chrome-stable kmod-nvidia libxcb-devel openssl
                            xorg-x11-drv-nvidia zsh
             LocalPackages: hp-zbook-g5-tweaks-1-1.fc35.x86_64 rpmfusion-free-release-35-1.noarch

  fedora:fedora/35/x86_64/silverblue
                   Version: 35.20220213.0 (2022-02-13T00:49:17Z)
                BaseCommit: faf747c4006db1d83e696d191a3d8935d5615dacb8125eab345ecc845d1a7ab3
              GPGSignature: Valid signature by 787EA6AE1147EEE56C40B30CDB4639719867C58F
       RemovedBasePackages: firefox 97.0-1.fc35
           LayeredPackages: code-insiders google-chrome-stable kmod-nvidia libxcb-devel openssl
                            xorg-x11-drv-nvidia zsh
             LocalPackages: hp-zbook-g5-tweaks-1-1.fc35.x86_64 rpmfusion-free-release-35-1.noarch

● fedora:fedora/35/x86_64/silverblue
                   Version: 35.20220210.0 (2022-02-10T00:46:21Z)
                BaseCommit: cd742114c5cab53776508494222dfe5d3c481ad90eb2917e83ec2c0e15dbf2b9
              GPGSignature: Valid signature by 787EA6AE1147EEE56C40B30CDB4639719867C58F
       RemovedBasePackages: firefox 96.0.3-1.fc35
           LayeredPackages: code-insiders google-chrome-stable kmod-nvidia libxcb-devel moby-engine
                            openssl xorg-x11-drv-nvidia zsh
             LocalPackages: hp-zbook-g5-tweaks-1-1.fc35.x86_64 rpmfusion-free-release-35-1.noarch
                    Pinned: yes

[travier]

You can give a try to the experimental feature from coreos/rpm-ostree#3125. Docs are still pending: coreos/rpm-ostree#3349.

[travier]

This should be fixed by https://src.fedoraproject.org/rpms/containers-common/c/d16e5dd7d023261c3ec1cc93641e2a7f48ed39c4?branch=rawhide

[travier]

I don't see a build yet for that (the fix is also in F35): https://bodhi.fedoraproject.org/updates/?search=&packages=containers-common&releases=F35

[vteivans]

I'm having the same issue with docker-ce.

[cgwalters]

Ugh, https://src.fedoraproject.org/rpms/containers-common/c/d16e5dd7d023261c3ec1cc93641e2a7f48ed39c4?branch=rawhide can't really work in general because it it's not guaranteed that the containers-common %post runs after docker is installed.

There's not really a good way out of this; I think it's probably simplest to drop the duplicate man pages from containers-common.

[lsm5]

I don't have a strong opinion on dup man pages. @rhatdan PTAL ^

[cgwalters]

If you really, really want to try to have "own the Dockerfile man page only if docker.rpm isn't installed" semantics, it would probably work to do it instead in %posttrans. But I think these types of games are a long term pain and source of problems and it's just simpler to drop it.

[lsm5]

If you really, really want to try to have "own the Dockerfile man page only if docker.rpm isn't installed" semantics, it would probably work to do it instead in %posttrans. But I think these types of games are a long term pain and source of problems and it's just simpler to drop it.

Ack, I'm fine with removing them from c-common. Perhaps they're better off in podman-docker which already conflicts with all the docker packages. @rhatdan @mheon wdyt.

[cgwalters]

Perhaps they're better off in podman-docker which already conflicts with all the docker packages.

That seems like the best idea to me!

[mheon]

Sounds fine to me.

[cevich]

Idea: Move the podman version of the man page into the podman-docker package. There's no reason I can think of why anybody in their right mind would have both that and moby-engine installed at the same time (they will conflict on bin/docker IIUC).

[rhatdan]

Well the usability issue here is huge.

If a podman user wants to know about the contents of Dockerfile there is a 99% chance that the man page is not installed.
Podman build's man page mentions Dockerfile (So does Buildah build)

The number of people who co-install Podman and Docker is way smaller then the number who install one or the other.
Podman-docker being installed is also very small number.

We could move Dockerfile to a subpackage of Moby and have Podman require it, although that is not ideal because I would prefer to have the Containerfile man page listed when users are interested.

[rhatdan]

Could we split it out as a recommends and then that would allow users of Moby and Podman to be coinstalled and then when a conflict happens, they could remove containers-common-Dockerfile. package.

[cgwalters]

We need to do something now - anyone who has both podman and moby installed is no longer getting OS updates. That's bad.

[lsm5]

removed them from https://koji.fedoraproject.org/koji/taskinfo?taskID=82820318 . We can resolve this better in a future build as @rhatdan would prefer or after checking with docker folks.

[cevich]

Idea: What about moving the location of the man page, like to section 8, or some other place so the file name/path doesn't conflict.

[lsm5]

removed them from https://koji.fedoraproject.org/koji/taskinfo?taskID=82820318 . We can resolve this better in a future build as @rhatdan would prefer or after checking with docker folks.

i gotta fix the build. Will rebuild and do the same for f35 and f36

[lsm5]

Idea: What about moving the location of the man page, like to section 8, or some other place so the file name/path doesn't conflict.

1. we would need to move Containerfile and other manpages too.
2. There would be multiple dockerfile manpages if people install moby and containers-common. That's bound to cause confusion.

[lsm5]

rawhide: https://bodhi.fedoraproject.org/updates/FEDORA-2022-ffaa83f05a
f36: https://bodhi.fedoraproject.org/updates/FEDORA-2022-be76885bc1
f35: https://bodhi.fedoraproject.org/updates/FEDORA-2022-e2349225f5

[tidux]

This issue should be left open until the Fedora project implements sufficient integration testing to not ship packages with known file conflicts.

[rhasti]

How to install the package from update-testing in silverblue for testing using rpm-ostree?

[leb4r]

How to install the package from update-testing in silverblue for testing using rpm-ostree?

I found this link useful

e.g.

rpm-ostree override replace containers-common-1-45.fc35.noarch.rpm

# upgrades should work now :)
rpm-ostree upgrade

build can be found here

[offlinehacker]

You can also do sudo rpm-ostree override replace https://bodhi.fedoraproject.org/updates/FEDORA-2022-e2349225f5

[rhasti]

FEDORA-2022-e2349225f5 does resolve the issue for me. Thanks.

[travier]

Closing this one as the update has been pushed to stable.