`podman auto-update` does not respect the `--override-arch=xyz` flag #6613

bttnns · 2020-06-15T20:46:19Z

/kind bug

Description

podman auto-update does not respect the --override-arch=xyz flag.

I'm running an updated Fedora IoT on a Raspberry Pi 3 b+, and podman only wants to pull images that are arch=arm64/v8, when many images are tagged arch=arm64. I've mitigated this via using the --override-arch=arm64 flag, which seems to work for the pull and run commands, but not auto-update. <this might even be a separate issue, arm64==arm64/v8 ?>

I can get the image to update by passing in a --pull always, making sure to generate systemd with the --new flag and running systemctl restart x.service

Steps to reproduce the issue:

Follow example listed here: https://www.mankier.com/1/podman-auto-update
Replace image with something like mikenye/readsb for example.
podman auto-update

Note: the --override-arch=arm64 flag is setup in the systemd unit. Running podman auto-update --override-arch=arm64 isn't possible as that flag doesn't exist.

See https://hub.docker.com/r/mikenye/readsb/tags for available arch tags

See https://github.com/mikenye/docker-readsb/blob/master/buildx.sh for how the images are built.

See sdr-enthusiasts/docker-piaware#33 (comment) for details on arm64 == arm64/v8 in this case

Describe the results you received:

error auto-updating container "<hash>": image check for "<image:tag>" failed: Error choosing image instance: no image found in manifest list for architecture arm64, variant v8, OS linux

Describe the results you expected:

An updated image running.

Output of podman version:

Version:            1.9.3
RemoteAPI Version:  1
Go Version:         go1.14.2
OS/Arch:            linux/arm64

Output of podman info --debug:

debug:
  compiler: gc
  gitCommit: ""
  goVersion: go1.14.2
  podmanVersion: 1.9.3
host:
  arch: arm64
  buildahVersion: 1.14.9
  cgroupVersion: v2
  conmon:
    package: conmon-2.0.17-1.fc32.aarch64
    path: /usr/bin/conmon
    version: 'conmon version 2.0.17, commit: 19c059ee0c01a2fb2c425cff307fba1ad2cf7741'
  cpus: 4
  distribution:
    distribution: fedora
    version: "32"
  eventLogger: file
  hostname: adsb
  idMappings:
    gidmap: null
    uidmap: null
  kernel: 5.6.15-300.fc32.aarch64
  memFree: 135544832
  memTotal: 984621056
  ociRuntime:
    name: crun
    package: crun-0.13-2.fc32.aarch64
    path: /usr/bin/crun
    version: |-
      crun version 0.13
      commit: e79e4de4ac16da0ce48777afb72c6241de870525
      spec: 1.0.0
      +SYSTEMD +SELINUX +APPARMOR +CAP +SECCOMP +EBPF +YAJL
  os: linux
  rootless: false
  slirp4netns:
    executable: ""
    package: ""
    version: ""
  swapFree: 468996096
  swapTotal: 468996096
  uptime: 47m 26.07s
registries:
  search:
  - registry.fedoraproject.org
  - registry.access.redhat.com
  - registry.centos.org
  - docker.io
store:
  configFile: /etc/containers/storage.conf
  containerStore:
    number: 3
    paused: 0
    running: 3
    stopped: 0
  graphDriverName: overlay
  graphOptions:
    overlay.mountopt: nodev,metacopy=on
  graphRoot: /var/lib/containers/storage
  graphStatus:
    Backing Filesystem: extfs
    Native Overlay Diff: "false"
    Supports d_type: "true"
    Using metacopy: "true"
  imageStore:
    number: 4
  runRoot: /var/run/containers/storage
  volumePath: /var/lib/containers/storage/volumes

Additional environment details (AWS, VirtualBox, physical, etc.):

Fedora IoT, Raspberry Pi 3b+

The text was updated successfully, but these errors were encountered:

bttnns · 2020-06-15T20:52:43Z

It's worth noting that it's semi confusing that the CPU architecture of this device could be either:

