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