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. > 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. > - 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) > 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. > > > I'm glad that interactive aptitude will provide a way around this (it almost > > > always will), but I don't think that alone is an adequate recommendation for > > > the release notes. > > > As I've said, I think it would be a good "second" option ("expert" mode?) > > Well -- do we want users using the "expert" mode if they aren't already > familiar with it? And if not, is there any reason to document it in the > release notes? I guess we don't want users using this mode if they are not familiar, but users familiar with it should be pointed out that a better upgrade procedure exists. Although I'm inclined to think that it might not be "better" (as the window of exposure to issues in case of a reboot is bigger) Regards Javier
Attachment:
signature.asc
Description: Digital signature