[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: making udev require 2.6.15 kernels

On Feb 10, Sven Luther <sven.luther@wanadoo.fr> wrote:

> We need something which upgrades seamlessly, and the above solution is not
> acceptable for the etch release, as has been said already in the past.
This would be nice, but so far nobody has been able to design anything
better, myself included.

> So, let's start to look for a real solution here, knowing that a kernel
> upgrade will mean a reboot anyway, but there is really no need to impose two
> reboots on the user.
My only alternate proposal is:

# disables the kernel version check
touch /etc/udev/force-upgrade
# this will also pull new initramfs, hal and $DEITY knows what else
apt-get install udev linux-image-whatever

But I am not sure about its merit.
It probably needs a few more tweaks to the package because postinst will
not be able to start udevd.

>   - older udev with newer kernel works mostly, but some events are lost.
Not really. udev versions older than 072 do not support the new nested
classes used by the input subsystem in kernels >= 2.6.15.
The effect is that device nodes in /dev/input/ will not be created, and
the respective drivers will not be loaded.
Also, udev versions older than 059 have some bugs which break
referencing sysfs attributes since kernel 2.6.12.
The first problem is the important one.

>   - newer udev with older kernel breaks big time (no idea how it breaks
>     though).
They will not even start, because they depend on recent kernel features
like $MODALIAS variables and netlink uevents.

>   - when upgrading newer udev, the older one is removed, thus triggering the
>     newer udev with older kernel problem.

> Is it not possible to have a newer udev which is not removing the older udev,
> so you have both installed, and the older udev will work with older kernels
> and the newer udev will work with newer kernels ?
I do not believe that this would be possible, at least for the general
case, because the version of udev in stable is almost a different
program with different interfaces with other system components.

> Also, what about 2.4 kernels, they don't use udev right ? so the point is moot
> with them, and the only problem is the sarge 2.6.8 -> etch 2.6.15+ upgrade
> path.

> Also, could you comment more about the many breakage we have recently seen
> with udev, and if we can expect this to stabilize in the etch timeframe, or if
> it will continue to be problematic ? 
Can you be more specific? I do not remember many breakages recently.
I am sure that I can manage to have a stable package ready in time for
the release, just like I did for sarge.
As a plus, udev and the related kernel interfaces are much more mature
and much less a moving target than two years ago, so I do not expect
more troubles in the future.


Attachment: signature.asc
Description: Digital signature

Reply to: