I have debian 6.0.x Linux with Gentoo OpenVZ Virtuals installed in them. The OpenVZ kernel, shipped with Debian has no DEVTMPFS enabled, so, udev in OpenVZ containers don't work. Udev-171 is last existing udev, which don't need DEVTMPFS. It is now masked, and marked for removal at 60 days. Please, don't do it. Let it be in the tree. Debian 7.0.x, AFAIK don't have OpenVZ kernel at all, so i can't upgrade to it. Reproducible: Always
And if you remove udev and udev-mount from runlevels and handle creating the required /dev entries by `mknod` and `MAKEDEV` after mounting it by hand as 'tmpfs'? That is what I'm reading how others solved the issue. If that is really the way to go with about this, then it should be automated somehow by the boot process. But yes, I can change the mask message and remove the '60 days' from it so we can keep the old udev for a bit longer. However keeping behind with sys-fs/udev is the most stupidest solution for the problem, and is not really going to work since many packages in Portage already require at least 196, 197.
Well, i shall try to do it.
Well, i removed udev from init scripts, now there is hundreds of devices in /dev (which doesn't actually exist). By now there is only one error - gentoo tries to open Console 12 (Alt+F12), i think, to throw messages, but there is no such console in OpenVZ, so it throws many errors in syslog. When i begin to add devices to container (i need to proxy audio card to virtual machine), may be other problems will occur.
I see MAKEDEV being used for console at: http://forum.openvz.org/index.php?t=msg&th=11196&goto=48348&#msg_48348 And I see: $ grep mknod /etc/init.d/udev-mount [ -c /dev/console ] || mknod -m 600 /dev/console c 5 1 [ -c /dev/tty1 ] || mknod -m 620 /dev/tty1 c 4 1 [ -c /dev/tty ] || mknod -m 666 /dev/tty c 5 0 [ -c /dev/null ] || mknod -m 666 /dev/null c 1 3 [ -c /dev/kmsg ] || mknod -m 660 /dev/kmsg c 1 11 What about creating own init script for OpenVZ to initialize these /dev nodes?
It creates it, no problem. There is tty12 in /dev. Problem is that OpenVZ does not permit to write something to it. It says - "operation not permitted".
Ouch. Find an answer. http://forum.openvz.org/index.php?t=msg&goto=34850& . Now it is working.
So, now i can work in OpenVZ without udev. Now, i think, i will wait for one of three things - 1) Gentoo team changes something in eudev (so, that it can be with or without DEVTMPFS). Well, i don't believe, that it can be done. 2) RHEL team will release RHEL7, and OpenVZ will be made for 3.x.x kernels 3) This thing - http://openvz.org/Vzctl_for_upstream_kernel will evolve into something more usable
I think, bug may be closed.
(In reply to comment #8) > I think, bug may be closed. OK, lets wait for what the OpenVZ maintainers have to say about this first (the people in the vserver-devs@g.o mail alias)
I'm not sure what kernel specifically is being used by Digital Ocean but existing gentoo users there are affected by this same issue. (they are not allowing any new gentoo builds until they come up with another image. Portage is already failing to update and trying to force udev-202 even though I have it masked.
You
If you have use >200 udev, you can run ( in test enviroment) openvz in vanilla kernel ( >3.7 is minimal, latest recommended). http://wiki.openvz.org/Vzctl_for_upstream_kernel
Udev is a nice feature to have inside containers and personally I use it on my servers. But evidently to have this feature administrator either have to use kernel with DEVTMPFS enabled or build own kernel. In my view building kernel is not a hard task in Gentoo - just take config from upstream, build it with gcc-4.4 (or for me it works with gcc-4.6...) and use dracut to generate initramfs... The problem in this bug is that debian do not enable required features in their kernel. In my opinion this is bug in debian kernels so, please, post it there. Note, upstream suggested configuration ( http://download.openvz.org/kernel/branches/rhel6-2.6.32/042stab076.8/configs/config-2.6.32-042stab076.8.x86_64 ) has everything required enabled. If it's impossible to convince debian maintainer or build customized kernel then it's possible to disable/mask udev in stages and maintain static device nodes.
And update subject as it adds misunderstanding. It's perfectly valid to have both options enabled: vz ~ # egrep 'CONFIG_(VE|DEVTMPFS)=' /boot/config-2.6.32-openvz-076.8 CONFIG_VE=y CONFIG_DEVTMPFS=y
(In reply to Peter Volkov from comment #14) > And update subject as it adds misunderstanding. It's perfectly valid to have > both options enabled: > > vz ~ # egrep 'CONFIG_(VE|DEVTMPFS)=' /boot/config-2.6.32-openvz-076.8 > CONFIG_VE=y > CONFIG_DEVTMPFS=y From this thread, http://forums.gentoo.org/viewtopic-t-917082-start-25.html See post from 'chris972' saying, "The "!VE" makes all the difference. You CAN'T activate it with openvz, because devels consider OpenVZ can't work with DEVTMPFS." I've verified it back then, it was not possible to enable both at the same time, has this been changed in later OpenVZ patchsets?
Interesting. As far as I see, there is no such restriction anymore: config DEVTMPFS bool "Create a kernel maintained /dev tmpfs (EXPERIMENTAL)" depends on HOTPLUG && SHMEM && TMPFS And I remember there was a change to make devtmpfs "virtualized" (work in CTs), so I think that issue was fixed.
(In reply to Peter Volkov from comment #16) > Interesting. As far as I see, there is no such restriction anymore: > > config DEVTMPFS > bool "Create a kernel maintained /dev tmpfs (EXPERIMENTAL)" > depends on HOTPLUG && SHMEM && TMPFS > > And I remember there was a change to make devtmpfs "virtualized" (work in > CTs), so I think that issue was fixed. I'll take your word for it (since you can enable both at the same time) (And that'd be this bug FIXED then, and old $subject was correct :-)
kk ;)
