A Multiboot USB Drive with Windows 7, Ubuntu, UBCD4Win, Drive Tools, etc. - Second Cut

I had previously worked through the steps to create a bootable USB drive.  I had intended to create just a simple alternative to booting the basicWindows 7 system recovery tools from a CD, but it turned out to be easier to make a more powerful and flexible multiboot USB drive.  Now I had a larger (16GB) USB drive, and more stuff to put on it.  This post contains what I hoped would be a simpler and more comprehensive description of the process of setting up that kind of multiboot device.

USB Drive Setup

I started with YUMI and a bunch of ISOs, either downloaded or created with ImgBurn (see the previous post).  For now, the ISOs I wanted to install were the full Windows 7 DVD, the Windows 7 System Recovery CD, the full Windows XP SP3 CD, Ubuntu 10.10 and 12.04, Knoppix, Acronis True Image Home (ATIH) 11 and also ATIH 2011 with Universal Restore, Ultimate Boot CD (UBCD) and UBCD4Win, Balder FreeDOS, Hiren's Boot CD, BartPE, U.S. DOD LPS, Super Grub Disk, Super Grub2 Disk, MHDD, Microsoft Windows Memory Diagnostic, Memtest86+, Balder FreeDOS, Darik's Boot & Nuke (DBAN), Clonezilla, GParted, Partition Wizard, Parted Magic and diagnostic CDs for Samsung, Hitachi, Western Digital, and Seagate hard drives.  Some of these, I knew, were redundant.  I figured I would work out the details later; I was just curious to see how much would fit, and what would work, in the multiboot approach.

Some of those ISOs were already listed as distributions in YUMI.  That was true for Balder FreeDOS, Clonezilla, DBAN, GParted, Hiren's Boot CD, Knoppix, Memtest86+, Parted Magic, Partition Wizard, both flavors of Ubuntu, UBCD, and the Windows 7 installer.  For the others, there was an option at the bottom of the YUMI menu:  Try an Unlisted ISO.  Except for that last choice, using the option to install a recognized ISO would remove that ISO from the list, apparently to help people keep track of what had already been installed.

The ISOs that I had created from CDs, using ImgBurn, were not necessarily named properly. YUMI didn't recognize some of them until I renamed them to match the hint provided in YUMI. For instance, YUMI wanted the downloaded (still zipped, yet renamed to remove the ISO pre-extension) version of Memtest86+.

The installation process got interrupted partway through: I had to pull out the USB drive to use the jack for something else, and wound up killing YUMI and starting again. Neither Windows Explorer nor Windows Disk Management were able to see the drive at all when I reinserted it. This may have been due to not removing the USB drive properly.  I had to plug it into another computer, eject it from that computer, plug it back into the machine running YUMI, and kill and restart YUMI again, to get YUMI to see it again. At about the same time, I also noticed that YUMI would no longer make a program or other ISO (e.g., Ubuntu 12.04) available on its list, once that program was installed on the multiboot USB drive.  Also, YUMI now seemed not to be making any new files or folders on the USB drive, even though it was reporting that the various processes were completing successfully.  The ejecting and reinserting process also apparently fixed these problems:  now, as before, the programs already installed on the USB drive were no longer listed in YUMI, and I could see new things being added to the USB drive.

Windows Explorer seemed to tell me that the installation process was somewhat irregular, presumably due to the divergent demands of these various programs.  Many got their own subfolders, under the "multiboot" folder on the USB drive.  Hiren's Boot CD got its own folder on a higher level; UBCD was represented by just an ISO file in an "ISOS" folder on the USB drive; Balder FreeDOS seemed to have been installed as nothing more than a single file in the multiboot folder.

As noted above, I had to use the "Try an Unlisted ISO" option for a number of the programs listed above.  I used this, first, with the full Windows 7 DVD.  I decided to take this route, after first using the canned "Windows 7 installer" option because, as noted above, I was hoping to install several flavors of Windows.  When I used the canned installer option, the process took only a few seconds, suggesting that perhaps that option was just copying over the information needed for a system recovery approach.  But when I used the custom "Try an Unlisted ISO" option, YUMI indicated that it was copying 3 GB of material, and took several minutes to do it.

After installing Windows 7 on the multiboot USB drive, I used the Unlisted ISO option for the Windows System Repair CD.  That took only a few seconds.  The USB drive's ISOS folder now contained entries for both of those ISOs.  Same thing when I added Windows XP.  I proceeded likewise for the other unlisted programs noted above:  two flavors of Acronis, BartPE, MHDD, Microsoft Windows Memory Diagnostic, two varieties of Super Grub Disk, UBCD4Win, U.S. DOD LPS, and four hard drive diagnostic CDs.

I made some additional observations during these processes.  One was that the ISOs seemed to be copied verbatim into the ISOS folder.  It was possible that long filenames, or filenames containing spaces or odd characters, could cause problems for some programs.  In other words, looking ahead, I wondered whether it would have been to my advantage to rename some ISOs, at least temporarily, to something simpler.  During each installation, YUMI would report information of the following nature:

Creating Label MULTIBOOT on F:
Good Syslinux Exists...
A Previous Multiboot Installation was detected...proceeding to add your new selectio...
Copy to F:\multiboot\ISOS\Super Grub Disk.iso
Try an Unlisted ISO and its menu entry were added!
All Finished, Process is Complete!

Most of these processes took only a few seconds.  After all, these ISOs were mostly very small, containing just a utility program.  Instead of using the "Try an Unlisted ISO" option, I probably could have configured many of them as "Try an Unlisted ISO (Run from RAM)."  When I had finally worked through the foregoing list of programs to install and indicated that I was done, YUMI said,

YUMI has completed the installation.

Your Selections have been Installed on your USB drive.

Feel Free to run this tool again to Install more Distros.

YUMI will keep track of selections you have already Installed.

Windows Explorer > Properties indicated that the 16GB USB drive was now about 60% full (around 8.5GB used, out of 14.9GB actually available).  I exited YUMI, ejected the USB drive, put it into my laptop, and booted it.

Using the Multiboot USB Drive

When I booted the laptop with the USB flash drive (hitting Esc at the appropriate time to see the option of booting from that drive), I got the YUMI Multiboot USB screen.  It presented four options:  Linux Distributions, System Tools, Other Operating Systems and Tools, and Directly Bootable ISOs.  Under Linux Distributions, it showed me the two Ubuntus (10.10 and 12.04) and Knoppix.  So that part of the installation seemed to have worked.  Under System Tools, it showed me Clonezilla, DBAN, GParted, Parted Magic, Partition Wizard, Balder DOS image (FreeDOS), and Ultimate Boot CD (UBCD).  It had nothing under Other Operating Systems and Tools.  Finally, when I chose Directly Bootable ISOs, it said, "Launching GRUB," and then it showed me quite a list:  Windows 7, the Windows 7 Repair CD, Windows XP, two flavors of Acronis, BartPE, MHDD, four HDD diagnostics options (Hitachi, Samsung, Seagate, and Western Digital), Windows Memory Diagnostic, two flavors of Super Grub Disk, UBCD4Windows, and US DOD LPS.  Collectively, these items accounted for everything on my original list except Hiren's Boot CD and Memtest86+.  I wasn't sure how those had slipped through the cracks.

I decided I wouldn't be able to run all of these programs at this point.  But I did want to try a few.  I started off with the full Windows 7 CD.  It worked.  I was able to go into its repair options and run CHKDSK on an external USB hard drive.  (I had to skip past some dialogs in which Windows expressed its interest in repairing my system.  I was not surprised that it was confused by what it found, and there seemed to be a good chance that it would make a mess of everything as a result, if I let it go ahead.)

After running CHKDSK on that external drive, I exited Windows 7 via its Restart option.  That put me back at the point of hitting Esc and seeing the YUMI Multiboot screen again.  This time, I tried Ubuntu 12.04.  I was able to use its copy of GParted to scan the laptop's internal and external hard drive.  GParted found problems with the laptop's C partition, so I retarted from within Ubuntu -- which, again, restarted the computer hardware rather than putting me back at the YUMI Multiboot screen, as might have happened in a virtual setup.  This time, I chose the Windows 7 System Repair CD, rather than the full Windows 7 DVD, and I was able to use that to run CHKDSK.

Next, I wanted to defragment the laptop's internal and external hard drives.  Of course, I could do that from within Windows after a normal boot, but it occurred to me that I didn't actually know, or recall, whether there were any defrag tools that could run from a non-Windows boot -- and, if there were such tools, I didn't know whether they would be included in any of the ISOs that I had installed on the Multiboot USB drive.  One thread indicated that Ubuntu, itself, did not have an NTFS-compatible defragger that would be advisable for use on an NTFS partition, especially on drive C, with the possible exception of ntfsfix.  So I looked instead at UBCD.  It seemed to be working -- its System Speed Test ran, producing a processor benchmark and other information -- but it did not seem to have anything for defragging, and it exited awkwardly, requiring a Ctrl-Alt-Del reboot.

BartPE appeared to have plugins that would defrag, so I tried that.  BartPE began to load, but then gave me a BSOD, requiring a hard reset.  That problem recurred on the second try.  BartPE did not seem to work, at least for purposes of this particular laptop.  It gave me a BSOD with STOP error code 7B.  As I watched it start to load, I was reminded that it used Windows XP, so I tried the Windows XP SP3 option from the Multiboot USB drive.  That gave me an Error 27 ("unrecognized command") in response to this command, apparently contained in the Multiboot CD:

find --set-root --ignore-floppies --ignore-cd /multiboot/ISOS/Windows XP SP3 Slipstreamed.iso

I was not able to determine whether the laptop would have accepted a CD in place of the USB drive, for purposes of booting WinXP, because I had no internal or external CD drive to try it with.  I could have tried a single-purpose USB drive containing only Windows XP, but at this moment I had insufficient time and interest to play with that.  My operating conclusion for the moment was that WinXP (therefore BartPE) did not work with this Multiboot USB drive on this machine.

Moving on, I looked to see if UBCD4Windows might have a defragger.  I noticed, in passing, that UBCD4Win contained a copy of DBAN (as did, I think, UBCD), so (if it worked) apparently I did not need to put a separate DBAN install on the USB drive.  UBCD4Win also had FreeDOS.  These options were available from its initial menu, and it appeared that I could add more.  I went into its menu option that would load UBCD4Win per se; I noticed, once again, that it relied on WinXP; and once again I got a BSOD.   As with BartPE, the STOP code was 7B.  A quick look at one troubleshooting guide seemed to indicate that WinXP and these other programs that used it (i.e., BartPE and UBCD4Win) might be failing to load updated drivers for the hard drive controller.  Another thread suggested going into the laptop's BIOS during bootup (F2 on my machine; DEL on some others) and changing the SATA setting from AHCI to Compatibility Mode.  I didn't seem to have exactly that option.  I did have one that was set as IDE->AHCI; I tried changing that to Native IDE.  It occurred to me, as I was doing that, that possibly I wouldn't be having this problem if I weren't trying to boot with the external USB hard drive connected; I had noticed that doing so tended to stall bootup on one of my desktop computers too.  Anyway, the AHCI change didn't help, and neither did booting with the external USB hard drive disconnected.  End of troubleshooting attempt.

I hadn't thought to verify whether the Windows 7 System Repair CD had a defragger.  I tried that now.  "DIR /S DEFRAG*.*" led to C:\Windows\System32\defrag.exe.  I tried it as "DEFRAG /C /H /M /U /X," but that didn't work.  It worked without the /M.  Apparently there was no "background" in the system repair mode.  (For details, type "DEFRAG /?")  So, OK, I did have an NTFS defragger on the Multiboot USB drive after all.  Only later would it occur to me that, by using the /C option, I might be asking the program to defrag the USB drive as well.  That concern faded, however, as the defragmentation went on . . . and on . . . and on.  Granted, defragmenting a fragmented 2TB drive can take a while.  And it did.  It took days.  I was not sure whether a Windows-based defragger would have taken just as long.  I had observed some pretty leisurely defragging operations from time to time.  But this was really a slow boat to China.

When the defragging was done, I decided to try running hard drive diagnostics.  The external USB hard drive was a Samsung.  When I tried to run the Samsung diagnostics that I had added to the Multiboot USB drive, however, I got the same "find --set-root" error as quoted above, except in this case it was referring to the Samsung HDD Diagnostics ISO, not the Windows XP ISO.  Basically, though, by this point it seemed that a lot of problems would be solved if they, or I, or someone could work through all the steps needed to make a Windows XP CD work on this USB drive.

And that's where I left it for now.  I had much of what I needed for the laptop on this one USB drive.  Until they improved Yumi and/or until I was able to troubleshoot the problems, I could perhaps get other ISOs to run from single-purpose USB flash drives apart from this multiboot one.  Despite the imperfections, these little devices had come a long way.

Windows 7: Assigning Process Priorities to Prevent Slowdowns

I had some programs that slowed down my system to the point that I could barely get any work done.  Examples included Beyond Compare (sometimes) and GoodSync (often).  These programs were not usually urgent; I would have been happy with letting them run at a slower pace, so that I could continue to use the machine in a more or less normal way.  This post describes my search for tools that would give me some control over the demands that those programs would place on my system.

The existing tool for this purpose, Windows Task Manager (available via Ctrl-Alt-Del > Start Task Manager, or via Start > Run > taskmgr.exe), would give me information about various processes.  Many other programs -- including various gadgets and other sorts of monitoring tools -- offered that.  A search led to Process Explorer and System Explorer Portable, which CNET and Softpedia portrayed as popular, highly rated replacements for Task Manager.  For basic system resource information, I was presently using (and liked) Moo0 SystemMonitor, and wasn't too interested in adding more of that right now.

What I was more interested in was actual control of processes.  Evidently it was possible to adjust process priorities manually in Task Manager, and perhaps in Process Explorer and/or System Explorer Portable; but it seemed that this would work only as long as processes were running. In other words, it seemed that the Task Manager manual setting would have to be recreated every time a program was shut down and restarted.

Further investigation led to utilities that would apparently allow me not only to adjust priorities, but to have my adjustments be remembered.  Programs I encountered at this point included Prio, Process Lasso, IO Priority, and Process Hacker. Softpedia searches indicated that Project Lasso was commercial, and had nothing for IO Priority.  I had seen a few very positive comments about Prio, so perhaps it was up and coming; but it was not a major player at either Softpedia or CNET. Those two sources also disagreed as to whether I was getting a free or trial version.  On both CNET and Softpedia, Process Hacker seemed to be the leading tool for process adjustment.

The CNET download gave me both .bin and .exe versions of Process Hacker.  I was more interested in a portable version, so I unzipped the .bin and drilled down to the appropriate .exe and ran that.  It gave me a colorful, hierarchical indication of running processes.

I decided to put it to a test.  I ran GoodSync and did a Ctrl-F in Process Hacker.  That gave me a separate list of files, processes, and threads that apparently involved GoodSync.  But where was GoodSync within the pretty list of colored processes, there in the main Process Hacker window?  I clicked on the Description heading, and that gave me an alphabetical list.  Ah, there it was.  GoodSync was currently using up to 3%, no, 5%, no, make that 10% of CPU resources.  The number kept rising.  In the amount of time it took me to write these words, it was up to 25%.  I had a quad core processor; maybe 25% was going to be the limit.  I clicked to sort on the CPU heading.  At first, GoodSync was solidly in second place as the greatest consumer of CPU resources, behind System Idle Processes.  It seemed that the latter just meant that I had a lot of idle capacity.  That seemed to be the message from Moo0 too:  the CPU was not very busy.

Process Hacker also said that GoodSync was using a steady 468MB in Private Bytes.  A StackOverflow post said that private bytes was "the current size, in bytes, of memory that this process has allocated that cannot be shared with other processes."  Another post in that thread clarified:  this value included pagefile (i.e., virtual) memory.  So it didn't necessarily mean that GoodSync was using almost a half-gig of what the RAM chips in my computer could offer.  The thread seemed to say that the most important value of that number was in whether it was growing, which would indicate a memory leak -- which apparently meant that the program in question kept asking for more and more memory, without reusing or returning what it had already requested and was no longer using.  This didn't seem to be a problem:  the Private Bytes number for GoodSync had not yet risen beyond about 480MB.

I clicked on the I/O Total Rate heading in Process Hacker.  It put GoodSync by far at the top of the list, using 22 mB/s (with variations), when the next most disk-intensive programs were generally asking for less than 20 kB/s.  This concurred with Moo0 -- it was tending to show GoodSync as the chief loader of the hard drive -- but this was giving me much more information about how GoodSync compared to the other programs running.  (I was working in the Processes tab in Process Hacker.  There were also Services and Network tabs.)  I also noticed, by this point, that the Private Bytes number did seem to be creeping upwards, now reaching 520MB.  I wondered where it would be in an hour or two.

So now, could I put the brakes on GoodSync?  I right-clicked on it, there in Process Hacker, and saw at least three relevant options:  Terminate, Suspend, and Priority.  Of these, the only one that would put on the brakes without completely ending progress was Priority.  That one was familiar; I had seen the same options elsewhere, probably in Task Manager.  The options were Real Time, High, Above Normal, Normal, Below Normal, and Idle.  Normal was the default.  I had seen somewhere that Normal was the default for everything in Windows.

So, sad to say, this thing wasn't going to give me fine-tuned tweaking options, like "40% of Normal" or "Run only when computer is idle" or "Try to finish this process by tomorrow morning."  I realized that not all of these possibilities might be feasible in Windows 7.  And, wow, what about RAM?  GoodSync was up to 905MB of Private Bytes now.  For that matter, Internet Explorer (where I was writing this) was at 870MB (with eight tabs open, and after 50 hours of uptime, according to Moo0).  I was using RizoneSoft MemoryBooster to keep RAM available, but it didn't have options to put restrictions on individual programs, and hitting its Optimize Memory button at this point didn't have any effect upon the Private Bytes reported by Process Hacker for GoodSync and IE.  I guessed that the situation was that memory leaks couldn't be squeezed much -- that you might basically have a choice between letting the program run or shutting it down so that memory could clear.

I dimly recalled that GoodSync might have its own internal option to throttle itself.  A look at this point reminded me:  its Auto > General tab would allow a specific sync job to slow down file copying if the average download speed exceeded a certain value.  I wasn't quite sure how that would work, but I didn't think the problem was with the speed of downloads (i.e., how quickly they would travel across the ethernet cable between computers).  What seemed most demanding about GoodSync was its use of system resources to do its calculations of what needed to be copied.  In other words, I didn't care whether it was slowing me down because of calculations, or downloads, or for some other reason; I just cared that, overall, it was slowing me down.  And at this point I was not seeing anything specifically geared toward that.  And even if I had, I'd still have a similar concern for some other programs.

Further exploration in Process Hacker indicated that I had overlooked another possible location of options.  I right-clicked on the Process Hacker line for GoodSync and chose Miscellanous.  There, I saw at least three intriguing options:  I/O Priority, Page Priority, and Reduce Working Set.  I decided to see what would happen if I changed a bunch of settings to their minimum values.  So I changed GoodSync right-click Priority from Normal to Below Normal.  I didn't see any difference, there, between Below Normal and Real Time (the highest setting).  On, then, to Miscellaneous > I/O Priority.  It was set to Normal; I set it to Very Low.  Still no obvious difference in the demands on CPU, I/O, or Private Bytes shown in Process Hacker.  Next, Miscellaneous > Page Priority.  It was at 5 (the highest possible value); I set it to 1.  Finally, Miscellaneous > Reduce Working Set.  It was just an on-or-off option.  I turned it on.  No visible difference in the numbers.  I decided to turn off Reduce Working Set, putting it back to its default setting, since I didn't know what it was.  Seems I was wrong:  it wasn't a checked, toggling option; evidently I was just reducing the working set further (whatever that meant) every time I hit it.

Well, by this point, as a correction to my impression from a moment earlier, it seemed that something had changed after all.  (It helped to see this when I changed Process Handler > View > Update Interval to a slower setting.)  Maybe this change was due to my adjustments to the settings, or maybe GoodSync had finished something it was working on, but for whatever reason it had dropped from an I/O Total Rate of 20+ mB/s to more like 3 mB/s.  I suspected that I had now given myself the equivalent of an option to "Run only when computer is idle."  With all these priorities set so low, hopefully the computer would suppress GoodSync when I had other things to do.  The risk now was, no doubt, that GoodSync would never finish its tasks.  I would have to just let it run a while and see how that went.

After closing Process Hacker and letting a few days pass (along with a reboot or two), I returned to see what was happening with GoodSync.  The system had now been up for a little over two days, and at this moment the spinning system tray icon showed that GoodSync was actively at work.  PH showed GoodSync as having 1.14GB in Private Bytes allocated to it.  Its I/O Total Rate was not exceeding about 1.5 mB/s.  It looked like my settings had persisted.  I was not actively using that machine at that point, so I couldn't say whether there would still be noticeable slowdowns.  But it seemed unlikely.  Moo0 was reporting that the CPU, RAM, and hard drives were almost never fully burdened.  And yet GoodSync did seem to be getting its tasks done.

I was not quite sure whether Process Hacker right-click settings all applied only to the specific process that I had clicked on.  Some appeared to apply to all, or at least multiple, processes.  There was more to learn.  But at least it did appear that Process Hacker had enabled me to slow down a program that was grabbing too much of system resources, without noticeably impairing that program's functioning.

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.

Saving Disk Space; Finding Types of Files to Shrink

I wanted to save drive space.  The first line of attack was to use a freeware program to find large files.  Among the various possibilities, WinDirStat, TreeSize, and SpaceSniffer seemed to be the most positively reviewed and/or familiar to me.  Among those three, TreeSize and WinDirStat used a directory listing to indicate the largest folders, while SpaceSniffer and WinDirStat used a graphic approach to highlight large individual files.  In other words, WinDirStat offered both.  The graphic approach led me to multiple space-saving solutions faster than the TreeSize approach.  Between the two graphic progams, I found SpaceSniffer's graphic presentation more readable and zoomable than that of WinDirStat, except that WinDirStat made it easier to tell, right from the start, whether a folder was large because it had many small or few large files.  SpaceSniffer also offered a full right-click Windows Explorer context menu, while the right-click options in WinDirStat were more limited.

This sort of program was good for quickly locating large space hogs.  The concept, which I pursued to some extent, was that you would probably free up the most space most quickly by homing in on very large files or folders.  But once I got past the point of being impressed by the graphics, I noticed certain drawbacks.  One was disorientation, especially in SpaceSniffer:  its method of zooming in on a particular folder was not the exact opposite of its method of zooming out.  It seemed like I was coming out by a route different than the one I had gone in on.  So it could be hard to build an intuitive sense of where you were located, with respect to the drive or directory as a whole.  Another drawback was that I could not compare across partitions.  I had to back out and start over, or run a different session of the program, to see clearly that I should be focusing on one drive rather than another.  Another missing dimension of coherence:  file type.  I might never know, from looking at the graphic maps, that I was consistently making PDFs or JPGs that were larger than they needed to be.  Even a grossly large PDF could escape notice when nestled among AVIs ten times its size.  There was also no logging or comparison capability that might alert me to the fact that a certain folder had been growing more rapidly than I would have expected -- or, for that matter, that a certain folder had disappeared since the last time I ran the comparison.

I thought that I might be able to capture the chief benefits of these programs -- that is, their ability to draw attention to large files -- while also adding at least some of those missing ingredients (though admittedly I could not compete with their graphics).  What I wanted, for this purpose, was a simple file list that I could sort according to selected criteria, particularly folder size, file date, file size, and file extension.  This approach seemed likely to require a much larger time investment up front; but once I had the file list, it seemed I would be able to do quite a bit of analysis and revision of files and processes, so as to root out a variety of kinds of disk space waste.  In short, I was seeking a systematic approach that would minimize my preoccupation with the same few large files (which may have had to remain large for good reason), turning my attention instead to other areas where I could make an impact on drive bloat.

