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. [EMAIL PROTECTED] http://www.debian.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
