Upgrading Debian Lenny 5.0 to Squeeze 6.0.
My very first piece of advice - if at all possible, make a full backup of the system. If it's a virtual machine, copy the virtual hard disk file somewhere before starting the upgrade. Spend this time now so that you avoid a full reinstall later in case of failure. And here I don't even mean a failed upgrade as such, but a failure caused by some packages being incompatible with your server's content (for example, this happened to me when it turned out that several of our webmasters' sites didn't meet the requirements of PHP 5.3, and I had to urgently roll back to Lenny with PHP 5.2.17 - to give these sites a chance to be brought into proper shape).
At the end of this article there are notes on the topic "what if this is domain-zero for the Xen hypervisor - how do I upgrade it". The gist of it is - you upgrade the system as usual, and afterwards you carry out these notes.
So, let's begin.
Preparation1) Check that everything is fine with your packages and that all packages are allowed to be upgraded:
# dpkg --audit
2) Held packages
Debian recommends unholding all held packages (i.e. packages that you yourself forbade from upgrading because these updates were undesirable). Whether or not to follow this advice is up to you - you know best why you once froze the version of one package or another (say, PHP itself at version 5.2, for example, because of issues with sites that didn't work with 5.3).
You can view held packages with two commands (one for aptitude, the other for apt-get; they are NOT interchangeable - a package can be held in aptitude and not held in apt-get, or vice versa, so you need to run both):
# aptitude search "~ahold"
# dpkg --get-selections | grep hold
3) Update everything that's there before upgrading the system
# aptitude update
# aptitude -f install
Upgrading Lenny --> Squeeze4) In the file /etc/apt/sources.list replace every occurrence of the word 'lenny' with the word 'squeeze'.
5) Updating the list of repositories
# aptitude update
6) Updating the dpkg, aptitude and apt packages
# aptitude install apt dpkg aptitude
During the upgrade, the system will ask a few times about things like "there's a conflict here, and the fix is to upgrade such-and-such and remove certain package versions". Agree to it.
If the system starts pestering you with questions like "Configuration file such-and-such has a newer version than yours, but your file has been modified... what do we do" - you'll be offered several options. The point is that the system needs an answer from you - either replace your config with the newer one, but WITH THE LOSS of all your changes to the old one, or keep the old one, which may not be compatible with the new package version. This is entirely up to you. If you value the old config more - press N or just Enter (the default answer is "no"); if you're ready to reconfigure the config from scratch - press Y.
7) Upgrading the system
# aptitude full-upgrade
During the upgrade, the system will ask whether to set the dash (sh) command interpreter as the default (i.e. whether to use it instead of bash). Choose whatever suits you (if you're not sure - just press Yes, that's fine).
Next you'll be asked whether to install the new grub (grub 2) instead of the old one. If you're not sure - answer "No" - you can update it later from the command line:
# upgrade-from-grub-legacy
If you're using Xen - I still recommend updating grub - the Xen 4.0.1-2 build was tested against the latest version of the bootloader, not the old one.
Next you'll be asked about restarting services that use NSS (an editable list of these services will be shown). Answer "Yes", otherwise some services may "hang" due to the change in access credentials. The same applies to services restarted because they work with PAM.
To the question "Switch the startup process to a dependency-based one" answer "Yes".
It will start asking about differences in the versions of configuration files - I already described above how to handle this (it's up to you; I left the old configs everywhere - and everything worked fine in my setups).
8) It has finished working
After the update, there are 2 possible outcomes:
a) Everything went fine, the installer updated the kernel to version 2.6.32-5 (2.6.32-5-xen if your machine is paravirtualized or is a dom0).
b) The installer finished, but left the kernel unchanged.
In case (b) we continue (it actually hasn't finished anything yet, and our Debian is still Lenny).
Install the kernel manually
# aptitude install linux-image-2.6.32-5-amd64
There are variations here:
linux-image-2.6.32-5-686 if you have a 32-bit system
linux-image-2.6.32-5-xen-686 if you have a 32-bit Xen system
linux-image-2.6.32-5-xen-amd64 if you have a 64-bit Xen system
Run the update process again:
# aptitude full-upgrade
In the second stage it will deliver everything it didn't deliver before.
PS. Case (b) happened to me once; usually everything already goes fine in case (a).
9) Finishing up
If you're running on "bare metal" or HVM - reboot:
# reboot
If this is a paravirtualized Xen system or even a dom0 - continue (do NOT reboot!)
And we have Xen10) And we're with Xen
If this is not dom0 but a guest system, and it doesn't boot via PyGRUB (or PV-GRUB) - then you need to copy the new kernel to dom0 and put it in place of the old one.
If it is dom0 - be sure to check that Xen will be loaded on system startup. Nothing fatal will happen if it doesn't load - you simply won't be able to start virtual machines, so you'll have to dig into GRUB anyway.
So, this is our Xen dom0. Let's go to /etc/grub.d (you did update the bootloader to version 2, I hope) and see what ls shows us:
# cd /etc/grub.d
# ls
00_header 10_linux 30_os-prober 41_custom
05_debian_theme 20_linux_xen 40_custom README
If everything looks like the example - i.e. the "linux_xen" module has higher priority than "linux" - then we'll need to do a bit more work (and that's most likely how it will be). In that case, Xen will be lower in the OS boot selection menu than the default plain Linux entry. And plain Linux will boot.
But what we need is for Xen to boot by default. Let's fix this misunderstanding:
# mv 20_linux_xen 09_linux_xen
# grub-mkconfig --output=/boot/grub/grub.cfg
Now Xen will boot.
Well, that's basically it. I'd also like to recommend that when updating Dom0, you stay somewhere near the server's physical console - it's a delicate procedure, and it will be worse if some subtlety with Xen fails and you have to go there in person anyway.
Comments