The approach I took was to develop a somewhat automated method of generating a list of files across multiple partitions, and then put that list into a spreadsheet.  It took some work to figure out a way to automate the production of a file list that would work simply in a spreadsheet.  The problem was that simple batch commands, with which I had some familiarity, did not want to put all relevant information about each file on a single line.  (While I was particularly interested in the full path, file size, and date, others might have wanted to draw on some other available types of file information, such as file attributes.)

As described in another post, I found the desired solution by installing TCC/LE and running its PDIR command in a batch file. This operation required two parts. First, I had to work up the command that I would run to make everything happen. This command would start TCC/LE and would tell it to open a batch file. To find where TCC was, I used the Properties > Target path I found in a right-click on its Start Menu icon. To see if this would all work, I generated a little batch file called Test File.bat. Then I ran this:

"C:\Program Files\JPSoft\TCCLE13x64\tcc.exe" "D:\Current\Test File.bat"

It worked. Test File.bat ran. So I went ahead and replaced the second part of that command with the name and location of the real batch file that I wanted to run. I called it ListAllFiles.bat, and I put it in a permanent location with other batch files that I would run for various purposes. (For the moment, it was an empty file, but that would change momentarily.) I also made a copy of the Start Menu shortcut that would run TCC. I modified that shortcut's Properties so that its Target line contained the information just described: the path to tcc.exe, and then the path to ListAllFiles.bat, each in quotation marks as shown in the line quoted above. Now I could double-click on that icon to make TCC run ListAllFiles.bat, instead of having to look up the proper command syntax. Once that was done, I just needed to make sure ListAllFiles.bat said what I wanted. I was still working on that, but for now it looked like this:

@echo off
cls
echo.
echo For cleanest results, empty the Recycle Bin before proceeding.
echo.
pause
cls
echo.
echo Notepad may take several minutes to display a large list.
echo.
echo Be patient ...
echo.
:: PDIR requires TCC/LE to be installed

pdir D:\ /s /(dy-m-d zc fpn) > "D:\Current\List of All Files on D and E.txt"

pdir E:\ /s /(dy-m-d zc fpn) >> "D:\Current\List of All Files on D and E.txt"

start notepad.exe "D:\Current\List of All Files on D and E.txt"

exit

The last four lines (double-spaced for clarity, in case the blog wraps them) were where the action was; everything before that just displayed a few informational notices and a comment about PDIR that would not be visible when the batch file ran. I opened the resulting text file, "List of All Files on D and E.txt," in a LibreOffice Calc spreadsheet, since LibreOffice (alternately OpenOffice 3.3) could accommodate a large number of rows. When I did that, LibreOffice Calc detected that it was a text file and defaulted to LibreOffice Writer, but I just copied and pasted from there into Calc. I told it that the imported text had fixed-width columns, and I pointed out where those columns were.  LibreOffice Calc crashed repeatedly during this process -- I had to remember to save frequently -- but in the end it came through.

So I had my table. I added a column to display the extension, extracted it using the RIGHT function (using different values to extract extensions of different length, e.g., .html, .px), and saved the extension in an adjacent column (i.e., undisturbed by those calculations of varying extension length).  I added a column in which I could record the date on which I had last examined the file to see whether it was currently feasible to shrink it, and another column for notes.  For instance, I had a 6GB zip file that I couldn't get into right now, because there were things I needed to do and learn before I would be ready for the project that its opening would commence.So I added that "Last Examined" column.  For purposes of making a first pass through the files, I could filter out that one, among many others, as not being of further concern right now.

Now that the spreadsheet was ready, I could do some file sorting.  First, I sorted by date, and also by extension, to find any files whose name or other properties might need to be adjusted, perhaps with the aid of a relevant utility (e.g., SetFileDate, TrID).  Then I sorted by file extension.  I added a Flag column to the spreadsheet, to indicate files that would be worth looking at, to see if I could possibly shrink them.  I put an X in the Flag column for each AVI file.  I suspected that, with or without editing, most AVIs could probably be converted to MP4 or some other more compressed format that would retain about the same apparent quality for a fraction of the space.  Likewise for BMPs (most could probably be JPGs) and WAVs (many could be converted to MP3).  I also flagged all ISOs, which I probably didn't need to keep, and all ZIP (and RAR and 7z) files, because they could hold a lot of unnecessary stuff somewhat removed from notice.

Next, I sorted the spreadsheet in order of declining file size, and flagged all files larger than 500MB.  Within that sort, I filtered for common image extensions (including PDF as well as JPG and PNG) and flagged all files larger than 100MB.  I could see that these steps were going to draw attention to whole folders full of files.  For example, I noticed a folder of mixed MP3 and WAV files, all of which could have been MP3s.  In that instance, I suspected I would probably wind up converting the whole folder at once.

I figured I would probably refine this approach, if I went back through it again sometime in the future.  But for right now, these steps resulted in the flagging of about 9% of the total number of files on these partitions -- and those 9% accounted for about 60% of disk usage.  I probably wouldn't have time to work through all of those files individually.  But identifying a few major categories of unnecessarily large files did seem likely to yield some reductions in disk usage that I could achieve through mass conversions and other relatively simple steps.  Finally, while I had concluded that I liked LibreOffice Calc -- it had pretty much stopped crashing as I got more familiar with it, thus probably making fewer finger fumbles -- the focus on just 9% of the files gave me a list short enough to handle in Excel 2003.

ASUS Eee PC: Booting from USB: Second Cut: Ubuntu

I had previously done a lot of flailing around, in an effort to boot an ASUS Eee PC from a USB thumb drive (a/k/a USB stick, pen drive, jump drive, flash drive).  It was time to try again.  This time, there seemed to be some easier and more promising avenues of attack.  This post describes this renewed effort, with a particular focus on booting Ubuntu 11.10.

First, the basics.  In the BIOS Setup Utility, I had set my BIOS to boot first from the USB drive.  I got into the BIOS setup by hitting F2 repeatedly while the the Eee was booting.  I already knew that F2 or Del tended to be the keys to hit, on various computers, if I wanted to go into BIOS setup.  But if I hadn't known that, it would have been wise to get into BIOS somehow and change a certain setting, so that instructions and information would come up onscreen while the computer was booting.  The setting to change for that purpose would logically have been in BIOS Setup > Boot > Boot Settings Configuration > Quiet Boot > Disabled.  But that was greyed out and already set to Disabled on my machine, and yet I wasn't getting those boottime instructions.  The answer was to go, instead, into BIOS Setup > Boot > Boot Booster > Disabled.

With that done, I was all set to reboot the Eee and see, onscreen, the information that I should hit F2 to run Setup.  If it went by too quickly, I could hit Pause (note that, on the Eee, Pause was actually Shift-Pause).  For some reason, I had to hit it twice to make it pause.  Maybe I had bad timing.

I wanted to go into the BIOS Setup, for purposes of booting with the USB stick, in order to tell the computer to boot, first, from the USB stick.  If I didn't do that, it would default to booting from the CD drive (nonexistent, in my Eee) or from the hard drive.  The place to make this change, in BIOS Setup, was at Boot > Boot Device Priority.  The item that needed to be first on the list was "Removable Dev."

Now I was ready to boot my bootable Ubuntu USB stick.  Problem:  I didn't yet have one.  For this, I needed a 4GB USB drive (possibly smaller but not, I think, any larger) with Ubuntu installed on it.  To install Ubuntu on the USB drive, I went to the Ubuntu download webpage, downloaded the Ubuntu 11.10 ISO, and followed their instructions to install it onto the USB drive.  Their instructions were just to download and run the Universal USB Installer from Pendrivelinux.com.  That installer was, itself, a portable program -- no installation needed.  When that installer was running, I needed to select Ubuntu Desktop Edition and follow the instructions.

So I had done that, and therefore I had Ubuntu on my jump drive.  And the Eee was seeing the jump drive when I booted it -- I could see a brief flash of recognition, onscreen, before the stupid thing went ahead and booted into Windows as usual.  This was probably about what I had managed to achieve last time I had tried this.

But, as I say, there were new suggestions and possibilities.  One was that I should have put Eeebuntu rather than Ubuntu Desktop onto that USB drive.  The idea was that Eeebuntu was designed to make it as easy as possible to get Ubuntu working well on an Eee.

