Auto-connection request for system-files in tegra gadget

Hello, I would like to request a new path to be added to the tegra gadget snap auto connection in order to enable uc24.


  • name: tegra
  • description: This gadget enables Nvidia AGX Orin and Orin Nano/NX to work with Ubuntu Core
  • snapcraft: snapcraft.yaml
  • upstream: This gadget snap reuses the pc gadget snap from here
  • interfaces:
    • \system-files:
      • request-type: auto-connection
      • reasoning: In order to run certain workloads on nvidia tegra platforms, we need certain device nodes present on the system. For example, in order to use the hardware encoders/decoders on an NX platform with nvidia’s gstreamer plugins, we need /dev/v4l2-nvdec and /dev/v4l2-nvenc on the system. This is handled on Classic using udev rules with the following lines:
KERNEL=="15480000.nvdec", DRIVER=="tegra-nvdec", ACTION=="bind", RUN+="/bin/mknod -m 666 /dev/v4l2-nvdec c 1 3"
KERNEL=="154c0000.nvenc", DRIVER=="tegra-nvenc", ACTION=="bind", RUN+="/bin/mknod -m 666 /dev/v4l2-nvenc c 1 3"

This request is similar to a previous one: Request auto-connection for system-files in tegra gadget the difference being that for UC24, we don’t need to add a systemd configuration anymore and the path for the udev files changed slightly in the install-device hook from /run/mnt/ubuntu-data/system-data/_writable_defaults/etc/udev/rules.d to /run/mnt/data/system-data/_writable_defaults/etc/udev/rules.d.

Here is the full snapcraft.yaml:

name: tegra
version: '24-0.1'
type: gadget
base: core24
summary: Gadget for Nvidia Tegra devices
description: |
    This gadget enables Nvidia AGX Orin and Orin Nano/NX to work with Ubuntu Core.

    To create a bootable image, include this snap and the \"tegra-kernel\"
    kernel snap in your model assertion and flash the device.
confinement: strict
grade: stable

package-repositories:
  - type: apt
    ppa: ubuntu-tegra/updates
  - type: apt
    components: [main]
    suites: [r36.4]
    key-id: 3C6D1FF3100C8C3ABB0869C0E6543461A9996195
    key-server: https://repo.download.nvidia.com/jetson/jetson-ota-public.asc
    url: https://repo.download.nvidia.com/jetson/t234
    architectures: [arm64]
  - type: apt
    components: [main]
    suites: [r36.4]
    key-id: 3C6D1FF3100C8C3ABB0869C0E6543461A9996195
    key-server: https://repo.download.nvidia.com/jetson/jetson-ota-public.asc
    url: https://repo.download.nvidia.com/jetson/common
    architectures: [arm64]

platforms:
  tegra:
    build-on: [arm64]
    build-for: [arm64]

hooks:
  install-device:
    plugs: [etc-udev-rules-dot-d]
  post-refresh:
    plugs: [etc-udev-rules-dot-d]

plugs:
  etc-udev-rules-dot-d:
    interface: system-files
    write:
    - /etc/udev/rules.d
    - /run/mnt/data/system-data/_writable_defaults/etc/udev/rules.d

# Min version to support shim 15.7 and min-size
assumes:
  - snapd2.60.1

parts:
  boot-assets:
    plugin: nil
    stage-snaps:
      - pc/24/stable

  udev-rules:
    plugin: nil
    stage-packages:
      - nvidia-l4t-init
    stage:
      - etc/udev/rules.d

Thanks in advance!

This request has been added to the queue for review by the @reviewers team.

Hi @sebwey,

This makes sense to me. +1 from me for granting the auto-connection of etc-udev-rules-dot-d system-files interface.

Hey folks,

This also sounds reasonable to me. +1 from me

+2 for, 0 against granting tegra access to the requested directories via system-files interface. This is now live.

Hey @shishirsub10 ,

I tested out a new revision of the gadget snap that has the auto connection granted. However, it still fails with the following message:

mkdir: cannot create directory ‘/run/mnt/data/system-data/_writable_defaults/etc/udev’: Permission denied

The install-device hook that is failing is the following:

mkdir -p /run/mnt/data/system-data/_writable_defaults/etc/udev/rules.d
cp $SNAP/etc/udev/rules.d/* /run/mnt/data/system-data/_writable_defaults/etc/udev/rules.d/

I assume we also need to get write access through system-files to /run/mnt/data/system-data/_writable_defaults/etc/udev in addition to the path that was granted in this auto-connection request?