** Description changed: [SRU] 2.68.5: https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/2098137 [ Impact ] Error containing "cannot reload udev rules: exit status X" when doing an actions e.g. installation of core on a privileged container. [ Test Plan ] 1. Produce error with snapd 2.66.1 deb snap install lxd --channel=5.0/stable lxd init (use defaults) - lxc launch -c security.privileged=true ubuntu:20.04 private-20.04 - lxc exec private-20.04 -- bash + lxc launch -c security.privileged=true ubuntu:20.04 private-2004 + lxc exec private-2004 -- bash snap changes <---- there should be an error to initialize system state snap change=x <---- look at the change with the error at the bottom, should see "ERROR cannot reload udev rules: exit status 1" exit 2. Change to snapd 2.68.5 deb lxc exec private-20.04 -- bash snap changes <---- expect the last "Initialize system state" with no Error exit Repeat for all targeted Ubuntu releases. ---original--- I think this is possibly a known issue since there's evidence of a workaround in e.g. https://stgraber.org/2017/01/13/kubernetes-inside- lxd/, but I couldn't find any proper discussion of it. Installing snaps in a privileged LXD container fails. Here's a test script: $ lxc launch -c security.privileged=true ubuntu:16.04 snap-test $ lxc exec snap-test apt update $ lxc exec snap-test apt install squashfuse $ lxc exec snap-test snap install hello-world 2017-08-24T12:03:59Z INFO cannot auto connect core:core-support-plug to core:core-support: (slot auto-connection), existing connection state "core:core-support-plug core:core-support" in the way error: cannot perform the following tasks: - Setup snap "core" (2462) security profiles (cannot setup udev for snap "core": cannot reload udev rules: exit status 2 udev output: ) - Setup snap "core" (2462) security profiles (cannot reload udev rules: exit status 2 udev output: ) This is because /sys is mounted read-only in privileged containers (presumably to avoid causing havoc to the host) and so the systemd-udevd service isn't started. The prevailing recommendation seems to be to work around it by making /usr/local/bin/udevadm be a symlink to /bin/true, but this looks like a hack rather than a proper fix.
** Description changed: [SRU] 2.68.5: https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/2098137 [ Impact ] Error containing "cannot reload udev rules: exit status X" when doing an actions e.g. installation of core on a privileged container. [ Test Plan ] 1. Produce error with snapd 2.66.1 deb snap install lxd --channel=5.0/stable lxd init (use defaults) lxc launch -c security.privileged=true ubuntu:20.04 private-2004 lxc exec private-2004 -- bash snap changes <---- there should be an error to initialize system state - snap change=x <---- look at the change with the error + snap change x <---- look at the change with the error at the bottom, should see "ERROR cannot reload udev rules: exit status 1" exit 2. Change to snapd 2.68.5 deb lxc exec private-20.04 -- bash snap changes <---- expect the last "Initialize system state" with no Error exit Repeat for all targeted Ubuntu releases. ---original--- I think this is possibly a known issue since there's evidence of a workaround in e.g. https://stgraber.org/2017/01/13/kubernetes-inside- lxd/, but I couldn't find any proper discussion of it. Installing snaps in a privileged LXD container fails. Here's a test script: $ lxc launch -c security.privileged=true ubuntu:16.04 snap-test $ lxc exec snap-test apt update $ lxc exec snap-test apt install squashfuse $ lxc exec snap-test snap install hello-world 2017-08-24T12:03:59Z INFO cannot auto connect core:core-support-plug to core:core-support: (slot auto-connection), existing connection state "core:core-support-plug core:core-support" in the way error: cannot perform the following tasks: - Setup snap "core" (2462) security profiles (cannot setup udev for snap "core": cannot reload udev rules: exit status 2 udev output: ) - Setup snap "core" (2462) security profiles (cannot reload udev rules: exit status 2 udev output: ) This is because /sys is mounted read-only in privileged containers (presumably to avoid causing havoc to the host) and so the systemd-udevd service isn't started. The prevailing recommendation seems to be to work around it by making /usr/local/bin/udevadm be a symlink to /bin/true, but this looks like a hack rather than a proper fix. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1712808 Title: udev interface fails in privileged containers To manage notifications about this bug go to: https://bugs.launchpad.net/launchpad/+bug/1712808/+subscriptions -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
