Hi, As far as I could understand, every distribution have problems with udev in containers.
For instance, on the OpenVZ wiki, it is recommended for Gentoo (http://wiki.openvz.org/Gentoo_template_creation#Set_up_udev ) to make udev handle devices as static. For CentOS 5 ( http://community.livejournal.com/openvz/24027.html ), they prebuilt containers tarballs so that udev would put nodes in "/etc/udev/devices" instead of "/dev", so that it will not interfere with applications searching what they need in "/dev"... which seems a little bit clunky workaround to me ; noticeably towards the fact that they use a system of main arborescence tarball that I do not really like, for it is quite a pain to maintain up to date, IMHO (I prefer boostraping from an "approx" server). For Etch, official OpenVZ wiki ( http://wiki.openvz.org/Installing_udev_in_VE_based_on_Debian-4.0 )suggests to modify udev's postinst script (not making it touch "/proc/sys/kernel/hotplug" , which is not allowed in a container) and to add the kernel "sysfs" capacity to the container (which I am not very comfortable with : the least kernel capacities the containers have, the most I am happy - otherwise, it kind of defeats the purpose of isolation). Generic documentation in OpenVZ wiki ( http://wiki.openvz.org/Physical_to_VE#.2Fdev ) explains that "/dev" mounted on "tmpfs" does not get well along with containers, and recommends their "/dev" to be static. To say a bit more about why I am bothered with udev, I should say that I build my containers using a basic "debootstrap", which do not (yet ?) make udev installed. So far, so good. Problems start occuring for things using udev such as libsane : first, udev will not get installed, not only because it cannot touch "/proc/sys/kernel/hotplug", like on Etch, but also because if I comment this one, it will fail to populate "/dev" from something in "/tmp". Which in turns prevents me from installing things that only depend upon it. Another problem occurs if I finally get udev installed, so much tweaking the postinst script that it gets installed, but not really configured. On the "udev" service start, especially on the next reboot of the container, it has good chances to wreak havocs in the once static "/dev", being able to prevent "tty" and such creation, but also potentially destroying specific devices (printers, scanners, ...) manually added to the container (openvz config files allow for a node on the "mother-OS" to be shared, but it is done on the container start through "makedev", and before "udev" enters the game, if it is installed - when it starts, it destroys what has been manually made). So, to clarify my thoughts, I guess, following OpenVZ recommendations, along with the bit of tryouts I made in my corner, that "udev" should neither be made to run in a container, nor touch the "/dev" entries. It could very well only get installed there only to satisfy dependencies, though not being activated. This may totally be a silly idea (I will not pretend knowing more of udev that its maintainer ;) "udev" works really good in Debian, by the way), but could an "/etc/default/udev" config file mention a "CONTAINER" variable that, if set to "1", will prevent its init script from being started (or from touching "/dev") and "dpkg" from making it configure the "/dev" ? I guess it may be a bit filthy towards "dpkg", but in that case, maybe also adding a preseeding entry could accomplish the same ? This way, it could be pointed in "/usr/share/doc/openvz/..." that such things should be defined in "/etc/default/udev" and in "dpkg" preseedings, for a container, so that "udev" could be installed there, and not cause any problems. In the meantime, those needing "udev" for specific hardware and such could use it on the hardware node. For instance, my LaserJet printer does need a udev script from "foo2zjs" : well, it is on the Hardware Node and in the CUPS container, but as "udev" only runs on the HN, it is enough for "udev" to load the firmware from there - the containers does not see anything particular : from its point of view, it only sees a printer which already has its firmware loaded, thanks to another home-made persistent symlink creation udev rule, that make me able to share this particular printer with this particular container, once it already is functionnal. In that case, you can see there is no use for "udev" to run in the container. As for the "dpkg" preseeding, even if "udev" were to be included in "debootstrap" in some time, it could as well get useful for future "udev" upgrades, when it will prevent from touching the static "/dev" as well. It would still be a workaround, but cleaner, IMHO, than make "udev" write wherever but in "/dev" (CentOS 5's method, linked in the begining of my message), while still allowing things hard-depending on "udev" to be installed. There still is something that I am wondering about, though : if some init scripts required "udev" to be running so that they could start, making "udev" start and write "wherever but in /dev" could be an useful trick... are there such packages that require in their initscript that "udev" is already running, in order for them to start ? Well, could this kind of modification to "udev", to keep it quiet in containers, could be envisaged ? If it were the case, I would really be willing to test and tell you which things in the postinst script cause problems, if you cannot test it for yourself. Regards. Tuomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