aarch64
arm64
arm64/v8
likely something else that I'm forgetting...

Maybe podman should try all of the above? /not sure.

Another note, I also have a few other arm devices (pi 4/pi zero, and a pinebook pro) that I use every now and then. So getting into multi-arch, lmk if there is anything I should check out =)

mheon · 2020-06-15T21:00:59Z

@vrothberg PTAL

bttnns · 2020-06-15T22:02:19Z

/edited the OP to add some:

Notes

vrothberg · 2020-06-16T08:42:45Z

Thanks for opening the issue, @btannous! I'll take a look but believe it'll be a quick fix, so I hope to get it in before Podman 2.0 :)

Use the architecture of the local image when looking for a new image on a registry. It seems to be common practice on ARM to tweak the architecture choice to pull the correct image. Fixes: containers#6613 Signed-off-by: Valentin Rothberg <[email protected]>

vrothberg · 2020-06-16T09:02:28Z

I opened #6615 to fix the issue.

bttnns · 2020-06-16T12:17:03Z

nice! now that was a quick pr. can’t wait to try it out.

bttnns · 2020-06-16T12:40:29Z

now if i can figure out how to use podman in rootless mode with a USB device i’d be all set.

tried a yesterday and failed.
quite a bit of ls -la /dev/bus/usb/001/ inside the container looking like ? ? ? ???

vrothberg · 2020-06-16T15:15:02Z

@btannous feel free to reach out on IRC, the mailing list or via an issue here on GitHub if you questions or hit issues :)

bttnns · 2020-06-16T15:16:24Z

when i get back into it after work i’ll jump on IRC. :)

bttnns · 2020-06-20T15:10:00Z

Just following up @vrothberg

My device issues using podman rootless were fixed by audit2allow.
grep readsb /var/log/audit/audit.log | audit2allow -a -M mydevicefiltered
then loaded the module like it says and 🥳

rhatdan · 2020-06-22T10:28:12Z

What were the AVCs you were seeing?

bttnns · 2020-06-22T12:05:39Z

@rhatdan !
This was my first time using audit2allow, but the docs were really helpful so :) there.

[b@adsb adsb]$ cat mydevicefiltered.te #I’d assume this is what you are looking for? 

module mydevicefiltered 1.0;

require {
        type init_t;
        type usb_device_t;
        type admin_home_t;
        type container_t;
        class file { ioctl open read };
        class chr_file { ioctl open read write };
}

#============= container_t ==============
allow container_t usb_device_t:chr_file { ioctl open read write };

#============= init_t ==============
allow init_t admin_home_t:file { ioctl open read };



[b@adsb adsb]$ cat podman.sh # I saved the podman commands I initially ran, these were followed by podman generate systemd....
podman run -d --pull always --label "io.containers.autoupdate=image" --override-arch=arm64 --name adsb-readsb --device /dev/bus/usb/001/004 -p 8080:8080 -p 30005:30005 -e TZ=America/Chicago mikenye/readsb:latest --dcfilter --device-type=rtlsdr --fix --json-location-accuracy=2 --lat=33.12595 --lon=-96.87263 --modeac --ppm=0 --net --stats-every=3600 --quiet --write-json=/run/readsb
podman run -d --pull always --label "io.containers.autoupdate=image" --override-arch=arm64 --name adsb-piaware -e TZ=America/Chicago -e BEASTHOST=192.168.128.13 -e FEEDER_ID=09900bcd-6c92-4d95-ba1a-842956f75288 -e LAT=33.12595 -e LONG=-96.87263  mikenye/piaware:latest 
podman run -d --pull always --label "io.containers.autoupdate=image" --override-arch=arm64 --name adsb-x -e TZ=America/Chicago -e BEASTHOST=192.168.128.13 -e LAT=33.12595 -e LONG=-96.87263 -e ALT=614ft -e SITENAME=quaa00 -e UUID=583c4b5e-af3f-11ea-95b6-da672c6e7d17 mikenye/adsbexchange:latest

