Installing Linux on an external USB hard drive

First a little background…

Why would one want to install Linux on an external USB hard drive instead of setting up a dual-boot type system? Well, for starters, the intended target for this OS is my laptop. My laptop hard drive already has Vista installed and I didn’t feel like using a partition editor to create a new partition using the free space on the drive. Also, installing a second hard drive in a laptop is simply not an option. I could have opted for installing a small-footprint Linux distro on a USB thumb drive, but I wanted a full-featured OS that was not limited in any way.

The main reason for this little project is that I can only be truly happy in a Linux environment when I do serious (web development) work. I love having a local MySQL, Apache, and PHP installation. I love having access to a terminal. I love using Subversion via CLI and I cannot stand PHPMyAdmin.

Now, normally, I don’t do any major development work on my laptop – it’s an e-mail checking, web browsing, IM’ing, and general computing type machine that runs Vista (oh come on, it’s not that bad.) But, I will be working out of the company’s Sacramento office for several days next month and I’d like to bring my laptop and get some actual work done. Because I am picky about my development environment, I decided to duplicate my work machine on an external drive that I could simply plug in to my laptop (or any other computer that supports booting from an external USB hard drive.)

So without further ado…

I opted to install Fedora 10 with the external drive attached to my desktop system – which, fortunately for me, shares much in common with my laptop. Namely, both systems have a 64-bit processor, 2 GB of RAM, and an ATI video card. In theory, it shouldn’t matter which system you attach the drive to for the installation process, so long as you don’t install the 64-bit version when the intended target is a 32-bit system. If you want an install that can be plugged into any system, you may want to opt for the 32-bit version of the OS. Also, if you install the OS on a platform with an ATI video card and then attach the drive to a system that has an Nvidia graphics chipset (or vice versa), you may have some video card driver issues when first booting into Xorg, but, then again, Xorg may detect the proper video card on boot up and correct the issue automatically.

The installation itself was straightforward enough – connect the external drive to the computer, insert Fedora 10 install DVD, reboot computer, select external drive as installation target, and install the OS. The whole installation process took several hours – mainly because I opted for the additional repositories during installation so the final install would be 100% up-to-date. Also, working on an external drive is always going to be slower than an internal drive.

Once the installation was finished, I rebooted my desktop in the hopes of being able to test it out. Alas, my desktop did not want to boot from the external drive even though I had selected “USB hard drive” as the boot device. I thought maybe GRUB had not been properly installed on the external drive, so I booted up the Fedora 10 DVD and did a “Linux Rescue” session, reinstalling GRUB. This did not fix the situation.

Dubious this installation would work at all, I proceeded to disconnect the drive from the desktop and connect it to the laptop (Toshiba Satellite A215-S7437) for a final test. During the BIOS POST, I hit F12 to bring up the boot device selection list and crossed my fingers. In the boot list that eventually appeared, the usual devices were present: CD/DVD, Hard drive, and Network – but there was also a “USB memory” device present. I selected this device and low and behold, Fedora 10 began loading and in no time at all, I was presented with a log in screen.

Impressions and observations so far…

The system is far more responsive than I thought it would be, considering it’s running from an external USB 2.0 drive. That being said, it’s obviously not as fast as an internal drive. But I find it to be more than adequate for more needs.

One glitch I have come across is when connecting another (USB powered) external drive to the laptop – it causes the primary external drive to reset and the whole system locks up. I suspect this is a limitation of the laptop’s USB hardware – but it could be a kernel issue as well.

Linux + Onboard SATA RAID

Are you considering using the onboard RAID feature of your SATA controller? Before you dive head-on into this project – there are a few things you should know.

Recently, my job took me into territory that was somewhat unfamiliar – the server realm. When I say server, I don’t mean a home server most of us Linux enthusiasts have. I mean a server – dual Opteron, 8GB RAM, and 2 x 320GB hard drives. The kind of server that can handle complex database queries in a matter of a few nano seconds. The kind of server that must be 100% secure and reliable. Our hope was to run the drives in a RAID-1 configuration for maximum stability. For those unfamiliar with RAID, a RAID-1 array mirrors data from one drive to another. This can really speed up disk reads and also gives you a very stable environment when using failover support – i.e. if one drive happens to die on you, the OS will automatically rollover to the backup disk. I had never setup a RAID array before, but felt confident that it could not be too difficult – of course, I was wrong.

The motherboard we selected for our server (a Tyan S2881) has four SATA connectors and a RAID controller. On initial power-up, I entered the BIOS and enabled the RAID controller for the SATA. Once RAID had been enabled, I entered the RAID BIOS and created the RAID-1 array using both disks. Assuming the RAID controller would handle everything else and that Linux would detect it, I continued with my installation of RedHat Enterprise Linux 4.0

I was gravely mistaken. Here is the issue: most newer motherboards that claim to have RAID support, have what is known as FakeRAID – essentially a software RAID. Drivers for these FakeRAID controllers found on most motherboards is not really supported in newer kernels. In my case, a Silicon Image 3114 controller, had a driver in the kernel but only supported the standard SATA protocol and did not enable any of the FakeRAID features of this chipset. Reading on boards and forums around the ‘net, I was informed that disabling the RAID controller in the BIOS and simply using the built-in software RAID within Linux was a much better alternative and was no better or worse than using the FakeRAID for my chipset.

Unsure if these claims were true, I spent some time finding a linux driver for my Silicon Image 3114 RAID controller. The manufacturer had them posted on their website along with installation directions. Half a work day was spent wrestling with these drivers reformating, repartionting. In the end I abandoned the idea of using the onboard RAID controller and proceeded to use the Software RAID option found in RedHat Linux.

After a successful install of RedHat Enterprise Linux 4 onto a RAID-1 array, I found that the boot loader was not correctly installed. If you run into the case where, after a successful install of Linux onto a RAID array, you are presented with simply: “GRUB” at boot up – do not worry. Grab your install CD or DVD and boot using “linux rescue”. Once booted, run:

grub
root (hd0,0)
setup (hd0)

Now reboot and you should be in business. Don’t forget to remove the install CD or DVD from the drive.

Heed my words, unless the RAID controller on your motherboard is a true hardware RAID controller, do not waste your time trying to get the FakeRAID working.