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

[ashleigh smythe]

Rick Moen wrote:
> 
> 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.

Not that it matters, but I'm getting flashbacks from second grade when I
was a tomboy and accidentally got picked for the "skins" side in a
"shirts vs. skins" capture the flag game so I'll just let you know:  

I'm a she! :-)


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


Ashleigh