Causes errors if present. Already removed in lxc-gentoo @ https://github.com/globalcitizen/lxc-gentoo/commit/26e407cf93cd0c047fea0b155cf732ecd1f9c8b7 Reproducible: Always Steps to Reproduce: 1. Start an explicit LXC guest running openrc. Actual Results: Errors observed. Expected Results: No errors observed, code should not be run anyway!
could you post the errors, please? Unless i'm out-of-date, kmod-static-nodes is a necessary startup script for most general installations, ever since kmod-14 and udev-206(? somewhere around there) hit the portage tree: static devnodes are not created without it (unless using eudev, that is; eudev will still create them if not already present), and sys-fs/udev expects static nodes to already exist in /dev upon startup (as undefined behaviour occurs if they do not). I expect it would make more sense to exclude kmod-static-nodes (and possibly other scripts) from starting via some other method; perhaps an lxc-specific (set of) runlevels??
AFAIK the purpose of openrc's rc_sys="lxc" setting within /etc/rc.conf is explicitly to remove useless/damaging code from non-standard environments such as LXC. Hence, this bug report, which is not the first of its genre I have made.
Hrrm. Perhaps you have a point, and this is merely a quirk of my kernel. Errors are: " * Creating list of required static device nodes for the current kernel ...Warning: /lib/modules/${KERNEL_VERSION}/modules.devname not found - ignoring [ ok ]"
Thinking about it, no that's not valid because /lib/modules is ~never used in an LXC guest (since it's not typically authorized to add modules to the kernel, as this would pretty much destroy the point of a container, by granting CAP_SYS_ADMIN or similarly high privilege).
what this specifically does is creates devnodes specifically for modules such as tun, fuse, etc.; unless /dev from the host has already run kmod-static-nodes and the host /dev has been propagated verbatum to the guest, i expect this is still important. A good example of this would be 'tun' ; kmod-static-modes creates the /dev/net/tun node so that it exists to trigger the kernel's auto-module-loading when something requires access to tun. That said, /dev/net/tun will also be created if the tun module has been loaded through other means (i.e. modprobe). I don't know if the LXC guest would need superior privileges to trigger this loading? (i have zero experience with LXC) A quick test would confirm or not, though: 1- configure kernel with tun support as a module, 2- ensure tun is not modprobe'd before starting a guest, 3- start the guest, use something that manipulates a tun iface (openvpn is a good example)
Normally (but not always), tun interfaces are set up on the host-side by the LXC userspace utilities (lxc-start), as is a guest-side equivalent. The guest and the host communicate between them. While I see your use case (no tun interfaces pre-initialized on the host, guest runs, dev nodes possibly don't exist within the guest and things like openvpn could in theory fail) this is pretty obtuse and quite possibly has the easy fix of just loading the requisite module on the host before starting the guest. On the other hand, since /lib/modules/* are not going to be present in the guest anyway, and according to the errors displayed running this code will therefore fail anyway, I'm not seeing much of an argument for keeping it.
Do the host and the lxc guest share the same /dev directory? If they do, the correct fix is probably to add -lxc to the keywords for kmod-static-nodes and tmpfiles.dev. Removing the script from the runlevel as shown in the commit in the description of this bug does not work if the host and guest are sharing the same OpenRC setup.
The host and guest have distinct /dev directories. Generally, the guest sees a reduced set of devices controlled through an lxc.conf device access control list. Furthermore, the guest can run either no init system or an arbitrary init system which has no relationship to the host whatsoever.
It seems like this init script should not run inside an lxc guest, so we need to add -lxc to the keywords line. Thanks, William
(In reply to William Hubbs from comment #9) > It seems like this init script should not run inside an lxc guest, so we > need to add -lxc to the keywords line. > > Thanks, > > William +1
done in kmod-18-r1 and 9999
