Podman 失败，在 Fedora 32 上拉取更大的图像

Question

我在我的 Fedora 32 机器上遇到了一个奇怪的行为。 一件事，我有两个在 Fedora 32 下运行的盒子。一个盒子工作得很好，另一个是我目前的工作笔记本电脑，遇到了问题，我现在将详细描述。

Podman 能够提取图像，但如果它们超过一定大小，我会遇到与 tar 相关的错误

❯ podman pull node:12-alpine
Completed short name "node" with unqualified-search registries (origin: /etc/containers/registries.conf)
Trying to pull registry.fedoraproject.org/node:12-alpine...
  manifest unknown: manifest unknown
Trying to pull registry.access.redhat.com/node:12-alpine...
  name unknown: Repo not found
Trying to pull registry.centos.org/node:12-alpine...
  manifest unknown: manifest unknown
Trying to pull docker.io/library/node:12-alpine...
Getting image source signatures
Copying blob 0a6724ff3fcd skipped: already exists  
Copying blob e21405c347ae done  
Copying blob 80b224d472a8 done  
Copying blob 5fd2bdfdbf4b done  
Copying config 0206ff8a5f done  
Writing manifest to image destination
Storing signatures
  Error processing tar file(signal: killed): 
Error: 4 errors occurred while pulling:
 * Error initializing source docker://registry.fedoraproject.org/node:12-alpine: Error reading manifest 12-alpine in registry.fedoraproject.org/node: manifest unknown: manifest unknown
 * Error initializing source docker://registry.access.redhat.com/node:12-alpine: Error reading manifest 12-alpine in registry.access.redhat.com/node: name unknown: Repo not found
 * Error initializing source docker://registry.centos.org/node:12-alpine: Error reading manifest 12-alpine in registry.centos.org/node: manifest unknown: manifest unknown
 * Error committing the finished image: error adding layer with blob "sha256:5fd2bdfdbf4bc383aabf3a03afec47f0e8b5542443e0d6edb74752991651d22a": Error processing tar file(signal: killed): 

而以下只是按预期工作：

❯ podman pull redis:6-alpine
Completed short name "redis" with unqualified-search registries (origin: /etc/containers/registries.conf)
Trying to pull registry.fedoraproject.org/redis:6-alpine...
  manifest unknown: manifest unknown
Trying to pull registry.access.redhat.com/redis:6-alpine...
  name unknown: Repo not found
Trying to pull registry.centos.org/redis:6-alpine...
  manifest unknown: manifest unknown
Trying to pull docker.io/library/redis:6-alpine...
Getting image source signatures
Copying blob 054f304e4d13 skipped: already exists  
Copying blob 4c0d98bf9879 skipped: already exists  
Copying blob 6ca68aee953e skipped: already exists  
Copying blob 5d65ae1c666f skipped: already exists  
Copying blob cc1404096495 skipped: already exists  
Copying blob c8b085ca330a [--------------------------------------] 0.0b / 0.0b
Copying config 18e4b21eb3 done  
Writing manifest to image destination
Storing signatures
18e4b21eb324530849a8224263413870807d5dfdee5674e6d763be0acc186811

这是我的播客信息（以防万一）

❯ podman info --debug
host:
  arch: amd64
  buildahVersion: 1.18.0
  cgroupManager: systemd
  cgroupVersion: v2
  conmon:
    package: conmon-2.0.25-1.fc32.x86_64
    path: /usr/bin/conmon
    version: 'conmon version 2.0.25, commit: 70f7fbb2f9b93b082ecb9cfe6505c7b557062799'
  cpus: 8
  distribution:
    distribution: fedora
    version: "32"
  eventLogger: journald
  hostname: localhost
  idMappings:
    gidmap:
    - container_id: 0
      host_id: 1000
      size: 1
    - container_id: 1
      host_id: 100000
      size: 65536
    uidmap:
    - container_id: 0
      host_id: 1000
      size: 1
    - container_id: 1
      host_id: 100000
      size: 65536
  kernel: 5.10.12-100.fc32.x86_64
  linkmode: dynamic
  memFree: 5446406144
  memTotal: 33274793984
  ociRuntime:
    name: crun
    package: crun-0.17-1.fc32.x86_64
    path: /usr/bin/crun
    version: |-
      crun version 0.17
      commit: 0e9229ae34caaebcb86f1fde18de3acaf18c6d9a
      spec: 1.0.0
      +SYSTEMD +SELINUX +APPARMOR +CAP +SECCOMP +EBPF +CRIU +YAJL
  os: linux
  remoteSocket:
    path: /run/user/1000/podman/podman.sock
  rootless: true
  slirp4netns:
    executable: /usr/bin/slirp4netns
    package: slirp4netns-1.1.8-1.fc32.x86_64
    version: |-
      slirp4netns version 1.1.8
      commit: d361001f495417b880f20329121e3aa431a8f90f
      libslirp: 4.3.1
      SLIRP_CONFIG_VERSION_MAX: 3
      libseccomp: 2.5.0
  swapFree: 8262774784
  swapTotal: 8262774784
  uptime: 27h 20m 18.12s (Approximately 1.12 days)
registries:
  search:
  - registry.fedoraproject.org
  - registry.access.redhat.com
  - registry.centos.org
  - docker.io
store:
  configFile: /home/mvelten/.config/containers/storage.conf
  containerStore:
    number: 0
    paused: 0
    running: 0
    stopped: 0
  graphDriverName: overlay
  graphOptions:
    overlay.mount_program:
      Executable: /usr/bin/fuse-overlayfs
      Package: fuse-overlayfs-1.4.0-1.fc32.x86_64
      Version: |-
        fusermount3 version: 3.9.1
        fuse-overlayfs: version 1.4
        FUSE library version 3.9.1
        using FUSE kernel interface version 7.31
  graphRoot: /home/mvelten/.local/share/containers/storage
  graphStatus:
    Backing Filesystem: extfs
    Native Overlay Diff: "false"
    Supports d_type: "true"
    Using metacopy: "false"
  imageStore:
    number: 2
  runRoot: /run/user/1000/containers
  volumePath: /home/mvelten/.local/share/containers/storage/volumes
version:
  APIVersion: 2.1.0
  Built: 1607438263
  BuiltTime: Tue Dec  8 15:37:43 2020
  GitCommit: ""
  GoVersion: go1.14.10
  OsArch: linux/amd64
  Version: 2.2.1

我已经排除了卷大小问题。所有与存储相关的目录的修剪和重置也没有成功。重新安装也没有用。

在我看来，当拉取的图像超过一定大小时，它总是会遇到指出的 tar 相关错误。

然后，当我从另一个 Fedora (32) 机器运行相同的拉取请求时，它就可以工作了。超级奇怪，我不知道在哪里寻找潜在的修复（花了很长时间，在互联网上搜寻类似的东西）。

任何帮助或建议将不胜感激，因为我现在被完全阻止了。

Answer 1

好的……我自己回答了问题……我的问题的实际根本原因是一个名为“SentinelOne”的软件，我们应该在我们的工作笔记本电脑上运行它……事实证明，它在拉力。