Re: Desktop upgrade strategy (was: What should be upgraded first: kernel or userland?)
On Mon, Mar 26, 2007 at 12:29:43AM +0200, Javier Fernández-Sanguino Peña wrote:
> On Sun, Mar 25, 2007 at 03:20:17AM -0700, Steve Langasek wrote:
> > > No, see the mail I sent previously, many things can go wrong after an upgrade
> > > and new kernel install: LILO, udev and device reordering might make a system
> > > unbootable before (and even after) the kernel upgrade.
> > Right. There are definitely going to be cases here where we can't ensure
> > the system will be usable after a reboot; it was my hope to limit these to
> > cases where the device config wasn't right after upgrade.
> > Should we have lilo upgrade listed explicitly as a step prior to the
> > dist-upgrade? That would minimize the window for this particular problem if
> > it doesn't cause other package removals.
> I think we should, it's rather easy. Just point to the section that describes
> the issue after the 'dist-upgrade' test. Users even wishing to reduce the
> window could just upgrade lilo and rerun it, before the dist-upgrade.
Yes, to minimize the risk lilo should be upgraded and rerun before the
dist-upgrade if possible.
> > The other cases where we still have problems are:
> > - once udev is installed, hotplug is removed; reboot to a previous 2.4
> > kernel may fail to bring up network devices correctly as a result.
> I *think* there's not that many users using hotplugged network devices, but I
> might be wrong.
I think it was pretty common, really.
> > - once udev is installed, reboot to a sarge-era 2.6 kernel will /likely/
> > fail to bring up network devices correctly as a result, and may also fail
> > to bring up filesystems other than the root filesystem.
> Yes, that's the works situation. I think it might make sense to tell users to
> have a 2.4 "failback" kernel for those situations (so they can continue the
> upgrade)
I think having a rescue disk is a better choice; using 2.4 as a fallback
requires an additional reboot just for testing it...
> > Given the alternatives, yeah, I can live with what we've got at this point.
> > Do you think we should document each of the possible problem cases, or is it
> > sufficient to provide recommendations on how to prepare for the need to
> > recover a system?
> I think we should provide recommendations on how to recover and make sure
> that we point out that network upgrades might need a remote control mechanism
> (remote console access) just in case.
Right, agreed.
Cheers,
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
vorlon@debian.org http://www.debian.org/
Reply to: