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

Re: making udev require 2.6.15 kernels



On Fri, Feb 10, 2006 at 11:27:12AM +0100, Marco d'Itri wrote:
> 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.

Yeah, but more heads together searching actively may find a solution where
people alone have not.

More to this later, as i am busy, just a few comments now.

> > 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.

Notice, the only case we really have to deal with is the case where the system
is already running with a 2.6.8 (or random self built) kernel, using the older
udev, and we are installing a newer kernel and udev.

The 2.6.8 kernel is already running, and the kernel upgrade needs a reboot
anyway, so, we only need something that :

  - don't mess up the currently running stuff, is it possible to have udev
    installed to take effect after the next reboot, and keep the old udev live
    until then ? 

  - installs without trouble.

  - works fine when the newer kernel is booted into.

This should be possible without too much pain, it mostly depends on the first
item, which doesn't need a fully concurent udev, just that the currently
running one is kept upto the reboot.

Naturally, the problem with this approach is that if the reboot with the newer
kernel fails, then the user is hosed, but this can be worked with in some
manner.

So let's imagine the following scenario :

  1) sarge-udev & etch-udev install concurently, maybe using the divert or
  alternative mechanism to not overwrite their files.

  2) when etch-udev is installed, it doesn't remove the older one, but also
  doesn't activate itself.

  3) at boot time, before any of the udev thingy is called, a script is run,
  which checks the kernel version, and activate one of the two alternatives.

Well, it may even work in the general case, upto a point, not sure, but it
should be helpful at least in the sarge->etch upgrade scenario.

> > 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 got a guy complaining about powerpc/alsa being broken this past week for
example, but i vaguely remember other issues these past month too.

> I am sure that I can manage to have a stable package ready in time for
> the release, just like I did for sarge.

Ah, it needs to be ready at etch freeze time, that is end of july.

> 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.

Which sounds cool, but doesn't help with sarge->etch upgrades sadly.

Mmm, this became longer than i thought it would.

Friendly,

Sven Luther



Reply to: