On Wed, Mar 21, 2007 at 04:22:31PM -0700, Steve Langasek wrote:
> > 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?
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.
> > 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.
As far as I've seen, networking issues in upgrades have been related to
device reordering and to #403706 (but this seems to affect new installs, not
upgrades)
> > > 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 guess that Frans suggests avoiding it by doing a minimal upgrade
(initram-tools, coreutils) before the dist-upgrade.
> > 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.
As I've said, I think it would be a good "second" option ("expert" mode?)
> > 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...
Maybe not honoring recommends is precisely why it is working better than
aptitude (see #411280 and #401317). In #401317 Osamu makes some tests
with/without recommends that I would like to reproduce in a more recent
"etch" (as the tests were done in December)
> 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?
If the only issue is related to the libfam dependency hell then removing the
desktop, is there any way to fix that by maybe removing libfam0c102 prior to
upgrade?
> 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?
If we can find a good procedure using aptitude, even if it involves using
apt-get for some steps (as I've sent in my previous e-mail) maybe there's no
need to accept -4 into etch. I don't have much time and/or hardware for
upgrade testing, so help (and bug reports to the upgrade-reports) would be
really appreciated.
Regards
Javier
Attachment:
signature.asc
Description: Digital signature