Bug 1958546 - 3.2.0-rc1 opening file `` for writing: No such file or directory: OCI not found
Summary: 3.2.0-rc1 opening file `` for writing: No such file or directory: OCI not found
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Fedora
Classification: Fedora
Component: podman
Version: 34
Hardware: x86_64
OS: Linux
unspecified
high
Target Milestone: ---
Assignee: Lokesh Mandvekar
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2021-05-08 17:25 UTC by Guy Streeter
Modified: 2022-03-23 13:35 UTC (History)
19 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2022-03-23 13:35:01 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)
podman pod inspect output. (2.63 KB, text/plain)
2021-05-08 17:25 UTC, Guy Streeter
no flags Details


Links
System ID Private Priority Status Summary Last Updated
Github containers podman issues 10274 0 None open Unable to start container after update **podman 3.1.2-1.fc34 -> 3.2.0-0.1.rc1.fc34** 2021-05-10 06:17:58 UTC

Description Guy Streeter 2021-05-08 17:25:21 UTC
Created attachment 1781074 [details]
podman pod inspect output.

Description of problem:

After upgrading podman to 3.2.0-rc1, I get:
 opening file `` for writing: No such file or directory: OCI not found
failure for all my pods. Downgrading to 3.1.0 the problem goes away.


Version-Release number of selected component (if applicable):
3.2.0-rc1

How reproducible:

This happens every time I try to start any of my pods with the new version. It never happens with version 3.1.0.

Actual results:
error starting container ede27395508dc8dc8485829b9f8d65384bbc5a1666b4d589252b67b20c76841a: opening file `` for writing: No such file or directory: OCI not found


Expected results:
Successful start of pod.


Additional info:
I only have rootless pods, so I have not tried anything as root and I have not tried single containers.

Comment 1 Guy Streeter 2021-05-09 23:47:39 UTC
I removed my containers and images and rebuilt my pod, and I'm no longer getting the error.

Comment 2 Robin Lee 2021-05-10 03:41:30 UTC
I met the same error with podman-3.2.0-0.1.rc1.fc34.x86_64

Containers that created by toolbox-0.0.99.1-1.fc34.x86_64 with the previous podman-3.1.2-1.fc34.x86_64 fails to start. Re-created containers would run, with the same version of Toolbox.

Comment 3 Matthew Heon 2021-05-10 16:10:04 UTC
Fixed upstream.

The real issue here is that an early RC somehow made it into the stable repos. We are taking action to back out the the RC and restore 3.1.2 to stable until the final 3.2.0 release.

Comment 4 Ankur Sinha (FranciscoD) 2021-05-11 11:24:18 UTC
Hi Matthew, 

Thanks for this. Would it be possible to not use the bot for stable releases, as noted by pnemade in the update? Bodhi already includes the necessary logic that the update process should follow as documented by FESCo, and this should only be overridden by a human if necessary, not by a bot.

https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/#stable-releases etc.

I also note that the version in rawhide appears to be older than the version in F33/34 (3.1.0... vs 3.2.0) because the bot keeps obsoleting updates in rawhide? Could the tooling please be tweaked to ensure that the rawhide version does always remain ahead of stable Fedora releases (perhaps by not obsoleting each update until it has actually made it to "stable" there)?

https://bodhi.fedoraproject.org/updates/?packages=podman

Thanks very much,

Comment 5 Matthew Heon 2021-05-11 12:49:17 UTC
I'm not really the correct target for these questions - I'll tag in Lokesh, who manages the Podman package for Fedora.

Comment 6 Woti 2021-05-13 11:09:44 UTC
The same happens to me on my headless Fedora 33 Server-Edition. Rolling back to version 3.1.0 is running fine.

Comment 7 Lokesh Mandvekar 2021-08-05 18:21:55 UTC
Does this still occur with v3.2.3 in updates or with v3.3.0-rc1 (soon to land in f34-updates-testing)?

Comment 8 Lokesh Mandvekar 2022-03-23 13:35:01 UTC
Closing. Please reopen if you still notice this issue with v4.0.2.


Note You need to log in before you can comment on or make changes to this bug.