Steve writes: > Third, you write that the old udev *also* won't work with the new > kernel. Can you be more specific? In my testing, this also works > fine; I wasn't able to identify anything out of place when rebooting > to a 2.6.32 Debian kernel with a lenny udev.
If indeed the old udev doesn't work with the new kernel, and the new udev doesn't work with the old kernel, and this situation cannnot be rectified somehow, then the only correct solution is to change the udev packages so that it is possible to install multiple versions of udev at once and use the correct one at runtime (or initramfs build time). This follows from the following analysis: We want the system never to be unbootable. It's not acceptable if an interrupted upgrade can result in a need to use rescue media. This means that there must always be a kernel+initramfs pair (in /boot and wired into the bootloader) which is compatible with the installed udev. That means that before we replace the old udev with the new udev, we must have previously generated and installed a kernel+initramfs pair which contain the new kernel and the new udev. (And, as an aside, we must have done this without overwriting the previous kernel and initramfs.) However, the udev on the initramfs is copied from the running system when the initramfs is build. That means we can't generate the initramfs for the new kernel until we have upgraded udev. If there is backward compatibility in at least one direction, then the dependencies (and/or safety catches in maintainer scripts) can be arranged to do the right thing without needing to guess what is going on from apt/dpkg command lines or the like. Ian. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