edit: this pi is in my garage hooked up to an RTLSDR (this one https://flightaware.com/adsb/prostick/ ) capturing ADSB and passing it to flightaware and adsbexchange.

edit2: I also had to give me group permissions

[b@adsb ~]$ cat /etc/udev/rules.d/42-usb-permissions.rules 
# /etc/udev/rules.d/42-usb-permissions.rules
SUBSYSTEM!="usb", GOTO="end_skip_usb"
ATTRS{idVendor}=="0bda", ATTRS{idProduct}=="2832", GROUP="b"
LABEL="end_skip_usb"

bttnns · 2020-06-22T12:19:11Z

ha. I feel like I can now properly own this shirt: https://shop.spreadshirt.com/mhayden/setenforce+1-A5d8a6aa81cbf3a25d5e9317b?productType=812&sellable=zrd3xQERz7uLe3JqmeJn-812-7&appearance=2

vrothberg · 2020-06-22T12:20:32Z

You make Dan very happy with that :)

rhatdan · 2020-06-22T16:29:43Z

Do you have some kind of terminal that is a usb_device_t?
ls -lZ/dev/ | grep usb_device_t

bttnns · 2020-06-22T17:42:31Z

@rhatdan

[b@adsb ~]$ ls -RlZ /dev/ | grep usb
crw-------. 1 root root    system_u:object_r:usbmon_device_t:s0       238,   0 Apr  1 17:24 usbmon0
crw-------. 1 root root    system_u:object_r:usbmon_device_t:s0       238,   1 Apr  1 17:24 usbmon1
drwxr-xr-x. 3 root root system_u:object_r:device_t:s0 60 Apr  1 17:23 usb
/dev/bus/usb:
/dev/bus/usb/001:
crw-rw-r--. 1 root root system_u:object_r:usb_device_t:s0 189, 0 Apr  1 17:24 001
crw-rw-r--. 1 root root system_u:object_r:usb_device_t:s0 189, 1 Apr  1 17:24 002
crw-rw-r--. 1 root root system_u:object_r:usb_device_t:s0 189, 2 Apr  1 17:24 003
crw-rw-r--. 1 root b    system_u:object_r:usb_device_t:s0 189, 3 Jun 22 17:41 004
crw-rw-r--. 1 root root system_u:object_r:usb_device_t:s0 189, 4 Apr  1 17:24 005
lrwxrwxrwx. 1 root root system_u:object_r:device_t:s0 18 Apr  1 17:24 189:0 -> ../bus/usb/001/001
lrwxrwxrwx. 1 root root system_u:object_r:device_t:s0 18 Apr  1 17:24 189:1 -> ../bus/usb/001/002
lrwxrwxrwx. 1 root root system_u:object_r:device_t:s0 18 Apr  1 17:24 189:2 -> ../bus/usb/001/003
lrwxrwxrwx. 1 root root system_u:object_r:device_t:s0 18 Apr  1 17:24 189:3 -> ../bus/usb/001/004
lrwxrwxrwx. 1 root root system_u:object_r:device_t:s0 18 Apr  1 17:24 189:4 -> ../bus/usb/001/005
lrwxrwxrwx. 1 root root system_u:object_r:device_t:s0 10 Apr  1 17:24 238:0 -> ../usbmon0
lrwxrwxrwx. 1 root root system_u:object_r:device_t:s0 10 Apr  1 17:24 238:1 -> ../usbmon1

rhatdan · 2020-06-22T18:05:31Z

How did one of those get into the container? Or would you expect the container to access these devices?

bttnns · 2020-06-22T18:09:47Z

I’m passing the device to the container using this:
podman run -d --pull always --label "io.containers.autoupdate=image" --override-arch=arm64 --name adsb-readsb --device /dev/bus/usb/001/004 -p 8080:8080 -p 30005:30005 -e TZ=America/Chicago mikenye/readsb:latest --dcfilter --device-type=rtlsdr --fix --json-location-accuracy=2 --lat=33.12595 --lon=-96.87263 --modeac --ppm=0 --net --stats-every=3600 --quiet --write-json=/run/readsb

