As many might know already, CentOS 5 has been released (for some time).
However, the issue for some (or many) will likely be the huge, mammoth, overly large upgrade to CentOS 4.4’s replacement, CentOS 5.
The good news is, its done, and you don’t need to reformat, you can simply put yum to even more yummy goodness and get it to do the mammoth task for you.
Of course, it isn’t without a bit of finger work, but that’s still better than a backup and format if you just got your wonderful system up and running, or fear formatting might give you problems.
Here’s exactly what is done (and what it is essentially doing, my interpretation):
rpm -Uvh http://mirror.pacific.net.au/linux/CentOS/5.0/os/i386/CentOS/centos-release-5-0.0.el5.centos.2.i386.rpm
http://mirror.pacific.net.au/linux/CentOS/5.0/os/i386/CentOS/centos-release-notes-5.0.0-2.i386.rpm
The above is all one line, essentially, what it does is reconfigure yum to use CentOS 5, the release notes are added as, release notes, use them if you so feel the need to.
Next, you will notice the rpm output state that it outputted the file CentOS-Base.repo as CentOS-Base.repo.rpmnew. That’s not what we want, of course, that is instead protecting you from upgrading to CentOS 5 without knowing it.
Anyway, rename it to CentOS-Base.repo, but, before doing so, move (mv) CentOS-Base.repo to CentOS-Base.repo.CentOS4, so you have that handy if you need to use it again.
mv CentOS-Base.repo CentOS-Base.repo.CentOS4
mv CentOS-Base.repo.rpmnew CentOS-Base.repo
That’s two lines, two seperate renames (moves)
Next we need to remove “hal”, which is the hardware abstraction layer. Don’t get worried by the name, it’s only a core system component, you can safely delete it. (Really).
yum remove hal
What that does is remove hal (which is the hardware abstraction layer) a key component of the current OS, not needed in the new OS
With hal, HALted, we can now move on further. The next task is to clean yum’s cache out, we do that with a simple:
yum clean all
This asks yum to clean up all its repositories and its package cache, can take some time if your a yum addict, due to packages needing to be deleted.
Next, we perform a command that is designed to revv up our rpms to reaching CentOS, there’s a few steps involved in this process.
uname -a
This outputs some information about the currently running system, you should see something like Linux asterisk1.local 2.6.9-42.0.10.ELsmp. The first “asterisk1.local” is the hostname, the second, “2.6.9-42.0.10.ELsmp” is the outdated, 11times superseded kernel included in CentOS 4. Yours will likely differ, take note and edit the next line as necessary.
rpm -e --nodeps --justdb kernel-2.6.9-42.0.10.EL kernel-smp-2.6.9-42.0.10.EL
Fear not my fearful viewer, the above is going to delete the kernel in your machine. That’s right DELETE the kernel. But wait, isn’t the kernel a critical system component? Yes, it is. So do it. What the above does is uses rpm to erase the kernel from the rpm database, ignoring dependancies, but, here’s the big kick, our “–justdb” flag does just that, the rpm database is changed, and not the filesystem, so we aren’t trashing your beautifully outdated kernel afterall. The second item, kernel-smp, is purely for the SMP version of the kernel, you should also add kernel-devel-2.6.9-42.0.10.EL if you have the devel kernel package, and the same for smp devel. This won’t hurt your machine, it will hurt your rpm database, but that’s intentional.
With that out of the way, you need to read on if you are a Trixbox user, as you’ll have problems, if you don’t use Trixbox, read on after the trixbox changes.
With the kernel out of the way, we have some other .. critical parts of the Trixbox system to surgically remove.
rpm-e --nodeps --justdb zaptel*
With Zaptel (a critical part of the system for those with FXO / FXS cards, and other features, it has kernel modules that depend on the kernel, so upgrading means we break that. What we need to do is move it out of the way, but we might not want to trash the modules on the system just yet, so that’s what the above will do, it’ll move anything zaptel related out of the way of yum dependancies, so that the upgrade can succeed.
With that done, there are some other issues that need to be looked at as well.
If you run asterisk-addons (and if you use Trixbox, you do), you need to remove them temporarily, and compile from source under the new system. Trixbox don’t have a ported asterisk-addons package in their repo yet, and asterisk-addons is very easy to compile (if that’s what you want to call it).
Don’t think you can get out of the zaptel or asterisk-addons deal either. I’ve tried to ignore it, provide it the requested mysql lib, it didn’t work. I didn’t try rpm database erasure, but that might work, but you’d later on need to be able to unerase, much easier to compile from source.
yum remove asterisk-addons
This removes asterisk-addons, this is items like the CDR for mysql, and MP3 format, and so forth, that’s fine, you can have it back rather quickly after the upgrade finishes.
Now, if you don’t have Trixbox, or do have Trixbox, and have done the above, you are ready to do something incredible. Take the plunge.
yum upgrade
That’s right, this upgrades the operating system to CentOS 5. It’ll take a bit, and will flood your screen with package changes and other items, but that’s OK, if you are using PuTTY, log, if you aren’t, well, commit to your own memory :). Go to sleep, wake up in the morning, and you’ll discover the power flicked out overnight and you have a wonderful Windows XP Login screen in front of you, with no sign of what you left open last night visible. That’s OK, most won’t have the violent weather we are having right now to interupt the process. The process takes about 2 – 3 hours of downloading packages, installation, and cleanups (a total of 850 something yum actions in my case).
With that done, you’ll have just one more CRITICAL step before you reboot.
yum install kernel
Obviously you can guess what we are doing here. For those that can’t, we are installing the CentOS 5 kernel (currently 2.6.18, which is great for those of us who have newer machines, better dual core support, and … TEMPERATURE monitoring with lm_sensors that should work).
With the new kernel installed, we want to check that we have a valid grub config, and the kernel installed (you did watch the yum output) is a file that exists. Essentially, we are looking for three items, which should have the same 2.6.18- format number, and be named the same in the /boot folder, and a entry for the file in the /boot/grub/menu.lst file.
So, taking note of that, you would cd /boot, and run ls -al in that folder, and check that you have files like this:
initrd-2.6.1-1.1.1.el.img, vmlinuz-2.6.1-1.1.1.el, System.map-2.6.1-1.1.1.el
If you can see those, we need to check that the grub bootloader is capable of booting the new kernel.
cat /boot/grub/menu.lst
You should see some config info as well, amongst that, the below, assuming the kernel is the version above:
title CentOS (2.6.1-1.1.1.el)
root (hd0,0)
kernel /vmlinuz-2.6.1-1.1.1.el ro root=LABEL=/
initrd /initrd-2.6.1-1.1.1.el.img
You might see features like noapic and acpi=no, or other like settings with the kernel, they are generally fine, you don’t need them to boot, but of course, they do modify the behaviour (more like Safe Mode on windows).
Before you proceed below, (and you might have noticed this in the yum upgrade) asterisk will start again, and require some changes. I recommend editing the /etc/asterisk/modules.conf file, and commenting out the load=format_mp3 line.
You might have to execute killall safe_asterisk during the upgrade process as a result of asterisk starting.
It is at this point, I would like to say the above is my experience, just looking back on what I did, so bits could be missing, and this is simply a post outlining the process involved.
With that done, you’ll already have just one more step to enter the world of CentOS 5 (at least, by my method), and that’s to:
reboot
No guesses required for what that command does.
Basically, here’s how I did it. I typed it. Pressed enter. Hoped that I didn’t have to beg my colocation provider to format it again (its good it wasn’t in the data centre), and within minutes, it started responding to ping again, and all was well in the new CentOS 5 environment (going on something like 12 hours or more now).
Obviously I compiled asterisk-addons from source, that’s pretty simple.
Go to digium, download the asterisk-addons package for 1.2.14 (or your version of asterisk, most are 1.2), and gunzip, untar, and type make, make install, and you’ll be right!
Hopefully you don’t break your system, but of course, if you do, I’m sorry, I didn’t want to provide this information to those who knew little about what they are doing. I highly recommend that if you don’t feel confident in your approach, you contact someone else to do it for you with the technical expertise. They might charge an hourly rate, but if they break it, you aren’t choking yourself.
Again, this is an all care, but zero responsibility post, please keep that in mind when reading it.
The commands again for those in a hurry (hey, this is the bottom right ;)):
rpm -Uvh http://mirror.pacific.net.au/linux/CentOS/5.0/os/i386/CentOS/centos-release-5-0.0.el5.centos.2.i386.rpm
http://mirror.pacific.net.au/linux/CentOS/5.0/os/i386/CentOS/centos-release-notes-5.0.0-2.i386.rpm
(all one line)
mv CentOS-Base.repo CentOS-Base.repo.CentOS4
mv CentOS-Base.repo.rpmnew CentOS-Base.repo
yum remove hal
yum clean all
uname -a
rpm -e --nodeps --justdb kernel-2.6.9-42.0.10.EL kernel-smp-2.6.9-42.0.10.EL
rpm-e --nodeps --justdb zaptel*
yum remove asterisk-addons
yum upgrade
yum install kernel
reboot
Makes it that much easier 🙂