podman: Stuck on Storing Signatures
/kind bug
Description Using Void Linux, latest podman gets stuck on sitespeed.io container at “Storing Signatures” step.
Steps to reproduce the issue: podman run --rm -v “$(pwd)”:/sitespeed.io sitespeedio/sitespeed.io:9.3.2 https://sitespeed.io
Describe the results you received: [vlad@void-vm ~]$ podman run --rm -v “$(pwd)”:/sitespeed.io sitespeedio/sitespeed.io:9.3.2 https://sitespeed.io Trying to pull docker.io/sitespeedio/sitespeed.io:9.3.2…Getting image source signatures Copying blob edb2b29fa1e2 skipped: already exists Copying blob c46b5fa4d940 skipped: already exists Copying blob 6b1eed27cade skipped: already exists Copying blob 93ae3df89c92 skipped: already exists Copying blob 76d5ea985833 skipped: already exists Copying blob 473ede7ed136 skipped: already exists Copying blob cf82bd0b1aa3 skipped: already exists Copying blob 7dc6cf341fb3 skipped: already exists Copying blob 3c9757b8e6c7 skipped: already exists Copying blob 275861923052 skipped: already exists Copying blob 4c29465436d4 skipped: already exists Copying blob 66700b5e3941 skipped: already exists Copying blob 160f3f39f1b5 skipped: already exists Copying blob a0507231acd7 skipped: already exists Copying blob b965ed368ed7 skipped: already exists Copying blob ad9103b58e2d skipped: already exists Copying blob 946c4c8160b3 skipped: already exists Copying blob df426434925b skipped: already exists Copying blob 8791c156ea54 skipped: already exists Copying blob b1ac729adf6d skipped: already exists Copying blob 4d916c8de88f skipped: already exists Copying blob 67578fe28a3d skipped: already exists Copying blob 47f6b4d4a060 done Copying blob 203d22208385 done Copying blob 671ce6b824ea done Copying config 681cf2afef done Writing manifest to image destination Storing signatures
Describe the results you expected: I would expect it to not freeze at “Storing signatures” step and actually run the container
Output of podman version:
Version: 1.4.0
RemoteAPI Version: 1
Go Version: go1.12.5
OS/Arch: linux/amd64
Output of podman info --debug:
debug:
compiler: gc
git commit: ""
go version: go1.12.5
podman version: 1.4.0
host:
BuildahVersion: 1.8.3
Conmon:
package: Unknown
path: /usr/libexec/podman/conmon
version: 'conmon version 0.2.0, commit: '
Distribution:
distribution: '"void"'
version: unknown
MemFree: 135749632
MemTotal: 2013794304
OCIRuntime:
package: Unknown
path: /usr/bin/runc
version: 'runc version spec: 1.0.1-dev'
SwapFree: 0
SwapTotal: 0
arch: amd64
cpus: 4
hostname: void-vm
kernel: 4.19.50_1
os: linux
rootless: true
uptime: 2h 52m 7.41s (Approximately 0.08 days)
registries:
blocked: null
insecure: null
search:
- docker.io
- registry.fedoraproject.org
- registry.access.redhat.com
store:
ConfigFile: /home/vlad/.config/containers/storage.conf
ContainerStore:
number: 1
GraphDriverName: vfs
GraphOptions: null
GraphRoot: /home/vlad/.local/share/containers/storage
GraphStatus: {}
ImageStore:
number: 1
RunRoot: /tmp/1000
VolumePath: /home/vlad/.local/share/containers/storage/volumes
Additional environment details (AWS, VirtualBox, physical, etc.): Hyper-V VM on Windows 10 Ent
About this issue
- Original URL
- State: closed
- Created 5 years ago
- Comments: 26 (9 by maintainers)
My bad, turns out pulling the image exited correctly, it’s just that I ran
podman container runand the container has no output, so I thought it was stuck on “Storing signatures”.Finally solved the problem by doing
sudo rm -rf ~/.config/containers/storage.confand then runningpodman pullwithout the--storage-driveroption.Podman sees that I now have
fuse-overlayfsandlibfuse3-devinstalled and creates new config files with overlay as the default filesystem driver.Specifying the
--storage-driver overlayoption results in the problem detailed here: https://github.com/containers/buildah/issues/1745, even though if I understand correctly it shouldn’t change anything due to overlay being the defaultAlso, for anyone else googling and finding this,
--storage-driver fuse-overlayfsis (I think) incorrect syntax. Proper usage is--storage-driver overlay.It would be nice if the overlay packages were required dependencies of podman and then overlay was used as the default driver from the beginning. That would save new users a lot of time not having to deal with this difficult to diagnose issue.
@Dulani I believe fuse-overlay should work in 7.8.
@Jousboxx
podman infoshould contain an optionGraphDriverNamethat will tell you what your current driver is.After I logged this ticket I set up a bunch of other containers and worked with those. I just tried the container in question here and it actually worked this time around. I should’ve mentioned that it was a fresh install of podman and I did hello world container (which worked) and next container that I tried was the one mentioned here that failed for me.
Since it works now we can close the ticket but there might be something funky going on with a fresh install and particular sequence of containers.
Still attaching debug log for a successful run -