Dual-Boot RAID 0: Ubuntu 10.04 and Windows XP

I wanted to set up a SATA RAID 0 array that would function like any other dual-boot system:  I would turn on the computer; it would do its initial self-check; I would see a GRUB menu; and I would choose to go into either Windows XP or Ubuntu 10.04 from there.  This post describes the process of setting up that array.

With no drives other than my two identical, unformatted SATA drives connected, I turned on the computer.  The BIOS for my Gigabyte motherboard did not give me the obvious RAID configuration option I had hoped for.  I hit DEL to go into BIOS setup.  Nothing jumped out at me.  Desperate for guidance, I turned to the manual.  I was looking at an Award Software CMOS Setup Utility.  The manual directed me to its Integrated Peripherals section.  There, I set OnChip SATA Controller to Enabled, OnChip SATA Type to RAID, and OnChip SATA Port4/5 Type to As SATA Type.  I hit F10 to save and exit.

According to the manual, that little maneuver was supposed to give me an option, after the initial boot screen, to hit Ctrl-F and go into the RAID configuration utility.  Instead, the next thing I got was this:

Press [Space] key to skip, or other key to continue...

I didn't do anything.  In scanned my drives and then led on to the Ctrl-F option.  I rebooted and tried it again.  Hitting the space key led to the same result.  Ctrl-F opened the AMD FastBuild Utility.  I hit option 2 to define an array.  This gave me a list of my two drives, labeled as LD 1 and LD 2.  Apparently it wasn't supposed to show anything.  LD was short for "logical disk set."  It was essentially showing two separate arrays, each having one drive.  So although the manual didn't say so, it seemed that I needed to get out of here and go into option 3 to delete these arrays.  I did that and then went back into option 2.  Now I was looking at a blank list of LDs, just like in the manual.

So now I was ready to prepare my array.  In option 2, I hit Enter to select LD 1.  This defaulted to RAID 0 with zero drives assigned to it.  I arrowed down to the Assignment area and put Y next to each of the two drives listed.  Now it said there were two drives assigned.  But now I had a couple of things to research.  The screen was giving me options for Stripe Block, Fast Initialize, Gigabyte Boundary, and Cache Mode.  The manual didn't say what these were.

I did a search for information on the Stripe Block size.  I found an old AnandTech article that took the approach of choosing the lowest stripe size where performance tended to level out -- where, that is, increasing the stripe size another notch did not increase performance.  For the RAID controllers they were testing, it looked like performance kept increasing right up to the range of 256KB to 512KB, for those controllers whose options went that high.  Mine only gave me a choice between 64KB and 128KB, so I chose the latter.  A more recent discussion thread seemed to support that decision.

Regarding the "Fast Init" option, a search led to some advice saying that slow initialize would take longer but would improve reliability.  A different webpage clarified that the difference was that slow initialize would physically check the disk and would be suitable if you had had trouble with the disk or if you suspected it had bad blocks.  I decided to stay with the default, which was Fast Init ON.

The "Gigabyte Boundary" option would reportedly make the larger of two slightly mismatched drives in an array behave as though it were the same size as the smaller one.  The concept appeared to be that, if you were backing up one drive with another (which was not the case with a RAID 0 array), you would use this so that the larger drive would never contain more data than the smaller drive could copy.  Mine was set to ON by default.  I couldn't quite understand why anyone would need to turn it off, even if the drives were the same size.

Finally, the "Cache Mode" option was apparently capable of offering different choices (e.g., write-back), but mine was fixed at WriteThru with no other options available.  So I thought about it a long time and then decided this was acceptable to me.  So then I hit Ctrl-Y to save these settings.  Now I was back at the Define LD Menu, but this time it showed a RAID 0 array with two drives and Functional status.  That seemed to be all I could do there, so I exited that menu.  I poked around the other options on the Main Menu.  I seemed to be done with the FastBuild Utility.

Next, the manual wanted me to use a floppy disk to install the SATA RAID driver.  I could have just gone ahead and done that -- I still had a floppy drive and some blank diskettes -- but I thought surely there must be a better way by now.  Apparently there was:  use Vista instead of WinXP.  But if you were determined to use XP, as I was, the choices seemed to be either to go through a complex slipstreaming process or use the floppy.

There was, however, another option.  I could buy a RAID controller card, for as little as $30 or as much as $1,000+, and it might come with SATA drivers on CD.  This raised the question of whether the RAID cards actually had some advantage beyond their included CD.  My brief investigation suggested that a dedicated RAID card could handle the processing task, taking that load off the CPU, but that there wasn't much of a processing task in the case of RAID 0.  In other words, for my purposes, a RAID controller card wouldn't likely add any performance improvement.  Someone said it could even impair performance if it was a regular PCI card (as distinct from e.g., PCIe) or if its onboard processor was slower than the computer's main CPU.  There did seem to be a portability advantage, though:  moving the array to a different motherboard would require its re-creation, in at least some cases, but bringing along the controller card would eliminate that need -- though the flip side was that the card might fail first, taking the array with it.

Further reading led to the distinction between hardware and software RAID.  An older article made me think that the essential difference (since they all use hardware and software) was that software RAID would be done by the operating system and would run on the CPU, and would therefore be dependent upon the operating system -- raising the question of whether dual-booting would be impossible in a software RAID array, as a generally informative Wikipedia article suggested.  To get more specific, I looked at the manual for a popular motherboard, the Gigabyte GA-MA785GM-US2H.  That unit's onboard RAID controller, plainly enough, was like mine:  it depended upon the operating system.  Wikipedia said that cheap controller cards provide a "fake RAID" service of handling early-stage bootup, without an onboard processor to take any of the load off the CPU.  FakeRAID seemed to get mixed reviews.

An alternative, hinted at in one or two things I read, was simply to set up the RAID 0 array for the operating system in need of speed, and install a separate hard drive for the other operating system.  I was interested in speeding up Linux, so that would be the one that would get the RAID array.  I rarely ran Windows on that machine, so any hard drive would do.  A look into older, smaller, and otherwise seemingly less costly drives led to the conclusion that I should pretty much expect to get a 300GB+ hard drive, at a new price of around $45.  Since I was planning to use Windows infrequently on that machine, it was also possible that I could come up with some kind of WinXP on USB solution, and just boot the machine with a flash drive whenever I needed access to the Windows installation there.

I decided that, for the time being, I would focus on just setting up the Ubuntu part of this dual-boot system, and would decide what do to about the Windows part after that.  I have described the Ubuntu RAID 0 setup in another post.

Ubuntu 10.04 Reinstallation: Another Go

I had previously installed Ubuntu 10.04 once or twice.  This post provides a synthesis of the process, done on a Windows XP dual-boot machine.

Things to Save

The first thing to think about was, What did I want to save from my previous installation?  I was already keeping my data in an NTFS partition that WinXP recognized as D:.  I had named that partition DATA in both operating systems (OSs).  So I did not have most of my data on the root (commonly referred to with a simple slash, "/") partition containing my Ubuntu program installation.  The main exception was what Ubuntu knows as the /home partition.  (This and other Ubuntu folders, being included on a partition formatted in ext3 or ext4, were invisible to Windows.)  The /home partition was the default location for user data files.  My own files -- documents, PDFs, etc. -- were no longer there, but Ubuntu would still save various settings and other things there.  So I decided to try create a new /home partition, and copy the old /home folder's contents to the new /home partition, before reinstalling Ubuntu.  That little effort became the subject of a separate post.

Just in case, I saved my open tabs in Firefox (Ubuntu) using an extension whose name was not visible to me at this writing -- called (I believe) CopyAllURLs.  I also used the FEBE addon to save my complete Firefox setup; and since FEBE had failed in the past, I used the InfoLister addon to save at least the list of addons that I had currently installed.  I had previously saved their settings separately, for those addons (e.g., Tab Mix Plus, Forecastfox) that allowed me to do so.  I saved all of these things to my data drive, not to the Ubuntu programs drive that I was about to wipe out.  All of these steps proved to be unnecessary:  the separate /home partition (below) saved my entire Firefox setup just as I had left it.

I started up Chrome and Opera, both of which I had installed on this machine, and saved a list of their open URLs.  This, too, was unnecessary, thanks to the separate /home partition.  I had already migrated my email and contacts from Thunderbird (Ubuntu) to the Windows portable version of Thunderbird.

There was another thing to save, but I forgot until too late.  I should have run the installed-software command to make a current list of the programs I had installed on Ubuntu.  Instead, I was going to have to use the older list that I had saved some months earlier, and any programs installed since then would have to be rediscovered and reinstalled one at a time.

I should also have saved /etc/fstab.  My set of hard drive partitions had mostly not changed.  I could have just edited that instead of starting over from scratch (below).

That was pretty much all that I needed to save from the old Ubuntu programs partition that I was about to wipe out.  Most of my work was done in Windows virtual machines running on VMware Workstation, and those were on a separate partition already.  So now it was time to begin the installation.

