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

etch --> lenny upgrade report on Alpha platform

(The subject change seemed appropriate...)

On Sat, Aug 23, 2008 at 05:06:37PM -0700, Steve Langasek wrote:
> On Fri, Aug 22, 2008 at 08:35:56AM -0500, Bob Tracy wrote:
> > I recently
> > upgraded the Alpha from etch to lenny (feedback available if anyone is interested)
> Yes, feedback is certainly welcome.  If there are alpha-specific issues,
> feel free to post this to the list.  Otherwise, filing a bug report against
> the upgrade-reports pseudopackage is probably best.

I have no way of knowing whether it's specific to the Alpha, so I'll
simply relate my experience with the upgrade and we can decide from there.
I started the upgrade process approximately two weeks ago...

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.

Other than the sheer number of packages that were being replaced, I'll
hazard a guess that another reason for the difficulty was caused by packages
that were renamed between etch and lenny.  Most of the problematic
renamings were of the general form "packageN_x.y..." --> "package_N.m...",
i.e., a major version number either became part of the package name or was
removed from it.

I ran into similar issues when upgrading from Sarge to Etch, and it's at
least encouraging that things *can* be sorted out manually when the
automatic procedures fail.  At this point, "dpkg -l" produces a completely
clean list of installed packages, i.e., each package line in the listing
begins with "ii".  Also, package updates released after I did the upgrade
have installed cleanly.

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".

Bob Tracy          |  "I was a beta tester for dirt.  They never did
rct@frus.com       |   get all the bugs out." - Steve McGrew on /.

Reply to: