Re: making udev require 2.6.15 kernels
On Fri, Feb 10, 2006 at 01:54:37PM +0100, Marco d'Itri wrote:
> On Feb 10, Sven Luther <sven.luther@wanadoo.fr> wrote:
>
> > 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.
> I think that this can be arranged easily (by not killing the old udevd)
> with a few package tweaks and should not cause any problems as long as
> the next reboot will happen "soon".
> I'm just not sure if it can/should be automatic too.
Well, we put a pre-inst debconf question here, where we ask the user if he
wants to go ahead and reboot as soon after the install, or abort.
If he wants to go ahead, we doit and put a postinst deconf note stressing he
should reboot with the newer kernel ASAP (in the do-it-now style).
> Even if for some reason the old daemon could not be kept running then
> /dev will continue working until the next reboot.
Cool.
> > 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.
> If the new kernel fails and users reboot again with the old kernel then
> the system will boot using the static /dev. How much this will break is
> system-dependent and impossible to predict.
Ok, but there is a sane setup to fall back on. As i mentioned to Jonas, the
best way to recover from this is probably to boot into the recovery mode of
d-i anyway.
> > 1) sarge-udev & etch-udev install concurently, maybe using the divert or
> > alternative mechanism to not overwrite their files.
> As I explained, I do not believe that on-disk co-existence of two udev
> packages is feasible.
Mmm, even if for a short time as planed here ?
> > I got a guy complaining about powerpc/alsa being broken this past week for
> Nobody reported this to me.
Yeah, i asked him to file a bug report though, but you can't thrust those
powerpc guys to do that :)
> > Ah, it needs to be ready at etch freeze time, that is end of july.
> This is a lot of time.
Well, less than 6 months now, so now is the best time to handle this. We still
need to tackle the out-of-tree module issues, and the non-free firmware too.
Friendly,
Sven Luther
Reply to: