A few months ago I decided to migrate my not entirely functioning Red Hat ES 3.0 system to the Debian stable release. I wanted to do my upcoming work using completely noncommercial, open source software, including the operating system. This migration seemed like a task that would be relatively straightforward for someone with 25 years of software development experience.
It wasn't, but the adventure was certainly educational. The next time I need to migrate a Linux system, perform a major operating system upgrade, or install a system on a new PC, I'll have a much better understanding of what to do before I start and what to watch out for as I proceed.
If you run Linux on hardware that is your own, or over which you have administrative responsibilities, it is inevitable that at some point you will need to migrate or upgrade your operating system. While my migration involved Red Hat and Debian, the lessons presented here apply generally, because you'll need to address most of the problem areas encountered in my migration regardless of which Linux system you are migrating to or installing.
My hardware is an HP Pavilion a300n with a 2.6GHz Celeron processor and 768MB of RAM. I purchased it in 2002 with Microsoft XP installed. This article describes the surprising events I encountered as I modified the system to a dual-boot configuration and migrated across four different Linux versions. The final section of the article summarizes the most important lessons I learned.
My goal was a stable dual-boot system, obtained without an unnecessarily difficult migration process. For this reason, I purchased my version of Red Hat 8.0, and I actually studied significant portions of the included manuals before I started my upgrade.
The Red Hat Linux 8.0 Installation Guide (section G.1.1) advises, "The simplest way to make room for Red Hat Linux is to add a new hard drive to the computer and then install Red Hat Linux on that drive." This sounded like good advice to me. I purchased a new hard drive and installed it. After I booted the system, Windows detected the drive, but it didn't know anything about it. Otherwise, Windows seemed to run fine.
I followed the procedures in the Red Hat manuals and carefully installed version 8.0. Finally, when I had completed all of the steps, I had an operable Linux system, equipped with a nice array of standard Unix utilities and open source software packages.
There were only two things left to test: 1) Did Windows still run properly? and 2) Could I boot into both systems? I shut down Red Hat Linux expecting to see a choice of operating systems. To my surprise, the system went immediately into Windows XP, but in a "recovery" mode. Apparently, Windows had detected that the boot sector had been compromised and intended to "fix" the problem by rewriting the correct boot information from a backup copy. When I saw this, my immediate fear was that if I let this happen, I would have no way to return to the Linux installation I had just configured. I pressed and held the power button until the system finally shut down.
My desktop computer was, in effect, unusable! Looking again at the Red Hat manuals, it didn't appear that I had done anything wrong. Instead, Windows XP was doing something that the Red Hat documentation hadn't anticipated.
Wondering what to do, I browsed the internet (using my laptop) and studied other sections of the Red Hat documentation. In the Troubleshooting section, I saw information about alternative boot options, which included using a CD or a floppy boot disk. A floppy boot disk seemed like a simple solution to my problem. I found references on the internet to a Red Hat utility to create a floppy boot disk. I booted back into Linux using the Red Hat installation CD, opened a terminal window, and ran the command. Finally, I had my dual-boot system: with the floppy in the drive, the computer booted into Linux; without the floppy, the system booted into Windows XP.
Not too long after, a new consulting assignment required that I become familiar with Oracle. A visit to the Oracle web site found a developer's version of Oracle that runs under Red Hat. I decided to upgrade my system to ES3 in order to be able to run Oracle.
The first thing that disturbed me was the high cost of ES3. I was now getting into the corporate sector of Red Hat's marketing, and the company expected me to pay big bucks in order to have the Red Hat operating system that could run a pared-down developer's version of Oracle. Well, being an entrepreneur, I accepted that and duly spent my $400-plus for ES3, and several hundred more dollars to update my memory so that it could support both ES3 and Oracle.
The available information suggested that I could perform the upgrade to ES3 on top of a previously existing Red Hat operating system. I selected the upgrade installation option, and everything proceeded apparently without error. At the end of the installation, I had a fully operating Linux system, as far as I could tell. Then I installed Oracle. This installation also went fine (a few glitches and difficult decisions set aside).
Now I had ES3 and Oracle on my computer. The system was very stable in this configuration. However, I soon discovered that all activities that required the root permission for configuring the operating system using the Red Hat GUI applications (for example, changing the system clock) were no longer functional. Somehow, either the ES3 or Oracle upgrade had altered my system, completely disabling Red Hat's very nice GUI-oriented system administration capabilities. Because I'm not a Unix system administrator, this was a very annoying problem. As usual, I searched the internet for documentation and fixes from people who had experienced similar problems, but to no avail.
The Red Hat system administration GUI failure was part of my inspiration to move to an entirely new Linux distribution. I chose Debian because of its reputation for stability and its commitment to remaining noncommercial, and because the size and momentum of the community seem to ensure its long-term viability.
This time I decided to be a purist and obtain my Linux system for free, downloading ISO images of the system installation CD from the internet. Thus began the first in a series of frustrations in migrating to Debian.
Finding the ISO images was not difficult. The Debian team recommends using the Jigdo software to download Debian ISOs. Jigdo, short for "jigsaw download," performs error-free ISO downloads in a piecemeal manner that does not overburden the Debian download servers with excessive bandwidth spikes. (Debian software is free, after all.)
Once I had my ISO images on disk, I needed to make the actual installation CDs. This was not as simple as expected. I knew I couldn't just put the .iso files onto the CDs using a simple Unix or Windows copy command, but it didn't take long before I had a growing stack of useless, improperly created CDs (and rapidly rising impatience). Then I discovered Alex Feinman's ISO Recorder Power Toy. ISO Recorder is a very convenient tool that runs on Windows XP. It integrates with the operating system such that when you right-click on an ISO image file, a menu option labeled "Copy image to CD" is displayed (see Figure 1). Clicking on the copying option produces a correctly formatted CD using the ISO image.
Figure 1. ISO Recorder software running in Windows XP
With proper Debian installation CDs in hand, I thought I was finally set. I made a floppy boot disk using an image from the Debian web site. Then, with the Debian installation manual displayed on my laptop, I inserted the CDs and installed Debian version 3.0 (Stable). I guessed when it came to the video card and monitor specifications, but I assumed that selecting a very generic configuration was likely to work.
Wrong! I could not persuade the X Window System to display correctly on my screen. Internet searching led me to look at my XF86Config-4 file in /etc/X11. I tried several not-too-drastic hack tweaks (making certain to save all of my intermediate file versions), but nothing worked. Finally, I broke down and went to the Hewlett-Packard site to retrieve the actual detailed specifications for my video card and monitor. A few quick internet searches later, I realized I had a big problem: Debian 3.0 ("Woody") does not support the video card in my HP machine.
This points out one of the drawbacks of Debian's slow and careful approach to advancing the version it labels "stable." My more than two-year-old computer, bought from a reputable manufacturer and equipped with a basic low-tech video card, cannot properly run the current Debian Stable version.
Further investigation revealed that the actual culprit was the version of XFree86 (4.3) implemented in Debian "Woody." Subsequent stable XFree86 versions (4.4+) include support for my video card. I could have tried to upgrade my Debian Stable installation to the newer XFree86--but that seemed like an enormous risk, given all the problems I'd already had and my total lack of experience with the Debian distribution. With a little more investigation, I found that Debian itself offered a solution: I could upgrade to the Debian Testing version ("Sarge").
Now I faced a dilemma: my initial goal had been to have a very stable installation, but the only Debian version that supported my hardware configuration was the Testing version. After all the effort I'd already invested in Debian, going back to Red Hat or to another Linux distribution was not an option. Hoping that what Debian calls "testing" might be "stable" to many other organizations, I decided to migrate to the Debian Testing version, aka "Sarge."
The first thing I noticed is that the Debian team has significantly simplified the installation procedure for the Testing version. The installation requires only one CD. The installation launches from the CD and establishes a connection to a Debian network installation server. The installation proceeds over the Net.
My installation of Debian "Sarge" proceeded without incident. I was cautious
selecting the default properties for my video card and screen during the
installation. Once I saw that the X Window System worked, I went back to the
XF86Config-4 file and added higher-resolution graphics modes in its
Screen section. If you decide to edit this file
yourself, study the XF86Config man page
first, and make a backup of your working copy before you proceed.
The most worrisome period of my "Sarge" installation was when the system asked me about configuring the boot. I could not find any information about making a floppy boot disk for "Sarge." Would Windows XP overwrite any attempt by Debian to make itself bootable from the hard drive?
The Debian installation uses the GNU GRand Unified Bootloader (GRUB) utility to configure the boot procedure. I was somewhat optimistic when the procedure clearly showed several operating systems available for booting (including a Debian Recovery system) and let me arrange the order in which the operating systems would boot. There was also an option for disabling (temporarily) individual operating systems. One surprise was that in addition to Windows XP, there was also a bootable Windows NT operating system.
I completed the boot configuration procedure and rebooted the computer. Sure enough, it presented me with the list of operating systems I had requested, with Debian Testing as the default operating system. I let the system boot into Debian, and everything worked fine. Next I tried booting into Windows XP. That worked, and Windows made no attempt to "fix" my corrupted boot sector.
Ever curious, I next selected that surprising Windows NT entry. Immediately, the warning message appeared and the system launched into its Windows boot sector recovery procedure. I pressed and held the power switch, and the system powered down. Now I understood a secret about my as-purchased HP system: the standard boot was into this mini-NT operating system, the only purpose of which was to check for a "corrupted" boot sector. If the sector contained only the original NT and XP data, XP launched; otherwise, the Windows recovery procedure launched. It's a clever system for fighting virus attacks on the boot sector.
I've run the Debian Testing version for several months now without any
significant problems. Several times I've downloaded new packages using the
Debian package management utility apt. I've
also occasionally refreshed my entire set of packages using the very convenient
apt-get update command. All the packages/applications I've needed
thus far (mostly software development tools) have been available using apt. If
you have a choice between downloading source code and building from scratch, or
apt-get, the latter will most certainly be the most
convenient and straightforward option.
I've now "successfully" migrated my HP computer through four complete Linux distribution installations. Here's what I recommend to anyone who needs or chooses to migrate a Linux system:
If you are not a Unix/Linux system administrator, migrating or installing a new Linux distribution can be a daunting and time-consuming task. Planning ahead, including being prepared to scour the internet for details of issues you encounter along the way, will enable your system migration to proceed with fewer delays and, we hope, eliminate dead ends before they happen.
The following links provide useful information on installing and migrating Linux systems:
Kevin Farnham is the owner of Lyra Technical Systems, Inc, a small consulting and publishing company.
Return to the Linux DevCenter.
Copyright © 2009 O'Reilly Media, Inc.