tldr; podman .. —device /dev/bus/usb/001/004 ..

And yes, this particular container opens the usb RTLSDR device and listens on the 1090 freq for ADSB decoding using https://github.com/Mictronics/readsb

rhatdan · 2020-06-22T18:57:57Z

SGTM. nothing I have to change in the defauls. Great work btannous.

In rootfull mode the change policy would not be needed, I believe.

bttnns · 2020-06-22T19:11:44Z

+1 to that, tested and worked in rootfull mode without any changes (ie, without my custom module)

bttnns · 2020-06-22T19:12:28Z

Thanks again for the review!

openshift-ci-robot added the kind/bug Categorizes issue or PR as related to a bug. label Jun 15, 2020

vrothberg self-assigned this Jun 16, 2020

vrothberg mentioned this issue Jun 16, 2020

auto-update: use image's arch #6615

Merged

openshift-merge-robot closed this as completed in #6615 Jun 16, 2020

github-actions bot added the locked - please file new issue/PR Assist humans wanting to comment on an old issue or PR with locked comments. label Sep 23, 2023

github-actions bot locked as resolved and limited conversation to collaborators Sep 23, 2023

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

`podman auto-update` does not respect the `--override-arch=xyz` flag #6613

`podman auto-update` does not respect the `--override-arch=xyz` flag #6613

bttnns commented Jun 15, 2020 •

edited

Loading

bttnns commented Jun 15, 2020 •

edited

Loading

mheon commented Jun 15, 2020

bttnns commented Jun 15, 2020

vrothberg commented Jun 16, 2020

vrothberg commented Jun 16, 2020 •

edited

Loading

bttnns commented Jun 16, 2020

bttnns commented Jun 16, 2020 •

edited

Loading

vrothberg commented Jun 16, 2020

bttnns commented Jun 16, 2020

bttnns commented Jun 20, 2020

rhatdan commented Jun 22, 2020

bttnns commented Jun 22, 2020 •

edited

Loading

bttnns commented Jun 22, 2020

vrothberg commented Jun 22, 2020

rhatdan commented Jun 22, 2020

bttnns commented Jun 22, 2020

rhatdan commented Jun 22, 2020

bttnns commented Jun 22, 2020 •

edited

Loading

rhatdan commented Jun 22, 2020

bttnns commented Jun 22, 2020

bttnns commented Jun 22, 2020

podman auto-update does not respect the --override-arch=xyz flag #6613

podman auto-update does not respect the --override-arch=xyz flag #6613

Comments

bttnns commented Jun 15, 2020 • edited Loading

bttnns commented Jun 15, 2020 • edited Loading

mheon commented Jun 15, 2020

bttnns commented Jun 15, 2020

vrothberg commented Jun 16, 2020

vrothberg commented Jun 16, 2020 • edited Loading

bttnns commented Jun 16, 2020

bttnns commented Jun 16, 2020 • edited Loading

vrothberg commented Jun 16, 2020

bttnns commented Jun 16, 2020

bttnns commented Jun 20, 2020

rhatdan commented Jun 22, 2020

bttnns commented Jun 22, 2020 • edited Loading

bttnns commented Jun 22, 2020

vrothberg commented Jun 22, 2020

rhatdan commented Jun 22, 2020

bttnns commented Jun 22, 2020

rhatdan commented Jun 22, 2020

bttnns commented Jun 22, 2020 • edited Loading

rhatdan commented Jun 22, 2020

bttnns commented Jun 22, 2020

bttnns commented Jun 22, 2020

`podman auto-update` does not respect the `--override-arch=xyz` flag #6613

`podman auto-update` does not respect the `--override-arch=xyz` flag #6613

bttnns commented Jun 15, 2020 •

edited

Loading

bttnns commented Jun 15, 2020 •

edited

Loading

vrothberg commented Jun 16, 2020 •

edited

Loading

bttnns commented Jun 16, 2020 •

edited

Loading

bttnns commented Jun 22, 2020 •

edited

Loading

bttnns commented Jun 22, 2020 •

edited

Loading