Installation from CD

This time, I installed Ubuntu 10.04 from scratch, using the CD.  Previous inquiries had suggested that the PAE-enabled kernel would be installed automatically when installing from the CD.  (PAE allowed 32-bit Ubuntu to access RAM well beyond the 4GB theoretical limit -- apparently up to 64GB.)  By right-clicking on individual items in the partition install screen during installation, I manually designated a 30GB root ("/") partition for programs.  The installer automatically detected my previously formatted 5GB swap partition.  It seemed that people were still having problems with ext4, so I formatted the root partition as ext3.  At reboot, GRUB did say that I was installing a PAE kernel, so that was good.

Installing Software

Now I ran the second half of the installed-software command (above) to restore the set of programs that I had installed on Ubuntu at various points.  This involved using Nautilus to put a copy of my installed-software list someplace accessible (I chose my Desktop), using "cd ~/Desktop" as the short way of getting to the desktop, and then typing the necessary commands:

sudo dpkg --set-selections < installed-software
sudo apt-get install dselect
sudo dselect

This gave me a menu, from which I chose option 3, "Install and upgrade wanted packages."  It did so.  It took about an hour.  During the process, it asked "Do you want to erase any previously downloaded .deb files?"  My search yielded no clear answer to this question.  I guessed, from a couple of things I saw in that search, that this was like the question that came up in some Windows installations (in Microsoft Office, perhaps), where you would have the option of keeping downloads on the hard drive to make future fixes or upgrades faster, at the expense of consuming additional disk space.  I tried the Yes option.  It paused for a minute and then put me back at the menu.  So I guess it deleted some .deb files.  Anyway, the installed packages included ntfs-config, so now I could run that ("sudo ntfs-config"), so that Ubuntu would recognize my NTFS (Windows) partitions and put appropriate entries in /etc/fstab.  So then /home would be recognized on reboot.

Unfortunately, something in the install-software process screwed up my system, leading to a "udevadm" error message and a whole separate post.  But then, when I rebooted, I had another problem.  I was looking at a nearly blank screen.  It just showed the name of Ubuntu across the top ("Ubuntu 10.04.1 LTS P4 tty1," where P4 was the name of my computer) and then gave me a simple login prompt:  "P4 login."  I wasn't sure what to search for, to solve this problem, so I booted with the alternative installation CD and chose the "Rescue a broken system" option.  Ultimately, it gave me two basic options:  either reinstall GRUB or execute a shell in my Ubuntu program partition (in my case, /dev/sdb8).  I had no idea what to type at the prompt, and I didn't seem to be having a GRUB problem, so I tried a search; but it turned up stuff dealing with monitor problems.  I tried another search and came across the idea that I could just type "startx" to open the graphical user interface (GUI), so I rebooted, entered my username and password at that prompt, and then typed startx.  But this gave me some error messages:  "Failed to open device," "No valid modes," and "Screen(s) found, but none have a usable configuration."

Basically, it seemed that the installed-software process had messed up my system.  So I started over, installing Ubuntu from scratch, and this time I didn't use the installed-software option.  I had to go back through the process of setting up my separate /home partition, and then I worked manually through the installed-software process.  That entailed setting up my repositories.  After that process, some programs were still not installed.  Drawing upon my previous installation and its follow-on comments (as well as notes in a few other posts), I used System > Administration > Synaptic Package Manager to install acroread, adobe-flashplugin, boinc, dvgrab, fdutils, gparted, mplayer, nautilus-open-terminal, ntfsprogs, p7zip-full, sysinfo, ubuntu-tweak, unetbootin, and webhttrack.  Then I installed several programs that I had downloaded separately, on the assumption they were not available via Synaptic.  These included VMware Workstation 7, which I installed, as I had learned to do, by typing "sh VMware-Workstation-Full-7.1.0-261024.i386.bundle" in the folder containing that downloaded bundle file.  The simple "sudo sh" prefix was also adequate for installing my separate .bin downloads (i.e., GoogleEarthLinux.bin).  I installed Beyond Compare, Opera, and Google Chrome by just double-clicking on the .deb downloads.

Settings and Adjustments

Creating the separate /home partition had preserved most of my Nautilus settings, but I still had to tweak a few of those manually.  It had not saved my monitor driver settings, so now I went into System > Administration > Hardware Drivers, searched for available drivers and, for my machine, found NVIDIA accelerated graphics driver (current version) > Activate. This, like other installation and activation steps, would work only when there was no other Synaptic or software installer running.  I rebooted to activate the hardware driver.  Unfortunately, I was still getting some bad ghosting.  Tightening my video cable connectors solved the problem.

