Installing RAID 0 in Ubuntu 10.04 (Lucid Lynx)

In a previous post, I was working toward having a dual-boot Windows XP and Ubuntu 10.04 system, with a RAID 0 array for at least the Ubuntu installation.  Here, I describe the process I went through to set up that array.  I had previously had a WinXP/Ubuntu dual-boot system on a single Western Digital Velociraptor drive; the main change here is adapting that to the RAID scenario, and seeing whether this would be faster.

I started with a very helpful video by amzertech.  (Actually, two videos.)  I have provided a detailed description of the process (below).  To summarize, I had to boot the alternate Ubuntu CD and use it to install root ("/") and swap partitions on each drive in a RAID format, along with a /boot partition on one drive.

Troubleshooting

It all seemed to go pretty smoothly, and certainly other people seemed to have had good luck with that video.  But when I was done and I tried to boot the system without the CD, I got "error:  no such disk" and then a "grub rescue" prompt.  And in the FastBuild Utility discussed in the previous post, I was no longer seeing two drives configured into one logical disk set; they were back to being two separate JBOD ("just a bunch (or a box) of disks") drives.  So it seemed that what I had done previously was not necessary.

After digging around in a search, I found a post where they said the problem got solved for them by undoing the BIOS edits I described in the previous post.  So I rebooted, hit Del, went into the BIOS > Integrated Peripherals and set the OnChip SATA Controller to Disabled.  This greyed out the other two items that I had changed and put them back into their previous settings.  I saved and rebooted.

This time, I got "DISK BOOT FAILURE, INSERT SYSTEM DISK AND PRESS ENTER."  A search led to a Tom's Hardware thread where they advised, among other things, adjusting the boot order in the BIOS.  So I tried setting the hard drive to boot first, instead of the CDROM drive.  But I got the same error again on reboot.  That thread contained many other suggestions:  update your motherboard's BIOS, make sure all cables are firmly connected, disconnect all other drives, use other software (e.g., Disk Boot Manager), check that the jumpers on your hard drives are set correctly (at least if you're using PATA drives, which I wasn't), fiddle with BIOS settings, etc.

The BIOS update was a possible solution, but I began instead by rearranging cables a couple of times.  My goal there was to match up the hard drive on which I had installed the /boot sector (I didn't know which of the two it was) with the lowest-numbered SATA connector on my motherboard (i.e., SATAII0 as distinct from SATAII1, SATAII2, etc.).  But that didn't do it either; still the DISK BOOT FAILURE message.  I also tried going back into the BIOS and setting Hard Drive as the first, second, and third boot options.

Following some other suggestions, I went back into BIOS and enabled the OnChip SATA Controller as Native IDE type (even though they were SATA drives).  This gave me a new error:  "MBR Error 1.  Press any key to boot from floppy."  I tried reversing the cables, in case I had the drives in the wrong order.  And that did it.  Success!  Ubuntu booted.  I restarted the computer, set the BIOS back to boot first from USB, second from CDROM, and third from hard drive (as it had been previously), and thus verified that the solution seemed to be as follows:  set BIOS to Native IDE type, and make sure the drive with the /boot partition is connected to the first SATA connector on the motherboard.

Assessment

In Ubuntu, I went into Synaptic and installed GParted.  I took a look at what had happened.  I had used two 640GB drives for my RAID 0 array.  In an earlier time, this would have been extravagant.  By now, however, prices on such drives were in the basement.  But I did still wonder if I could use the rest of these drives for some other purpose.  I had allocated an absurdly large 100GB space (50GB per drive) for my root partition -- leaving a total of more than 1TB unused!

So now, in GParted, I saw three drives:  md0, sda, and sdb.  md0 was a net 93GB, with no further information.  sda essentially had the partitions I had set up in the RAID setup process:  the root partition, the /boot partition, the swap partition, and about 540GB left over.  sdb had its own matching root and swap partitions, though they were labeled as having an "unknown" file system, and a matching 540GB unallocated.

More RAID Partitions

Could I use that 1TB of unused space?  I wouldn't have put my data there -- RAID 0 had twice the risk of data loss, in the sense that either drive's failure would take down the array -- but there were some other possibilities.  In particular, I could store my VMware virtual machines (VMs) there, as long as I kept backup copies elsewhere; they would run faster on the RAID array.  And I also wanted to set up a separate /home partition.  But should I have created these partitions while I was going through the initial RAID setup?  And could I store anything on just one hard drive or the other, or did everything on these two drives have to be set up in a RAID format now?

I decided not to research the option of storing things on just one drive or the other at this point.  Apparently it was possible, and could even be done after the fact from within Windows XP.  Since there would be a lot of completely unneeded empty room left over after this RAID installation, I would just let it sit on the drives as unformatted space for the time being.  But for the VMs and anything else (video editing files?) that might call for the performance of RAID 0, I decided that I did want to make use of some of that space.  And I wanted it to be in separate partitions, for backup purposes, not part of the Ubuntu RAID installation mentioned above.  I figured the contents of these partitions would change more frequently and would require a different backup schedule than what the root program installation would need.

RAID 0 Setup:  Detailed Description

So now that I had my BIOS and my drives and everything else in order (above), I restarted the process of setting up the RAID 0 array, and this time I took notes.  I booted the alternate CD and went into Install Ubuntu.  I went through the initial setup options (language, keyboard, etc.).  When it got to the partitioning screen, I chose Manual.  Now I saw that, actually, I didn't have to undo what I had already done.  The 100GB RAID 0 device I had already set up would be just fine.  I could just arrow down to the FREE SPACE items and add stuff there.

So I did that.  For each of the two drives (sda and sdb, on my system), I selected FREE SPACE and hit Enter > Create a new partition > 50 GB (giving me 100GB total) > Continue > Logical > Beginning > "Use as" > "physical volume for RAID."  Then I chose "Done setting up the partition."  Then, back in the Partition Disks screen, arrow up and hit Enter at "Configure software RAID" > Yes.  Next, Create MD device > select the two items shown as 49999MB (i.e., about 50GB) > Continue > Finish.  This put me back at the Partition Disks screen again, but this time I had a new RAID 0 device of 100GB.  I selected that device, hit Enter > Use as > Ext3 (more reliable than Ext4) > Enter.  I set the mount point to /home and the mount options to relatime and labeled it UHOME.  Then I selected and hit Enter on "Done setting up the partition."  I repeated this process, starting by selecting FREE SPACE, and created another pair of 200GB logical partitions that I labeled as RAIDSPACE and set it to mount as /media/RAIDSPACE.  My VMs would go on a folder in this partition.  I still had 700GB left over, but at least I had made a stab at converting some of that unallocated space to a useful form.

I noticed, in this process, that my previous root partition was no longer set as root.  I configured it again.  Now, when I went to Configure software RAID, it seemed that Ubuntu was going to be reinstalled there.  I went ahead with that.  With those changes made in the Partition Disks screen, I arrowed down and selected "Finish partitioning and write changes to disk" and hit Enter.  It gave me an option of formatting the root partition, but since I had already installed Ubuntu there, I didn't want to do that.  This put me into an empty blue screen for a while, but then it began installing the base system.  So maybe I should have let it format the root partition after all.  It went through the installation process and then told me that this seemed to be the only operating system on this computer and asked if it was OK to install the GRUB boot loader to the master boot record.  I said yes.

When it was done, it went into Ubuntu.  I reinstalled GParted and took another look.  It looked like I might have done something wrong.  The only md device was md0, the 93GB partition from before.  It did show the UHOME and RAIDSPACE partitions on sda, with matching Unknown partitions on sdb, all with RAID flags next to them.  Nautilus showed RAIDSPACE as a legitimate partition with 348GB free (19 GB used already!).  But no, everything seemed OK.

Bringing Stuff Over to the New Installation

I shut down the machine, connected a disk containing files from my previous system drive, booted with a live CD, and copied some things over. Specifically, I installed a third hard drive and, while booted with the live CD, used GParted and Nautilus to prepare a partition on it and then copy over all of the files from my previous machine's Windows XP installation.  I tried to copy the /home partition from my previous installation, to replace the contents of the /home partition in the RAID array, but the array was not accessible from a live CD boot.  So I copied the previous /home folder to that newly installed third hard drive.  (I knew that the previous system drive was bootable, so I would not start the system from a hard drive (i.e., without a live CD) while that one was connected, lest it screw up my new installation.)  I got an error message for just one file, a Google Earth file:  "Can't copy special file."  A "special file," according to Andreas Henriksson, was something like a pipe, device node, or socket.  I would be reinstalling Google Earth anyway, so this was no problem.

When those copy operations were done, I disconnected the previous drive and rebooted from the hard drive, this time with an external USB drive connected.  The external drive contained my previous fstab and some other materials that I needed now, as I began to work through the Ubuntu post-installation adjustment process described in another post.

The first step of that process required some adjustment for the RAID situation.  The /home partition in the RAID array wasn't available via live CD.  So I tried the technique of commenting out the regular fstab line for /home and replacing it with a reference to /dev/md2 (where the home partition was to be) and /home_tmp (instead of home).  I typed "sudo mkdir /home_tmp" and then rebooted.  Now, if all went well, the system would think its /home folder was in /home_tmp.  On reboot, I typed "sudo Nautilus," went into /home (not /home_tmp), deleted its "ray" folder (my username), and replaced it with a copy of the "ray" folder from my previous installation.  Then I typed "sudo gedit /etc/fstab," deleted the line referring to /home_tmp, and rebooted.  Then, in sudo Nautilus I deleted /home_tmp and rebooted once more.  All was good:  my settings from the previous setup were back.

I proceeded through the remaining steps to configure my new Ubuntu installation, as described in that other post.  The RAIDSPACE partition was not available to me as a normal user, but I wanted it to be, so I typed "sudo nautilus," right-clicked on RAIDSPACE, and changed its permissions.  Then I copied my VMS from the external drive to a VMS folder in RAIDSPACE.  I was getting an error message on reboot, "Ubuntu is running in low-graphics mode," when it did not seem to be.  Also, I noticed that the GRUB menu was no longer remembering the operating system that it had last used; it was defaulting to Ubuntu in every case.  I was not the only one who had this problem in RAID.  But otherwise, the previous post pretty much covered the adjustments required to get my system back to normal.

As mentioned above, I had copied over the Windows XP files from what used to be my system drive to the third hard drive now installed in this computer.  When I ran "sudo update-grub" to consolidate the changes I had made to the GRUB2 menu while making those adjustments, it said, "Found Microsoft Windows XP Professional on /dev/sdc1."  GParted said that sdc1 was the right place -- it was the NTFS partition to which I had copied those files.  I wondered if just copying WinXP files from one drive to another in Ubuntu was sufficient to create a working WinXP installation in the new location.  So now I rebooted and, in the GRUB2 menu, I chose Windows XP.  And, what do you know, it worked!  Just like that.  No GRUB errors or anything.  I had to adjust a few settings in WinXP, but for the most part things were in good shape.

The Acid Test

So that seemed to pretty much wrap up the process of converting my dual-boot WinXP/Ubuntu system from a single hard drive to a RAID 0 array.  I was sure there would be other changes to come, but it was time for the acid test:  I wanted to see how VMware Workstation performed in the RAID 0 environment.  It had been dragging, functioning very slowly for a long time, in the computer that this one was going to replace.  It had run more quickly on this replacement computer in the single hard drive setup.  No doubt the Velociraptor helped.  But how did it do in the dual drive array?

Let me say, first of all, that the general startup process in Ubuntu was darn snappy.  I noticed it right away.  Boom! my startup programs all came to life pretty smartly.  Inside VMware Workstation, likewise, performance seemed faster than it had been in native WinXP on the Velociraptor.  I was sure there would be much additional learning, but this had been a real step forward.

Transitioning Away from Windows Toward Ubuntu: The Next Step

In September 2008, I reached a point of relative stasis in the development of my computer setup.  I was using two computers, each with its own monitor, but with a common mouse and keyboard via KVM switch.  Both computers were dual-boot setups, so that I could have gone into Windows or Ubuntu on either one; but I tended to just use one or the other.  Specifically, on one computer, I installed Ubuntu and then used VMware Workstation to run Windows XP in virtual machines (VMs).  On the other computer, I was almost always running Windows XP, rarely going into Ubuntu.

I had assumed, there at the end of summer 2008, that I would be revisiting this layout in summer 2009.  Generally, that didn't happen.  Instead, two years passed.  At this point in 2010, however, I found that there had been some developments, such that this system could evolve.

One development was that, sometime in the intervening two years, I set up a third desktop computer.  It was mostly a collection of hand-me-down parts, but it ran Windows XP well enough.  If I really needed to do something in XP, I probably could do it there.  Moreover, I had acquired a laptop, for a bargain price of around $350 -- plus another $250 or so that I didn't entirely expect to spend, when I went to the store, for an extended warranty, laptop sleeve, screen protector, wireless mouse, etc.  Such a deal!  Anyway, neither the laptop nor the bucket-shop computer were anything to write home about, but they would serve in a pinch.

Another development was that I had run into several systems problems on the primary Windows XP machine.  It still ran stably, but I was getting occasional flaky problems.  Probably there would have been a list of them, if I had taken a minute to list the ways in which the machine was not performing up to snuff.

Probably the most worrisome such problem was that I had reached a dead-end in my efforts to install Windows updates on that primary machine.  It just wouldn't install them.  I had revisited the problem repeatedly.  At this point, it would probably have been more effective to just reinstall WinXP from scratch on that machine.

That update situation had been persisting for a while.  It hadn't bothered me much.  Recently, though, something else had happened.  I had somehow started using McAfee antivirus software, and I had just discovered that McAfee had been piling up gigabytes of stuff in .bup files.  I was concerned that this feat would have been possible only by mixing in data files; therefore, I had begun an effort to compare against an old backup and figure out what, if anything, might have gone missing over the past several months or longer.  So that was the end of McAfee, for me, but it was also a wake-up call to take computer security more seriously.  That meant keeping updates installed, but perhaps it also meant it was time to continue my migration away from Windows.

For such reasons, I thought it might be time to consider running both of my primary computers under the same kind of Ubuntu - VMware - WinXP VM setup.  If I needed XP, I could still drop back into the dual-boot, or just use that hand-me-down computer.  If I needed Vista or Windows 7, I could use the laptop, which was presently running the one but which apparently qualified for a free upgrade to the other.

In addition to those developments on the Windows side, things had also been happening on the Ubuntu side of the equation.  First, the good things.  Ubuntu was looking good and running well.  I had learned a bit more about Wine.  Generally, I was continuing to become more familiar and comfortable with the world beyond Windows.  I still had occasional issues with VMware, but generally nothing lethal.  As an additional consideration, Oracle had created the impression that it might be positioning VirtualBox to compete effectively with VMware.  Even without that, it was still nice that I could leave a WinXP VM running in Ubuntu for a week without needing to reboot it, while that would just never work on the native WinXP machine.

At the same time, after these several years of experimenting with Ubuntu, I had to agree with someone who had said that Linux distributions still tended to be terribly unpolished in comparison with Windows.  Somewhat contrary to my expectations, I was not finding many instances in which Ubuntu programs were delivering superior functionality and reliability.  For instance, I had bought a copy of Beyond Compare, a file synchronization program.  (I subsequently realized that I probably could have gotten by with a freeware alternative, but whatever.)  There were Windows and Linux versions of Beyond Compare.  The Linux version did not seem to be very actively developed, and it was having problems that I wasn't having in the Windows version.  The same was true elsewhere.  I was still using IrfanView, which did not yet have a Linux version; I was still using CoolEdit 2000, because it had features that Audacity did not provide.  Generally, I was finding that Ubuntu was great as an operating system; I was finding it useful as an underlying layer, to handle tasks that WinXP couldn't handle (e.g., delete files that WinXP couldn't delete); I found that WinXP running in a VM on Ubuntu was more stable (although slower) than a native WinXP installation.  But at the point of application, for my purposes, Ubuntu wasn't a serious competitor against Windows XP.  And I was increasingly unwilling to invest the time to learn how to do everything in two or more different ways.

My conclusion, at this point, was that the best of both worlds called for running Windows XP within virtual machines (in VMware or otherwise) on an Ubuntu operating system base, on an Ubuntu/XP dual-boot computer.  I had already worked through many of the issues in this sort of setup, and could therefore hope to be efficient and preserve multiple troubleshooting options without too much of a time investment.  If Windows 7, Ubuntu, or some other operating system (OS) began to display capabilities that I badly needed, I would hopefully be able to incorporate those OSs into my setup, one computer at a time, without too much disruption overall.

Installing Ubuntu 9.04: External USB Drive

I was installing Ubuntu 9.04 (Jaunty Jackalope) in a Compaq CQ60-420US laptop computer from which I had removed the original Windows Vista installation. Although people generally advised against removing Vista and its recovery partition, I had several reasons for doing so: (1) I wanted to use Ubuntu (I would use WinXP in a virtual machine when I needed to run Windows-compatible software); (2) given the limited size of my laptop's hard drive, I could use the extra 10GB or so that was used by the factory-installed Vista recovery partition; and (3) Vista had a reputation of being slow, which was especially undesirable on the relatively underpowered hardware of a cheap laptop.

After I repartitioned and reformatted the hard drive, I found that I could not get the Ubuntu system to recognize the external USB hard drive. (That drive was not a USB flash drive; it was a regular internal SATA hard drive in a Rosewill RX-358-S SLV external enclosure.) First, I took a few steps, recommended in various posts, that did not seem to make much difference:

1. Following some users, I typed (in Terminal) "sudo gedit /etc/modules" and then added "usb_storage" as a separate line at the end of that file, exit, and reboot.
2. When that didn't solve the problem (though, for all I know, it may have helped), I typed "sudo mkdir /mnt/OFFSITE," where OFFSITE was the name I wanted for my external drive. Then I typed "sudo mount -a." But the rest of those instructions failed because the external drive still wasn't mounted.
3. I tried the advice to use System > Administration > NTFS Configuration Tool > Enable write support for external disk. Possibly this step takes place automatically if you type "sudo apt-get install ntfs-config" instead of installing ntfs-config through Synaptic. But it did not solve the problem.

I also tried the advice to install ntfsprogs (now included in the Synaptic list, above) and then type "sudo ntfsfix /dev/sdXX" where XX designates the correct drive (e.g., c1). This gave me "Volume is corrupt. You should run chkdsk." Given the NTFS orientation of ntfsprogs, this appeared to refer to the chkdsk program in Windows.


I didn't plan to install any version of Windows on this computer. My desktop computer was dual-boot, but for purposes of simplicity and to preserve disk space on the laptop's relatively small hard drive, I wanted to make this a Linux-only machine. So to run chkdsk, I tried restarting the computer with a Windows installation CD. But this introduced a new problem. Each time I booted the computer and hit the space bar in response to the CD's message, "Press any key to boot from CD," it went through the process of loading various drivers and then, when it reached the point of saying, "Setup is starting Windows" (in the bar at the bottom of the screen), it gave me a blue screen of death (BSOD): "A problem has been detected and Windows has been shut down to prevent damage to your computer," etc. The bottom line of the message referred to "STOP: 0x0000007B." (Note that I was getting this error before reaching the point of deciding whether I wanted to enter Recovery Console.)

Research on this problem led to a Microsoft troubleshooting page. It identified a number of possible problems, but I was not sure any of them applied precisely to me, and I hated to spend a lot of time on a troubleshooting wild goose chase (TWGC). I did run self-tests of hard drive and memory in the laptop's BIOS setup; that is, I rebooted the machine, hit the Esc key to go into BIOS setup, and ran its diagnostics. Those tests found no problems with those pieces of the laptop's hardware.

It occurred to me, at this point, that possibly I needed a BIOS upgrade. I went to the support webpage for this laptop and discovered, there, a flaw in my plan to make this a Linux-only laptop: Compaq was not distributing firmware upgrades for its laptops in Linux form. To upgrade the firmware, I needed to be able to run Windows.

Before addressing that problem, I tried rebooting the laptop from the Windows CD without the external USB drive connected. This could potentially defeat the purpose of booting from the Windows CD (i.e., I wanted to use it to run chkdsk on the external drive), but now I was curious. This, however, did not make a difference. Evidently the external USB drive was not the reason for this STOP 0x0000007B message.

In that case, the Windows CD appeared to be objecting that it did not find a working version of Windows already installed on the laptop's internal hard drive. But that seemed silly. Of course there would be no version of Windows installed on a hard drive, if the purpose of running the Windows XP CD was to install Windows on that drive. How did this error message expect me to "run chkdsk /f" if I could not even run Windows?

Well, I could install WinXP after all, make it a dual boot machine, and deal with the inevitable GRUB issues, as Windows and Ubuntu fought over which system would load first and then, just when I needed the machine most, refuse to load either. Or I could give up on the idea of running Windows diagnostics or firmware updates on this laptop. But I had previously experimented with booting Linux from a USB drive (a/k/a "thumb drive" or "jump drive"). Since then, I had become aware of another Linux USB drive approach known as Penlinux, where you could either buy one of their pre-configured Ubuntu 6.10 USB drives (for about $45, which was less than the cost of a 2GB USB drive back in 2007, when they apparently came up with this); or you could make one for yourself. I had heard of similar things in Windows; I wondered whether I could boot Windows XP from a USB flash drive and do these various maintenance tasks that way. The discussion of setting up a bootable WinXP USB flash drive appears in a separate post.

When I did boot the system with the bootable WinXP USB flash drive in TXT mode, I went into Recovery Console. There, I got a screen I had not received previously: "Setup has recognized the following mass storage devices in your computer: [none]." At this point, I did not have the external USB hard drive connected, so apparently this was OK. I pressed Enter and got the ordinary Recovery Console. There, a "dir" command produced "drive is not valid" messages for all drives other than C and D. For C, I got "There is no floppy disk or CD in the drive." D was recognized as the USB flash drive. So Recovery Console, started by the USB flash drive, appeared unable to recognize even the mere existence of the Ubuntu-formatted internal hard drive. I typed "exit" and rebooted the system without the USB flash drive inserted. Ubuntu still booted up OK. When I pressed a key to try to boot from the WinXP CD, I still got the BSOD and the STOP 0x0000007B message, as above. So merely starting the system with the USB flash drive, by itself, did not seem to have made any helpful change in the system. I booted with the USB flash drive again. This time, after booting in TXT mode, I chose the Setup option instead of the Recovery Console option in the Windows XP Professional Setup process. Unfortunately, this directed me to that same message: "Setup has recognized the following mass storage devices . . . ." But this time, when I pressed Enter to continue, I got the partitioner: WinXP was willing to set itself up in the jump drive. Again, though, it didn't see any other drives.

* * * * *

I thought that I might need to create (and, optionally, delete) a WinXP partition in order to completely rid this hard drive of the traces of Vista. (I assumed Vista was the culprit; I had not seen these problems previously in WinXP.) I booted my Gparted CD and inserted a 15GB NTFS partition before any other, where drive C would normally be. I had hoped to use my new bootable USB flash drive to install WinXP on it, but that drive was still not booting this laptop successfully, so I tried to install WinXP on that partition using a slipstreamed WinXP SP3 CD instead. That again gave me the "A problem has been detected" BSOD (above).

It began to appear that the process of deleting all partitions and starting over was more difficult than I had realized. That Recovery partition was no ordinary partition. There seemed to be a process by which it could be deleted from inside Vista itself; but once the Vista partition was gone, so was that option. At this point, I discovered Hiren's BootCD, another apparently famous funky tool that supposedly contained an unbelievable list of disk utilities. I downloaded a copy (version 9.9) and burned it to CD. I booted it, and it gave me four options: Boot from Hard Drive, Start BootCD, Start Mini Windows XP (which might well have done the same thing as the BartPE boot CD, as I now realized), and Windows Memory Diagnostic. I chose Start BootCD and used it to run PartitionMagic 8.05 Pro. PM did not see anything on the drive other than unallocated space. I tried running another program, but got a mouse error; apparently at least some of the programs on Hiren's BootCD were best run after a fresh reboot. I rebooted and tried Mini Windows XP. It was able to recognize a USB flash drive, so I used one to copy over the DiskPart.exe program I had previously downloaded. An AvaFind search of my drives revealed, at this point, that WinXP already contained DiskPart.exe, although in an apparently earlier (or at least smaller) version (i.e., 160KB rather than 191KB). With the larger one onboard, I moved the USB flash drive to the target computer and tried to run it from within Mini Windows XP. Unfortunately, this gave me an error message: "Error creating process [msiexec.exe /l diskpart.msi]. Reason: The system cannot find the file specified." I found msiexec.exe on the other (working) computer and copied it, and the older DiskPart.exe (i.e., same date as the msiexec.exe), to the flash drive. I tried again with this on the target computer. This did give me the DISKPART prompt and the options described in my other post. I typed "list disk." It showed that I had only Disk 0, which was right (if you don't count the jump drive). I typed "select disk 0" and then "clean." After a moment, it said, "DiskPart succeeded in cleaning the disk." I typed "list volume" and it did not show any volumes on the hard drive. So it seemed that it had indeed cleaned the drive. To test it, I tried something that had failed previously (see, again, my other post): I typed "exit" (to get out of DiskPart.exe), inserted the Windows XP installation CD, and tried to boot it. I got "NTLDR is missing" because, silly me, I had not yet removed the USB drive. I removed it and tried again. The disk churned for a long time and then gave me the familiar old BSOD. The older version of DiskPart.exe had failed to fix the hard drive. I restarted Hiren's BootCD and went into Hard Disk Tools > HDD Regenerator > Scan and repair. It ran for about an hour and detected no errors. (At this point, and repeatedly after this, I tried a number of other tools on Hiren's BootCD, not listed here.) Seagate SeaTools for DOS told me that it was a Seagate hard drive. I used that program's Advanced Features > Erase Track ZERO. I went into the Fujitsu low-level format tool, also on Hiren's BootCD, but it did not seem to recognize any drives. I tried rebooting the Windows XP installation CD again, but it still gave me a BSOD. In Hiren's BootCD, I went back into Mini Windows XP > BootCD WinTools, but didn't see anything that looked useful. I tried Start > Programs > Check Disk, but it did not find a volume to work on. Taking a different approach, I restarted the computer and chose Hiren's BootCD option (rather than Mini Windows XP) > Partition Tools > PartitionMagic Pro. There, I selected the unallocated space (i.e., the only thing listed) and created an unformatted primary partition that used up all of the unallocated space. I rebooted the WinXP installation CD, but still got a BSOD. Back in Hiren's BootCD, I tried the Active Partition Recovery program. It said this:

Logical C:

Detected file systems:

from partition table: FAT32 (LBA)
from BOOT sector: Unknown

Get file system from BOOT sector? [Y/N]

I said Yes. Next, it gave me an option to Perform Extended Disk Scan, with this note:

Extended Disk Scan may detect partitions being deleted even if you have created new ones instead, formatted and used them!

The screen also showed two partitions within HDD 80h. I arrowed down so that the first of them was highlighted: "Logical C." This gave me an error message: "Error reading sector # 0 or BOOT sector is invalid." When I highlighted the second one, "Unallocated," I got no error message, but it was weird that this partition was only 2.49MB. Anyway, I went back and ran the Extended Disk Scan. It was slow. After a while, it detected a 14.9GB NTFS logical drive. The program gave me the option of adding this partition to the drives list. I said yes. There was another one, a while later, a 35GB partition. Yes to that too. Both of these, I thought, were WinXP partitions that I had created, during the past month or so of fooling around with this laptop. As the scan reached the halfway mark, I was getting concerned that it hadn't yet found either the original Vista partition or the original Recovery partition. But then, about three-fourths of the way through, it did find a 10.9GB partition. The whole process took maybe six hours, on a 250GB drive. When it was done, I had three logical drives and two unallocated portions. Now what? I thought maybe I would take a look at these partitions in one of the other programs there on the Hiren's BootCD, so I hit Esc. This gave me an option of writing the detected partition information back to the hard drive. As I reflected on the matter, I decided that these former partitions were sort of like a former girlfriend: sure, things hadn't been so good with them, but then, things hadn't been so great without them either. So I decided sure, why not, let's take them back. Just like that, they were written to the hard drive, and I was rebooting. I went back into the partition tools, there on Hiren's BootCD, and took another look via PartitionMagic. Now PartitionMagic said it had "detected an error 116," and offered to fix it. I said sure. Now there was another error, partition table error #108. PartitionMagic was willing to format the single partition that it did find, so I went with that. It said it was "formatting partition *: (BADMBR)," but then it gave me Error #4, "Bad argument/parameter." Bad argument, indeed: this really was turning out like a reunion with an ex-girlfriend!

I decided to fight fire with fire. Vista had created this problem; maybe Vista could undo it. Probably the clearer reasoning would have been, they did this at a factory, so I need a factory to fix it. But I wasn't reasoning along those lines. I had gotten my hands on a copy of Microsoft Vista, and I was going to install it and see what would happen. The Vista DVD gave me an option of recovering my system, but I didn't have any previous images it could work from, so I went ahead with the installation option. Vista detected the five partitions or unallocated spaces that Active Partition Recovery had restored. I told Vista to delete each of those partitions. Now I had one big 232.9GB unallocated space. I went ahead with the installation of Vista into that big empty space; maybe I should have used the option to format that unallocated space first. But the main thing was that Vista installed, where WinXP had failed to do so. That was promising. Maybe it wouldn't even have been necessary to install Vista; maybe WinXP would have installed OK after I ran Active Partition Recovery. But maybe not; after all, PartitionMagic was still confused. Speaking of which, I decided to run it again, after Vista finished installing itself. This time around, when PartitionMagic on Hiren's BootCD detected an error, I didn't let it fix it; I now dimly recalled that PartitionMagic never got entirely comfortable with larger hard drives. Maybe if I hadn't let it fix the imaginary error the last time, it would have worked OK. But probably not: as before, it still thought we had a partition table error #105. I took out Hiren's BootCD and put in the Windows XP installation CD, and rebooted. But, wouldn't you know it, I still got a BSOD. Vista was happy with the hard drive; Ubuntu was happy with the hard drive; but WinXP couldn't be satisfied. Well, I had a Seagate Seatools CD from mid-2007. I assumed it was newer than the Seatools for DOS found on Hiren's BootCD, but perhaps not. What could this Seatools CD tell me? I rebooted with that CD, and I discovered that it could tell me, "No Hard Drives Found."

It seemed that Vista had its own special way with my hard drive. This called for a choice. I could leave Vista alone, giving it its own 15-20GB partition - that is, I could venture into the land of the Vista-Ubuntu dual boot. That might be the eventual outcome, but first I felt it was a good idea to screw around some more. I thought I might start by using Gparted to reduce the size of the Vista partition, as if I really were going to set up a dual-boot system after all, and see what happened then. So that's what I did. I booted with my Gparted CD, removed the 1MB unallocated space prior to the Vista partition, shrank the Vista partition to 30GB, inserted a 30GB ext3 and 5GB swap partition after that, and left the rest for an ext3 partition for data. Then I rebooted into Vista. I got Windows Boot Manager, telling me this:

Windows failed to start. A recent hardware or software change might be the cause. To fix the problem:

1. Insert your Windows installation disc and restart your computer.
2. Choose your language settings, and then click "Next."
3. Click "Repair your computer."

I did this, using the Vista DVD. I chose the "Repair and Restart" option, removed the DVD, and rebooted. Vista ran a disk check and then came up OK, but wanted to reboot because of hardware changes. After that second reboot, it seemed to be functioning normally. I rebooted with Gparted, to see what had changed. There was now a 6MB unallocated space after the Vista program partition. So possibly what screwed things up was that I removed that 1MB unallocated space that had been before the Vista partition. I ran a check on the two ext3 partitions in Gparted. They were OK. I rebooted with the WinXP CD and, as usual, I pressed a key to boot from the CD. This time, I got this:

Windows Boot Manager

Choose an operating system to start, or press TAB to select a tool:
(Use the arrow keys to highlight your choices, then press ENTER.)

Vista (recovered) was the only option. I restarted the computer and tried again to boot from the WinXP CD. Still got a BSOD. I could have uninstalled Vista and reformatted the drive, just to see if there was somehow a "right" way to remove Vista, thereby making the drive once again accessible from the WinXP installation CD. I decided instead to get my Ubuntu installation in place in a Vista dual-boot. Maybe I wouldn't need to go back to WinXP or worry about it anymore, and could perhaps even replace the Vista partition with an occasional Vista boot from a USB drive (for purposes of e.g., upgrading the laptop's firmware).

In that case, the final question was whether Vista and Ubuntu could work with the external USB hard drive. That, you will recall, was the question that triggered this expedition.  By this point, however, I had begun to suspect that the problem was with the external hard drive, which appeared to be defective.

GRUB Error 17

Almost exactly a year earlier, I had been wrestling with Error 17 in the GRUB bootloader in Ubuntu, and now it was back. (Back then, I had been running Ubuntu 8.04; now I was running 9.04.) One difference: back then, it seemed to have been accompanied by additional information, but this time I was only getting the bald "Error 17" report, with no other text. I didn't know why I was getting this error. I hadn't changed anything. All I could imagine (based on a HowToGeek article) was that possibly I had installed some Windows XP security updates since my previous reboot, and maybe one of them had messed up GRUB. Following the advice in that HowToGeek article, I rebooted with the Ubuntu 9.04 Live CD. In Terminal (i.e., Ubuntu's Applications > Accessories > Terminal), I typed "sudo grub" to get into the GRUB prompt. The instructions assumed that I had installed GRUB into the first partition on the first hard drive (i.e., hd0,0). I wasn't sure if that was correct, and I wasn't sure how to find out. The notes from my previous year's go-round (above) seemed to say that I could use "find /boot/grub/stage1" for this purpose. But it seemed likely that, from the Live CD, that would just tell me where GRUB's Stage 1 files were (or something like that) on the CD, not on the hard drive. It seemed that I would have to gain access to the Ubuntu boot partition in order for that command to work. So I started with Nautilus (i.e., Ubuntu's Places > Computer menu pick, which opens up the Nautilus program that Ubuntu calls File Browser). There, I saw icons for my various partitions, including one labeled "Mass Storage Drive." When I double-clicked on that, I got "Unable to mount location. Can't mount drive." Ah, so this suggested a different theory. Maybe GRUB wasn't damaged after all. Maybe the problem was that the boot drive was screwed up. To learn more about that, I went into GParted (i.e., System > Administration > Partition Editor) and looked at my partitions. And this was truly remarkable. In place of the Ubuntu and WinXP partitions that I had installed on my first hard drive, there was now . . . nothing! The Ubuntu and WinXP partitions were completely gone, wiped out. Instead, I just had a disk consisting of one big unallocated space. Well, that would certainly explain why there was no GRUB boot menu. How could that happen? I tried a Google search, but that didn't point out any obvious explanations. I tried to recall what had happened when I shut down the machine the previous day. But there didn't seem to have been anything remarkable. Nothing stood out in my mind particularly. I would usually shut down that computer at night, but maybe this time I had left it running, and some mysterious virus had done this overnight? I wasn't sure. So, OK, it was time to start over. Fortunately, I had made Acronis True Image 11 backups of the program partitions onto another drive, so I rebooted from the Acronis CD and restored those. But then - what's this? The WinXP backup was there, but it looked like I had not done an Ubuntu backup. This was possibly because the Ubuntu installation on that machine had given me endless problems; apparently I had intended to start over. So, OK, that's exactly what I did. Not at this point - for now, I had a hard drive with only Windows XP installed - but later. Unfortunately, this did not solve the problem. Even with the Ubuntu partition completely gone, I still got GRUB Error 17 when I rebooted. GParted on the Live CD was telling me that no, I actually had not succeeded in restoring WinXP to that empty drive just now, despite the opinion of Acronis to the contrary. I rebooted with the WinXP installation CD, and it concurred: there was no Windows installation. I tried again with Acronis, this time trying to restore only the program partition, not the MBR. Also, this time I indicated that the restored partition was a primary partition, not active, as I had done on the previous try. While I was still in Acronis, I checked, and sure enough, the drive did now definitely have a Windows XP partition as its only formatted partition. I rebooted, and this time XP ran normally. No more Ubuntu (until I got around to reinstalling it); no more GRUB Error 17.

Configuring 64-bit Ubuntu 9.04 with Vista Dual-Boot

I had a Compaq CQ60-420US laptop. It had come with Vista pre-installed. I didn't like that, so I wiped it off. This led to a whole ordeal in trying to get the hard drive to work with WinXP, for which I had developed lots of tricks and tweaks. That effort ultimately failed, and I wound up with Vista back on the thing after all. I had wanted to get away from dual booting, but I still needed some flavor of Windows for the occasional hardware interaction, e.g., updating the BIOS and other firmware. So for now, I was going to leave Vista in place and set up a 64-bit Ubuntu 9.04 (Jaunty Jackalope) dual-boot with it. This post describes the process of setting up that dual boot. A review of some guides gave me the general impression that installing a Vista-Ubuntu dual boot was much like installing a WinXP-Ubuntu dual boot, unless you used the wubi alternative. The approach I took was as follows:

1. With Vista already installed, insert the Ubuntu program CD, reboot, and go through the ordinary installation sequence. If you do nothing, the CD will pretty much take you right to the Install icon. If your BIOS isn't set to boot from CD before hard drive, hit F2 or Esc or Del or F8 or whatever key it is that gets you into your BIOS setup, promptly after the computer first starts up, and adjust the boot priority there.
2. You may find that the bootable Gparted CD provides a clearer view of hard drive partitions than does the partitioner in the Ubuntu installer. If the partitioning step leaves you dazed and confused, you may want to back up, download Gparted, burn yourself a CD, boot with that first, set up your partitions as you like, and then come back into the Ubuntu installation process. Note: if you're going to run Windows in a virtual machine, you may want to give it an NTFS partition somewhere, so you have a place to store data. Windows can't read Linux (e.g., ext3) partitions.
3. After the initial installation, make sure that Vista starts up OK. No point spending hours refining a system that isn't ready for prime time. Then restart and go into Ubuntu, and make various adjustments, including these: (a) Nautilus > View > Show Hidden Files. (b) Nautilus > Edit > Preferences > Behavior > Always open in browser windows.
4. Go through the steps described in my previous post on configuring Ubuntu 9.04 (including comments). That post updates the first part of an earlier post on how to configure 9.04. After running updates, type "sudo gedit /boot/grub/menu.lst" and put # symbols in front of each line (i.e., older Ubuntu kernels) that you don't want to appear in the GRUB menu.
5. Before continuing with items in that earlier post (as explained in more detail there), I initially thought that the next step would be to install and configure Thunderbird (just plain old thunderbird, not mozilla-thunderbird) and Lightning-extension via Synaptic. But then I decided I would just use web-based e-mail and calendaring (probably via Gmail) on the laptop, and would download and archive my e-mails solely on my desktop, thereby sparing the need to synchronize the two computers.
6. Now refer back to the earlier post, to install programs that came via individual downloads rather than through Synaptic. For me, these included Google Desktop for Linux, Adobe Reader, and VMware Workstation 6.5.3.
7. I installed .deb files by double-clicking on them in Nautilus, and .bin and .bundle files by running "chmod +x [filename]" and then "sudo ./[filename]." I didn't have any .tar.gz and .tar.bz2 files to install this time, but if I had, I would have moved them to my /home/[username] folder, navigated there in Terminal, and then used a tar unpack command (e.g., tar -vxf [or tar xvfz] filename.tar.gz, or tar xvf filename.tar, or tar yxf filename.tar.bz2).
8. To install Google Earth, continuing to follow my previous notes, I typed two lines: "wget http://dl.google.com/earth/client/current/GoogleEarthLinux.bin" and then "sh GoogleEarthLinux.bin." This gave me a Google Earth installation, but with flickering and basically nonfunctioning display. I tried System > Administration > Update Manager, and at first that program assured me that my system was up-to-date; but when I made it check again, it reported errors related to Wine and Opera. I ignored these for now, since they did not seem relevant. People seemed to be experimenting with the flickering video problem in Google Earth. There was a relatively complex tutorial that apparently fixed it in some cases, at the risk of messing up the system. Choosing instead an easy fix that seemed to work for some, I went to System > Preferences > Appearance > Visual Effects and downgraded from Extra to Normal. That didn't help. Following another tip, I downgraded further, from Normal to None (i.e., no visual effects), and also turned off the Atmosphere feature in Google Earth (View > Atmosphere). That fixed it.
9. To configure Firefox, I went to another computer and used the FEBE extension to make a full backup of that machine's Firefox installation. I copied the folder containing the FEBE backup to the target computer (i.e., the one where I've been doing all this installation stuff). I installed FEBE in Firefox on the target machine, restarted Firefox, started to watch the tutorial on restoring with FEBE, turned to the instructions on manually restoring with FEBE, and then took these steps on the target machine: Close Firefox. Go to the FEBE backup directory (i.e., the one where I put the FEBE backup folder that I copied over from the other computer). Copy its .fbu file (in my case, profileFx3{default}.fbu) and rename the copy as a .zip file. I called it FEBErestore.zip. Extract the contents of the .zip file (creating, in my case, a folder called FEBErestore). Move the contents of the FEBE restore folder to the Firefox profile folder, which I found in Nautilus at File System/home/ray/.mozilla/firefox/[random name].default. In my case, for example, I moved the contents of the FEBErestore folder to this .default folder. When it told me that a folder already exists, I said Merge All, and Replace All for the "file already exists" message. During this process, I got an "Error while copying 'febe.jar'" message. The details of the error said "Permission denied." I canceled and tried again as root (type "sudo nautilus" and then do the move in the Nautilus session that opens that way). That worked. Then I closed everything else and started Firefox and, yeah, it looked like all the extensions were there, configured and everything.

This was the extent of my Ubuntu configuration for now. During these processes, I came across some miscellaneous issues:

• I wanted to change login passwords. This, I thought, would be under System > Administration but no, eventually I found it instead under Applications > Accessories. Double-clicking on that did not work; I had to right-click and choose Change Password; but then the password that I changed it to did not work for login. I thought the problem might be that I hit Enter instead of clicking on the button after doing the change; that is, possibly the default was Cancel rather than Change. I could not tell; neither button seemed to be highlighted by default. So then it turned out that I had changed the password to unlock the keyring, rather than the password to log in. It looked like I had changed that properly, second time around; but still no.
• As in other Ubuntu installations, panels did not readily allow me to move icons to the locations I would designate. Sometimes they would not move; sometimes they would not go exactly where I indicated. On the bottom panel, for example, I could not rearrange them in the far right corner. It turned out to be easier to move things *out of* the corner (where the Windows system tray would be) than to move them *into* the corner. It turned out that I had to unlock every item that I wanted to drag another icon past. Tooltips came up, irritatingly enough, when I was trying to move icons, making it difficult to see what I was doing.
• The bottom panel failed to show icons or buttons for my currently running programs. The solution was to right-click on the bottom panel, choose Add to Panel, and choose Window List. But then, on reboot, it did not work again. I fixed it by right-clicking on the end of the Window List item on the bottom panel and checking Lock to Panel.
• When trying to view the contents of some hard drive partitions, such as a partition I called DATA, I got "Cannot mount volume. You are not privileged to mount the volume 'DATA'. Following my previous notes, in Terminal I typed "sudo mkdir /media/DATA," thinking that perhaps I had not yet created the mount point, but this gave me "cannot create directory `/media/DATA': File exists." I typed "sudo nautilus," went to File System > /media/DATA > right-click > Properties, and verified that I (i.e., user "ray", not just root) had full permissions. I typed "sudo fdisk -l" (that's an L, not a one) to get a list of devices. That showed that the DATA partition was being recognized as an NTFS device at /dev/sda4. I typed "sudo gedit /etc/fstab" and saw that there was no line in the fstab file for /dev/sda4. Following some notes from a few months earlier, I typed "sudo ntfs-config." (Note that this was one of the programs I had installed from Synaptic, above.) This detected the VISTA programs partition (i.e., drive C in Windows), but not the DATA partition. I ran ntfs-config again. This time, it didn't mention the VISTA drive, but as before it did give me the option to enable an internal drive. I accepted that. Now I saw that there was indeed a line for the DATA partition as well. While I was here, I used blkid to find the UUIDs for each partition (e.g., "sudo blkid") and replaced that portion of the relevant line in fstab. For example, the line that previously read "/dev/sda1 /media/VISTA ntfs-3g defaults,locale=en_US.UTF-8 0 0" now began with "UUID=19142FAA142F8D35" instead of "dev/sda1." Following the format of other lines in fstab, I preceded this one with a line that said, "# Entry for /dev/sda1 : " and followed a similar procedure for the DATA partition. I rebooted and was now able to view the NTFS-formatted VISTA and DATA partitions. On second thought, I went back into fstab and removed the line for the VISTA partition, since I didn't expect to need it normally in Ubuntu and didn't want to expose it to accidental deletions and such.

This seemed to give me a basic working dual-boot 64-bit system. The next step, for me, was to configure VMware, so that I could run any Windows program within Ubuntu.

Ubuntu, GRUB, and Acronis True Image: Restoring

I was in the process of working through my Ubuntu and Windows XP dual boot installation, when I encountered a problem that probably most dual-booters encounter: the periodic need to replace a confused WinXP installation with a fresh new one had incidentally messed up my GRUB bootloader, so that I could no longer choose to boot into Ubuntu Linux. This post describes the steps I took to solve that problem, and concludes with what I learned from the effort. I had resolved this problem once before. I looked at my previous notes and saw that apparently I had used the Super Grub Disk (SGD) to solve this problem. Attempting to recreate that solution, I booted my copy of the SGD and selected Boot & Tools. That didn't seem to have what I needed, so I went back and chose Advanced > GRUB > Restore GRUB in Hard Disk (MBR). That seemed to be the place. On one of its pages, it said this:

Example: ======== Has Windows rewriten your MBR? Now you will be able to boot your Gnu/Linux AFTER rebooting from Grub Super Disk.

(The typographical error was theirs, not mine.) I hit Enter and then chose the recommended Automatically Install option. This resulted in a message that looked like one that had flashed past me when the SGD was booting. Here, it said,

Booting 'trying /grub/stage1' findf /grub/stage1 Error 15: File not found Booting 'trying /boot/grub/stage1'

and so forth. It said it was running "setup (hd0)" and then "Checking if [various boot grub stages] exists . . . yes" and then running stages 1.5 and 1, and finally "SGD as succeeded!" I hit Enter again and then kept selecting SGD's "Go back" options until I got options to Quit and then "Reboot P.C." But no, it actually hadn't succeeded. On reboot, the machine again defaulted automatically to Windows. I rebooted, to watch more carefully and see if I had missed an option. Nope. It just went straight to Windows. I found a How-To Geek webpage with instructions on how to reinstall GRUB after a Windows reinstallation wipes it out. It said to boot from the Linux live CD (i.e., the one I installed from). This meant choosing the option that said, "Try Ubuntu without any change to your computer." Before I could proceed with the next steps, I had to figure out where I had installed GRUB during the Ubuntu installation. One thread said that operating systems tend to put it on the first partition of the first hard drive by default. I didn't recall putting it anywhere else. I guessed this must have been one of those options for which I accepted the default value. So I could proceed with the How-To steps without change. The recommended next steps, then, were to type these lines in Ubuntu's Applications > Accessories > Terminal:

sudo grub root (hd0,0) setup (hd0) exit

and then reboot. I started doing that, but when I typed "setup (hd0)," I got "Error 17: Cannot mount selected partition." I typed "exit" and got "Error 27: Unrecognized command." The correct command, I eventually figured out, was actually "quit," not "exit." Next, I went into System > Administration > Partition Editor. There, I was reminded that Ubuntu (or at least Gparted) referred to partitions as sd, not hd, and I also saw that Windows was installed at /dev/sdc1 and Ubuntu was at /dev/sda6. Another advisor seemed to confirm my understanding that these would be translated as hd2,0 and hd0,5. That is, you change sd to hd and then, starting with 0 in both cases, you assign a number to the letter (a = 0, b = 1, etc.) and a number to the number (1 = 0, 2 = 1, etc.). But this didn't tell me where GRUB had been installed, and I wasn't seeing any clarification on that in the several threads I examined. The error messages had indicated that GRUB could not mount hd0, so maybe that meant it wasn't on the drive where Ubuntu was installed. So, OK, I tried the foregoing sequence of commands again, this time focusing on hd2,0, where Windows was installed. When I typed "setup (hd2)," again I got "Cannot mount selected partition." I then realized that, the first time, I had indicated "root (hd0,0)" whereas I had just figured out that Ubuntu was at hd0,5. So I tried again, and this time the results were different. What I typed was this:

sudo grub root (hd0,5) setup (hd0)

When I typed that, it gave me the same sequence of notes as SGD had given me, above. That is, it said, "Checking if [various stages] exists . . . yes," and it ended with "succeeded" and then "Done." So I typed "quit" and rebooted without the Ubuntu live CD. But, dammit! Still no GRUB menu. I found a Fedora thread that recommended steps to take if you were using Vista instead of WinXP and if you wanted to use the Windows boot loader instead of GRUB. That seemed a little bit removed from my situation, so I went to the next post, which provided a solution for those using Gentoo Linux. Another post translated that one, somewhat, into Ubuntu terms. The core of those instructions seemed to be this: (1) Boot with the live CD. (2) Delete the Stage 1.5 files. (3) Reinstall GRUB. To do step (2), in more detail, I went to Terminal and typed "sudo -i" and then nautilus. In File Browser (i.e., Nautilus), I navigated to "36.7 GB Media," which seemed to represent the hard drive where I had installed Ubuntu. Once there, I went into boot > grub. There, I selected all files with stage1_5 in their names, and deleted them. Then, in that same folder -- moving on to step (3), here -- I opened menu.lst and searched for "(hd" (without the quotation marks, but with the opening parenthesis) to find the places where there might be a hard drive command. Not counting the commented lines (i.e., those beginning with the # symbol), there seemed to be a section that designated the Debian (i.e., Ubuntu) GRUB menu items and another section for the Other (i.e., Windows) menu items. I wasn't going to change the ones for Windows, so I focused on the Ubuntu part. It said, in several places, that root was at (hd1,5). Using the approach described above, I translated that as sdb6. I went to System > Administration > Partition Editor and observed that sdb6 did not exist on my system. So there, it seemed, was a problem. As noted above, the Ubuntu location was supposed to be sda6, i.e., hd0,5. Not hd1,5. But I wasn't even getting the GRUB menu, so I thought the advice was probably correct as far as it went: I still needed to reinstall GRUB. The advice seemed to be that this menu.lst file gave me the information I needed for that purpose: it said that GRUB was installed at hd1,5. So I should have typed hd1,5 instead of hd0,5 in the sequence of commands described above. But that made no sense, because there was no such thing as hd1,5. I decided to stick with the installation I had apparently already done at hd0,5, and change those three root references in menu.lst to hd0,5 instead of hd1,5. While I was at it -- relying, again, on the information found in GParted -- I changed the root reference in the Windows part of menu.lst from hd1,0 to hd2,0, because that (i.e., sdc1) was where my Windows program files were installed. In other words, I was basically banking on the theory that what I needed to do, besides deleting the Stage 1.5 files and reinstalling GRUB, was to correct erroneous references in menu.lst. Then I saved menu.lst and told the Ubuntu CD that I wanted to restart the computer. The machine started to shut down, but then just died at a black screen with a flashing cursor. Weird. I tried to remove the Ubuntu CD, but it wouldn't come out. I punched the reset button and removed it. Still no GRUB menu; the machine booted straight to Windows again. I rebooted with the Ubuntu CD. It occurred to me that the computer was automatically looking at the Windows installation, and that that's where I should be installing GRUB. So I went back into Terminal and tried this sequence:

sudo grub root (hd2,0) setup (hd2)

That gave me Error 17 again, "Cannot mount selected partition." So, OK, by this point I was really mixed up. What if I left root (hd2,0) as it was (not knowing what this command achieved) and tried again with setup (hd0), as someone else had supposedly done? But no, that got Error 17 too. Root (hd0,5) and setup (hd0) was the only combination that seemed to work. I looked at menu.lst again and didn't see anything else to change. I tried rebooting again without the Ubuntu CD. This time, the reboot went normally, without freezing up; but it still went immediately to Windows. I needed different advice. I found some Ubuntu documentation that addressed several different scenarios. The first steps were -- you guessed it -- boot with the Ubuntu live CD, go into Terminal, and type "sudo grub." This time, though, before going on to type the root and setup lines, they had me type "find /boot/grub/stage1." The answer that came back was hd0,5. I was instructed to type this (as I had already done) in the root command, so I entered "root (hd0,5)" and then "setup (hd0)." Then I quit and rebooted. As expected, I got the same outcome as before: booted straight into Windows. I restarted the computer. But when I rebooted with the Ubuntu CD this time, after choosing the "Try Ubuntu" option, I got billions of error messages. They were zipping by too quickly to read, but the basic idea was like this:

[ 256.923837] SQUASHFS error: Unable to read page, block 250ab9de, size d104

Something like that, anyway. I found a thread that went through various possibilities; their basic idea was that the CD or the CD drive was screwed up. But I didn't pursue that because, meanwhile, I punched the reset button and tried again. This time, no problem: the CD booted Ubuntu. I went ahead with the next possibility offered by the Ubuntu documentation page: "Overwriting the Windows Bootloader." Here, they told me to type "sudo -i" and then "fdisk -l" (that's an L, not a one) to see where Ubuntu was installed. That command indicated that I had a Linux partition at sdc6. Say what? That would be hd2,5. Next, they told me, type "mkdir /mnt/root" to make a mountpoint. Then mount the partition with "mount -t ext3 /dev/hda2 /mnt/root". But -- what was this "hda2" supposed to represent? Did they mean sda2 (in their example), or did they mean hd1,2? Their "fdisk -l" produced references to hda2 and such, whereas mine had produced references to sdc5, sdc6, and so forth. Confusing! But they said we could try it out and we'd find out if it wasn't correct, so in place of their hda2 I typed my sdc6. (Complete command: "mount -t ext3 /dev/sdc6 /mnt/root".) That didn't get an error message, so I went to their next step, which was to type "ls /mnt/root" and see what I got. I think the idea of this command was to show me what folders existed under my mount point. The folders were more or less like theirs -- I had a bin folder, a media folder, etc. So apparently I was on the right track so far. I hadn't made a separate boot partition -- all my Linux program stuff was in that one partition -- so, as they seemed to intend, I skipped the part about mounting a boot partition if you have one. Next, they said this:

Now that everything is mounted, we just need to reinstall GRUB : sudo grub-install --root-directory=/mnt/root /dev/hda

But since I was replacing their references to hda with sdc, I typed exactly what they had, except the last part of mine was /dev/sdc. That gave me what looked like an error message: "/dev/sdc does not have any corresponding BIOS drive." They said, if you get BIOS warnings, type exactly the same thing but with a space and then a "--recheck" at the end. So I hit the up arrow (to recall the command) and typed that on the end. It said, "Probing devices to guess BIOS drives." Then it said a bunch of other stuff, including "Installation finished. No error reported," along with a list of devices that looked right. That's what the advice page said I should get. So then they said,

Now you can reboot and the GRUB menu should appear. If you see a warning message regarding XFS filesystem, you can ignore it.

So I rebooted without the Ubuntu CD. I got the SQUSHFS error again, but it was different this time: it gave me only a series of errors and an instruction to remove the CD and reboot. I did, but now I booted directly into Windows again. So we had achieved nothing. They offered another approach on the Ubuntu documentation page. They said you could download the Auto Super Grub Disk, run it within Windows, then reboot. When I ran it, it gave me a bunch of options. It didn't do anything for a minute, but then Spybot popped up and told me a command had been entered regarding UNetbootin Uninstaller. I told Spybot this was OK, and to remember this decision. This gave me a dialog:

Reboot Now? After rebooting, select the UNetbootin menu entry to boot. Reboot now?

I clicked OK. The Ubuntu documentation said to do nothing until you see your GRUB menu again. I did see that menu. I let it default into Ubuntu. But this gave me an error:

root (hd0,5) Error 22: No such partition Press any key to continue

So, ah, some of my editing must have screwed up something. I looked for the "Any" key. (Kidding.) I pressed a key, and this took me back to the GRUB menu. By the way, this was a modified GRUB menu; it had options to edit or reload GRUB commands, get a command line, etc. The last bit of Ubuntu advice on this was to say "yes" next time I booted into Windows using this menu, and that would remove this funky little Auto Super Grub Disk installation. But apparently we weren't quite ready for that; I had to figure out how to fix the Ubuntu installation first. I started with "e" to "edit the commands before booting." Since I'd had WinXP highlighted when I did that, it seemed to take me to the part of menu.lst that had to do with Windows. I hit Esc to get back to the menu. This time, I highlighted the top entry, the regular Ubuntu boot line, and I hit "e" there. I typed "e" again there to edit the first line, changing it back to "root (hd1,5)." I hit Enter and that saved it. I hit Esc then, to go back to the main menu, and hit Enter on that first Ubuntu option to boot it. But my change had not been saved. I tried again. This time, after saving the change, I went down to the next line in menu.lst before hitting Esc. That wasn't the solution either. Third time: after chaning it to "root (hd1,5)," I pressed "b" to boot. Hey -- that worked! Ubuntu was booting up! I got a bunch of command-line details that normally would have been invisible, possibly because Auto Super Grub Disk was still doing its job, but otherwise we were OK. I logged into Ubuntu and went back to /boot/grub/menu.list as root (i.e., sudo -i), to change those other two lines back to hd1,5. Obviously I did not fully understand the translation of sd to hd, but whatever. But when I got there, all three lines were still hd0,5. Apparently my change via the Auto Super Grub Disk (ASGD) edit menu did not result in a change in menu.lst. Sooo ... was all this advice about menu.lst a wild goose chase? It seemed that I needed to make my changes for the second and third lines of the GRUB menu via ASGD, not here in menu.lst. (By the way, the stage1_5 files were back, here in /boot/grub. Not sure what part of this mangled process had reinstalled them.) I rebooted and, just for the hell of it, told ASGD to edit the first boot option, the regular Ubuntu thing. Stupid thing still said "root (hd0,5)." So it seemed that I had been able to boot with a temporary override of menu.lst, and that maybe I should have edited menu.lst back to root (hd1,5) after all. I re-edited and booted this temporary fix so I could get back into Ubuntu and do that. I changed the Ubuntu root lines back to hd1,5 and also changed the Windows root line back to hd1,0. When that was done, I rebooted and took another look at the GRUB menu. Now each root line looked right. So far, the moral of the story seemed to be: forget about everything else; just use ASGD to solve this problem. I booted with each line. Regular Ubuntu worked; Recovery Mode Ubuntu worked (I didn't test its dpkg, root, or xfix options); the memtest86 option worked; and the Windows option . . . did not work. I got this:

Error 12: Invalid device requested

Was hd2,0 the correct answer after all? I tried that. No, this time it said, "This is not a bootable disk. Please insert a bootable floppy and press any key to try again." Floppy -- what? Where was Windows? I used a panic-combination of Esc and Enter to bail out of that. Back at the ranch, the question was where I should tell the computer to look next. Or maybe the problem was in these lines:

map (hd0) (hd1) map (hd1) (hd0)

This, it seemed to me, was telling the system to treat hd0 as though it were hd1, and vice versa. Maybe I needed to edit these lines, too, when I was changing the root line to hd2. I tried that, basically changing all references in this part of menu.lst from hd1 to hd2. But no, I still got "This is not a bootable disk." Oh, but now the thing was really fubar: it said "GRUB Loading stage1.5," and it just hung there. I punched the reset button. We were back to the point of editing GRUB for Windows. Whew. Now, I needed outside help. I found a thread where somebody explained those map commands:

Windows will not like being booted from any other partition than the first on the first disc. You should be able to use GRUB to fool Windows into thinking such, by using the map commands.

Another option that some people had was to use rootnoverify instead of just root. I tried editing this portion of menu.lst to that effect. I still got Error 12. Since I had now seen other posts indicating that my understanding of the translation from sdc to hd2, I was more confident that the reference really should be to hd2,0, not hd1,0. So I made those changes again, along with the rootnoverify change. This gave me the "not a bootable disk" error again. I thought I would try to make some of these changes permanent, even though they were not working, so that I did not have to keep re-editing menu.lst here in the GRUB menu. So I selected the first GRUB line and hit Enter to go into normal Ubuntu. But now, what's this? I got "Error 22: No such partition." I edited the line. It was saying "root (hd1,5)," which is what I had said and what had worked, but now it was not working and, in my opinion, it should never have been working. I changed it back to hd0,5 and tried again. But now that got an Error 22 too. Bizarre! The Recovery Mode option was still saying hd1,5, so I tried that. Error 22. Jeez. I hit Reset and booted the Ubuntu CD, to try to figure out where we were now. Then I got the idea to check my hard disks. I had seen some references to differences between the old ATA (or PATA) and the newer SATA drives, and now I was confirming that one of my three drives in this machine was a PATA. Could it be confusing the issue? The system was treating the 320GB PATA as sda. I didn't intend to keep all three drives in the system; I just had not gotten around to rearranging things. So now was my opportunity. I used GParted to make partitions on the unused SATA drive and, after some fiddling around, was able to move my NTFS partition data from the PATA drive over to that SATA drive. I shut down the computer, unplugged the PATA drive, and also switched the cables for the two SATA drives, so that the Windows drive would hopefully now be the first drive in the system. I also took advantage of the opportunity to test Acronis True Image as a restorer of an Ubuntu installation. That is, I inserted the Acronis CD and tried restoring my most recent Acronis True Image .tib backup, to see how well it was working. It was only a few days old, but it would predate the messing around I had lately done with GRUB, so possibly it would get me back closer to a clean slate in that regard. In restoring, I decided not to restore MBR and Track 0; I wasn't sure where those would go or what they would overwrite, and anyway I had now relocated the Ubuntu partition, so I would doubtless have to be editing that stuff. I just restored the Linux partition to the new location. Incidentally, I also made all the new partitions on the second SATA drive to be primary partitions, as were most or all of the partitions on the first SATA drive. I was pleased, by the way, that Acronis seemed willing to try to restore the Ubuntu partition even though the backup had been a 21GB partition and the new one was only 12GB. It seemed to be aware, or at least willing to try, to see if it needed more than 12GB to do the restoration. (It didn't; I had less than 7GB worth of files on the Ubuntu partition.) When it was done, I took out the Acronis CD and rebooted. I got "Error loading operating system." This hadn't happened, the last time I had restored Ubuntu with Acronis. That time, I had gotten a GRUB menu. So I thought what I would do first, this time, would be to boot with my Super Grub Disk (SGD), and see if that would give me back a GRUB menu. There, I went into Advanced > GRUB > Restore GRUB in Hard Disk (MBR) > Automatically Install. It said, "Done. SGD has succeeded!" Now what? There weren't any options. I hit Enter and then kept hitting the Go Back option until I got to Quit > Reboot P.C. I did that and removed the CD. What do you know: it worked. I had my GRUB menu. Now I chose a regular Ubuntu boot. "Error 22: No such partition." OK, how about Windows? The UNetbootin option was still there -- I hadn't uninstalled the Automatic SGD yet -- but by the time I was done typing these notes to keep up with it, it had already decided something and reverted back to the GRUB menu. I tried Windows again, but this time I got "Error 13: Invalid or unsupported executable format." Now what in the world was that all about? I needed to get a grip on what should be happening. I punched Reset, booted the Ubuntu CD, and went into Partition Editor. No surprises there: the Windows partition was now sda1 and the Ubuntu program partition was sdb1. As root, I went to menu.lst and changed the Windows root line to (hd0,0), and commented out the map lines in that section (because now Windows was in the primo position, drive zero partition zero, as God intended), and I changed the Ubuntu root lines to hd1,0. I rebooted without the Ubuntu CD. This time, selecting Ubuntu at the GRUB menu gave me "Error 17: Cannot mount selected partition." Windows was still hung up at Error 13. Gee, a whole new category of error messages to screw things up. OK, what did the authorities say? One source said that, here at the GRUB menu, I needed to press "c" to get a command line, and then type "find /vmlinuz". It said "(hd0,0)." The source said that this was supposed to be the root line for the Ubuntu sections in my menu.lst. So I hit Esc to get out of the grub> prompt (for some reason, "quit" didn't work here) and then "e" to edit the normal Ubuntu boot line in GRUB. And yes, that booted. So I went into menu.lst and changed that for all three Ubuntu lines. Now, rebooting back to GRUB, I tried the Windows option. Still Error 13. My Google search for this one led to a bunch of very confused people who didn't seem to be getting anywhere. I tried commenting out the makeactive line in GRUB for the Windows boot option, but that just provoked a reboot. One of them suggested that you could use Super Grub Disk (SGD) to do a FIXMBR. That was new to me, so I tried it. I chose SGD's Windows > Fix Boot of Windows option. Working through the steps on this introduced me to new information. Apparently "natural Linux" would refer to a partition as hda or hdb, while "IDE Linux" would call it sda or sdb, and SCSI Linux would call it hd0 or hd1. Anyway, after I indicated sda or hd0 or whatever you want to call it, and ran the procedure on that, I had to find my way back to SGD's Windows Basic options. There, I selected "Boot Windows." As the commands flashed by, I noticed that it ran "rootnoverify" and some other stuff and then put me back at the GRUB menu with just two options: Microsoft Windows XP Professional or UNetbootin. I tried the Windows option. Windows booted! Alright. We were getting somewhere. I felt I could probably fix any remaining Ubuntu GRUB problems now. But as I was typing these words, I noticed that time was passing and, you know, Windows was not actually completing the bootup process. It was just sitting there on that black screen with the Windows XP logo staring at me and the little progress bar rolling along. Then, after maybe five minutes, that went away and I just had a black screen. This was not really what I had intended. And there it stayed. Black forevermore. I punched Reset. This put me back at the SGD, which I had forgotten to take out of the CD drive. Reset again, sans CD. I got the normal GRUB menu and, when I chose Windows, I got the normal Error 13. I chose the normal Ubuntu and it booted. I inserted the Windows XP CD, rebooted from the CD, and chose Recovery Console. There, I ran FIXMBR and FIXBOOT and rebooted. Back at GRUB, I chose Windows again. I still got Error 13! One thread seemed to say that FIXMBR and FIXBOOT would have solved the problem, if the problem had been a corrupted NTLDR, whatever that was. So we knew, now, that that was not it. They also said I could type "geometry (hd0)" on the GRUB command line ("c") to get some information. They were right. I got an indication that the filesystem type for partition 0 was ext2fs, which was apparently not the same as ext3. Had GParted screwed this up? Had I accidentally indicated ext2 when I meant ext3? Or was GRUB reporting it wrong? A mystery. But, wait, why was hd0 a Linux partition at all? That was supposed to be where Windows was. I typed "geometry (hd1)." Just two partitions, filesystem type unknown. But I knew I had just two partitions on the Windows drive. Geometry reported the partition type was 0x7, which appeared to be shorthand for NTFS. One possible answer came from the advice to basically put the Windows section of menu.lst back the way it was. I booted into Ubuntu and went to menu.lst. There, I made it read as follows:

title Microsoft Windows XP Professional root (hd1,0) map (hd1) (hd0) map (hd0) (hd1) #savedefault makeactive chainloader +1

This worked. It seemed that the GRUB "geometry" command gave me more accurate information, for purposes of knowing how to edit GRUB's menu.lst, than I was able to get from GParted or whatever other sources I had been using. I tried rebooting with this setup. Selecting Windows at the GRUB menu gave me the option to restart Windows normally or choose Safe Mode. This was promising. And yes! The sucker went right on into WinXP. It gave me the option to uninstall UNetbootin, but I didn't take that option yet. First, did Ubuntu still boot at GRUB? I rebooted to find out. Yes, it did. Back to GRUB; back to Windows; uninstall UNetbootin. Problem solved. Morals of the story: use SGD and especially ASGD; use GRUB's geometry command for information; simplify the hard disk setup if possible. With this taken care of, it seemed I could get back to what I had been trying to do before this GRUB problem came up.