Fwd: Re: [vox-tech] debian woody to sarge upgrade = dead xserver: solved

[Rick Moen]

Quoting David Hummel (dhml at comcast.net):

> Glad you're up and running Ashleigh, but sorry you had to resort to a
> fresh install.

<aol>Me too</aol>

> It would be helpful to hear from others who have upgraded from woody to
> sarge.  I too was under the impression that editing
> /etc/apt/sources.list, and then:
> 
> $ apt-get update; apt-get dist-upgrade
> 
> would be all that's required.  Is this in fact how others have
> successfully done this upgrade?  Are there any other gotchas that people
> have encountered in doing this?

Ashleigh already made reference to my old Linux Gazette "2 cent tip" on
the subject, so here's my later elaboration on that:  "Gradual Upgrade" 
on http://linuxmafia.com/kb/Debian/ .

Summary:  If you're paranoid about upgrading between functional branches
(e.g., stable -> testing), you can timidly upgrade most-crucial packages
first at the beginning of each jump.  A number of Debian developers with
warped tastes in entertainment have used that technique -- and then posted
the gory details -- to upgrade systems all the way from Debian 1.3 "bo"  ->   
2.0 "hamm"  ->  2.1 "slink"  ->  2.2 "potato"  ->  3.0 "woody"  ->  sarge 
(without wiping and reinstalling).

The only "gotcha" I would have expected in upgrading from woody to sarge
might be if the original system had used XFree86 3.x rather than 4.x.
I mention that in my knowledgebase file, and say that in such a case,
I'd probably junk the 3.x packages prior to upgrading, and then just do
"apt-get install x-window-system" (or whatever) after reaching sarge.

Oh, and you might want to apt-get install a more-suitable kernel-image 
package after syncing up to sarge.  People arriving on Debian from other
distros often fail to realise that Debian's maintenance programs never,
by default, touch your kernel except to upgrade it to a newer packaging
of the same kernel version.

I.e., if your dual-Opteron system was originally installed using your
ancient Debian 1.3 "bo" CDs with their 2.0.29 uniprocessor default
kernel, then you'll still have a (shiny new, patched) 2.0.29
uniprocessor kernel upon arrival at sarge -- if you don't take measures
to the contrary.  (My knowledgebase piece details that, too.)


I didn't follow Ashleigh's situation really closely.  (Sorry; been
busy.)  From what I remember of it, he essentially was getting SIG11
errors from the XFree86 4.x binary, on sarge -- for reasons never clear.

I guess I'd have tried a "apt-get --purge remove" of all the X11
packages, then tried to reinstall them.  If that didn't work, I'd have
pulled in the packages from the unstable branch, instead.

How do you do that, you ask?  Well, you have to first configure Debian
to know about both the testing and unstable branches, but know that it's
to draw from testing unless you specifically say otherwise.  That
requires two steps:

1.  /etc/apt/sources.list lines for both branches.
2.  A "your default branch is testing, dummy" configuration item.

There are (I think) a couple of ways to do item #2.  I vaguely recall
that my way of doing it is sub-optimal:

[rick at uncle-enzo]
/etc/apt $ cat preferences 
Package: *
Pin: release a=unstable
Pin-Priority: 50

This is called "pinning".  If you want the gory details, see "man 5
apt_preferences".  I believe that any package source has a Pin-Priority
of 100 by default; the above lowers all "unstable" package sources to 50
so that they're never pulled down by default.  Otherwise, having both
branches' lines in /etc/apt/sources.list would be a problem, you see.

I vaguely recall that the preferred solution is to put something like
this in /etc/apt/apt.conf:

APT::Default-Release "testing";


Roderick Schertler's page has the full story, which I've not yet gotten
around to digesting:  http://www.argon.org/~roderick/apt-pinning.html

Anyhow, having done both of those things (#1 and #2, above), and re-run
"apt-get update" to get the latest package catalogues, you can at any
time preferentially pull down non-default-branch packages by using
apt-get's "-t" (target-release) option.

#  apt-get  -t unstable  xfree86-server 

The nice thing about that is that apt-get will _also_ resolve
dependencies of the named package from the same branch -- while leaving
the rest of your system alone.


Caution:  Some people think that, if hybrid testing/unstable systems
with default = testing (as described above) are a good idea, then hybrid
stable/testing systems with default = stable would be even better.
Wrong.  The problem is that the (figurative) distance in package
versions between stable and testing is huge, while that between testing
and unstable is tiny.  If you're on the stable branch, then stay there 
(and, if necessary, use stable-compatible third-party packages from
www.backports.org and other places), unless and until you've made up
your mind to move your _entire_ system to a more cutting-edge branch.


About SIG11 errors:  Most often, signal 11 indicates RAM defects (89%
of the time), or CPU problems including overheating (1%).  Let's say as
a vague handwave that the other 10% are defective software.  Since
Ashleigh wasn't getting SIG11s _before_ he upgraded, one suspects
software.  Thus my "chuck X11 out completely, including --purge to snag
conffiles, and refetch X11 packages; and, if that doesn't work, snag the
unstable branch's packages" bit.

-- 
Cheers,                     "All power is delightful, but absolute power
Rick Moen                    is absolutely delightful."  - Kenneth Tynan
rick at linuxmafia.com