Most of my newly installed programs did not require immediate configuration.  To configure BOINC, I went to Applications > System Tools > BOINC Manager > Next > Choose a Project > World Community Grid > Next, and then went into Advanced > Settings to adjust my preferences.

GRUB2 had lost the setting by which it would remember which operating system I had booted last, and would reboot that one instead of defaulting to Ubuntu, so I typed "sudo gedit /etc/default/grub"; I changed one line to say GRUB_DEFAULT=saved instead of GRUB_DEFAULT=0; I added another line, right after it, that said "GRUB_SAVEDEFAULT=true"; I saved and closed that file; and then I typed "sudo update-grub."

Following a previous post, I pruned the list of entries shown in the GRUB2 menu at bootup.  First, I typed "sudo gedit /etc/grub.d/10_linux" and added a line, immediately after the comments section at the top, that said "GRUB_DISABLE_LINUX_RECOVERY=true" (without quotes, as always).  That would prevent me from seeing the "recovery" versions of Linux kernels in that menu.  At the end of that same file, I searched for the place that had these two lines:

list=`echo $list | tr ' ' '\n' | grep -vx $linux | tr '\n' ' '`
done

and changed it by inserting another list line between those two:

list=`echo $list | tr ' ' '\n' | grep -vx $linux | tr '\n' ' '`
list=`version_find_latest $list`
done

(Note that backticks ( ` ) are not the same as single quotes ( ' ) in such files.)  This, I hoped, would show me just the one or two most recent Linux kernels.  Finally, I saved and closed 10_linux and modified its companion file with this command:  "sudo chmod -x /etc/grub.d/20_memtest86+."  This command would hopefully prevent me from seeing the memtest options in the GRUB2 menu.  I rebooted and confirmed that it worked.

Other settings did remain intact via the preserved /home partition.  Unlike the steps described in the previous installation and in another tweak post, I did not have to make manual adjustments to prevent icons for mounted drives from appearing on the desktop.  My previous list of programs that should run at startup remained intact.  Gedit was still my default crontab editor.  The permissions giving me access to various partitions as ordinary user, not root, were still in place.  My VMware settings seemed to have been preserved, except for what may have been a few new root-level settings in the new version of VMware Workstation that I had just installed.

When these steps were complete, I ran Update Manager one last time, rebooted, and confirmed that everything looked good.  Then I rebooted with a CD and made an Acronis disk image on a separate partition.  Done!

Restoring GRUB on Dual-Boot Vista-Ubuntu (9.10) Machine

I had Ubuntu 9.10 (Karmic Koala) installed.  I reinstalled Microsoft Vista.  This knocked out the GRUB boot menu.  To restore the boot menu, I followed some Ubuntu community documentation.  The steps I used there, boiled down for my purposes, were simply to reboot from the Ubuntu CD, go into the Ubuntu partition via the Places menu, type "mount | tail -1" to make sure the Ubuntu partition was now mounted (in my case, it said something like "/dev/sda2 on /media/UBUNTU type 3" because I had named the partition using GParted), type "ls /media/UBUNTU/boot" to make sure I had the partition containing GRUB (along with memtest86+ and other files), and then run "sudo grub-install --root-directory=/media/UBUNTU /dev/sda."  That last command did not end in a number (e.g., sda2); it was simply the drive containing the boot partition.  In place of UBUNTU in my example, I would have typed the long UUID if that was what the mount command had given me.

That pretty much fixed it.  When I rebooted, I did have a GRUB menu.  But when I opted to go into Ubuntu, I got an error message:

One or more of the mounts listed in /etc/fstab cannot yet be mounted:

SWAP: waiting for UUID=[UUID number]

Press ESC to enter a recovery shell.

I pressed ESC.  I went to Applications > Accessories > Terminal and typed "sudo gedit /etc/fstab."  This opened fstab.  The lines weren't wide enough to view clearly, so I expanded the box.  Fstab contained an entry for SWAP, which (above) was the partition that didn't boot in my case.  I started another Terminal session and typed "blkid" to see what the UUIDs were.  I saw that the UUIDs and the /dev entries for SWAP didn't match.  I changed the fstab line for SWAP to match what blkid had given me, for both the UUID and the /dev location.  (I had to use the right-click option to copy from the Terminal output for blkid.)  I saved fstab and rebooted.  That seemed to fix it; the boot proceeded normally.