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: > > [EMAIL PROTECTED] > /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 _______________________________________________ vox-tech mailing list [EMAIL PROTECTED] http://lists.lugod.org/mailman/listinfo/vox-tech
