Many people seem to be afraid of mixing stable with testing, but frankly, testing is fairly stable in its own right, and with proper preferences and solution checking, you can avoid the "stability drift" that puts your core packages on the unstable path.
"Testing is fairly stable??", you ask. Yes. In order for a package to migrate from unstable to testing, it has to have zero open bugs for 10 consecutive days. Chances are that, especially for the more popular packages, somebody is going to submit a bug report for an unstable version if something is wrong.
Even if you don't want to mix the environments, it's still nice to have the option there in case you run into something that requires a newer version than what is in stable.
Here's what I recommend for setting this up:
First, create the following files in /etc/apt/preferences.d
:
stable.pref
:
# 500 <= P < 990: causes a version to be installed unless there is a
# version available belonging to the target release or the installed
# version is more recent
Package: *
Pin: release a=stable
Pin-Priority: 900
testing.pref
:
# 100 <= P < 500: causes a version to be installed unless there is a
# version available belonging to some other distribution or the installed
# version is more recent
Package: *
Pin: release a=testing
Pin-Priority: 400
unstable.pref
:
# 0 < P < 100: causes a version to be installed only if there is no
# installed version of the package
Package: *
Pin: release a=unstable
Pin-Priority: 50
experimental.pref
:
# 0 < P < 100: causes a version to be installed only if there is no
# installed version of the package
Package: *
Pin: release a=experimental
Pin-Priority: 1
(Don't be afraid of the unstable/experimental stuff here. The priorities are low enough that it's never going to automatically install any of that stuff. Even the testing branch will behave, as it's only going to install the packages you want to be in testing.)
Now, creating a matching set for /etc/apt/sources.list.d
:
stable.list
: Copy from your original /etc/apt/sources.list
. Rename the old file to something like sources.list.orig
.
testing.list
: Same as stable.list
, except with testing
.
unstable.list
: Same as stable.list
, except with unstable
, and remove the security lists.
experimental.list
: Same as unstable.list
, except with experimental
.
You can also add a oldstable
in sources.lists.d
and preferences.d
(use a priority of 1), though this moniker will tend to expire and disappear before the next stable cycle. In cases like that, you can use http://archive.debian.org/debian/
and "hardcode" the Debian version (etch, lenny, etc.).
To install the testing version of a package, simply use aptitude install lib-foobar-package/testing
, or just jump into aptitude's GUI and select the version inside of the package details (hit enter on the package you're looking at).
If you get complaints of package conflicts, look at the solutions first. In most cases, the first one is going to be "don't install this version". Learn to use the per-package accept/reject resolver choices. For example, if you're installing foobar-package/testing, and the first solution is "don't install foobar-package/testing", then mark that choice as rejected, and the other solutions will never veer to that path again. In cases like these, you'll probably have to install a few other testing packages.
If it's getting too hairy (like it's trying to upgrade libc or the kernel or some other huge core system), then you can either reject those upgrade paths or just back out of the initial upgrade altogether. Remember that it's only going to upgrade stuff to testing/unstable if you allow it to.
EDIT: Fixed some priority pins, and updated the list.
There's a couple of potential pitfalls here. First of all, you mention dd for backups. While dd can be a wonderful tool, it's not an ideal backup tool, and if you're referring to using it to backup a live machine, it's a very poor choice. You're going to have some really badly inconsistent data and may not end up with a working image file.
Also, one note for the future. . . always setup your disk layout with LVM (and leave a few GB unallocated in the Volume Group), as it makes these kinds of situations about a hundred times easier to deal with. If the partitions were logical volumes under LVM, you could snapshot them, and then make use of the snapshot to give you a fairly consistent image.
Now, how critical is it that this box stay up? If you can take it down for a few minutes, there are P2V (Physical to Virtual) converters that you can use to make this transition a lot easier.
What kind of hardware configuration are you dealing with? If you have mirrored disks (RAID1) you might be able to break the mirror, pull a disk, and bring up the yanked disk in a second box. You could then clone that non-production copy.
Another important thing to consider, is what are you using for Xen? Is it RHEL and the Xen that's included? Or is it Citrix XenServer (now free)? This makes a difference as they both expect (by default) a slightly different disk format. Manually building an image for XenServer is a bit more complicated than building one for stock Xen.
It may sound a little unorthodox, but I've actually had better success in this type of situation by doing a simple base Linux install on a separate box, then running rsync from the production box to the new box, and then converting the non-production rsync'ed clone into the Xen domU (I've even had some luck just rsynch'ing from the production box to a Xen domU). Just run rsync (I recommend the options -HavSux
) the old box to the new one while it's running, and once the rsync has completed, run rsync again. The first one will take a while to run, and will leave you with a lot of inconsistencies. The second one will run faster and because it only has to pull the changed stuff this time, put things in a more consistent state.
Whether that will be "good enough" for you, with regards to consistency, will depend on your requirements and what applications you're running. For example, if you've got an active database server on the production box, you'd definitely not want to leave rsync'ed file backups as "good enough". Instead, after the second rsync you'd take a database backup using the database tools, and import that on the clone. Or you'd wait to do that final synchronization until you have your xen domU up and running.
Good luck, and plan on a couple of dry runs and a couple more practice runs to get things working smoothly before you go for real.
Best Answer
You should avoid symlinks, it can make nasty bugs to appear... one day. And very hard to debug.
Use
mount --bind
:it will be made at every reboots which you should do now if you want to catch errors soon