** Changed in: snapd
Milestone: 2.68.3 => 2.68.5
** Description changed:
- [SRU] 2.68.3:
+ [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
- snap changes <---- there should be an error to initialize system state
+ 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.3 deb
+ 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
