Re: Desktop upgrade strategy (was: What should be upgraded first: kernel or userland?)
On Wed, Mar 21, 2007 at 04:42:15PM +0100, Frans Pop wrote:
> > However, users running with 2.6 kernels in Sarge and upgrading, might
> > encounter issues with udev (it does not support versions prior to
> > 2.6.15 and sarge provided 2.6.8), as described in #325568 (Upgrade path
> > for udev needs documenting).
> This is not essential as long as you don't try to reboot before a new
> kernel has been installed.
My concern here is: what happens if an upgrade is interrupted in the middle,
due to such things as a power outage, hardware failure, two admins not
communicating with one another, or admin confusion about the state of the
upgrade? Is the system recoverable at every point during the upgrade
process, without extraordinary measures?
> And even then my tests have so far shown that the system will probably
> still boot (though X may not start).
And will the networking necessarily start? That could be a problem for a
number of users if it doesn't.
> > It has been reported (in #396331) that a userland upgrade without
> > upgrading first the kernel would remove the *running* kernel. This was
> > fixed in aptitude 0.4.4-1 (bug #386307) which was allowed into testing.
> > (Is a newer release going to be accepted, BTW?)
> This can be avoided.
Sorry, what can be avoided -- upgrading userland before the kernel? Per bug
#413458, I don't think this is true?
> I've just found a relatively straightforward way to upgrade a desktop
> system that also answers the kernel/userland question. Actually, there
> are two methods.
> A. For those comfortable with interactive aptitude
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.
> B. Upgrading from the command line using mostly apt-get
And apt-get has different bugs (#410695), doesn't honor recommends, and
hasn't been what we've been recommending users use for upgrade testing for
the past months...
We can't flip-flop the recommended upgrade procedure every time we find a
bug affecting one tool but not another. What do you think about the fam NMU
we discussed?
> - openbsd-inetd
> - pppoeconf
> Note: I confirmed that some of these (the last two) are because of #411123
> which makes me feel that aptitude 0.4.4-4 really _should_ be allowed into
> Etch!
Hmm. I'm provisionally amenable to accepting aptitude -4 into etch, but
this is obviously a quite late change that will receive little additional
testing before the release; so I'd like to hear what the other members of
the release team have to say about this. In particular, is this fix one
that would be worth delaying the release over if we find that -4 introduces
regressions or requires further testing for purposes of the release notes?
Thanks,
--
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: