Windows 7: Overlapping Partitions, Entire Drive Is Unallocated, Has No Brain, Still Feels Great

I was using Windows 7.  I had a hard drive containing multiple partitions.  I was in the habit of booting with an Ubuntu Live CD, now and then, to get a GParted view of the drive's condition.  GParted would quickly show me problems with partitions, in a way that seemed superior to what I could get in Windows.

(I was new to Ubuntu 11.10.  Unlike earlier versions, there was no longer an option to start GParted via an easy menu pick, which as I recalled was System > Information > Gparted.  I found it in 11.10 by mousing to the top left button (tooltip:  "Dash Home") and doing a search for GParted.  Once I did that, the Live CD temporarily added it to the toolbar stretching down the left side of the screen.)

This time, GParted gave me the surprising information that the entire drive (which I had just been using, minutes earlier) was unallocated; and when I took a closer look via the right-click Information option, GParted said, "Can't have overlapping partitions."  This post discusses this situation.  (The processes described here unfolded over a period of some days, so there may be some discontinuities in the account, but I think the basic picture comes through.)

I began with a broad search and then a narrower one.  These included repeated suggestions that I go into Terminal (available via search, and also down toward the bottom of the left-side button bar, as above) and type "sudo fdisk -lu."  (That's a -LU, not -1U.)  I had a couple of drives, and thus had to enlarge the Terminal window (or scroll back up) to see what it was saying about /dev/sda, which was the drive GParted had considered problematic.  As I looked down the list of what fdisk was telling me about partitions, I couldn't figure out what GParted was complaining about.  What I expected to see was something like this:

Device        Start        End
/dev/sda1         63     5000000
/dev/sda2    4999999     8000000

In that example, sda2 would start before sda1 ended.  But I didn't see anything like that.  The numbers in my list made sense.  I also didn't have an error message in my list, like that shown by one user:  "Partition 1 does not end on cylinder boundary."  A later post in that thread suggested typing this in Terminal:

sudo parted /dev/sda unit s print

That just gave me the same "Error:  Can't have overlapping partitions" message.  This was to be expected:  GParted was a front end to parted.  This was just two ways of getting the same report from the same program.

The problem identified in another thread was in the total disk size reported by fdisk.  The top part of the fdisk output said there was a total of 312581808 sectors in /dev/sda, but the list of individual partitions said that the extended partition (and a logical partition within it) ended at 312590879.  The latter was a bigger number than the former.  That is, the partitions were supposedly continuing on past the end of the drive.  There was also a discrepancy between an early line in the fdisk output, which said that sector size was 512 bytes, and a later line, which said that sector size was 2048 bytes.  The advice given in that thread was to use fdisk to delete and recreate the partitions with the correct size.  I would have been inclined to use GParted for that, as it seemed easier, but on reflection I realized that I had probably used GParted to create these partitions in the first place.  But I guess I could have used GParted and then tested it with fdisk again.

But anyway, I didn't have those problems.  The numbers in my fdisk output made sense.  So far, no answer.  I drifted through another thread that pointed me toward TestDisk.  Typing "TestDisk" in Terminal told me that I would have to install the "universe" repository of program downloads in order to install TestDisk.  This might not have been a problem with an installed copy of Ubuntu but I wasn't sure how to do that with a live CD in Ubuntu 11.10.  It appeared that I might have to remaster my Live CD to include the universe repository.  That seemed to be getting pretty far away from the original mission.

It occurred to me that I ought to be able to get similar output from a Windows program -- to see a list of partitions and sectors like that which I could see in fdisk in Ubuntu.  This would not be CHKDSK, which would check the file structure within a partition.  At the moment, I wasn't sure what program I would use for that purpose.

Before I could pursue that thought, I looked again at the fdisk output.  Now I saw something I hadn't noticed before.  My last partition did not go beyond the end of the drive.  But it did go beyond the end of the extended partition.  In other words, I was supposed to have this arrangement:  Primary Partition 1, Primary Partition 2 (optional), Primary Partition 3 (optional), and then either Primary Partition 4 or Extended Partition; and the Extended Partition was supposed to contain any additional (logical) partitions -- up to the end of the drive, usually.  Mine didn't do that.  The relevant lines from fdisk -lu looked like this:

Device        Start       End
/dev/sda3    7000000    9000000
/dev/sda8    8000000    9500000

In the System column provided by fdisk (not shown here because of insufficient line space), sda3 was the extended partition.  In other words, these numbers were saying that dev8 was starting inside the extended partition, as it should; but it was ending after the extended partition, and that was improper.  It wasn't a question of GParted not being reliable, as I had begun to fear.  GParted appeared to be identifying a legitimate issue.  But GParted wasn't going to help me fix it:  as noted above, it was showing the whole drive as being unallocated, which was incorrect, and the only option it was offering me was to create a new partition in that big unallocated space -- that is, wipe out all my data and partitions on that drive.

I was thinking that I should double-check GParted using a Windows tool, and that anyway it would be nice to have a Windows-type alternative to this Ubuntu tool.  I assumed Microsoft itself would not be inclined to give me something useful for this purpose.  The last partition was a Linux partition, not a Windows partition -- using ext3 format, I believed, not NTFS -- and Microsoft was not known for doing much that would be helpful in the Linux world.

It seemed that I would have to use fdisk, from the Ubuntu CD.  I wasn't entirely sure how to proceed.  Fdisk was giving information in terms of "blocks," but when I typed "fdisk" by itself at the command prompt, it gave me options in terms of cylinders, heads, or sectors per track, but not blocks.

Then again, as I thought about it, I realized that I actually could go into Windows > diskmgmt.msc and delete that ending Linux partition.  Disk Management did display it.  It surprised me that, if I wanted to use a GUI tool rather than a command-line option like fdisk, the tools offered in the Windows operating system would be more helpful, in this case, than those offered by Ubuntu.

I had been able to see that ending partition in GParted previously.  It had been marked in some way to indicate that it was problematic.  Why had GParted ceased to display it that way?  It occurred to me to boot up with an older Ubuntu CD -- version 10.04 rather than 11.10.  I did that and went into System > Administration > GParted.  But no, it was showing "unallocated" too.  So something had changed.  GParted was wrong, and I was definitely going to have to use another tool to fix the situation.

Before taking the plunge into fdisk, I decided to use this opportunity to play with one or two other partitioning utilities I had burned to CD.  One was Minitool Partition Wizard.  It got a glowing Editor's Review and four stars from 389 voters at CNET.  Unfortunately, it produced "Boot failed: press a key to retry" when I tried to boot my machine with the CD I had burned.  Oops.  Same thing on retry.  Well, evidently it was time to download a newer copy.  They were up to version 7.0.

While that was downloading, it turned out that I had another copy of Minitool Partition Wizard CD, version 5.2.  I tried that.  It loaded OK, and it showed the partitions without a problem.  It was also faster and easier to get to the information, using a dedicated partition CD, instead of having to load Ubuntu and find GParted.

So, OK, this was looking promising.  In Partition Wizard, I selected the appropriate drive and clicked the "Show Disk Properties" option.  It didn't report errors.  I wasn't sure if it was even capable of reporting errors.  It said that that last, troublesome partition was actually unallocated space.  As I recalled, I had formatted that partition to be ext3, in case I wanted somewhere to install Ubuntu.  Maybe the Linux partition had deteriorated somehow; maybe that's why it was now problematic.

I decided I could do without that Ubuntu partition.  Since I knew there was nothing in it, I told Partition Wizard to extend the preceding partition to take over this allegedly unallocated space.  But not all of it.  I had become superstitious about running partitions right up to the ends of drives.  Just for good luck, I made that unallocated space into an NTFS drive.  Partition Wizard decided that the last 14MB of that space would have to remain unallocated.  I clicked Apply.  Then I deleted the partition I had just made and replaced it with a relatively small (3GB) ext3 partition (which would not show up in Windows, just in case "unallocated" was a potentially troublesome status at drive's end), putting the rest of the space into the preceding partition.

That last step didn't go swimmingly.  Partition Wizard said that it had "Failed to execute the following command" with "Error Code 36':  Minitool Partition Wizard detects that file system of the partition have errors.  Please use 'Check File System' function to fix it first."  Ah, so there was a tool of that sort lurking there somewhere in Partition Wizard.  But where?  Now I saw why it hadn't popped out at me earlier:  it was in the Partition menu (and also the context menu), but it was greyed out.  I couldn't very well check the file system with a greyed-out tool.  It didn't seem willing to run on any partition or drive on that computer.

By this point, the download of Partition Wizard version 7 had completed on the working machine, so I installed it there and took a look at it.  Apparently it would work, for at least some purposes, while Windows was running.  I doubted it would help the troubled computer, since the partition that I was trying to resize contained my paging file.  The Check File System option was not greyed out.  But now it seemed that, if I wanted a bootable CD, I had downloaded the wrong thing.  The Minitool page for the bootable CD didn't specify that the bootable CD ISO would give me the Check File System option, but I decided to give it a whirl.  I downloaded that ISO and tried to burn it to a blank DVD.  ImgBurn said, "Invalid or unsupported image file format!  Reason:  First image file part is less than 2048 bytes in size."  So, OK, bad download.  I re-downloaded the ISO and tried again.  It was a slow download.  This time, when I tried to boot the newly burned DVD, I got "Unknown keyword in configuration file:" followed by eight junk characters and then "Could not find kernel image:  linux."  I tried a cold boot but still got the same thing.  This DVD was junk.  I looked for other sites to download the ISO from, but they seemed to be the kinds of sites that would install malware.

I did want a bootable CD alternative to GParted, for situations like this.  I looked into Parted Magic, but it didn't sound like it had the power of GParted.  Their Live USB option had TestDisk, though, and would apparently only take about 45MB, so I thought it might be a good option to put on an old 256MB USB drive.  I started up UNetbootin and pointed it toward Distribution > Parted Magic > Latest_Live.  I had already plugged in my USB drive, so I chose that, and indicated that I wanted to reserve 50MB for files to be preserved across Ubuntu reboots.  (I wasn't sure exactly what that was about, but it sounded good.)  It started the process of downloading and installing whatever it needed, onto my USB drive.  It said the download would be 175GB.  Larger than expected.  I decided to install from an ISO instead, so that I wouldn't have to re-download if the first try didn't succeed.  So I downloaded the Parted Magic ISO and then went through the UNetbootin installation process that way.

While that was in play, I rebooted the troubled machine and went into Windows > Start > Run > diskmgmt.msc.  As expected, Disk Management reported no drive problems.  It showed all my partitions, including the smallish ending partition I had set aside for some possible future Ubuntu installation.  I right-clicked on the partition adjacent to the ending partiiton, which Disk Management showed as "unallocated."  There was an option to "Extend Volume."  I went partway through that.  It looked like Windows 7 was ready to fix the problem.

I installed Partition Wizard on the troubled machine.  I wondered whether it would perform differently than the bootable CD version (above).  It looked like it, too, was ready to go.  Why was life so hard for had the CD?  Another highly recommended alternative was Easeus Partition Master.  I downloaded it from CNET (four stars, 943 voters) and installed it.  Same thing there:  the Windows installed version saw the partitions as expected, and seemed prepared to merge or resize as desired.  But their "Bootable CD" option took me to a webpage that said the free version -- what I had just installed -- wouldn't include a bootable disk option.

By this point, the UNetbootin process was nearly done.  But I decided to reboot with the Ubuntu 11.10 CD to test some other drives first.  To my surprise, GParted was now showing everything as being OK on the previously troubled machine.  Had we fixed something when I wasn't looking?  And now I saw what the problem was -- why I'd gotten that funky fdisk output (above).  The last partition on the disk, the one that I had set aside as unallocated, was not in the extended partition.  It was a primary partition.  Somehow, I had gotten myself into this arrangement:  Primary Partition 1, Primary Partition 2, Extended Partition, and then Unallocated space outside of the extended partition.

Well, I didn't want that, especially not if it was going to confuse GParted or anyone else.  It looked like I was going to have to wipe out the extended partition -- what's 900GB, between friends? -- and rebuild the thing, and have no excuse to test my cool new bootable USB version of Parted Magic (sniff!).  Then it occurred to me to wonder what those Windows programs -- Disk Management and Easeus and Partition Wizard -- were planning to do with this situation.  Were they somehow going to merge that last unallocated space into the extended partition, in some way that GParted wouldn't do?

Or, no, wait.  I was trying to get GParted to merge the unallocated space directly into the last logical partition.  That's not how these things are done.  I needed to merge the unallocated space into the extended partition, and then shuffle that space on down the line, inside the extended partition, to whatever logical drive was most deserving.  Is that what Windows Disk Management was planning to do?

I decided to find out, because if Windows could walk & chew partitions at the same time, I could meanwhile use the troubled machine to work on other things.  Boot back into Win7; back into Disk Management; extend the volume.  It took ... about seven seconds.  Kind of ridiculous.  I checked it with a GParted reboot.  Now GParted was reporting a single partition filling the entire drive, plus a 1MB partition at the end.

Some days had passed since I had started the processes described in this post, and I wasn't entirely clear on exactly what I had done as I reviewed my notes (above).  But I was sure I had set up an empty ending partition, in my superstition that having a little space at the end could sometimes prevent problems, and 1MB sounded like a possibility.

But in any case, the question had recurred:  why was GParted not seeing the multiple partitions that I had just been working in, in Windows?

I decided to try out the bootable Parted Magic USB drive that UNetbootin had concocted for me.  I made sure my BIOS was set to boot USB-ZIP first (instead of USB-FDD or USB-CDROM), and proceeded to boot that Parted Magic USB.  Its boot menu gave me choices between the default, which would run from RAM, and a couple of bootup alternatives, in case my system had less than 312MB of RAM.  It also gave me submenus for Extras, Failsafe, and RAID.  The Extras menu contained options to load various hardware diagnostics (e.g., Hardware Detection Tool, Memtest86+) and boot managers (e.g., GRUB, GRUB2).

I loaded the default (which, as I soon discovered, would load automatically after 20 seconds if I didn't make a selection).  This gave me an impressive desktop:  Parted Magic was offering me at least 20 to 30 utilities (e.g., Disk Health, Monitor Settings, File Manager) plus Firefox.  I was surprised they were able to squeeze so much onto one little USB drive.  I tried out the Firefox:  it worked.  This definitely seemed like a tool worth having.

But then it seemed that maybe I had played with the Parted Magic boot menus too much.  After a first or second reboot, the graphics became kind of buzzy (i.e., unexpected colored dots flashing in various colored spots, and along random horizontal and vertical lines) and off-centered (i.e., with a couple inches of black space on the left edge of the monitor) and began flashing on and off (i.e., intermittent black screen).  I tried a cold boot (i.e., shut the machine down for at least 30 seconds before restarting, to clear memory).  (Incidentally, the shutdown menu gave me the option of saving my current Parted Magic session.  I guessed that this option was possible on a USB drive, which would have space to store such information, but might not have been available on a bootable Parted Magic CD.)  But when I rebooted, I got two unexpected results:  the USB drive did not boot -- instead, I went into Windows -- and now the buzzy and off-center graphics were affecting Windows too.  Hmm ... probable hardware issue.  I tried rebooting with an Ubuntu DVD, without the USB drive plugged in.  But no, same thing there.  It seemed to be getting worse:  the black spells were longer.  A monitor reset didn't help.  I connected the monitor to a different computer.  It worked OK there.  I tried doing a longer cold shutdown -- several minutes -- and booting again, still without the USB drive plugged in.  That worked.  Now I got a normal Ubuntu screen.  I tried booting the USB drive again.  Now it worked.  Without further ado, I went straight into its Partition Editor.  But that turned out to be just GParted.  It showed the same thing as GParted had shown when run from the Ubuntu Live CD.  And I was getting the funky graphics again, and had to do another five-minute shutdown.

I had not yet succeeded in finding a bootable freeware CD or USB drive that would give me a believable impression of the partitions existing on that hard drive.  I booted into Windows to take a look with the installed (as distinct from bootable) versions of Easeus and Minitool that I had installed there.  I expected them to provide a realistic picture, even if all they did was to parrot what Windows was detecting (i.e., multiple NTFS partitions on that drive).  But now, even after a 10-minute shutdown, the graphics were still buzzy, off-centered, and flashing (indeed, mostly) black.

What in the world had happened?  I was tempted to try the bootable USB drive in another computer, to see whether it was the cause of this, but then I decided I really didn't want two messed-up computers.  It did appear that the USB drive had caused it; there had never before been anything of this nature.  The screen was totally black by now.  I had to do a hard reset to see anything.  I wasn't getting any distortion at the bootup phase.  I tried loading the fail-safe defaults in the BIOS.  I got an option to boot into Safe Mode, so I tried that.  I was still getting some buzziness there.  I tried Control Panel > Device Manager > Display Adapters > right-click on the adapter > Update Driver Software.  It said my software was up to date.  I tried right-click > Uninstall the display adapter (but not its driver software).  A reboot into Normal Mode still showed some buzziness here and there (e.g., in a CMD window).  I went back into Device Manager.  Instead of Display Adapter, I had Other Devices > Video Controller (VGA Compatible).  After five minutes or so, I saw a balloon tip telling me that the drivers specific to my video adapter (ATI Radeon HD 4250) had installed successfully, and now that device was visible as a Display Adapter in Device Manager.  But apparently that took us back to the Dark Ages.  After a reboot, the screen was black.

I rebooted into Safe Mode, hoping to do a System Restore.  Funny thing:  the login screen wasn't taking keyboard input.  I couldn't enter my password.  Even if I typed the password and hit Enter, the login screen did not change.  I rebooted and tried the same thing in Normal Mode, though this time I was entering the password into a black screen.  (I saw a flash of the login screen before it went black.)  I got a Microsoft happy sound, which as I recalled indicated that I had succeeded in logging in.  But the screen remained dark.  Moving the mouse, hitting WinKey, etc. brought no joy.  I could see the hard drive light burning away -- there was obviously a lot going on -- but I was blind to it all.

The monitor had VGA and DVI ports.  It was connected via DVI.  I thought I should try a VGA cable and see if that made a difference.  This transition led to the culprit:  loose DVI connector.  No VGA necessary.  Sorry for slandering the good name of the Parted Magic bootable USB drive.  I mean, it still had GParted, and thus continued to be useless for present purposes in that regard.  But at least it hadn't completely fubared my graphics circuits.  At least not as far as I could tell.

Back in Windows Normal Mode, I started Easeus Partition Master 9.1 and MiniTool Partition Wizard Home Edition 7.1, both in their installed forms.  Both saw the multiple partitions on that drive that GParted had been unable to see.  Minitool listed them in alphabetical order by name; Easeus listed them in the preferred alphabetical order by drive letter.  Easeus did, and MiniTool did not, show an 1.6MB unallocated partition at the end of that drive.  Both appeared to be glorified and perhaps enhanced versions of Windows Disk Management.  Both provided an indication as to whether a given partition was primary or extended.

On the drive in question (unlike another drive in that machine), both Easeus and MiniTool were listing the partitions as neither primary nor logical, but rather as "simple" partitions.  I hadn't paid much attention to the difference until now.  I didn't recall requesting any simple partitions; I had always just used primary and extended.  I guessed that Windows Disk Management had converted the primary and extended partitions previously visible in GParted to simple partitions in that little seven-second operation where it "resolved" the previous situation.  The general idea was that there were dynamic disks with simple partitions, and there were basic disks with primary and extended partitions, but the two did not mix:  you could not have a dynamic disk with a primary or extended partition, or a basic disk with a simple partition.

It seemed that GParted was unable to work with simple partitions.  Another way to say this was apparently that GParted would work only with basic (not dynamic) volumes, and the latter was what Disk Management had given me.  I noticed that MiniTool did, but Easeus did not, provide a right-click option to resize a partition, also available in Windows Disk Management.

A search led to a MiniTool webpage that said MiniTool could convert a dynamic drive back to a basic drive without data loss.  (Of course, one could always wipe and recreate partitions and then restore data from backup, assuming backup existed.)  It looked like I would have to buy the pro version to get this capability.  Another thread said that this wasn't possible without data loss via Acronis products, though one person did interject that a bit of expert-level hex editing could do it pretty easily.  (I suspected that, if it were that easy, these programs would have been offering the capability, but maybe that was exactly what Minitool was doing.)  The MiniTool webpage said that Partition Magic could do it.  I had used PartitionMagic for years, almost always with good results, but thought it was defunct and incompatible with Windows 7.  (Symantec had bought a good program and let it go to pot.)  So I wasn't quite sure what that MiniTool page was trying to say.

I was out of time for researching this issue.  My present impression was that I could (a) stay with the dynamic disk and use Windows Disk Management or the free MiniTool to resize or delete its simple partitions as needed; or (b) backup and wipe the drive, and then create a basic drive and fill it with primary and extended partitions, using virtually any of these tools, including GParted; or (c) buy the pro version of MiniTool and try converting the simple partition to primary without data loss; or (d) explore that expert editing approach to convert the partition manually.

My principal reason for wanting to be able to use GParted was to have a non-Windows perspective on what was happening on the drives.  This was useful in two regards.  First, until Windows converted the basic disk to a dynamic disk, I had been able to see partition information (with GParted and also with fdisk) and get insight into possible problems on my drive.  Second, GParted gave me a very quick heads-up as to whether there were problems on a drive that would call for CHKDSK /R.  Without GParted, I just ran CHKDSK /R on each partition.  It was a very slow and inconvenient process, but I had the impression that it was better than just using the disk tools available within Windows drive properties.  Its inconvenience tended to discourage doing it.  Being able to book GParted (with or without Ubuntu) and take a quick look seemed to encourage more often disk checks.  Typically, there would be no more than one partition needing this attention.

I decided that it would be easier to stay with the dynamic disk, at least for now, and that doing so would give me a chance to learn something about that kind of disk and its simple volumes.  I just had to remember that this was why I was getting those weird results from GParted.  There was also the possibility of an eventual update from GParted or some other tool to handle these volumes.

Windows 7: The INSTALL Partition

For a long time, probably since the 1980s, I had kept my Windows installation on drive C and my data on drive D.  (Drives, or partitions of drives, can be readily created within Windows 7 and also by partition manager programs.  GParted, included in the downloadable Ubuntu CD, has been the most reliable partitioning programs for my purposes in recent years.)

Having the data on drive D had several advantages.  One was that I could back up drives C and D on different schedules.  Once I got a good Windows installation set up on drive C, I didn't need to back it up very often.  I'd just make a drive image (using Acronis True Image in the past few years), and I'd make an updated image backup just when I had done some significant new program installation or adjustment.  By contrast, I would want to back up my data on drive D on at least a daily basis.  Of course, when I made the image of drive C, I would need someplace to put it other than drive C.  An external drive was a possibility, assuming the bootable CD would recognize it, but it would tend to be slower, and this would be complete downtime, when it would not be possible to do other work.  It worked the other way, too:  having the data on a separate partition meant that I could completely reinstall Windows without affecting or even worrying about my data.

There were exceptions to that last statement.  Some program configurations were so detailed, time-consuming, and/or oft-changing as to constitute a sort of data.  Not the kind of data I was supposed to be working on, but data nonetheless.  An example:  Firefox add-ons.  It could take a half-hour or more to find, install, and configure my Firefox add-ons after doing a new Windows installation.  Some add-ons allowed me to export my saved settings, but obviously I would not want to store those on drive C; they'd be wiped out if I reinstalled Windows sometime down the line.

I also found it was handy to keep a local copy of the programs that I would install in Windows, after installing the Windows operating system itself.  I did not want to have to re-download all those programs and re-invent all of the things I had previously figured out about installing them.  So instead I had folders containing the programs to install, with installation notes in accompanying text files, and I named the folders in such a way as to guide me in the installation sequence that worked best (e.g., "01 Motherboard Drivers").  There were also quite a few program installers that I tried and uninstalled, or hadn't gotten around to installing.  Also, some ISOs -- ready-to-burn CD images that I had downloaded but hadn't burned to CD, or wanted to keep because it was a hassle to re-download a 700MB image.  I had collected these sorts of things, not only for Windows, but also for Ubuntu.

I accumulated about 75GB of this stuff.  Keeping it all on drive D meant that my daily data backups were swelling up with all this material that didn't need to be backed up every day.  So at some point I moved a bunch of it over to its own partition, with occasional backups.  What I kept on drive D was mostly stuff that I was actually using in my current installation.  One example:  those Firefox settings files.

Sometime in the late 1990s, I discovered that I could move my Start Menu to drive D.  This would have the advantages mentioned above, including especially the fact that my custom-arranged Start Menu (top-level folders:  Productivity, Online, Multimedia, Tools, Startup, Miscellany) would not have to be rearranged each time I installed Windows.  As long as I installed everything in its default installation location, the shortcuts in the Start Menu would come back to life as soon as I reinstalled the target program where the shortcut expected to find it.

A few months before writing this post, I came to realize that, of course, I could also install my portable applications in the Start Menu.  This would be ungainly in the sense that a bottom-level folder in the Start Menu might contain a slew of program files instead of a nice, orderly collection of shortcuts.  But it was handy for keeping everything that ran in one place, where I could copy it to a jump drive and use considerable parts of it on any other Windows machine.  The Start Menu, wherever located, could also be accessed and synchronized on a network, so that I only needed to configure the Start Menu once and would then have it available for any computer I would attach to my home network.  (Making it available did require a registry tweak.)

Putting the portable applications in the Start Menu had an unwanted side effect.  Many portable apps (especially those coordinated by PortableApps.com) used many of the same program files.  That was a problem because I liked to use DoubleKiller to delete duplicate files on drive D.  I couldn't do that anymore, at this point, because it would detect tons of duplicative portable program files that were supposed to be there.  I looked for a different duplicate remover, one that would allow me to exclude folders like the Start Menu folder, but ultimately decided to stay with DoubleKiller for now.  The reason was that I did not want to risk that, one fine day, I would forget to exclude the Start Menu from a DoubleKiller sweep, and (although this was unlikely) would punch the wrong button and delete that Start Menu from my hard drive.

What I decided to do, instead, was to move the Start Menu so that it would join those other program files -- programs to be installed, etc. -- in their own partition.  I called it INSTALL and gave it a letter of W, so that its location would not be affected by the connecting and disconnecting of various USB drives and whatnot.  So then hopefully the shortcuts in it would stay in place, and would require no further adjustment forever and ever.

Right now, unfortunately, they did require adjustment.  I modified the registry tweak to point toward drive W:\Start Menu rather than D:\Installation\Start Menu.  This caused almost no problems.  The main issue was just that a bunch of shortcuts were now dysfunctional, in that they pointed at executable files on D that were now on W.  I ran Glary Registry Repair 3.3.  It identified 165 new registry errors.  As I scrolled down the list, I noticed that a huge number of the problems identified by Glary were links to IrfanView on D.  I considered doing a global registry search and replace for the IrfanView location -- or, indeed, for all references, changing them from D to W, perhaps with the aid of a global registry search-and-replace tool like Registry Toolkit ($25) or Registry Replacer ($15) or Replace Registry Values (free).  But then I decided it might be safer to let Glary fix those dud links and then do a search in a registry editor for any remaining references to D:\Installation|Start Menu.  I used O&O RegEditor to do that search.  I was now down to a total of just 29 registry references to D:\Installation\Start Menu.  I was going to edit them in O&O, but then decided not to.  As long as they weren't hurting me, I was better off just leaving them alone.  One ill-advised registry edit could cost me an hour or more for recover or restoration.

So this was pretty much the end of the project, aside from some continuing cleanup, correction of shortcuts, etc.  I now had an INSTALL partition, labeled as drive W, containing my customized, shared Start Menu and installers for various programs.  I could now run DoubleKiller on drive D without worrying that it might knock out program files, and without having to do manual exclusions to focus it on the data duplicates that I was seeking.

Windows 7: Notes on the System Imaging Feature

I decided to make a drive image using Window 7's system image feature. I had made an image previously, but System Recovery couldn't find it when I needed it.  As I was starting the system imaging process, I saw this warning:

Backing up to dynamic disk gives you limited functionality while performing system image restore.

I wondered whether my previous image would have been visible, when I tried to restore from it, if I had copied my Win7 image to a partition that was not on a hard drive containing any RAID arrays -- more specifically, to what Disk Management (diskmgmt.msc) would show as a "basic" rather than a "dynamic" drive.  I had originally saved the image to a basic drive, but had then moved them to a partition on a dynamic drive.  If I had originally tried to save it to the dynamic drive , maybe I would have gotten this "limited functionality" notification at that point.

My mission at this point was to see whether Win7's system imaging could do what Acronis True Image Home 2011 apparently could not.  Could it restore a bootable Windows 7 partition to a new drive C located on a RAID0 array?

I went into Control Panel > Backup and Restore > Recover system settings or your computer > Advanced recovery methods > Use a system image.  It gave me the option to create a backup now.  I took that, just in case.  I tried saving to a partition on the dynamic drive, just to see what would happen.  It did give me a warning, "The selected volume is on a dynamic disk."  I clicked on its "More information" link.  That opened this dialog:

Set up backup

When restoring a system image from this volume, the disks on your computer cannot be formatted to match the layout of the disks in the backup.  To have full restore functionality, select a volume on basic disk as your backup location.

It wasn't clear whether that meant that the very process of creating a backup on a dynamic drive would have this effect, or if they were just saying that trying to *restore* from a dynamic drive would be difficult.  I decided to save to the partition on the dynamic drive nonetheless.  But as I proceeded, it appeared that I was only setting up an ordinary backup.  The option wasn't available to "Include a system image of drives: PROGRAMS (C:)."  The explanation, which didn't entirely persuade me, was, "Because you are trying to restore your computer to a previous state, you can only back up data files" -- not program files, that is.

I canceled out of that and clicked Restart to continue the system recovery -- bearing in mind, here, that I was hoping to restore to the RAID0 array, which had not yet entered service, whereas this backup program was sounding like it intended to restore to (and overwrite) my current drive C.  I was actually willing to let it do that -- the system had been through a rough night -- but upon rebooting, it said, "Windows cannot find a system image on this computer."  It defaulted to the "Select a system image" option," so I went with that.  Then Advanced.  But still, we weren't able to find those images that I now had on two separate partitions.

So now I wondered if the failure to find my previous system images was due to the fact that I had changed their names.  I thought it made sense to do so.  They were all called WindowsImageBackup.  I changed them to put the date in front, e.g., 2011-01-07 WindowsImageBackup.  Maybe this kind of rigidity was calculated to make the program easy to use.  I suddenly realized that, contrary to my assumption, perhaps later backups would not overwrite the previous WindowsImageBackup folder.  I looked inside the WindowsImageBackup folder, and it did appear that images might be saved in subfolders with different dates in there.

So, OK, back in the partition on the dynamic drive, I changed the name of one of those folders back to plain old WindowsImageBackup.  It was still in a subfolder, not in the root folder.  I went again to Control Panel > Recover system settings or your computer > Advanced recovery methods > Use a system image you created earlier to recover your computer.  I skipped the backup step, this time, and clicked Restart.  The "scanning for system image disks" process still said, "Windows cannot find a system image on this computer."  I canceled that automatic search and again tried "Select a system image" and then Next.  Still no joy.

That was the story for the search for the WindowsImageBackup folder on the dynamic drive.  Back in Win7, I tried renaming the copy of the WindowsImageBackup folder that I had copied to the basic drive.  I went through the same steps again.  "Scanning for system image disks" and this time, praise Jesus and pass the tequila, we had a discovery!  We had liftoff!  We had a window that said, "Select a system image backup."  So the answer to this little mystery was that (a) you were not supposed to change the name of the WindowsImageBackup folder and (b) it had to be on a basic (i.e., not dynamic) drive.  Since this worked, I did not try the alternative of going into the WindowsImageBackup folder, in Win7, and just double-clicking on various files to see if they would spontaneously fire up and run the system recovery software.

So now that we had a system image ready to be restored, the question was whether it would insist on being restored only to the basic drive, or whether I would have an option to restore it to the RAID0 array I had set up to be my boot drive.  Actually, it did not say where it was going to restore.  It said that it was going to restore drive C, but it did not say where it believed drive C was located.  But surely it would not wipe out data partitions, at least.  I went ahead with it.  After five minutes or so, it said, "Restore completed successfully," and it rebooted back into Win7.  It had restored the image to the existing drive C, the one I had booted from.  So there did not appear to be an option to choose a different target drive.

So I now had restored my original hard drive to its original condition as of about midnight the previous evening, before things started getting funky.  Along the way, I had learned a bit about how Win7's system recovery feature functioned.

The remaining unknown was whether I could just munge my various copies of the WindowsImageBackup together into one.  Keeping backup copies, I went into Windows Explorer and did a simple copy-and-replace operation to combine those WindowsImageBackups, into one properly named WindowsImageBackup folder.  I didn't try to figure out which versions of the same file to keep; I just copied and replaced, more or less at random.

I left this combined WindowsImageBackup on the dynamic drive for the moment.  Then I went into System Image and let it do its reboot thing.  Its scan for system image disks failed to detect the ones on the dynamic drive.  So it seemed to be pretty much confirmed that it didn't want to save to, or restore from, dynamic drives.

I moved the WindowsImageBackup folder, containing the munged combination of two different backups, to the basic drive, and tried System Recovery again.  This time, it found the folder, but it detected only the older of the two backups within it.  So it seemed my file munging process had probably replaced the newer versions of some of the indexing files in that folder with older versions.  Apparently the imaging program looked at those small files when deciding which images were available.  I didn't test whether overwriting older indexing files with newer ones might have shown only the newer images.  Tentatively, it seemed that the best solution, when there were two distinct WindowsImageBackup folders, was just to keep them separate and eventually delete one of them, rather than try to combine them.

Ubuntu 10.10: Streamlined RAID 0 Installation

I had previously installed Ubuntu 10.04 on a two-drive RAID 0 array.  I did that to make a Windows XP guest virtual machine (VM) run faster in VMware Workstation 7.1.  I had then run into some problems with that installation, and had abandoned it.  Now it was time to try again, but this time with Ubuntu 10.10.  This post describes the process in more streamlined terms, drawing from the previous post in which I logged the details of that earlier attempt.

This time, as before, I had two hard drives for the RAID 0 array, plus a third drive on which I had already installed Windows XP.  The two empty hard drives for RAID were each 320GB.  That third drive also held my /home partition (i.e., the contents of the /home partition from a previous Ubuntu installation), which contained many of my settings and adjustments for various Ubuntu programs.  In other words, my Ubuntu installation would not be like a Windows XP installation, where it would be necessary to reinstall all of my applications (except the portable ones) after reinstalling the operating system.  The third drive also held my Linux swap space, which I probably could have put into the array instead, along with a partition I called LOCAL, which would hold backup copies of the VMware virtual machines.  I was going to put the active VMs into the RAID 0 setup to make them run faster, but of course RAID 0 was riskier in the sense that failure of either of the two hard drives would mean the loss of everything in the RAID 0 array.

I started by downloading and burning the Ubuntu 10.10 alternate (or "alternative") CD.  I booted that CD and chose the "Check disc for defects" option.  This took five or ten minutes, and then it said, "Integrity test successful," and then rebooted.  So then I went through the "Install Ubuntu" option and took the basic steps (selecting my country, my keyboard type, etc.).  The meat of the RAID 0 process began about three minutes into that video by amzertech (speaking, here, of its Part 1, not Part 2), where it was time to partition the drives.  I went to Manual (i.e., not Guided), and this put me into the main "Partition disks" screen, the one beginning with "This is an overview."  I went down to the first of the two hard drives.  It referred to them as SCSI partitions, but it also recognized them as being sdb and sdc.  So it looked like I had correctly cabled that third drive to actually be the first in the system (i.e., sda, a/k/a SCSI3 according to the partitioner), so as to make Windows happy.

The general concept of the RAID setup process was that, first, you designate some free space on each drive as a physical volume for RAID, and then you combine those physical volumes from the two (or more) drives into a single software RAID device.  The following paragraphs provide the details.

First, following the video, I went down to the first of the empty 320GB drives that I was going to use for my RAID array.  In my case, unlike the video, there was not yet any "pri/log" line showing "FREE SPACE" that I could select, under the drive identification line on the screen, so I just highlighted the drive itself and hit Enter.  This gave me the option of creating a new empty partition table on the drive, and I went with that for each of the two drives.  Then I highlighted the pri/log line under the first 320GB drive, showing free space.  There, I hit Enter and chose "Create a new partition."  For its size, I typed "50GB" and made it a primary partition at the end of the drive.  I guessed that this meant the outside of of the physical disc, where I believed data transfers would be faster.  Instead of leaving "Use as" at the default ext4 setting, I highlighted and hit Enter and went down to select "physical volume for RAID" (enter) > "Done setting up the partition."  I went through the same steps with the second 320GB drive, which was sdc on my system.  So now, back on the Partition disks" screen, each of the two drives showed an entry that looked like this:

#1   primary   50.0GB   K   raid

So this would give me a total of 100GB for my Ubuntu program installation, and I would still have several hundred GB left over as free space.  Now, on the main "overview" screen, I went up to the line that said "Configure software RAID" > "Write the changes to the storage devices" > "Create MD device" > RAID0.  This put me at a list of "active devices."  I wanted sdb1 and sdc1 (i.e., I didn't want to use one of the partitions I had previously created on sda, my third hard drive).  These were the only partitions on drives sdb and sdc, so the choice was easy.  For some reason, they showed up here as being 49999MB rather than 50GB.  I selected sdb1 and sdc1.  I highlighted each of those two, hit spacebar to select them, and then tabbed to Continue > Finish.  This put me back in the "overview" screen, where I saw that I now had these new lines, near the top:

RAID0 device #0 - 100.0 GB Software RAID device
   #1       100.0 GB
              131.1 kB         unusable

I highlighted the line that began with #1 and hit Enter > Use as > ext3 (apparently still more reliable than ext4) > Mount point > "/ - the root file system" > "Done setting up the partition."  This put me back in the "overview" screen, where the line now looked like this:

   #1       100.0 GB     f   ext4      /

I decided to go ahead with the video's approach of putting the swap space on the RAID0 partition.  To do this, I went through the same steps as above, starting with the free space line on each of the two drives.  The only differences were:

(a) I allocated only 5GB on each drive for this partition.
(b) This time, I selected sdb2 and sdc2 (instead of sdb1 and sdc1) as my active devices for the array.
(c) Under "Use as," I chose "swap area" instead of ext3.

The result, back in the "overview" screen, was that I had these lines:

RAID0 device #0 - 100.0 GB Linux Software RAID Array
   #1       100.0 GB    F   ext3      /
RAID0 device #1 - 10.0 GB Linux Software RAID Array
   #1         10.0 GB     f  swap     swap
              131.1 kB unusable

At this point, I wanted to vary from the video by adding one more partition, where I would put my VMs and possibly other things.  I went through the same process as with the first RAID device (above), and I used all of the remaining space on the two drives except for about 1GB.  The active devices in this case (when I got to that point in the process) were, of course, sdb3 and sdc3.  Back in the "overview" screen, I saw that I now had RAID0 device #2 of 528GB.  I would never need all of that space for my VMs, but I had no other use for the space, and this RAID setup process was a one-shot deal:  designate the space in some useful form now, or leave it forever unallocated.

So now, the final step.  I needed to create a /boot partition on just one drive.  That was why I needed to save 1GB.  I could have made one of those last active devices (either sdb3 or sdc3) larger than the other, but there was no point:  as I understood it, RAID0 would use only the amount of space that they both had in common.  So I would wind up with 1GB unused on one of the two drives.  Anyway, to create the /boot partition, I selected that remaining free space on sdb (i.e., the first of my two RAID drives) and used it all up on another ext3 partition.  This time, I chose ext3 without first choosing "physical volume for RAID"; and after choosing ext3, I didn't go right to "Done setting up the partition."  Instead, I stopped first at the "Mount point" option, where I chose the "/boot" option.  Back in the "overview" screen, I saw that I now had my three RAID0 devices at the top of the list, and the /boot device as sdb4 down under the first of my two 320GB drives.

In the "overview" screen, I saw that there was too much information; some had scrolled off the bottom of the screen.  I arrowed down until I got to the very bottom of all that, where I chose the "Finish partitioning and write changes to disk" > Yes option.  This started me right into the Ubuntu installation process, where I just entered basic information (e.g., my name).  The installation was very straightforward, and it worked:  Ubuntu booted up.  I then went to System > Administration > System Monitor > File Systems tab.  There, I saw /dev/md0 as root directory and /dev/sdb4 as /boot.  (The video said that the swap would not be visible here, and it wasn't.)  So my next step, at this point, was to refine the basic installation to suit my preferences.  The description of that process appears in a separate post.

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.

Ubuntu 10.04: Creating a Separate Home Partition

I was reinstalling Ubuntu 10.04. In the previous installations, I had gone with the default approach. In particular, I had kept the /home folder in the root ("/") partition. That meant some extra work to save and/or recreate my user settings. This time around, I decided to create a separate /home partition to store those settings. This post describes that effort.

As I looked into this idea, I noticed that some guides to this process were a bit vague about key details, and other guides admitted that it could be complicated and it didn't work for everyone.  So I decided the safest bet was to start with the Ubuntu Community Documentation webpage.  For the partitioning, I rebooted with an Ubuntu Live CD and went into System > Administration > GParted.  To figure out how big to make the partition, I mounted the partition containing my Ubuntu installation and then went into Applications > Accessories > Disk Usage Analyzer and drilled down until I got to my /home partition, which was under /media.  Its name was a long string of random numbers and letters, something like 4bas83ng-gabbdd-adbg-fb37abd.  (It's a unique identifier, different for each computer and device.)  The /home partition for me, with almost all of my data elsewhere, was only about 120MB.  I decided on 1GB, to be on the safe side, and called it "home."  When GParted was done, I shut it down, exited the Live CD, and rebooted Ubuntu normally (i.e., without the Live CD).  Then I went into Applications > Accessories > Terminal, and typed "sudo blkid" to find the UUID for the new 1GB partition.  Following the Community Documentation, I then followed the advice to make a backup of fstab by typing these two lines:

sudo cp /etc/fstab /etc/fstab.$(date +%Y-%m-%d)
cmp /etc/fstab /etc/fstab.$(date +%Y-%m-%d)

(Note:  shell commands are case-sensitive, and punctuation is important.)  The second line was almost identical to the first, so I didn't actually retype it; I just hit the Up arrow key and then the Home key and edited the first few characters, and then hit Enter.  Now I was ready to edit fstab:  "sudo gedit /etc/fstab."  I added a line for the new home partition.

At about this time, I got distracted and strayed from the advice on the Community Documentation page at this point.  I ran into problems.  For reference purposes, the following section describes some error messages and other steps I took while trying to fix things.  After the following section, this post describes how I got back on track.

********************************************

DETOUR:  IF YOU HAVE FOLLOWED ME HERE, YOU ARE NOW LOST

********************************************

One of the first things that went wrong, aside from entering the wrong commands, was that I rebooted somewhere in the middle of the process, so Ubuntu read the fstab and assumed that my /home folder was on that new partition -- but I had not yet copied anything there, so the bootup froze.  So I had to reboot with the Live CD again, go into GParted, and delete that new home partition.  Then I rebooted without the CD, went back into GParted, recreated it, and did the copying step ("sudo rsync" etc., above).   Except that it didn't work.  I ran out of space.  Apparently I had not correctly calculated the necessary size of the new /home partition.  I went back into GParted and tried again.  This time I took the overkill approach:  30GB for /home.  (I had the extra space lying around, so why not?)  After a lot of fooling around with "sudo mkdir" this and "sudo umount" that, I did reach a point at which I had the right /dev/sd?? mounted at /media/home, and then the rsync command worked.  Then, as instructed, I renamed the old /home folder so that it wouldn't be detected as my /home folder:

cd /
sudo mv /home /old_home

I rebooted and sat back to see what would happen.  I got this on the initial Ubuntu reboot screen:

The disk drive for /home is not ready yet or not present
Continue to wait; or Press S to skip mounting or M for manual recovery 

This called for some additional screwing around.  I wrote down what happened; but when I returned to this post after an absence of a few days, I observed that Blogger had decided that what I wrote was garbage, and deleted it.  Thanks, Blogger!  I believe the gist of it was that I had forgotten that the new home partition would have, of course, a new UUID.  So I had to change fstab to account for that.  I also wound up running the rsync command (above) from a Live CD boot, after mounting the root and /home partitions, in this format:

sudo rsync -axS --exclude='/*/.gvfs' /media/UBUNTU/home/. /media/home/.

where UBUNTU was the label of my Ubuntu (root) program partition.  After rsync ran successfully, this new home partition contained about 4GB of files.  Booting with an Ubuntu Live CD, I ran GParted and resized /home to 10GB.  I had to do a reboot or two to get past the error messages and complete this repartitioning process, as often happened with GParted.  I then tried to install Ubuntu, designating separate root ("/") and /home partitions.  I told the installer to format the root partition but not the home partition, where I was saving settings from the previous installation.  But while I was installing from the CD, the installation program disappeared.  This happened three times with two separate installation CDs.  But when I told the installer to just put everything in root (i.e., not to recognize a separate /home partition), it went ahead, and the installation process was complete.

So now I apparently had to get Ubuntu to recognize my old /home partition in place of the new one that it had just installed.  I started Nautilus (i.e., Ubuntu's File Browser, from the Places > Computer menu pick), right-clicked on home, and saw that Mount was an option, implying that it was not yet mounted.  So that meant that, whatever I was doing with a /home folder right now, I would be doing to the newly installed one.  I went into Applications > Accessories > Terminal and typed the same commands as above:

cd /
sudo mv /home /old_home

That parked the new /home folder under the name /old_home, where it would still exist just in case, but would not operate.  Now I needed to tell Ubuntu to mount my saved /home partition at boot.  I typed "sudo blkid" and used the mouse (with right-clicks) to copy the UUID for home.  I typed "sudo gedit /etc/fstab" but this gave me never-ending error messages.  Oops.  Apparently gedit needed /home.  I killed that Terminal session, started a new one, reversed the mv command shown above (i.e., "sudo mv /old_home /home"), and tried gedit again.  This time it worked.  I noticed that fstab didn't list most of my drives, so I went to my main installation post and executed its steps related to ntfs-config.  I checked /home in Nautilus again and verified that the separate home partition was still not mounted.  Now I hoped that "sudo mv /home /old_home would put the newly installed home partition out of the way, and that my old one would operate.  But on reboot, I got several errors, one after another:

Could not update ICEauthority file /home/ray/.ICEauthority

There is a problem with the configuration server.
(/usr/lib/libgconf2-4/gconf-sanity-check-2 exited with status 256)

Nautilus could not create the following required folders:  /home/ray/Desktop, /home/ray/.nautilus

The last one made me think that my /home partition was not being recognized.  But following the advice in a thread where they seemed to be discussing all of these messages, I didn't pursue that; instead, I rebooted with the Ubuntu alternative installation CD and chose the "Rescue a broken system" option and chose to "Execute a shell in the installer environment."  But this didn't seem to be the best route to a command-line option, so I bailed out.

(Note:  I also ran into a "udevadm" error during this process.  It did not appear to be due to this home partition effort, but there is a possibility that it was.)

****************************

END OF DETOUR

**************************** 

Eventually, I reinstalled Ubuntu, made my way back to the Community Documentation page, and tried again.  My entry in fstab now looked like this:

UUID=xxxxxxxx /media/home ext3 nodev,nosuid  0  2

I had already created /media/home and had done the rsync part from my previous installation (above), so now I tried these commands:

cd /
sudo mv /home /old_home
sudo mkdir -p /home/ray

where "ray" was my username.  Then I went back to fstab and changed it again to this:

UUID=xxxxxxxx /home ext3 nodev,nosuid  0  2 

and rebooted.  This time, rebooting went fine:  no error messages, and my desktop was back in its configured condition, with panels and buttons where I had put them before reinstalling.  Very nice.

Error While Resizing Vista NTFS Partition with GParted

I was using the GParted 0.5.1 live CD to resize an NTFS partition.  (I had already backed up the data on the partition.)  When I tried to resize in GParted, I got an error:

An error occurred while applying the operations

See the details for more information.

IMPORTANT
if you want support, you need to provide the saved details!
See http://gparted.sourceforge.net/larry/tips/
save_details.htm for more information

I clicked OK.  Unfortunately, the details did not explain what had gone wrong.  I rebooted into Vista and then did a complete shutdown.  (Previously, I had just hibernated the system.)  I allowed a minute or so for the memory to clear, and then rebooted with the GParted live CD.  This time, it worked.  The problem was that I had hibernated instead of completely shutting down Vista before using GParted.