The previous article here was about upgrading Mandriva Linux on a Compaq Armada M700 laptop used for business. Since that laptop has a minimal amount of software installed, mainly just business related applications, I thought I would document upgrading from Mandriva 2007.1 to Mandriva 2008.1 on my tower PC. This PC is for business and personal use. As a result it has much more software on it than the laptop. Further, with this upgrade I intend to attempt to keep using the system while it is upgrading. I wanted to test this to see if one could actually do an upgrade in the background while continuing to be productive on the PC. I suspect I may have to restart applications, like Firefox, as they are upgraded. Since I am using Firefox to write this article I am saving after every sentence.

I have started this article on the PC while it is upgrading. I have X running and am using the applications I normally use every day in my business on this PC. Those are: xterm (eight instances for various CLI uses including one that runs ‘mc’), Kontact (includes Kmail, Kaddressbook, Korganizer, etc.), Firefox web browser, Kopete (Jabber, AIM and MSNIM instant messenger), XChat for IRC.

For the beginning of this upgrade I start by choosing some Mandriva 2008.0 repositories at easyurpmi.zarb.org. There are 1700+ packages that will have to download and install over our SOHO shared internet connection. We have a FTTH connection that is 4Mb/512Mb so I started the upgrade at the console ([Ctrl] [Alt] [F1]) after changing out my package sources. I used this command: ‘urpmi –auto-update –limit-rate 300k -v‘ to keep the downloads from taking all the available bandwidth. One thing I noticed, I just attempted to read the manual page for urpmi while the upgrade is going and man returned “garbage”:

$man urpmi
±R¸©k ąéºo©ýK..f…….åØ4ª]’”(AR [ïAR#¨æ¶ä©”‘êÚö/¤Sk&iæu¦ü÷Né©zøùÁj/ì¿=IB³5ĐqÛÉccþu0§2¥

So, apparently that will not work for a while as this upgrade proceeds. One of the first things upgraded is urpmi and its’ support programs and libraries. I am a little surprised that I cannot yet read its’ man page as I thought man pages should be standard across releases. Obviously my thinking is flawed about that. I expect that man page problem to clear up as the upgrade proceeds.

At this point the upgrade has been going for about an hour. The only thing upgraded so far is urpmi and its’ support applications. The packages for the upgrade are still downloading at the console. This PC has a 1.8G /var partition and I suspect that urpmi is downloading as many packages as it can before installing them. The reason I think this is that the laptop upgrade using this method would download a few files, install, remove the downloaded files, etc. This was likely due to the smaller size of the available disk space on the laptop. Currently the /var/cache/urpmi directory shows it has 849M in it with the /var partition showing 86% full using ‘df -k‘.

Wow, /var is 100% full and urpmi is still downloading, to where I am not sure. I am wondering if this is going to work at this point. After waiting a few more minutes I see many “retrieving failed” messages, then urpmi begins trying to install the packages it did download. Unfortunately there is no space left in which it can work. Looks like it is time for some creative symbolic linking to give urpmi more space. I had to ‘kill -9‘ urpmi (yeah I know, bad bad bad) to get it to stop. I then mv the /var/cache/urpmi directory to /mnt/data/urpmi then symbolically link /mnt/data/urpmi back into /var/cache. The /mnt/data mount is a ~70GB SCSI disk for business and personal data that has about 10GB free. It includes old data that has been backed up that I can purge if more than 10GB is needed. I doubt much more space is actually needed though. I then restart ‘urpmi –auto-update –limit-rate 300k -v‘ and watch to see if this works. The urpmi program starts downloading from the point of failure. So, this problem is solved with a workaround.

At 1.5G of data in the /mnt/data/urpmi directory the packages finish downloading and urpmi begins processing files for installing the upgrade. The installation fails due to two RPM packages I have installed from oddball sources with unresolvable dependencies, one a game the other a gutenprint update, neither were from Mandriva. I remove them and restart the install. This results in the 1700+ packages actually beginning to be installed. After this install finishes I will reboot and see how the system has fared.

Old packages are being removed, so I decide to shutdown X at this point to avoid a possible X crash.

… time passes …

About 19 hours have passed since that last sentence was typed. I’m reinstalling the applications I use on a fresh install of Mandriva 2008.1 at this point. The upgrade from repositories path on this PC did not complete correctly for the 2007.1 to 2008.0 upgrade. After all the 1700+ files finished downloading when I tried to ‘shutdown -r now‘ the init program just returned to me a message about nothing to do for the runlevel (I forgot to write the exact message down.). After staring at that for a moment with an unusable system I decided to press reset.

The system came back up and asked me for the runlevel after going through the grub boot loader. I thought this was not looking good but typed in ‘5′ for runlevel 5. Again init returned to me a message about nothing to do for the runlevel (Again I forgot to write this down.). Time for some forensics. I have an ISO for a Mandriva One Live CD, boot and run from CD disc. Unfortunately I had not burned the CD yet and the ISO was languishing on my now hosed PC. Luckily I had just recently gotten and burned a Knoppix 5.3 Live DVD image. I booted the Knoppix 5.3 DVD, mounted the root partition on my PC and began looking around. My first place to look was in /etc/rc.d since that is where init finds its’ “stuff”. As soon as I saw the subdirectories I thought to myself “Well, there’s your problem.”. For some reason there were no scripts in /etc/rc.d/init.d/ and thus no symbolic links to those scripts in /etc/rc.d/rc0.d/, /etc/rc.d/rc1.d/, /etc/rc.d/rc2.d/, /etc/rc.d/rc3.d/, /etc/rc.d/rc4.d/, /etc/rc.d/rc5.d/, /etc/rc.d/rc6.d/. At this point I just wanted to get on with my 4th of July, Independece Day (USA) holiday. I did have the Mandriva 2008.1 install DVD burned just in case something like this happened. I rebooted with that and started a fresh install. About an hour later I had a basic install of Mandriva 2008.1 running on my SOHO tower PC.

The results of my experiment with upgrading Mandriva releases using repositories now has a 50% success rate. The upgrade of my business laptop could not have been smoother using this method. The upgrade of my business / personal use tower PC could have definitely been smoother. Although I did prove I was able to continue to keep using the PC while the upgrade was running. Everything kept working up to the point where I shutdown X. The bottom line here is Your Mileage May Vary (YMMV) using this method so be certain to have a fall-back CD or DVD from which to do a fresh install.

Hmmm, my wife’s PC running Mandriva 2007.1 needs upgrading … I wonder if …

This article has been accessed this many times:

html hit counter code

1. by Gene on July 5th, 2008 at 4:46 pm

   One thing I should mention. Since I had to do a fresh install I changed my file system types from ext3 to xfs on all but the /home partition. While both are journaling file systems the xfs file system has some capabilities that ext3 lacks. One of these is the ability to have more than 32,000 files in a directory. If one tries that with ext3 the results are not pretty. I will change the /home partition to xfs from reiserfs with some maintenance down time after I clean off cruft and make sure I have a good backup.

2. by Gene on July 16th, 2008 at 1:16 pm

   A problem I have encountered since this upgrade is that Kopete no longer logs into MSN-IM. I keep getting an error stating the password is invalid. This error is bunk since I was using Kopete with MSN-IM the day before the upgrade and my password has NOT changed.

3. by Gene on August 16th, 2008 at 2:16 pm

   Sometime in the last few applications of updates and security fixes for Mandriva 2008.1 the MSN-IM login with Kopete started working again. I have not looked into this further, but I suspect some hack in the Kopete code with 2008.1 to allow Kopete to continue working with the MSN-IM moving target did not work as planned and has been fixed in an update.