Your message dated Thu, 2 Apr 2009 03:47:38 +0200
with message-id <[email protected]>
and subject line Re: Bug#503953: udev will not install in a Lenny OpenVZ
container
has caused the Debian Bug report #503953,
regarding udev will not install in a Lenny OpenVZ container
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact [email protected]
immediately.)
--
503953: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=503953
Debian Bug Tracking System
Contact [email protected] with problems
--- Begin Message ---
Package: udev
Severity: normal
*** Please type your report below this line ***
Howdy,
As libsane-extras maintainer, Julien Blache, told me, there seems to be
plans for dropping makedev and such support starting from Debian
Squeeze, in exclusive favor of udev.
Problem is udev will not install in a Lenny OpenVZ container, as such
environments are restricted on purpose. OpenVZ makes it so the Hardware
Node (HN) runs the kernel, and Virtual Environments (VEs) run under
/var/lib/vz/private/${ID}, just accessing a very basic subset of the
kernel capacities ; ie one kernel, many Debians. You could see this as a
super-chroot, I guess...
Problem is the line "echo > /proc/sys/kernel/hotplug" in the postinst
script will make the installation of udev abort, as this thing is not
allowed in a container (basically built with a simple debootstrap).
It was a known bug in OpenVZ upstream, and their wiki suggested
commenting out this line for Etch. But with Lenny, the script will hang
trying to copy basic things from /tmp in the /dev directory...
So as for now, udev will not install in a Debian Lenny OpenVZ container.
Not that udev is not usefull on the HN : for instance, I use it to
create persistent symlinks for hardware I want to share with the VEs, or
to load the firmware into my LaserJet 1018 printer - but in VEs,
there is no real use for this : a static /dev is really sufficient...
but some people like Julien seem to think udev static alternatives are vowed
to death, and, if we do not ask them otherwise, will consider it is not worth
taking care of those... which implies dependency to udev, which cannot
be installed, causing a few limitations in packages able to be
installed in containers. Though I share a lot of hardware with VEs (HP
LaserJet 1018 and PhotoSmart D5160, Epson Perfection 1670, and 4 Hauppauge
DVB-T cards), without needing udev, so...
If udev alternatives were to be dropped in a relatively near future
(better to be worried much too early than much too late), could udev be
fixed so that it will install in such a container ? If this was not the
case, could you put a clear statement declaring that for things like
containers, makedev and such _should_ _not_ be abandonned ?
Toward this matter OpenVZ upstream does recognize udev does not get well
along with containers, and recommends deactivating this one in VEs...
though I have discussed with some people saying it did not have problems with
it in, for instance, CentOS... so I guess udev is a possible thing in
containers.
It is not that much a problem for Lenny, as makedev alternative is still
generally taken into account, but I am worried about what could happen in the
future.
Well, I am not sure about the best thing to do, but I would be grateful
if you took that matter in consideration.
Regards.
Tuomas
-- System Information:
Debian Release: lenny/sid
APT prefers testing
APT policy: (900, 'testing')
Architecture: i386 (i686)
Kernel: Linux 2.6.26-1-openvz-686 (SMP w/1 CPU core)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
--- End Message ---
--- Begin Message ---
Version: 0.140-1
On Oct 29, Tuomas Noraef <[email protected]> wrote:
> Problem is the line "echo > /proc/sys/kernel/hotplug" in the postinst
I fixed this in 0.140-1, postinst now uses /sys/kernel/uevent_helper
which does not exist in VEs so it will not try to enable udev at
installation time.
The init script already performs the same check, so udev will never be
started. It's not a good idea to start it anyway, since AFAICS VEs only
have a very partial subset of sysfs (the sysfs capability did not change
anything on my system) and generated uevents appear to be lost.
> It was a known bug in OpenVZ upstream, and their wiki suggested
> commenting out this line for Etch. But with Lenny, the script will hang
In my experience, the openvz wiki is full of cargo cult administration
tips provided by random lusers.
Do not trust if further than your knowledge.
--
ciao,
Marco
signature.asc
Description: Digital signature
--- End Message ---
