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 # ASAP reboot 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. Correct. > 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. Correct. > 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. -- ciao, Marco
Attachment:
signature.asc
Description: Digital signature