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

Re: Udev 151-2 upgrade problem on debian-testing-'squeeze' i386 cd binary1 20090302-04-:09

Ciao Marco,

I've been working on wrapping my head fully around the various issues with
the udev and kernel upgrade, to ensure we have it documented properly in the
release notes.  It's clear to me that we will need to include documentation
of this issue in the release notes no matter what changes are made to the
packages, because users will need to know that the new udev won't work
correctly with the Debian 2.6.26 kernels.  At the same time, I think
something needs to change in the packages to improve the 'dist-upgrade'
experience, because we both know many users won't read the release notes.

First, what happened to the idea of using 'Breaks'?  This was proposed
months ago, but it hasn't been implemented yet in the package.  Should I
provide a patch that implements this?

Second, I've done some research and testing regarding the nature of the
incompatibility with CONFIG_SYSFS_DEPRECATED.  From what I see, the primary
impact of dropping the compat code from udev is that udev rules will no
longer be applied to certain devices, such as block devices and network
devices.  This will break /etc/udev/rules.d/70-persistent-net.rules, and
break any permission-setting on disks (e.g., the 'disk' and 'floppy' groups)
and certain alias symlinks for CD drives, but those are the only problems
I've been able to identify on a standard as a result of running udev 160
with CONFIG_SYSFS_DEPRECATED; and of these, only 70-persistent-net.rules is
potentially a boot-breaker, and would still permit booting the system far
enough to rescue by hand at console (i.e., the same process one would use if
a newer kernel was installed but not configured to boot by default, which is
one of the scenarios that currently permits bypassing this preinst error).

So do you know of any other things that will break, or can you provide
pointers to other areas I should look at?  You mention in the bug that some
rules "will not work in ways beyond most people's ability to understand",
but I don't even see any documentation here for those of us who *do* have
the ability to understand and want to try to explain it to the others.  :-)
If there aren't any other issues, then IMHO the case is clear for
downgrading the CONFIG_SYSFS_DEPRECATED handling from a preinst abort to a
preinst debconf note (i.e.: interrupt the upgrade before udev unpack, to
make sure the admin gets the message before we proceed).  Right now, the
cure (aborting the install of a core package during a dist-upgrade, leaving
apt in a difficult-to-fix state) is definitely much worse than the disease
(some devices not fully configured after reboot if the kernel isn't
upgraded, requiring the user to grab a console shell to install a proper

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.

Finally, you comment in
<http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=571255#89> that "the new
kernel (indirectly) depends on a newer udev."  In my testing, I'm able to
install a 2.6.32-5 kernel package from squeeze directly onto lenny without
upgrading udev in the process.  When you say it "indirectly depends", do you
mean that there is a *logical* dependency that isn't reflected in the
package dependencies, or are you referring to some earlier situation whereby
upgrading the kernel package did pull in a udev upgrade at the same time?

To summarize, with the information I have available, I believe there are two
changes that should be made to the udev package:

 - add the Breaks: linux-image-2.6-$flavor
   (<< $SYSFS_DEPRECATED_fixed_version) to udev, as discussed
 - change the preinst CONFIG_SYSFS_DEPRECATED abort to a debconf error note
   warning users about the network, permissions problems if they don't
   install a new kernel

But I know that I may have overlooked some details.  If you see any problems
with my suggestion, please let me know what they are so that I can look for
better solutions.

And if there aren't problems with this proposal, I'm happy to prepare a
patch to the package for this if that would be helpful to you.

Steve Langasek                   Give me a lever long enough and a Free OS
Debian Developer                   to set it on, and I can move the world.
Ubuntu Developer                                    http://www.debian.org/
slangasek@ubuntu.com                                     vorlon@debian.org

Attachment: signature.asc
Description: Digital signature

Reply to: