[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: etch --> lenny upgrade report on Alpha platform

On Sun, Aug 24, 2008 at 01:29:43AM -0500, Bob Tracy wrote:
> In a nutshell, the instructions I found for doing the dist-upgrade were

> (1) Edit /etc/apt/sources.list
> (2) Change all occurrences of "stable" to "testing".
> (3) apt-get update
> (4) apt-get dist-upgrade

> Step (4) successfully identified and downloaded 1.2 GB of updated packages,
> then bombed spectacularly during the installation of those packages.  As
> near as I can tell, "apt-get" got extremely confused by all the
> interdependencies.  After watching the train wreck to its conclusion (lots
> of error messages as apt-get's confusion increased), I found a few packages
> had been successfully upgraded in place.  A few more were found installed,
> but unconfigured.  Still more were in the forced-deconfigured state.  I
> ended up spending the next several days manually installing packages with
> "dpkg -i", occasionally having to specify --auto-deconfigure to get past
> some of the more stubborn cases of multiple dependencies.

If it calculated an upgrade and started downloading packages, then that's a
quite positive sign!  It means that the ultimate upgrade failure is due to
isolated bugs in one or more of the packages it was trying to install, and
not a systemic issue with dependency changes between the two releases.

A report against upgrade-reports would definitely be useful here, and in
particular I think we would want a copy of /var/log/apt/term.log covering
the upgrade attempt in question, to see what packages failed to upgrade and
why.  (The failing packages should be considered RC-buggy, and fixed before
the release.)

> Separate report on the new Xorg radeon driver...  There's a new feature
> enabled by default that attempts to use the video BIOS to determine if
> there's anything connected to any of the potentially multiple video
> outputs on the card (VGA and DVI to name two possibilities).  There's
> no reason to expect that feature to function properly on a non-x86
> platform, and in that respect, I wasn't disappointed :-).  Specifying
> 'Option "DefaultConnectorTable" "true"' in "xorg.conf" causes the
> driver to assume a default video output configuration based on the
> detected chipset, and that got things working for me.  The clue that
> led to trying that option?  A line of output in the Xorg.0.log file
> where the driver indicated it was having to "guess wildly".  Needless
> to say, it "chose poorly".

Ah, nice... :)  That sounds like it should be a separate bug report on the
radeon package, then?

Steve Langasek                   Give me a lever long enough and a Free OS
Debian Developer                   to set it on, and I can move the world.
Ubuntu Developer                                    http://www.debian.org/
slangasek@ubuntu.com                                     vorlon@debian.org

Reply to: