Ubuntu 10.04 and Windows XP Dual-Boot: GRUB2 Woes

I was installing Windows XP SP3 and Ubuntu.  I encountered some error messages early in the process.  This post describes the steps I took in an attempt to resolve those problems.

First, I got this error:

Setup did not find any hard disk drives installed in your computer.

In my search for a solution, I found a thread offering a number of suggestions.  The one that worked for me was to go into the BIOS (hit Del at startup) and make sure the SATA controller was set to ATA, not AHCI.  Mine had started out as ATA, but a notice had popped up when I was first booting it, offering to change it to the AHCI, and I had accepted.  After I fixed this, the next bootup problem was this message:

Windows could not start because the following file is missing or corrupt:

\system32\hal.dll
Please re-install a copy of the above file.

My search on that led to a page offering a number of suggestions.  I started with just rebooting.  That didn't fix it.  suggesting that I go into the BIOS and switch the order in which the BIOS would try to boot my hard drives.  This led to a new message:

error: no such device: [UUID number]

grub rescue>

This apparently happened because I had previously installed Ubuntu on that hard drive.  For this one, I took the advice to boot from the WinXP installation CD, choose R to repair an existing installation, choose the existing installation (no administrator password), and type this sequence of commands:

D:\WINDOWS> C:

C:\> CD \

C:\> FIXBOOT C:

C:\> FIXMBR

C:\> BOOTCFG /rebuild

The last one led to an offer to add D:\WINDOWS to the boot list.  I took that offer.  But then it asked "Enter Load Identifier" and "Enter OS Load Options."  I didn't know what to add, so I just hit Enter for each.  This led to a new error message:

Error: Failed to add the selected boot entry to the boot list.

I guessed that the system was seeing the Windows installation on drive D because I had reversed the boot order in the BIOS.  I did think I had cabled them correctly, with the Windows drive going to SATA0 (i.e., the first SATA connector) on the motherboard.  I looked into Load Identifier and found a Microsoft page with information on that and other parts of this situation.  It told me to type the name of my operating system:  Microsoft Windows XP Professional, though apparently anything would do.  For OS Load Options, it said, type /fastdetect.  Unfortunately, this was not satisfactory.  I got the "failed" error again.

The responses to this seemed to lean in the direction of editing the boot.ini file.  A thread on that gave me the idea of just copying my boot.ini file from another computer.  A Microsoft page gave information on editing it if I was already in WinXP, which I wasn't.  A webpage devoted to boot.ini said it should be possible to just delete the boot.ini file in order to boot the system.  The webpage also gave some sample boot.ini files.  I typed "help" at the prompt and got a list of options.  There didn't seem to be an editor in the Repair Console.  I typed "dir" to verify that boot.ini was there, and then typed "type boot.ini" to see what was in it.  It didn't look very complicated.  What's more, it looked like my XP Pro entry was already there, which could explain why my BOOTCFG command didn't work.  I pressed the up arrow to retrieve my BOOTCFG command and hit Enter to run that again, just in case.  It failed again.

I typed "exit" and shut down the computer and swapped cables so that maybe this drive would show up as C rather than D.  That merely resurrected the "no such device" GRUB error.  I decided to explore that one for a while.  A search led to some commands that I could have entered, but then I saw a suggestion that maybe I could fix it by just installing Ubuntu, which I had planned to do anyway, and let it sort itself out.  So I went ahead with that, following the Ubuntu installation approach I had worked out previously.  But at this point I only did the initial installation from the CD, and then rebooted to see what the Windows situation was now.  Sadly, I still had the "no such device" error.

I guessed that the problem was that I was using two drives.  One of them had perfectly reasonable Windows and Ubuntu installations on it.  The other had leftovers from some previous Ubuntu installation.  I didn't know for sure, but on that hunch I unplugged the second drive and rebooted.  But no, that gave me the "no such device" error either way, no matter which disk I plugged in.  I plugged in both drives, rebooted with the live CD, and ran System > Administration > GParted to take a look.  Interestingly, it showed that a partition on the second drive was marked as a boot drive, when it should not have been.  I changed that.  It didn't make a difference.

Ultimately, I plugged in a USB drive while booted with the Ubuntu live CD, copied over the data files, wiped both of the drives in the machine, and reinstalled WinXP and Ubuntu, in that order.  That solved the problem.

Windows XP & Ubuntu RAID 0 Dual Boot: Error: No Such Device

I had set up a dual-boot system with Ubuntu 10.04 on a two-drive RAID 0 array and Windows XP SP3 running from a third hard drive.  I replaced the WinXP drive with a different one, copying the files over from the old drive's partitions to the new one, and rebooted.  When I selected the Windows XP option in the GRUB2 boot menu, I got an error message:

error: no such device: [apparently a UUID number]

error: invalid signature.

Press any key to continue...

As described in comment 90, within a long thread on this Ubuntu bug, with an alternate approach in another post, the solution to this problem was said to involve editing grub-mkconfig_lib.  Since I was able to get into Ubuntu (though not Windows), I took the approach described in comment 90.  In Ubuntu, in Terminal, I typed these commands:

sudo apt-get update

sudo apt-get install grub-common

The first command ended with errors along the lines of "could not connect to archive.getdeb.net."  This turned out to be an indication that the getdeb repository was down.  I repaired it by editing sources.list to refer to a mirror site instead.  Next, I typed this:

sudo gedit /usr/lib/grub/grub-mkconfig_lib

and changed gedit's Edit > Preferences to show line numbers.  I went down to line 174, ready to insert a # sign before whatever was on that line.  But it was just "fi" which, I thought, marke the end of an "if" statement.  What they wanted me to add did not look like it belonged there.  The long thread had not been visited for nearly four months; I suspected the file had been changed in a bid to fix the problem.

I got that error in the first place, as noted above, not because of an obvious malfunction in GRUB2, but because I had moved the partition containing the Windows XP program files.  I heard that just typing "sudo update-grub" would cause GRUB2 to search for operating systems.  And it did:  in the process of "Generating grub.cfg," it reported that it found Windows XP on /dev/sdc1.  I wondered if that would fix the problem by itself, so I rebooted and selected the Windows option again from the GRUB menu.  And that was it.  Problem solved!

Ubuntu 10.04 Installation: The Streamlined Version

In another recent post, I described the process of installing Ubuntu 10.04.  This post offers a streamlined version of that post.  That is, it describes another such installation, performed on the basis of that post.

The first step was to install Ubuntu from the live CD.  As before, in this step I installed everything into one root partition.  When installation was complete, I copied my saved fstab from a separate partition to replace the existing /etc/fstab, and then typed "sudo gedit /etc/fstab."  There, I replaced the UUID for the root partition with the new one shown in another Terminal session via "sudo blkid."  I saved and closed fstab.  This part still did not go smoothly -- I still had not mastered the translation of the Ubuntu Community Documentation webpage into terms that fit my situation -- but essentially I typed "cd /" and then "sudo mv /home /old_home" to park the newly installed but largely empty /home folder; then "sudo mkdir /media/home."  On reboot, my desktop was restored to its previous condition.  I deleted the /old_home folder.

Next, I went to the folder where I had saved my backup copy of sources.list and typed "sudo cp sources.list /etc/apt/."  I opened sources.list, copied the commented command lines, and ran them.  They generated what appeared to be error messages.  In Software Sources, I triggered a reload.  It closed without errors.  In Synaptic, I installed these programs:  acroread, acroread-fonts, adobe-flashplugin, boinc, dvgrab, fdutils, gparted, mplayer, nautilus-open-terminal, ntfs-config, p7zip-full, sysinfo, ubuntu-tweak, unetbootin, and webhttrack, as well as these font packages:  ttf-mscorefonts-installer, sun-java6-fonts, ttf-sil-gentium, ttf-sil-gentium-basic, ttf-dustin, and ttf-georgewilliams.  As before, I typed "sudo sh" to install my .bin and .bundle downloads (e.g., GoogleEarthLinux.bin) and double-clicked to install my .deb downloads.  Then I went into Update Manager, and ran and reran it until I was all caught up.

Monitor driver installation and BOINC configuration were as described in the "Settings and Adjustments" section of the previous post.  The GRUB2 menu edits, as described more carefully in that post, were as follows:  to get rid of the Memtest+ options, I typed "sudo chmod -x /etc/grub.d/20_memtest86+."  To let Ubuntu remember which operating system it had used last, I typed "sudo gedit /etc/default/grub," changed the first line to be "GRUB_DEFAULT=saved," and added a second line that said "GRUB_SAVEDEFAULT=true.  To limit the number of Ubuntu kernels shown, I typed "sudo gedit /etc/grub.d/10_linux," added "GRUB_DISABLE_LINUX_RECOVERY=true" at the top, and changed two lines at the bottom to be three that read as follows:

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

I saved and closed that and typed "sudo update-grub."  I typed "sudo vmware" and made some root adjustments there.  I rebooted and everything looked good.  There were a few rough spots, but I could see that this might not take very long at all, once you got the hang of it.

Ubuntu 10.04: UDEVADM Trigger Is Not Permitted While UDEV Is Unconfigured

In the process of installing Ubuntu 10.04, I got an error message:  "udevadm trigger is not permitted while udev is unconfigured."  Trying to reboot into Windows XP on that dual-boot computer led to the same error message.  This post describes my efforts to resolve that error.

As I looked into it, I found some indications that this was due to a bug in Ubuntu.  In my case, the immediate trigger seemed to be the decision to use an "installed-software" package (as described in the main installation post) to restore many of my previously installed programs at once.  Alternately, it may have been due to the concomitant effort to set up a separate home partition.

At least one user fixed this problem by using a different kernel.  I didn't seem to have any other kernels on my machine at this point, so I started over and re-did the basic Ubuntu installation.  This time, I installed everything to the root partition.  I rebooted, copied over my backup of fstab, changed it to reflect the new root partition's UUID, and rebooted.  Having discovered that I had made some mistakes in the separate home partition process, I tried that once more, and now that worked too.  I rebooted and ran installed-software (above).  This time, I declined to erase previously downloaded .deb files.  I rebooted again.  Unfortunately, I now had that udevadm message again.  Examining it more closely, I saw that, after a minute or two, it went on to say this:

ALERT!  /dev/disk/by-uuid/xxxxxxxxxxx does not exist. Dropping to a shell!

where "xxxxxxxxxxx" stands for a UUID.  Which UUID?  I could not figure out how to do things in the shell that opened up, so I rebooted with the Ubuntu Live CD.

According to fstab, the UUID belonged to my Ubuntu programs partition.  I typed "sudo blkid" and compared its output.  Fstab was correct:  it was identifying the UUID for that partition.  So when Ubuntu would try to boot, it would not find itself.  How was that possible?  This seemed to be a GRUB problem.  Following advice, I opened /etc/default/Grub and uncommented (i.e., removed the leading # sign from) the line that read "GRUB_DISABLE_LINUX_UUID=true."

I was then supposed to run update-grub, but I didn't know how to do that from a Live CD boot.  One post said that it was possible; I needed to do so "from inside a chroot environment."  Wikipedia seemed to say that chroot means "change root"; the idea was that I would use chroot so that, when I was running a program (e.g., update-grub) as root, the "root user" doing so would be that of the hard drive, not of the CD.  A Community Documentation page told me that it was "a special directory on your computer which prevents applications, if run from inside that directory, from accessing files outside that directory . . . like installing another operating system inside your existing operating system."  In other words, I needed to use chroot and then run update-grub as the root of my Ubuntu installation.  Unfortunately, the procedure described in that Community Documentation page required me to begin by installing dchroot and debootstrap, and I wasn't able to do that.

Something made me think that Super Grub Disk, which I had forgotten about, could provide a solution.  Looking into that led me to Rescatux instead.  But then the Super Grub Disk wiki said that Auto Super Grub Disk (ASGD) was the easiest solution for a Windows user.  Working on another computer, I downloaded it.  I expected an ISO, but it was an executable (.exe) file, so I ran it.  It gave me a dialog that seemed to be wiling to install ASGD on a USB drive, so I plugged one in, designated ASGD (not SGD) and USB (not hard drive) as my options (I had to restart ASGD to get it to see the drive), and clicked OK.  After a minute, it said "Installation Complete, Reboot."  So I plugged the USB drive into the troubled computer and did that, making sure to choose USB (actually, USB-HDD) as my first boot device in BIOS.  But it said, "BOOTMGR is missing."

So now I did try Rescatux.  I downloaded it, burned it to a CD, and booted it.  Its wizard came up, and I killed it.  But then it turned out that the wizard was the main thing, though the program did have a nice interface reminiscent of BartPE, with an applications menu and so forth.  Unfortunately, I couldn't figure out how to get the wizard back, so I had to restart it.  (The instructions on the SGD wiki were incorrect, and it was apparently not possible to edit pages or become a new user of the wiki.)  This time, from the Rescatux wizard, I chose GRUB options > grub-install > run.  It auto-selected my Ubuntu partition.  But then it said, "Which hard disk to install Linux on?"  I didn't want it to install Linux anywhere.  It made me nervous.  Anyway, I didn't want it to install GRUB either; I feared that would just wipe out the Windows part of my GRUB menu and give me a new problem to fix.

I tried again, this time with Super GRUB2 Disk.  The SGD wiki advised me to enter certain commands from the prompt, but did not say how to get to a prompt.  I tried the SGD option for "Detect any GRUB2 configuration file (grub.cfg)."  It found only one and seemed to be offering to load it.  I went with that.  It ran the GRUB menu OK and that took me to the udevadm error message.  Great.  I rebooted the SGD and tried the "Enable serial terminal" option.  But that just brought me back to the menu.  Tried it again; same result.

Back to the drawing board.  I found a different Ubuntu wiki page on how to recover GRUB2 via Live CD.  This seemed more on target.  It called for booting the Ubuntu Live CD, opening Terminal, and typing "sudo blkid" to get the device where Ubuntu was installed.  In my case, it was /dev/sdb8.  So then I typed "sudo mount /dev/sdb8 /mnt."  I didn't have /boot or /var on separate partitions, so I could just go directly to these commands:

sudo mount --bind /dev /mnt/devsudo mount --bind /proc /mnt/procsudo mount --bind /sys /mnt/syssudo chroot /mntupdate-grubexitsudo umount /mnt/devsudo umount /mnt/syssudo umount /mnt/procsudo umount /mnt

Then I rebooted.  Went through the GRUB menu; still got the UDEVADM message.  Back at the starting point, I tried searching again for answers to that error message.  Following an approach that seemed to work for some people, I started by booting the system and getting to my GRUB menu.  I hit the down-arrow key to stop the clock so that I could copy down the number of the Linux kernel I was trying to install.  In my case, it was 2.6.32-24-generic-pae.  (Alternately, I could have just typed "ls /boot" as one of the following commands.)  Having already found that Ubuntu was installed on /dev/sdb8, I rebooted with the Live CD, opened Terminal, and typed this:

sudo mkdir /media/newrootsudo mount /dev/sdb8 /media/newrootsudo chroot /media/newrootapt-get updateapt-get dist-upgrade

I rebooted and sat back to watch.  No joy.  Still got UDEVADM.  I rebooted the live CD and tried a modification of those commands:  redid the first three, down through the chroot step, but then typed "sudo update-initramfs -u -k 2.6.32-24-generic-pae."  This brought several error messages:  "Unable to resolve host ubuntu" and "No such file or directory" (in connection with an automatically generated "grep:  /proc/modules" command).  I rebooted, wishing these error messages wouldn't matter -- and, woo hoo! what do you know, they didn't!  I was booting into Ubuntu.  It ran a check on my disks, and that was the end of the story!

Ubuntu 10.04 & Windows Dual-Boot: Customize GRUB2 Boot Menu

I had a dual-boot machine with Windows XP and Ubuntu 10.04 (Lucid Lynx) on it.  I wanted to clean up and customize the GRUB menu that came up whenever I booted the system.  There were several parts to this.

I started with The Grub 2 Guide.  The Guide's point 6, "Adding Entries to Grub 2," said that files named 10_linux and 30_os-prober would search for installed Linux kernels and other operating systems.  I typed this:

cd /etc/grub.d
ls

and, sure enough, I had files called 10_linux, 20_memtest86+, 30_os-prober, and 40_custom, along with 00_header and 05_debian_theme files.  There seemed to be useful ways to change several of these items, so I went down the list in numerical order, starting with 10_linux.  I typed "sudo gedit /etc/grub.d/10_linux."  The thing to do here was to stop GRUB from listing Recovery Mode options in the startup menu.  I did a Ctrl-F to see if 10_linux contained this line:

GRUB_DISABLE_LINUX_RECOVERY=true

It didn't appear to have that, so I added it near the start of the file, right before the first "if" statement.  That was all for 10_linux, so I saved and closed it.  Now, how about controlling the menu so that it wouldn't list older kernels?  At this point, I thought about going with their "Building a Totally Customized Menu" option.  But the Grub 2 Guide said that a fully customized menu would not be updated with the addition of any new kernels.  The reason seemed to be that I would make 10_linux non-executable, so it would no longer go sniffing around to see what's new.   I didn't want to have to mess with updating the list manually every time a new kernel came along.  For guidance, I looked to the Grub 2 Title Tweaks Thread.  That, and the Grub 2 Guide, led to the following approach:

uname -r
sudo update-grub
ubuntu-tweak

The "uname" command told me what kernel I was now using.  At present, that was 2.6.32-22-generic-pae.  The "sudo update-grub" step told me what else was being listed on the Grub menu.  There was the option of seeking out other kernels in Synaptic, but running ubuntu-tweak (available via Synaptic, if you have the right repository) gave me an easier way of removing older kernels.  In Ubuntu Tweak, I went to Applications > Package Cleaner > Unlock > Clean Kernels.  This showed all installed kernels other than the one currently in use.  They said it was a good idea to keep one previously working kernel, so I skipped the first one on the list and checked the others.  Then I clicked Cleanup.  Ubuntu Tweak did its thing, and then I closed it.  It turned out there was another way to do this, that didn't require the Ubuntu Tweak step:  just tell 10_linux how many kernels to display.  This method required me to type "sudo gedit /etc/grub.d/10_linux" and then search for the place that had these two lines:

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

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

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

I found that right at the end of the 10_linux file.  So I made that change and then saved and closed 10_linux.  Next, I didn't want memtest+ to appear in the GRUB menu list, so I typed this:

sudo chmod -x /etc/grub.d/20_memtest86+

I looked for a quick way to confirm whether a file was executable, but there didn't appear to be an option for that in chmod, and the first several webpages I tried in response to a Google search didn't tell me.  Moving on, GRUB on my laptop had gotten confused, and it now pointed to two different Vista installations, only one of which was working.  The Grub 2 Title Tweaks Thread said I could hide it, but it seemed like I should also be able to remove it.  It seemed like a bad idea to have it hanging around.  Here's how those lines looked in GRUB:

Windows Vista (loader) (on /dev/sda1)
Windows Vista (loader) (on /dev/sda2)

The first one was not working.  If I hit it, I got "Disk error.  Press any key to restart."  I actually had to power down the laptop to get past that.  I didn't yet have a very well configured Ubuntu setup on the laptop, so I rebooted with a GParted CD (an Ubuntu Live CD would have worked too).  In GParted, I looked at sda1 and, well, no wonder it was showing up.  I had a Windows XP installation on a hidden partition in there!  I'd had some troubles installing Vista on the laptop, and apparently I had decided to keep the WinXP installation just in case.  So, OK, that was interesting.  I could have tried to rejigger the setup so that I'd have a triple boot system, but I didn't plan to be using XP very often on the laptop, and I could use GParted within Ubuntu (once I finished tweaking the laptop) to hide and unhide as needed.  For now, what I needed to do, in the GRUB menu, was to change the entry so that it would report the situation more informatively.  I typed this:

sudo cat /boot/grub/grub.cfg | grep "menuentry" | cut -d '"' -f 2
sudo gedit /etc/grub.d/30_os-prober

The first line gave me the current list of GRUB menu entries from grub.cfg (in case I hadn't already written down the names I wanted to change).  Precisely what I wanted to change was the first of the two "Windows Vista (loader)" entries.  So:  around the middle of 30_os-prober, I found this:

for OS in ${OSPROBED} ; do
  DEVICE="`echo ${OS} | cut -d ':' -f 1`"
  LONGNAME="`echo ${OS} | cut -d ':' -f 2 | tr '^' ' '`"
  LABEL="`echo ${OS} | cut -d ':' -f 3 | tr '^' ' '`"
  BOOT="`echo ${OS} | cut -d ':' -f 4`"
  if [ -z "${LONGNAME}" ] ; then
    LONGNAME="${LABEL}"
  fi

Following their advice, I could have changed those last three lines to five lines that read as follows:

  if [ "${LONGNAME}" = "Windows Vista (loader)" ] ; then

    LONGNAME="Windows XP (hidden)"

  elif [ -z "${LONGNAME}" ] ; then

    LONGNAME="${LABEL}"

  fi

In this case, unfortunately, both of those items were named "Windows Vista (loader)," so I figured they would both change to "Windows XP (hidden)."  What I needed had to be more specific, so instead I left their last three lines unchanged and added this after them:

  if [ "$LONGNAME" = "Windows Vista (loader)" ] && [ "${DEVICE}" = "/dev/sda1" ] ; then

    LONGNAME="Windows XP (hidden)"

  fi

And that worked.  The one other thing I wanted to change was to get GRUB to remember which operating system choice I had used last time, and default to that one again this time unless I selected something else.  In previous Ubuntu installations, the steps I had taken to do that had been to type "sudo gedit /etc/default/grub"; change one line to say GRUB_DEFAULT=saved instead of GRUB_DEFAULT=0; save and close that file; and then type "sudo update-grub."  But now I saw this in the Grub 2 Guide:  "The default OS will not be set merely by an interactive selection of an OS from the menu."  So that was apparently a change from Grub 1.5, or whatever I had been using previously.  So now, one option was to set up a custom menu, except that it wouldn't be updated for the latest kernels.  But then, confusingly, the Grub 2 Basics seemed to say that there was a simple solution after all.  I typed "sudo gedit /etc/default/grub" and made sure it said that "GRUB_DEFAULT=saved" and I also added a line right after that (since there wasn't already a line for this):

GRUB_SAVEDEFAULT=true

So I saved that, typed "sudo update-grub," and watched as it generated its list.  It looked like it was only going to show one Linux image, but I reserved judgment and rebooted.  Sure enough (speaking, here, of the desktop computer on which I had been making most of these changes), GRUB now showed only two items:  the latest Ubuntu kernel and Windows XP.  I chose Windows, the second of the two items.  I hit Enter and immediately hit F8, in the theory that Safe Mode would load faster than Normal Mode.  I guess it did, but it still wasn't in a hell of a hurry.  I clicked "Turn off computer" > Restart and watched to see if GRUB would remember that I had just booted Windows, not Ubuntu.  It did.  Excellent.  That seemed to be working.  I chose Ubuntu instead and rebooted again.  This time it went into Ubuntu.  Likewise, on the laptop, after some tinkering, sudo update-grub eventually produced the desired list, and it remembered the last boot too.

Resuming a VMware Virtual Machine: Could Not Open /dev/vmmon

I was tweaking Ubuntu 10.04 (Lucid).  One step I took was to clean out old entries from the GRUB menu.  This involved removing some old kernels.  That process may have caused a problem for VMware Workstation 7.  When I tried to resume a previously suspended virtual machine, I got this error:

Could not open /dev/vmmon:  No such file or directory.  Please make sure that the kernel module `vmmon’ is loaded.

One source recommended adding some extra lines to the VMware startup script.  I killed VMware and tried that.  I typed “sudo gedit /etc./init.d/vmware and added those lines at the start of that file, right after the end of the introductory comments.  But it didn’t work, and I wasn’t surprised; the code seemed a bit scrambled.  I closed Workstation and tried “sudo vmware.”  But that didn’t help either.  What did finally solve the problem was a simple command:  “sudo service vmware start.”  Then I started VMware and was able to restore my virtual machine OK.

Tweaking Ubuntu 10.04

I had upgraded from Ubuntu 9.10 to Ubuntu 10.04 (Lucid Lynx).  Now I wanted to make some adjustments.  For this purpose, I would be drawing upon the first and second lists of adjustments I had made when I had installed 9.10.

The first of those other things was to install a PAE-enabled 10.04 kernel, so that I would have access to all of my system's RAM.  I also found that VMware Workstation 7.0 was requiring me to enter my serial number.  I had not entered it after installing it on 9.10; I had just been using the trial serial number.  Now, unfortunately, Workstation was not cooperating:  it was saying "Unknown error entering serial number."  The solution to this problem was to run Workstation as root (i.e., type "sudo vmware" at the Terminal prompt) and enter the serial number there.

Since I was doing an upgrade of a previous installation, I did not have to reinstall packages, but I did have a problem with Software Sources.  I have described that one in a separate post.  (Even if I had needed to reinstall packages, the "installed-software" trick described in the lists of adjustments (above) would have made short work of it.)  On my laptop, I was doing the same upgrade, and there I made some problems for myself when I had to interrupt the upgrade.  Here on the desktop, the next task was (as described in separate posts) to try to get the printing and scanning features of my Brother MFC-7340 printer working from within Ubuntu.  After doing that, I tackled a problem that I had wanted to solve for years:  how to import the list of AutoCorrect entries that I had created in Microsoft Word into OpenOffice.org Writer, running on Ubuntu.  That took some time, but then I was able to get back to the project of working through those notes from previous installations.

The upgrade from Ubuntu 9.10 to 10.04 had preserved much of the configuration I had already set up.  So as I worked through the Ubuntu tweaking steps described in one of my previous posts, I had to deal with only a fraction of the issues addressed there.  One was to prevent icons for mounted drives from appearing on the desktop.  That called for Terminal:  “gconf-editor” > /apps/nautilus/desktop > unclick volumes_visible.  But it was already unclicked, and yet I did have icons for mounted drives visible on the desktop.  I went into Applications > System Tools > Ubuntu Tweak > Desktop Icon Settings and clicked Show desktop icons and left everything else unchecked, but this made no difference.  I tried again, this time using “sudo gconf-editor.”  Ah, yes.  The volumes_visible box was checked for root.  Unchecking it removed the icons from the desktop.

I had not noticed, but somewhere along the line, I had evidently installed nautilus-open-terminal via Synaptic, or possibly it came installed by default.  As its name suggested, this tool added a right-click (context menu) option in Nautilus, "Open in Terminal."  Unlike Windows Explorer, this option was only available for folders in the file listing in Nautilus -- in the right pane, that is, not in the left pane that would typically show the folder tree.  In that left pane, this and other options were absent.

Had another little problem.  During the upgrade to 10.04, the Firefox icon changed, on the left-side (formerly top) panel, to a red do-not-enter or not-allowed kind of icon; and in Applications > Internet, it changed to a grey question-mark box.  I fixed this by going to the panel, right-clicking on Applications > Edit Menus > Internet > Firefox > Properties, clicking on the icon, and selecting /usr/share/pixmaps/firefox.png.  Speaking of Firefox, I wanted Ubuntu to open Firefox and Google Chrome on startup.  I wanted to add these to a script that would run at startup, since I suspected that I would be coming up with other things that I wanted to have happen at startup too.  It seemed pretty technical – beyond my current ability, anyway – but it looked like I might be able to just write a script and put it into /etc./init.d.  I typed “sudo gedit” and then created a file called /etc./init.d/a_startup_script.sh.  I put, into it, the line that I got from e.g., right-clicking on Applications and choosing Edit Menus > Applications > Internet > Firefox > Properties:  “firefox %u.”  I saved it and typed “chmod +x /etc./init.d/a_startup_script.sh.”  Then I rebooted.  This achieved nothing.  So creating a general-purpose startup script remained a goal for the future.

I also went down Gizmo’s Freeware list of tweaks.  I had already done most of the ones I wanted, but there were a few others.  One was to install Windows TrueType fonts in Ubuntu.  I decided to extend their advice somewhat.  I took a look at System > Preferences > Appearance > Fonts.  I could see that a lot of Windows fonts were not present on the list there.  So in Windows XP, I went to C:\Windows\Fonts.  I selected and copied everything to another, temporary folder called UbuFonts.  In UbuFonts, I sorted by file type and deleted the ones that were not TTF files.  Back in Ubuntu, I typed “sudo nautilus” and went to /usr/share/fonts/truetype.  It already had a folder called msttcorefonts, but with only a fraction of the fonts that I had just copied from C:\Windows\Fonts to UbuFonts, and the font files there seemed older and smaller.  I made a backup copy of the msttcorefonts folder and then copied everything from UbuFonts into /usr/share/fonts/truetype/msttcorefonts.  Now System > Preferences > Appearance > Fonts had a much wider selection.  I changed the fonts to Tahoma 10 and the monospace to Courier 10.  Tahoma allowed me to see more information on each line onscreen.

Another tweak from Gizmo called for some playing around with Compiz.  This was a bad idea, as described in a separate post.  Another tweak of interest was to clean up the GRUB boot menu.  I typed “uname -r” and saw that I was using the 2.6.32-22-generic-pae kernel.  In Synaptic, I searched for linux-image, clicked at the top of the left-hand column to sort by those that were installed, and marked for removal all numbered items other than that kernel.  In this case, that included just two items:  linux-image-2.6.31-21-generic-pae and linux-image-2.6.32-22.generic (i.e., not pae).  I did another search for linux-headers and marked all non-2.6.32-22-generic-pae items there too.  In this case, trying to remove linux-headers-2.6.32-22 threatened to remove linux-headers-2.6.32-22-generic-pae as well; but I wanted to keep that, so I didn’t remove linux-headers-2.6.32-22.  On restart, I saw that GRUB now listed just the 2.6.32-22-generic-pae kernel and its recovery mode, along with memtest and Windows XP (it was a dual-boot machine).  I went back into Ubuntu without a problem.  I did later have a VMware problem that might have been related to this, though.

Gizmo also pointed me toward a number of recommended freeware apps.  These were for the KDE (not GNOME) desktop.  I thought it might be time to try KDE, if only to check out these programs.  One was the Wally wallpaper changer, which I installed through Synaptic.  Getting Wally (and the whole KDE desktop) involved a total of 91 files.  Other interesting pieces of Gizmo-recommended software I got through Synaptic:  gtk-recordMyDesktop and Dolphin file manager.  Downloaded directly from creators’ websites, I got Wink, FreeFile Sync, and Parted Magic.  I did consider using Dropbox as well, because of its good reviews (by e.g., PC Magazine, Online Backup Tools, Laptop, and alternativeTo; but I decided that Windows Live Sync had important advantages even though I would have to run it in a virtual machine when I was booted into Ubuntu.

(Note:  a few days later -- possibly the first time I tried it after installing KDE -- Google Desktop search was no longer responding to its default Ctrl-Ctrl hotkey.  That is, its Quick Search Box was not coming up.  Something I saw on some webpage, as I was trying to fix that problem, made me wonder whether the KDE installation was to blame.  A tip that fixed it was to open the Google Desktop Search preferences and change the hotkey to Ctrl-F1.)

The last thing to do, in this round of tweaking, was to clean out unnecessary stuff from the drive on which I had installed Ubuntu, so that I could make a backup image in case I needed to reinstall – so that I could just restore the image, that is, instead of having to go back through all these steps.  This, I thought, called for something like the TreeSize utility that I had used in Windows to see where I might have files or folders taking up huge amounts of space.  Among what seemed to be several possibilities, I found an actual Linux version of TreeSize, so I downloaded that – but I also discovered Ubuntu’s Applications > Accessories > Disk Usage Analyzer, whose Treemap Chart was especially interesting.  These revealed that my Ubuntu installation was not presently very large, so I didn’t have to worry too much about shrinking it for this particular image.  It also revealed that by far the largest space hog, within that installation, was the Google Desktop index of stuff on my hard drive, at 5.2GB.  I did see that the Google Chrome cache was also taking 400MB.  I went into Chrome’s Settings (the wrench icon at the upper-right corner) > Options but didn’t see any way to control that, other than to just clear the cache.  I decided to leave it for now, and changed some other settings while I was there.  And that was it.  Ubuntu 10.04 was tweaked, at least for now.

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

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

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

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

SWAP: waiting for UUID=[UUID number]

Press ESC to enter a recovery shell.

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

GRUB Error 17

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

Upgrading from Ubuntu 8.04 and 8.10 to 9.04

I had Ubuntu 8.04 (Hardy Heron) on one machine and 8.10 (Intrepid Ibex) on another. I discovered that 8.10 does, but 8.04 does not, permit an in-place update to 9.04 (Jaunty Jackalope). In other words, I would have to install 9.04 from scratch, using the installation CD, on the machine where 8.04 was installed; but I could update online, without doing a complete new installation with the CD, on the machine running 8.10. The online update was straightforward. Following advice, I took the following steps:

1. Go to System/Administration/Update Manager
2. Click the Check button to check for new updates.
3. If there are any updates to install, use the Install Updates button to install them, and press Check again after that is complete.
4. A message will appear informing you of the availability of the new release.
5. Click Upgrade.
6. Follow the on-screen instructions.

The difference here between 8.04 and 8.10 was that 8.04 would not give me that message informing me of the availability of the new release. That is, once you get as far as 8.10, all of your future updates can be done online. Note that the online installation process is much slower than the CD-based installation process. It tied up my machine for hours. By contrast, I was able to download and burn the ISO for the CD mostly in the background, while continuing to use the machine for other things. The advantage of the online upgrade is that you don't have to reinstall everything you had previously installed on Ubuntu. Websites advising on the upgrade process also provide information on upgrading from the ext3 to the ext4 filesystem. I did not thoroughly review this process before proceeding with that upgrade. It seemed to work fine, but then I was not able to reboot my system. I got Error 24. I tried reinstalling GRUB, but was not successful, and it looked like others had had the same experience. From what I could gather, it appeared that the upgrade causes problems only on the boot partition. Once I reinstalled from scratch, everything seemed OK; there did not seem to be any problems on any other newly upgraded ext4 partitions. There seemed to be two pieces of advice about upgrading from ext3 to ext4 on the boot partition: that it's not necessary, and that some programs are not yet ready for it. The next step for me was to install everything from scratch, now that I had wiped out my previous Ubuntu installation.

Ubuntu, GRUB, and Acronis True Image: Restoring

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Error 12: Invalid device requested

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

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

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

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

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

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

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

No Drives Are Attached, or Drives Are Powered Down

I was starting to build a second computer. I installed a Philips SPD2513BD DVD burner. I didn't notice that it was a SATA drive, and I was a little bummed about using up one of my two SATA connections, in this new computer, when I could have used one of the IDE/ATA connectors instead. But in the worst case I could swap it with the IDE burner in the other computer. I liked the specifications and the looks of this drive, and I had already paid shipping, so I decided to make a go of it. My plan for a quick and easy Windows XP Professional installation, on this new computer, was to use DriveImage 2002 to install a drive image PQI file containing a complete snapshot of an earlier WinXP installation. That way, I would not have to go through the whole rigmarole of installing Windows, sitting there hitting keys to get it to download updates, etc. I would just re-install this already complete previous installation, change a few hardware items, and be done with much of the installation chore. Unfortunately, it didn't work quite that way. When I tried to boot from the Drive Image CD, I got this error message:

No Drives Are Attached, or Drives Are Powered Down The Device Driver Is Not Installed

The message was obviously incorrect, insofar as it was coming from a CD that was loaded in the DVD drive. I had previously booted Bart PE and had seen, there, and also in an Ubuntu bootup, that the system was indeed recognizing both the DVD drive and the hard drive. I did a Google search for the error message, but came up with no answers. I was stumped. I searched for the error message in Google Groups as well. There, I got the idea to check the BIOS. No clues in the BIOS, but I then thought of trying to boot Drive Image from the floppy disk. (I had recently recopied Drive Image to fresh floppies.) But that gave me a Grub Error 22. Evidently this system was not willing to boot from the floppy, even though I did have it third in the BIOS bootup sequence. I tried moving it to first. That worked. The floppy booted. Apparently Grub had come preloaded ... or, as I thought about it, perhaps I had not completely reformatted the hard drive after installing Ubuntu on it. I postponed the Drive Image process to verify that, rebooting with PartitionMagic 8.0. Of course, it wasn't prepared to load that, either, not from the CD anyway, so I reverted to the original plan and proceeded to load Drive Image from the floppy, figuring I would fool with the partition issues later. But then -- I had forgotten -- Drive Image was able to identify and delete the partition, so PM wasn't needed. I was surprised and pleased that DI was able to read the PQI, given that it was saved on a DVD rather than a CD. I hadn't been sure that DVD technology was in the mainstream back in 2002. I still got Grub Error 22, so I researched it and got the advice to boot from the WinXP program CD, go into Recovery Console, and use FIXMBR and FIXBOOT. That solved the problem.