To be precise about it, some of the players had changed.  By this point, according to Wikipedia, Eeebuntu had become Aurora.  And, for that matter, Ubuntu Eee (apparently not the same as Eeebuntu) had become Easy Peasy, and Ubuntu Netbook Edition had been merged into Ubuntu Desktop.  A Wikipedia comparison table suggested that there were multiple kinds of netbook-oriented versions of Ubuntu:  some were designed for netbooks generally, some for ASUS Eee netbooks, some for specific kinds of ASUS Eee netbooks, and some for other portable devices (e.g., smartphones).  It made sense to get one designed for an Eee, so at the moment it seemed that an Aurora download (either the promised Gnome edition or one of the original Eeebuntu versions) might provide the road to the future, if I did need to try some other Ubuntu version on that USB drive.

I did not need to do that because, for me, the solution was simpler.  Before I got very far into this project at all, as advised, I tried hitting Esc when I booted, so as to bring up the boot menu.  That gave me an option to boot from the USB drive.  And it worked.  I didn't know whether this would address all of the needs and interests that had prompted me to try booting other programs (e.g., Hiren's, XBoot, Grub4DOS) in my previous try.  But for the moment, I was happy.

Windows 7 CHKDSK /R: Corrupt MFT: False Alarm

I was using Windows 7.  I rebooted with the Windows 7 program DVD, went into the System Recovery Options, and selected Command Prompt.  At the prompt, I checked each partition on my drive with CHKDSK /R.

There were five partitions.  For the first two, no problem.  On the third one, CHKDSK ran into problems partway through.  I don't remember the exact problem or wording, but as I recall it happened in the first of the five stages of partition checking.  It would give me an error message after getting partway through, and then quit.  I ran it again and noticed that it seemed to be progressing further through the partition, so I kept running it.  Once or twice, it seemed to regress, but I figured it was cleaning up something from the previous round.  Eventually it did complete the partition check.

So I moved on to the fourth partition.  Now, however, I got an error message.  I didn't write it down, but according to the multiple webpages I consulted for information on how to resolve it, from a Google search, the message was something like this:

Corrupt master file table. Windows will attempt to recover master file table from disk.

Windows cannot recover master file table. CHKDSK aborted.

And it wasn't just on that one partition.  I was now getting that error message on every partition on that drive -- including the ones that had just passed CHKDSK with no problems -- but I wasn't getting any such message on the other drive that I had in that computer.

If I hadn't made a backup just before running CHKDSK, the suggested solution would apparently have been to try recovering my data with something like TestDisk.  But before doing that, or wiping the drive and recreating my partitions and restoring the data from backup, I took a look with GParted, which I usually ran by booting from an Ubuntu live CD.  It didn't see any problems.  I rebooted with the Windows 7 CD and ran CHKDSK /R again.  Now it didn't see any problems either, on any of the five partitions.  So wiping the drive and recovering or restoring data would apparently have been unnecessary.  I wondered whether the process of retrying multiple times (or the condition that made it necessary to retry) on that third partition had somehow confused CHKDSK or my drive.

I hadn't experienced this before.  Possibly it was something unusual about my Windows 7 DVD, or about that particular bootup.  Another possibility was that maybe I should not have been running two separate sessions of CHKDSK at the same time.  That is, the System Recovery Options dialog would let me keep clicking on the Command Prompt option to open additional windows.  (I used Alt-Tab to switch between them.)  So I was running CHKDSK /R in each of two separate command windows.  I had one session working on the partitions on the first drive, and the other session working on the partitions on the second drive.  I figured they were independent of each other.  I had done this before without a problem, but only once or twice.  This time, the problem had emerged only in the second command window.

Was that the cause of the problem?  It seemed that I'd have to wait until the next time I ran CHKDSK /R to see if I got the same issue again.  At present, the solution seemed to be that, if I got that weird crashing in the first stage of disk checking, or if a partition that had just passed CHKDSK was now being reported as corrupt, I should just reboot and take another look, using either GParted or the Windows 7 DVD.

ASUS Eee PC: Booting from USB: First Cut

I needed a way to boot an ASUS Eee PC with Windows 7 installed.  The mission was to look at, and possibly replace or delete, a certain file in a particular directory on the Eee's drive C.  The Eee didn't have a CD/DVD drive, so it seemed that what I needed was a bootable USB drive with file management capabilities.  I knew the Eee was capable of being booted that way, because I had already successfully booted it with USB drives containing Acronis True Image and GParted.  Unfortunately, I had not succeeded in previous attempts to boot Ubuntu or some other program or operating system, so as to examine files and folders.  This post describes some more attempts along those lines, oriented specifically toward getting various programs to boot an Eee from a USB drive.

Hiren's Boot CD

More than a year earlier, I had made a similar attempt related to Windows XP.  In that attempt and previously, I had become familiar with various bootable USB jump drive packages, including the Universal Boot CD for Windows (UBCD4Win) and BartPE.  It now appeared that Hiren's Boot CD (HBCD) was an especially good option.  I noticed that it included DBAN, GParted, and other tools that I would like to have on a bootable USB thumb drive.  Following the instructions provided by Hiren and Pankaj (as also shown, somewhat confusingly, on a different website I found later), I took these steps:

1. I plugged in my USB flash drive -- 4GB, though they said 512MB was sufficient.  I suspected that a drive larger than 4GB would fail due to their use of FAT32 formatting.
2. I downloaded and ran their USB formatting program (changing no settings).  Then I downloaded and ran their grub4dos program as Administrator.  The device I selected was a Disk (not File).  It was a 4GB USB drive, so on my system that was hd3, which they described as "3851M" (i.e., not quite 4,000 megabytes).  I clicked Refresh next to Part List and selected Whole Disk (MBR).  I clicked Install.
3. I downloaded the Hiren's BootCD zip file.
4. I unzipped the BootCD zip file and found that it contained an ISO.  I didn't want to burn a CD in order to proceed with the next steps, so I tried using Virtual CDROM to position that ISO as a virtual CDROM drive. Specifically, in VCD, I clicked Mount, navigated to the ISO, selected it, and clicked OK. The mount failed.  I saw that Virtual CloneDrive (VCD) seemed to be more frequently downloaded, so I tried that.  When I started it, it gave me only a few options.  I adjusted those.  Now I had an icon in the system tray.  I right-clicked on that and got an option to mount drive G, which Windows Explorer was now showing as "BD-ROM Drive."  That opened up a dialog.  I navigated to the ISO.  That seemed to work.  The HBCD instructions said to copy everything from the mounted ISO to the USB flash drive, so I did.  There was some flaky behavior here:  at one point I basically had to restart Windows Explorer to see the contents of the mounted ISO again, but in the end I was able to copy those contents to the jump drive.

With those steps done, I plugged the USB drive into the Eee and rebooted.  I had to hit F2 repeatedly when it first started booting, because I had learned it did not remember boot settings.  I set the USB drive as the first drive to boot.  The USB stick did not boot.  The relevant error message seemed to be, "Cannot find GRLDR."  In other words, the grub4dos step seemed to have failed.  I looked at the directions and tried again.  This time, I skipped the formatting step -- the drive was already formatted -- and went directly to the grub4dos step presented on the alternate HBCD webpage that I had more recently discovered.  But everything seemed the same.  I tried booting the Eee again with the USB stick.  Same result.  I looked at the HBCD FAQs page.  It said this:

If you are getting GRLDR error, or if usb booting is halting with a blinking dos window, or if you are facing with smilar situations, try using syslinux to boot grub4dos. To do that, download syslinux.zip (145 KB), extract its contents, run ‘RunMe.bat’ inside of the extracted folder and follow its steps.

Oy.  But, OK, I downloaded and unzipped syslinux.zip and clicked on its RunMe.bat file.  It did copy files to the USB drive, as promised.  Now what?  I tried booting the Eee with the USB stick again.  That definitely worked.  I was now looking at a GRUB4DOS menu that listed a half-dozen programs.  Unfortunately, none of them was HBCD.  I tried a Google search for info on the HBCD "cannot find GRLDR" error.  Got a couple dozen hits, mostly in Vietnamese.  Bizarre.  I didn't like Bing, but an equivalent Bing search didn't have that problem.  Regardless, I didn't see a solution.  Back at one of the HBCD instructions pages, I noticed that they said I should have run grub4dos as Administrator.  I hadn't done that.  I was already logged in as Administrator, but maybe that wasn't sufficient.  I right-clicked on grubinst_gui.exe and clicked Run as Administrator.  That brought up the same Grub4Dos Installer dialog as before.

