Re: making udev require 2.6.15 kernels
On Fri, Feb 10, 2006 at 01:54:42AM +0100, Marco d'Itri wrote:
> On Feb 10, Otavio Salvador <email@example.com> wrote:
> > But udev will refuse to start or to install if the running kernel is
> > older then it?
> As it currently happens, it will either:
> - refuse to be upgraded
> - be installed but not started if it was not installed yet
> - not be started at boot time if the kernel is downgraded
Marco, we need to have a serious discussion about this udev thing. Now that
the ramdisk generator thingy is fixed or almost so, udev will be the next
major cause of pain for our users.
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.
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.
You are the best placed to lead this discussion, so please contribute to it
with an open mind, and be tolerant if we propose stupid sollutions you already
rejected or such, as we (well at least i) don't know udev as well as you.
The facts as i understand them are (correct me if i am wrong) :
- older udev with newer kernel works mostly, but some events are lost.
- newer udev with older kernel breaks big time (no idea how it breaks
- when upgrading newer udev, the older one is removed, thus triggering the
newer udev with older kernel problem.
=> this would mean that the only sane solution, as you proposed is to install
the newer udev after the kernel upgrade, but this is not practical.
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 ? This sounds like the sanest
solution (having udev install in /etc/udev and old-udev install in
/etc/udev-legacy or something ?).
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
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 ?
Thanks for your work on the udev package.