Illegitimi non carborundum


Up up [upgrade] and away

So, as with any distro release, the recent Mageia 2 announcement means that I have a few boxes to upgrade. With one of my boxes however, the upgrade is somewhat more complicated as I wanted to switch from 32-bit to 64 bit. Now, with the benefit of hindsight (or with a bit of basic thought before hand) I can say that a re-install of the box would have likely been several orders of magnitude easier, but I like to push boundaries so I opted to do an in-place urpmi upgrade while switching architectures. Read on if you'd like to bask in the glow of this experience!Firstly, my system was 99% up-to-date. It's disk layout is a bit weird. two raid setups (both raid 1 but one with only one disk (i.e. not very raidy) until I can be bothered/justify getting another one - it's only for recording TV programs so not really critical data) both with LVM on top.  The system was mostly up-to-date, but I had a slightly customised kernel (just included a fix for my TV card which was subsequently pushed as an updated kernel that I hadn't yet installed).

So the first port of call was to apply all updates, bar the kernel. I then installed the glibc and kernel from the Mageia 1 repos. This is safe to do so as our glibc package contains both 64 and 32 bit binaries. I had to force install the kernel as it was "incompatible", but it worked fine and I was able to reboot into a nice 64 bit kernel.

So far so good. Now the fun begins. As soon as I installed the Mageia 2 glibc package, everything started crashing. Not the best start. There isn't much that can be done in this situation other than reboot and bring the disks up manually and try and debug. I eventually found that a /lib/i686 folder seemed to contain the older version of glibc binaries. It was not owned by any package and renaming the folder made everything suddenly work again. Chalk that one up to experience, but I guess it was some kind of leftover cruft that wasn't tidied out the way properly.

After glibc was installed, I tried to do a bit of upgrading. urpmi seemed to ask a lot of questions and wouldn't let me do things piecemeal (upgrade rpm first, then urpmi, then the rest etc). So I ended up having to do a lot of stuff semi manually - installing certainly packages as I went.

Sadly urpmi simply refused to install some updated packages. I'm not sure why but it could be related to the --strict-arch option that I think is basically on by default. This didn't seem to be 100% true however, as some packages did update OK. Anyway, I had a mostly up-to-date mirror thanks to urpmi-proxy and a gazillion test installs made during the RC phase of Mageia 2, so I was able to upgrade the core packages bit by bit. gradually working up to a full install. Some packages were not recompiled between mga1 and mga2 which was a bit awkward as it meant the version numbers where the same. In order to switch the arch, you generally have to do:

rpm -Uvh --replacepkgs --replacefiles $PKG.x86_64.rpm; rpm -e $PKG.i586

This installs the x86_64 version but results in two packages for both arches being installed, hence the need to remove the i586 one after.

In order to easy the process, I enabled the 32 bit repos for Mageia 2 and issued the urpmi --auto-select command. I never ran this as it would have kept the system at mostly 32 bit. I did however take the list of non-lib packages (i.e. those not starting "lib...") and then used the information present to create a file with the full package names. I downloaded the ones I didn't have, but for the 64 bit arch and then ran various rpm -Uvh commands on this list, installing missing libraries as I went until it all worked. Most of this was scripted with copious sed, awk, grep and xargs commands so it wasn't a huge amount of hard manual work but was quite time consuming.

Eventually I got to the point where things were 99% upgraded, but my users, which are stored in LDAP, didn't go quite as smootly as I'd hoped. In the end I found it easier to just erase the LDAP db and do a slapadd on the ldif file I'd diligently saved prior to upgrade. It took me a while to work out that the reason my users didn't exist any more was that i'd not yet upgraded nss_ldap to the new architecture... that was probably the biggest "D'oh" moment of the whole upgrade and would have taken an hour or so of the upgrade.

I also made copious use of urpmq --not-available command (after disabling the 32 bit repo again) to check which packages had not yet been updated as urpmi --auto-select was slavishly reporting that "Packages are up to date" even when I knew it was lying.

Other than a few minor config file edits (a few path changes to reflect lib64 vs lib) that was about it. Installing systemd and dracut was totally painless and the first boot of the new system went very smoothly. The only issue I still have relates to cyrus-imapd which refused to run under systemd but this actually turned out to be a pam config issue with coreutils which I'll have to fix at some point (missing the /etc/pam.d/runuser-l file).

Ultimately I don't blame urpmi for this as it's very much outside of it's intended scope. I was able to keep the system running for the vast majority of this processes so all in all I was quite happen that it could be done. That said, it think it would have been significantly easier and less time consuming to just do a fresh install. As I had raid, I could have just broken the raid setup, partitioned and setup my OS disk and resinstalled before copying over config and data before joining the disks back into a working raidset again. That would have likely taken less "hands on" time, even if data syncing etc. might have ultimately taken longer.

Still, doing stuff like this is how we learn and I'm sure I've gained a few more titbits of knowledge by going through this process!

Share and Enjoy:
  • Digg
  • StumbleUpon
  • Facebook
  • Yahoo! Buzz
  • Twitter
  • Google Bookmarks
  • Slashdot