I went through the steps again.  In the process of abandoning the one HBCD instruction page for the other, I had also overlooked another step:  "Copy grldr and menu.lst (from HBCD folder) [actually found in the grub4dos\grub folder] to the usb drive."  I did that now.  The menu.lst (that's MENU.LST, with an L, not MENU.1ST, with a one) file overwrote the one that syslinux had placed on the USB drive.  I wasn't sure how this was going to work:  I hadn't removed syslinux from the USB drive.  But I gave it a try.  This time, I got a somewhat longer Grub4DOS menu.  Unfortunately, I didn't see most of the tools that had interested me originally; and after a moment, the computer went ahead and tried to load Windows 7, even though I had not to my knowledge issued any command of that sort.  I rebooted.  It seemed I must have left the cursor sitting on the option for "Custom Menu ... (Use HBCDCustomizer to add your files)," because that one was ready to boot automatically in just a few seconds.  Hitting Enter on that item opened a longer list.

What I wanted, in the particular situation, was something like Ubuntu, with which I could use a GUI to change files in a particular folder on the Windows 7 programs drive C.  I decided to try Eeebuntu 3.0.1 Netbook Remix.  It gave me an error message, and within 10 seconds I was back at the Grub4DOS menu.  I tried Ubuntu 10.04 Netbook Remix.  I tried Ubuntu 10.04 (GNOME Desktop x86).  All of these were giving me "Error 15:  File not found."  They seemed to be trying to load an Ubuntu (or whatever) ISO.  Was I supposed to have that on a separate USB drive, also plugged into the netbook?  I tried Eeebuntu again.  It seemed to be looking for eeebuntu-3.0.1-nbr.iso.  A search led to Aurora and Wikipedia webpages indicating that Eeebuntu 3 was based on Ubuntu 9.04, which at this point was two years old and outdated in a number of ways.  I wasn't that much more excited about the HBCD option to load Ubuntu 10.04, also a year old.

I had been thinking, or hoping, that HBCD would somehow miraculously combine all those dozens of CDs on one USB stick, but now that was just not materializing.  If I was going to be using HBCD just to boot Ubuntu, why not have the latest Ubuntu on a stick?  Make it simpler and more up-to-date.  I went to the Ubuntu download webpage and noticed that they were providing instructions that simply involved the Universal USB Installer and a downloaded Ubuntu ISO.  I ran my copy of Universal USB Installer and saw that it was willing to install Ubuntu 11.04 on a stick.  I was about to proceed with that, but then I wondered whether some other Linux distribution would be better for the Eee.  A search led to one webpage in which some people said that plain old Ubuntu was fine.  Another webpage suggested Leeenux.  I was familiar with Ubuntu, so I decided to try that (again).

When I had pretty much settled on the approach of using Universal USB Installer to download and install the ISO on my USB drive, it occurred to me that the advantage of HBCD was that I could have a bunch of ISOs on a companion USB drive, and could boot them all with the HBCD USB drive.  In this concept, I couldn't do it all with one drive, but I could do it with two, especially now that USB drive capacities were increasing:  my second USB drive could hold a dozen ISOs.  I revisited the option, presented in HBCD, of using HBCD Customizer (above).  I was thinking this might be a way to run Ubuntu 11.04 among others.  Thing is, I couldn't find it.  I didn't want to download it from just any random webpage -- it could be virus-ridden -- but it seemed like WOT-banned sites were featuring it.

XBoot

Another search led to some indications that the UBCD4Win was also customizable, so I turned to that possibility.  This search seemed more promising.  On closer examination, though, it appeared that creating this device required a Windows XP CD.  I had one, but others might not.  That requirement would also presumably have prevented me from using it to install Ubuntu.  So I turned to its cousin, UBCD (not for Windows).  A search led ultimately to Pendrivelinux.com, where I discovered XBoot, which was yet another possibility (along with YUMI and the Linux-based MultiSystem. The XBoot instructions required me to download the latest XBoot as well as the other ISOs that I would want to use.  I decided to start with ISOs for GParted, Ubuntu 11.04 (which, as I recalled, would not automatically contain GParted), Darik's Boot & Nuke (patched for XBoot), and Acronis True Image Home.  I had purchased a copy of Acronis, and would have been glad to recommend a freeware alternative, but I wasn't immediately finding one with an ISO.  There would probably be other ISOs I would want to add later, but this would do for now.  I wasn't as interested in some of the programs that were supposedly included in Hiren's Boot CD, for instance, because I was keeping a copy of my customized Start Menu (containing portable applications) on a separate USB drive, and many of the programs included in Hiren's were already on that Start Menu.  Many of those programs required an operating system (especially Windows) to be booted already, so I wasn't sure how or why I would be using them on a multiboot USB drive, though of course it could be handy to have everything on one large USB drive.

So anyway, I downloaded, unzipped, and ran XBoot.  It was a portable, which was nice.  I had created a folder for the four ISOs mentioned in the previous paragraph (i.e., GParted, Ubuntu, DBAN, and Acronis), so now I just dragged those ISOs over and dropped them on the XBoot program.  The instructions seemed to say I was supposed to do something with the QEMU and Edit MultiBoot USB tabs, but I couldn't quite figure it out.  I decided to start simply, by clicking the Create USB button on the first (Create Multiboot USB/ISO) tab.  This brought up a dialog giving me the options of using Syslinux or Grub4dos as my bootloader.  They recommended Syslinux, so I went with that.  The dialog automatically identified my USB drive.  XBoot then seemed to be copying my ISOs to the USB drive.  When it was done, it said, "USB created successfully!!  Check by running it on QEMU?"  I wasn't sure if that meant it was going to reboot the system into the QEMU operating system.  I wasn't in the mood to have my desktop system rebooted right then, so I said no.  Then I looked and saw that QEMU was just an emulator, so I probably could have tested it safely.  It wasn't too late:  the QEMU tab within XBoot allowed me (after a Refresh) to run the USB drive and, by golly, it seemed to work.

I plugged the USB drive into the Eee and rebooted it.  As in QEMU, it gave me the option to go into Utility, Linux, or Help.  The Utility submenu had Acronis, GParted, and DBAN.  I went into Linux in the main menu.  Ubuntu was the only option there.  I chose that option.  It ran.  I was able to access folders and go online in Firefox in Ubuntu.  Later, I discovered that, unlike the three other ISOs,  Acronis did not boot.  Acronis could be made bootable on a USB drive by installing the Acronis software and using its Bootable Rescue Media Builder.  I had already done that with another USB drive.  What I needed now was apparently not an ISO of the Acronis CD, but rather an ISO of that USB drive.  I used ImgBurn to create that.  Then I went back into XBoot.  There didn't seem to be an alternative to redoing the whole bootable USB creation process, so I did that.  This time, when the process finished, I tested all of the USB drive boot options in QEMU.  I saw that it had not deleted the previous options; I now had two Acronis entries.  One hung the system; the other successfully started Acronis.  I wanted to edit this menu, so I went to XBoot's Edit MultiBoot USB tab.  When I clicked the "Edit Syslinux menu file" button, I got an error:  "No application is associated with the specified file for this operation."  When I clicked Edit Grub4dos Menu File, it asked what program I wanted to use to edit it.  I tried Notepad.  That worked.  It opened menu.lst, which turned out to be in the root (top level) of the USB drive.  Menu.lst told me that the menu for the Utility section was on the USB drive too, in /boot/grub4dos/utility.lst.  My editing efforts were not too successful, so ultimately I just wiped the drive and started over.  I was not able to get Acronis to work, and in a subsequent retry the Ubuntu also stopped working.  I reformatted the USB drive (not Quick Format) and then redid the XBoot process without Acronis, and now the Ubuntu was failing to load.  I tried that twice.

Assuming I could get Ubuntu working again on the USB drive, the solution, so far, was to use XBoot, a Windows program, to load several program ISOs on a single USB drive.  The Eee would boot from this USB drive and would give me a menu allowing me to choose among those programs.  There seemed to be no practical limit on the number of ISOs that could be loaded this way.  The USB drive seemed to be capable of running just one ISO at a time, and Ubuntu loaded from the USB drive did not seem able to see the contents of the USB drive itself, so it did not appear that stray utilities added to the USB drive would be available to operating systems (e.g., Ubuntu) booted from the USB drive.

Grub4DOS

I wanted to try again to get a multiboot USB drive that would work with Acronis as well as with Ubuntu, DBAN, and GParted.  I found detailed instructions on using Grub4DOS in a way that seemed to meet this need.  The steps were as follows:

1. Download and unzip the needed files.  These were Grub4DOS 0.4.4 (2009-06-20) and the Grub4DOS installer (grubinst-1.1-bin-w32-2008-01-01.zip).
2. In the Grub4DOS-Installer folder, right-click and run grubinst_gui.exe as Administrator.  (This was familiar from the steps described above.)  Select Disk, click its adjacent Refresh button, and select the drive on which you want to install Grub4DOS.  The size of the drive was a clue.  In my case, I was installing to a 4GB flash drive, so I selected the one that was 3812MB in size.
3. Still in the Grub4DOS installer, click the Part List Refresh button.  This time, I got an error:  "Invalid partition table, if you still want to install, use the --skip-mbr-test."  This was presumably why Ubuntu had failed to boot on the last couple of tries with XBoot (above).  But I had already reformatted it!  Some advised using the HP USB Disk Storage Format Tool (HPUSBDisk.exe).  I closed down the Grub4DOS Installer and tried that.  I set it to do a quick format and not to create a DOS startup disk.  That did the trick; I was now able to go back in and select "Whole Disk" next to the Part List, as advised back in the Grub4DOS instructions.
4. Unlike the situation above, the instructions this time advised checking the "Don't search floppy" box (but nothing else) and then clicking Install.  That succeeded.  I closed the Grub4DOS Installer.
5. From the unzipped Grub4DOS download folder, I copied grldr to the USB drive.
6. Skipping to section 3 of the instructions (since I wanted multiple ISOs on the USB drive), I ran Acronis True Image Home on the desktop computer, where I had installed it.  I went to the Main Screen > Create bootable media.  When I got to the Bootable Media Type Selection section, I chose ISO Image.  I saved it to the same folder on the hard drive where I had my GParted and other ISOs.
7. I created menu.lst in that ISOs folder, so I'd have it in case I wanted to create another USB drive or retry with this one.  To create menu.lst, I started by copying and pasting this text into Notepad:

   timeout 10
   default 0
   
   title Acronis True Image Home 2011
   map --mem (hd0,0)/AcronisTrueImageHome2011.iso (hd32)
   map --hook
   chainloader (hd32)
   boot
   
   title CommandLine
   commandline
   
   title Reboot
   reboot
   
   title Halt
   halt

   The parts that could be edited were the title (Acronis True Image Home 2011), which could be anything I wanted, and the ISO's filename (AcronisTrueImageHome2011.iso), which had to match what I had actually called the ISO.  (Spaces in the ISO's filename would apparently have been a bad idea.)  I didn't change the (hd32) part of the "map" line.  The "--mem" part of the first "map" line was optional.  It apparently made the ISO load into RAM.  With 2GB of RAM on my Eee, I felt that I could do this with all of my ISOs.  If that had failed, I could have removed "--mem" from that line.
8. I copied the finished menu.lst over to the root of the jump drive. So now the USB drive contained two files:  grldr and menu.lst.
9. I copied the Acronis ISO over to the USB drive, so that menu.lst would be able to find it.  The instructions said I could have put it into a folder of its own, as long as the map command in menu.lst could find it (by referring to e.g., /subfolder/AcronisTrueImageHome2011.iso).
10. While I was at it, I copied the other ISOs (GParted, Ubuntu, DBAN) as well.  I used the patched DBAN ISO mentioned above.
11. I edited menu.lst so that it would include references to all four ISOs.  As just shown, it already had five lines referring to the Acronis ISO, beginning with "title."  So I copied, pasted, and edited those five lines for each of the other ISOs I wanted to boot.  Here, again, I was allowed to change only the title itself (e.g., changing "Acronis True Image Home 2011" in the copied "title" line to GParted, DBAN, or Ubuntu) and the name of the related ISO on the first "map" line.
12. I changed the timeout from 10 to 20 seconds.
13. Again, I made these changes to the copy of menu.lst that I had created in the ISOs folder on the hard drive, so that I would have a copy of it, and then copied it over to the jump drive.

I tried booting the resulting USB drive in the Eee.  It came up with a genuine menu.  First time around, it tried to boot Ubuntu automatically after 20 seconds' delay (that being the first item on my menu.lst), and failed.  Second time, I didn't let that happen; I arrowed down to Acronis (next item) and tried that.  That worked.  When I exited Acronis, it rebooted, and this time I tried DBAN.  That worked too.  Another reboot, another program:  GParted did not work.  It gave me a screenful of information, including this:

BOOT FAILED!
This Debian Live image failed to boot.
Please file a bug against the 'live-boot' package or email the Debian Live mailing list at debian-life@lists.debian.org, making sure to note the exact version, name and distribution of the image you were attempting to boot. . . .
Unable to find a medium containing a live file system.
BusyBox v.1.18.4 (Debian 1:1.18.4-1) built-in shell (ash)
Enter 'help' for a list of built-in commands.
/bin/sh: can't access tty; job control turned off
(initramfs)

It seemed that the Ubuntu/Debian live images (Ubuntu 11.04 and GParted) were not working with Grub4DOS.  A search suggested that others were having this problem too.  One post suggested that changes involving "kernel" and "initrd" might help, but I was not sure how to configure them.  I wondered if the --mem option was screwing up the Linux items, so I edited menu.lst to remove that option from those items.  For GParted, that worked, to the point of giving me the initial menu, but then it led back to the BOOT FAILED! screen (above).  For Ubuntu, I wound up back at the same message as I had gotten first time -- similar to the one just quoted, but much briefer.  It said something about BusyBox but then said, "(initramfs) Unable to find a medium containing a live file system."

Grub4DOS:  Ubuntu

I was perhaps experiencing the problem that "Some linux distributions just refuse to boot from an ISO file on a USB drive."  Of course, Ubuntu could be booted from a USB stick; it was the ISO part that was causing the problem.  This was apparently "experimental."  It seemed that the "kernel" and "initrd" commands could be copied literally, at least for Ubuntu 10.10; I wasn't finding much advice for 11.04.  The approach shown in a couple of websites was like this:

title Ubuntu 10.10
find --set-root ubuntu-10.10-desktop-i386.iso
map ubuntu-10.10-desktop-i386.iso (0xff)
map --hook
root (0xff)
kernel /casper/vmlinuz file=/cdrom/preseed/ubuntu.seed boot=casper iso-scan/filename=ubuntu-10.10-desktop-i386.iso splash
initrd /casper/initrd.lz

I adjusted menu.lst to replace the previous Ubuntu entry with these lines, copied the Ubuntu 10.10 ISO to the USB drive, and tried that.  (Note:  the line beginning with kernel is long; it wraps.  The next line after "kernel ..." is "initrd ...")  This gave me "Error 60:  File for drive emulation must be in one contiguous disk area."  A search led to the advice to use either Contig or WinContig to defragment the ISO on the USB drive -- to defragment a single file, that is, not necessarily the whole drive.  I was curious whether this kind of separate tool was necessary.  In Windows Explorer, I right-clicked > Properties > Tools tab > Defragmentation.  I selected the USB drive and clicked "Defragment disk."  In seconds, it said, "0% fragmented."  I tried booting again.  Now it said "Error 15: File not found" for the Ubuntu 10.10 ISO.  I couldn't figure this out:  the file was right there.  I re-copied the ISO over from the hard drive to the USB drive and, this time, I defragmented it with WinContig.  It offered to run on the whole USB drive after all, so I went ahead with that.  Basically, I was wondering if there was some kind of magic about the WinContig way of defragmenting.  It took much longer than the Windows defragmenter had taken -- a couple of minutes, altogether, just for that little USB drive.  Eventually I realized that it was hung.  I tried to use Task Manager (Ctrl-Alt-Del) to kill it, but that didn't work.  I rebooted the system.

I tried booting the Eee again with the USB stick.  This time, I got "Error 27: Unrecognized command."  I thought that maybe the Ubuntu ISO could not be in the root folder, so I put it into a subfolder called ISOs, and modified the three references to it (in the menu.lst lines quoted above) accordingly.  (The final menu.lst is shown below.)  Since things were not going well, I went back and re-did the 13 steps listed above.  This time around, they were like this:

1. Run the HP USB Disk Storage Format Tool on the USB drive.
2. Run grubinst_gui.exe as Administrator.
3. Copy grldr from the unzipped Grub4DOS download folder to the "MultiBoot" folder on the hard drive where I was saving everything that I would be copying to the USB drive.  That folder now contained grldr and menu.lst in its top level, and the ISOs in its "ISOs" folder.
4. Copy the contents of the MultiBoot folder to the USB drive.

This time, we were back to the good old days, when the Ubuntu ISO would actually get as far as loading its splash screen and seeming like it was going to start.  Evidently it helped to start over and/or to put the ISO in a subfolder.  (I wondered whether properly ejecting the USB drive from the desktop, rather than just yanking it out, made a difference too.)  And then, woo hoo, we had liftoff!  Ubuntu was operational.  I fiddled with it for a minute.  Nautilus worked; Firefox worked.  Fantastic.  I quit Ubuntu and tried the other ISOs on the menu.  GParted, splash screen ... BOOT FAILED.  Rats.  Acronis:  Orbit!  Finally, DBAN:  no problem.

Grub4DOS:  GParted and Parted Magic

So how to make GParted work?  A search led eventually to some suggestions that Parted Magic (which evidently contained GParted among other things) or RIPLinuX (which evidently contained Parted Magic plus) might be the superior tool and easier to put on USB.  I was willing to use any of the above, as long as I could figure out how to put it on a multiboot USB -- preferably, at this point, using Grub4DOS.  I looked into Parted Magic, reasoning that, again, I probably wouldn't need all the stuff on RIPLinuX, and it might load slower.  The contemporary way to put Parted Magic on a USB stick by itself was to use Unetbootin.  But how to put it on a multiboot USB?  One webpage claimed that I could download and unzip a USB version, install its contents to the root of the USB drive, and it would run with a modification of menu.lst.  Sadly, that version was no longer available at the cited SourceForge link.  That webpage made similar claims for Memtest86+, BartPE, and UBCD, and I was tempted to experiment with those as well.  I found other webpages providing seemingly easy instructions for adding Hiren's BootCD and Memtest86+ as well.  Most tempting was the option of adding a Windows 7 Recovery CD.  I decided to return to these possibilities later, time permitting.

But continuing with the Parted Magic investigation, I began to find that I probably should have called the subfolder "images" rather than "ISOs" -- referring, there, to the folder on the USB drive where I had put the ISO downloads.  So I made that change in menu.lst and in the folder structure now.  Then I found a thread that seemed to offer a way to make Parted Magic 5.10 work with Grub4DOS.  I downloaded the ISO of that fairly recent version and put it into the images folder on the desktop computer.  I replaced the GParted lines of menu.lst; and when the Parted Magic 5.10 ISO was finished downloading, I opened it with 7zip, extracted the pmagic folder, and put that into the images folder as well -- because that's what they did in that thread, for what reason I had no idea.  I copied the revised contents of the MultiBoot folder on the hard drive to the USB drive and tried booting the Eee with it.  The Ubuntu ran (again); the Parted Magic ran too, though for a minute there I thought it was hung.  Apparently it was taking it a while to load itself into memory.  It really had a lot of tools in it -- not only GParted but also Ghost for Linux, Partition Image, etc.  I didn't think I would be needing much else in the near future.  This success with Parted Magic version 5.10 made it unnecessary for me to look further into other posts relating to versions 5.9, 5.8, 5.7, 5.6, 5.5, 5.5, 4.5, or 4.3.  Acronis still ran, and DBAN still ran.  I was nearly home.

Grub4DOS:  Windows 7 Recovery CD

That discovery (above) of the possibility of adding a Windows 7 Recovery CD to my multiboot USB stick was just too good to pass up.  The instructions said that I would need to start by downloading Microsoft's Windows 7 System Recovery Disc.  This gave me a small torrent link called "Windows 7 32-bit Repair Disc.torrent."  I had already installed uTorrentPortable, so I used that to run that link and download the 143MB recovery disc.  When that was downloaded, I had an ISO that, once again, I could mount as a virtual CD using Virtual Clone Drive.  I downloaded and ran WinSetupFromUSB.  It looked like this might be destructive of my hard-won success on the USB drive, so I did this with another, blank USB drive.

In WinSetupFromUSB, I clicked Refresh to see the correct USB drive.  I clicked the Bootice button.  A dialog popped up.  I selected Process MBR and then Grub4DOS and clicked Install/Config.  I checked "Don't search floppy for GRLDR" but otherwise left everything else as it was, and clicked "Save to disk."  That seemed to be the end of Bootice, so I backed out of there; but then the Bootice dialog returned.  I killed it again, and this time it stayed dead.  Back in the main WinSetupFromUSB dialog, I realized I was suffering from a dearth of guidance.  The webpage I had been loosely following really wasn't cutting it.  Back to the previous one.  It seemed I should have formatted the USB drive while I was in Bootice, so I did that now:  USB-HDD, single partition, FAT32.  Now redo the Process MBR - Grub4DOS step just mentioned.   Now, back in the WinSetupFromUSB dialog again, I clicked the Vista / Win7 option, navigated to the virtual CD drive, and clicked GO.  A minute later, it was done.  I clicked Test in QEMU > GO.  It said, "Windows is loading files ..."  That took a while.  Then QEMU produced a BSOD.  This, I decided, was a project for another day.  A worthy one, if it worked, but a whole new undertaking, by the time I got all these other tools (Parted Magic, Acronis, DBAN, Ubuntu) working on that other USB drive.

Summary

It seemed that WinSetupFromUSB might be a good place to start, for someone who was beginning a voyage of discovery, on the way to creating a multiboot USB drive, and had some time to spare.  WinSetupFromUSB allowed the same Grub4DOS tool that I had found useful in the approach I took.  My approach is summarized in the four steps enumerated above:  run the HP USB Disk Storage Format Tool on the USB drive; run grubinst_gui.exe as Administrator; copy grldr from the unzipped Grub4DOS download folder to the "MultiBoot" folder on the hard drive where I was saving everything that I would be copying to the USB drive; download the relevant ISOs to the "images" subfolder in that MultiBoot folder; and then copy the contents of the MultiBoot folder to the USB drive.  Those contents included the menu.lst file, which in the end looked like this:

timeout 20
default 0

title Ubuntu 10.10
find --set-root /images/ubuntu-10.10-desktop-i386.iso
map /images/ubuntu-10.10-desktop-i386.iso (0xff)
map --hook
root (0xff)
kernel /casper/vmlinuz file=/cdrom/preseed/ubuntu.seed boot=casper iso-scan/filename=/images/ubuntu-10.10-desktop-i386.iso splash
initrd /casper/initrd.lz

title Parted Magic 5.10
root (hd0,0)
map --heads=0 --sectors-per-track=0 (hd0,0)/images/pmagic-5.10.iso (0xff) || map --heads=0 --sectors-per-track=0 --mem (hd0,0)/images/pmagic-5.10.iso (0xff)
map --hook
chainloader (0xff)

title Acronis True Image Home 2011
map --mem (hd0,0)/images/AcronisTrueImageHome2011.iso (hd32)
map --hook
chainloader (hd32)
boot

title Darik's Boot and Nuke
map --mem (hd0,0)/images/dban-2.2.6_i586-fixed.iso (hd32)
map --hook
chainloader (hd32)
boot

title CommandLine
commandline

title Reboot
reboot

title Halt
halt