I am jumping the gun a bit and upgrading my Mageia 1 installation on my personal / business SOHO desktop PC tonight, May 21st, to Mageia 2. Officially Mageia 2 is not due to release until May 22nd. But the online repository for Mageia 2 is in place at my preferred mirror and I know that it is basically ready to go right now. So, I am upgrading. Ironically, I am starting this article from my soon-to-be-retired Mandriva 2011 install on the SOHO router / Bacula backup server. I have X and fluxbox installed on here just for occasions such as this where my main PC is being serviced. I am publishing this and will update as I go, so any of you that follow this site via RSS can make comments if you wish while this is being written.
This upgrade is being done over the Internet using the new Mageia 2 media sources with ‘urpmi –auto-update -v’ from a command line login as root on console #1. I have stopped X at this point and the PC is in “runlevel 3”, meaning no GUI. Which is going to be good since X will be upgraded while this process is going.
The initial phase of the upgrade was some 200+ packages to get the bits of Perl, RPM and urpm* tools that will be needed once the upgrade enters the 2nd phase where more low-level stuff starts being replaced. The second phase is running as I type this paragraph and has 2,679 packages to upgrade with a total download over 2GB. Phase two is at 370 packages and counting.
One of my hopes is that the new Mageia 2 will have a release of Evolution mail that is more stable and works better than the one in Mageia 1. I have had crashes nearly every day using the older Evolution with my local Maildir store. It also has problems keeping up with the message counts and with deleted mail “resurrecting from the dead” even though I want it to stay “dead”. Sometimes I get new mail and it is filtered to the Maildir store … but no new message count shows up. I have missed some business mail for a couple of days due to this problem. My fervent prayer is the new release will work much better. I will of course report about that here in a later article once I have a bit more experience with the upgraded Mageia install under my belt.
May 21 21:55 CDT – 531 packages installed and counting.
May 21 22:30 CDT – 820 packages installed and counting. I have noticed a few “installation failed” messages pass by during this process. I have seen this happen before when upgrading from CLI. That means I will have to run ‘urpmi –auto-update -v’ again when this pass is done. I will do that and report on it when I do.
May 21 23:52 CDT – 1134 packages installed and counting.
May 22 00:44 CDT – 1427 packages installed and counting. It is into the freaking huge KDE 4.8 bundle now. What a beast. Although I do not use KDE myself, meaning the desktop, I have it installed to support my clients that do use it. It helps to be able to see on my screen what they should be seeing on their screen. It is a good thing I have set aside a great deal of drive space (16 GB, currently 93% used!) for my /usr partition. 🙂
May 22 01:08 CDT – Stopped the upgrade to remove some of the old kernel-source packages. The /usr partition got to 99% full and I was a bit nervous about that. Restarted the upgrade after removal of these. Note to self, remove these first next time.
May 22 01:40 CDT – I notice that many of the “failed to install” packages are *handbook packages for KDE applications. They are failing because they require the upgraded application to be installed. It appears none of the applications required for the *handbook packages are upgraded yet. A bit of a backward update attempt there I think.
May 22 02:35 CDT – Upgrade ended with a LOT of un-upgraded packages. I had to install some libraries, libpoppler*, individually. Then many of the un-upgraded packages did upgrade along with those libraries. Then when that finished I ran ‘urpmi –auto-update -v’ once more and another seven hundred(!) packages started upgrading that had been skipped. Among them … LibreOffice, which is one piece of software I use nearly every day.
May 22 03:09 CDT – Upgrade stopped again with 250 packages still not upgraded. Started it again and some more packages, but not all, did update. Looks like this is going to take some more runs though the upgrade process. Each time getting a few more packages updated.
May 22 03:16 CDT – Had to install gstreamer0.10-vp8 and python-gi by themselves with urpmi. Then libclutter1.0_0 by itself with urpmi. Then 61 other packages came along with libclutter and updated. Appropriately further cluttering my drive with software. 🙂 Still 139 packages to go. Gee, this is fun. I start the update again with ‘urpmi –auto-update -v’. This time I notice Gnucash installing … another program I use nearly every day.
May 22 03:32 CDT – Everything is updated, except for one problem package – qt4-examples is error-ing and will not install. I can live with that. going to reboot now to load the new kernel and see if anything goes “boom”.
May 22 03:35 CDT – Yup, it went boom.
Dependency failed. Aborted start of /data1
Welcome to emergency mode. Use “systemctl default” or ^D to enter default mode.
Give root password for maintenance
(or type Control-D to continue):
Bleh, that /data1 is a complete drive mount that has a lot of important “stuff” on it. Yeah, it is backed up. But who of you really wants to have to rely on your backups? This should extend my “fun” to new heights. What the heck, I’ll use Ctrl D and see what happens. Nothing. Okay root password and I have the # prompt. Gotta do some forensics folks. Be back in a bit.
The /data0 and /data1 mounts were not mounting even though they were working just fine prior to the upgrade. This is a multi-drive system with many more mount points than the average PC user might have. Still a bit disappointing that the upgrade did not “just work” for me. The “fix” was to edit /etc/fstab by hand in “emergency mode” with ‘vim’ to comment out those mount points. Then reboot.
I am writing this paragraph from my newly updated PC running Mageia 2. The ‘diskdrake’ tool is choking on this when I try to run it to edit the mount points:
Device Boot Start End Blocks Id System
/dev/sdc1 * 63 8177084 4088511 82 Linux swap / Solaris
That is a swap partition on the first part of one of the disks. Looks like I get to use gparted to remove that to see if I can then get the ‘diskdrake’ tool to work. There is nothing like an all-nighter upgrade to make one appreciate … sleep.
Okay, something had marked all the first partitions on each drive with the ‘boot’ flag. This was causing diskdrake under Mageia 2 to die on those disks that are not actually boot drives. Using gparted to remove the ‘boot’ flag then allowed me to load diskdrake and redo the mount points. Whew! For the record, this is probably not a problem most folks will run into. My system is used to run a lot of testing stuff for support purposes. So, the problem is probably something I did. That said, diskdrake should have been able to handle this problem instead of dying an ignoble death. At least gparted came through and helped me fix this problem.
My suggestion for an upgrade is, clean out any old stuff you don’t need, such as kernel-source files, before upgrading. Also, check your partitions if you have multiple disks. If each first partition on each disk is marked bootable, this might cause problems if you have more than two disks as I do. Use gparted to remove the boot flag on any partition that is not actually a bootable partition prior to upgrading. While I was able to get everything working after I had already updated, I do have over 20+ years dealing with PC hardware problems under Unix and unix-like systems. Due diligence to look for these problems I found before you upgrade could save you some headaches … and a sleepless night.
Good morning all. I’m going to bed now.