Windows 7 x64: Bootable RAM Tester

I was running 64-bit Windows 7 with 8 gigabytes (8GB) of memory.  I wanted to test that RAM.  So I looked around for a program that would do the testing.

It appeared that Memtest was still limited to 32-bit Windows (hence its full name, Memtest86).  Another option was Microsoft's Windows Memory Diagnostic (WMD). It appeared both of these would involve burning the program to a CD, booting the computer from that CD, and letting it run for a while, probably hours. I tried that with WMD, but it gave me an error:

Windows Memory Diagnostic (WMD) could not process the system memory map. This occurred because of deficiencies within WMD, not the computer. As a result, not all of the computer memory will be tested. The specific problem was:

The memory map contained ranges that extended above four gigabytes.

Press (C) to continue. Press any other key to exit WMD.

So WMD wasn't good with more than 4GB of RAM. Now I saw that this limitation was indeed stated in the webpage -- down in the Appendix. RTFA. The Appendix also seemed to say that WMD, too, was suited only for x86 (not 64-bit) CPUs.

That could be confusing, because it turned out that 64-bit Windows 7 came with a memory tester built in: Start > Run > mdsched.exe would bring up a dialog titled "Windows Memory Diagnostic" with an option to restart the system and check the memory.  So apparently what I had been playing with previously (above) was a different version of WMD (which was, incidentally, a particularly unfortunate acronym for a piece of computer software).  The built-in variety of WMD would be something that one could build into a monthly or quarterly batch file, to come up automatically.  It would not be useful for a nonbootable system, however, so I continued my search.

That search led me back to Memtest86.  Wikipedia said that I (and, seemingly, Memtest's own webpage) was wrong:  Memtest86 or Memtest86+ would supposedly work with 64-bit CPUs, and Memtest86 version 3.5a or above would supposedly test more than 4GB of RAM.  The Background page at the Memtest86 website said that Version 4.0a did indeed test up to 64GB (or, if using 4.0b Server edition, up to 8TB) of RAM, and that it would also work with 64-bit CPUs and would support up to DDR3.  It came in Windows and Linux versions.  For Windows, it came in USB, floppy, and CD ISO flavors.  Meanwhile, it appeared that Memtest86+ had not been updated in nearly a year, so I stuck with just trying the original (version 4.0a) Memtest86 for now.

I downloaded, burned, and booted the Memtest86 4.0a ISO.  It recognized 7678MB of RAM.  I wasn't sure why it didn't seem to be testing a full 8GB.  I turned away to work on something else.  When I returned, 21 minutes later, it had already finished a first pass and had started a second one.  So it apparently took less than 20 minutes to test 8GB (or so) of RAM.  It reported, "Pass complete, no errors, press Esc to exit."

I decided to test the built-in Windows Memory Diagnostic.  I booted Windows 7 and ran mdsched.exe (above).  Its blue and white design was prettier than that of Memtest86, I thought, but it was far less informative.  It was done with my 8GB of RAM in about 15 minutes.  The main advantages of mdsched.exe seemed to be that it was built-in and could be batched, run by Task Scheduler, or called up at a moment's notice, without any need to load a separate CD.  Because of that last point, the computer could reboot, run mdsched.exe, and then continue seamlessly into Windows without requiring user interaction.

Google Desktop on 64-bit Ubuntu 9.10

I could have downloaded Google Desktop in .rpm or .deb format for ease of installation, but decided instead to go with the repository approach.  I chose this approach in order to get automatic updates, and also to make it easier to install other Google software that might interest me.  There were a couple of repository options.  Before taking the manual approach to the repositories, I decided to try Google's automated installation script.  To run that script, I entered these two lines into Terminal, as instructed:

wget https://dl-ssl.google.com/linux/google-repo-setup.sh

bash google-repo-setup.sh 

That caused Ubuntu's Update Manager to fire up and offer to install a bunch of software updates.  I gave it my consent to proceed.  When it was done, I went into System > Administration > Synaptic and searched for google-desktop.  I marked google-desktop-linux for installation and clicked Apply.  Now I had a new Ubuntu menu item, Applications > Google Desktop.  I went into that and clicked OK, or whatever it was.

Now I noticed I had a Google Desktop icon in the system tray, or whatever they call it in Linux -- in, that is, the bottom right corner of the screen.  I right-clicked on that and set my Preferences.  In Preferences, I typed in "/media" as a folder to search, since I had some Windows XP partitions with data there.  Now the hard drive began churning away, presumably indexing the stuff in those partitions.

While that was doing its thing, I went back into Synaptic, searched for google, and clicked on Package, to arrange the options alphabetically.  I installed googleearth.  I noticed a google-chrome-beta, but decided I didn't need it right now.

I tried using Google Desktop.  It only searched the web.  I right-clicked on the system tray icon and changed the default search type to Desktop.  I was searching for "command economy."  It didn't find anything like that on my desktop.  I right-clicked on the icon again and chose Index > Index status.  It said it was only about 15% done with indexing, so I let it go for a while.  But when it was done, it had catalogued only a small number of my total files, so I guessed that it was not cataloguing subdirectories in /media.  I went into Google Desktop Help for Linux and searched around.  I didn't find an answer, so I posted a question.  Ultimately, I solved this (and other difficulties arising from 64-bit Ubuntu by downgrading to 32-bit Ubuntu.

Windows XP SP3 CD Won't Boot

I was trying to install Windows XP on a Compaq Presario CQ60-420US laptop. I had just gotten it back from HP service in Texas, where they supposedly replaced the motherboard to fix a nonworking wired network interface card (NIC). They had reinstalled Vista on it, which I thought was very nice of them, and now the NIC still did not work for purposes of accessing the Internet, but did work for half of a crossover cable connection with another computer. That is, the other computer could access the laptop, but not vice versa.

So I had decided to try to see if WinXP would fare better than Vista on these problems. I wiped out the Vista partition, used GParted to create a new partition, and stuck the WinXP installation CD into the CD drive. Unfortunately, XP would not boot from the CD. GParted had just booted from the CD, so I was pretty sure it wasn’t the drive hardware per se. With the WinXP CD inserted, the computer would recognize that there was a CD in its drive, and would say, “Press any key to boot from CD,” but this just caused the thing to grind away, apparently trying to read and act upon the information on the CD, before eventually (after maybe five minutes) giving me a BSOD (blue screen of death).

I found that this problem occurred with a WinXP CD, containing slipstreamed SP3, that I had used to install XP on another computer; but it appeared somewhat different with an SP2 XP CD.   With that CD, the system went all the way through "Setup is loading files" and said, "Setup is starting Windows" before giving me the BSOD.  Then again, this may have been what was happening when the SP3 CD was grinding away; perhaps it was just not reporting all of the drivers it was loading.

To fix this, one suggestion said to disable BIOS virus detection. But the BIOS did not have a virus detection option. Someone else said laptop CDs are not eager to boot from DVDs, but this was definitely WinXP on a CD.

The BIOS Setup seemed willing to let me try to boot from a USB drive. I wondered if I could install WinXP from a 4GB USB jump drive that I had lying around. To try it, I rearranged the Boot Order so that USB Diskette on Key / USB Hard Drive came first. I wasn’t too sure how to do the rest of this process, so I started by just copying the WinXP CD directly to a 4GB USB drive. While that was underway, I researched the question and found that there were many websites on how to do this, and all of them sounded complicated.

At the same time, I continued trying to figure out what was wrong with the laptop’s DVD drive. One source said that they solved the problem by flashing the BIOS on the laptop. This seemed like a more comprehensive kind of solution, so I decided to try this second – right after inserting the USB drive with a copy of the Windows XP CD and verifying that, no, it wouldn’t install WinXP by itself; booting from that USB drive would just give me “Invalid system disk. Replace the disk, and then press any key.”

It seemed odd that the system would boot a Vista CD but would require a BIOS update in order to boot a WinXP CD.  Or at least it had booted a Vista installation CD previously.  I decided to try that again.  Sure enough, with the Vista installation CD inserted, I got “Press any key to boot from CD or DVD” and then “Windows is loading files.”  I thought about trying to slipstream Vista into a WinXP CD, but got some warnings that maybe this would not be a good idea.

So, continuing with the current plan, I went to the HP-Compaq download page and looked for a WinXP BIOS update for this laptop.  All I saw there was a firmware update named sp43474.exe, for the GSA-T50L optical drive, dated April 2009.  Firefox 3.5.8 wouldn’t download it to my other computer; I had to right-click and use the IE View extension to download successfully.  The problem now was that this update was an .exe file, which I would only be able to install from within a running Windows installation.  Catch-22!

Just to be sure, I double-clicked on the sp43474.exe file on the other computer.  It said, “This software update will upgrade the firmware of your system’s optical drive GSA-T50L to rev SC05.”  I had done a printout to PDF from a system information utility before sending the laptop to Texas, so now I searched it for a reference to this model of DVD drive.  It said that, actually, what I had (at least before sending the laptop to Texas) was an Optiarc DVD RW AD-7561S ATA Device.  This seemed to be made by Sony, whereas the GSA-T50L was made by LG.  I supposed that both might ultimately have been made by the same Chinese sweatshop somewhere, but I preferred to try to find a driver for the Optiarc.  But I was curious why my laptop would have an unofficial CD drive.  I was not able to find any references to the Sony Optiarc AD-7561S drive on the Sony Optiarc page, so apparently it was an older or in some sense unsupported model.  I stumbled across a recent thread in which someone else was tired of hassling with HP, couldn’t find a firmware update, and was at the point of just installing the wrong update to see what would happen.  Same problem in another thread.  I even found a thread on an official HP forum where they were talking about this problem.  As one participant in that last thread said, “There does not seem to be any updates for the 7561s at all.”  So, OK, updating the firmware was not an option; the more likely option was to send the machine back to HP for a replacement, assuming they were willing.  I couldn’t do that now -- I needed the laptop -- so we were back at the option of installing XP from the USB.  I went through a long effort of that nature, but ultimately abandoned it and came back to this post.

While that long effort was underway, I began looking into other possibilities.  One was to adapt an Acronis True Image backup (or you could try Macrium for freeware) of a Windows XP installation from another machine, so that it would work on this laptop's different hardware.  The Acronis option that I would need, to avoid a BSOD, seemed to be Universal Restore, which would apparently cost at least $365 (list).  Alternately, it seemed that OEMs use Sysprep to deploy the same operating system installation on many computers, but it looked like more hassle than it would be worth for just one system.  I also looked into the possibility of installing XP via network connection.  This led me to a site that specialized in boot disks.  I didn’t see how I could use any of that, unfortunately -- at least not without a substantial additional time commitment, which was impossible.

The effort to install XP from the USB did not pan out, so at this point I returned to this post.  There seemed to be two basic options.  Either find a way to develop or adapt an Acronis image from another machine so that it would work on the laptop, or get to a command prompt (via USB drive, network connection, or otherwise) and run an installation command (seemingly something like X:\i386\winnt /s:X:\i386, where the /S switch defines the location of the startup files) to install WinXP from scratch.

I wondered if (a) Windows updates were being designed and revised to defeat the Acronis approach and (b) it would be possible to bail out of a WinXP basic installation before installing many hardware drivers, and make an Acronis image at that point.  I tried that, but WinXP would crash almost immediately; and as with other efforts, it would not boot into Safe Mode either.  I figured that putting the Acronis image on the laptop would at least have installed the I386 folder there, so now maybe it was just a question of getting to a command prompt.  I didn't need BartPE on a USB stick for that; I could boot BartPE from a CD.  I had a CD version of BartPE from 2007.  I guessed it would probably work, since XP was much older than that.  But it seemed that whatever caused the laptop to crash when I had the WinXP CD inserted was also going to reject WinXP as part of a BartPE CD.

I also had an Ultimate Boot CD for Windows (UBCD4Win).  The UBCD ground away for a long time, eventually showed me the WinXP splash screen -- and didn't crash!  Instead, it gave me a choice, "Select shell to start." It still seemed to be in its process, so I waited, and it chose the automatic option for me.  It gave me an option of setting up networking, but I didn't know how to answer the question as to which sort.  I tried to cancel, but it seemed intent upon continuing, so I just used the default options.  I went to Start > Command Prompt and typed DIR C: (using capital letters here just to indicate the actual command; DOS is not case-specific) and, no, the I386 folder was actually not installed there yet.  I put the WinXP CD in the CD drive and typed DIR X: because it looked like X was the letter that UBCD had assigned to the CD drive.  I typed COPY X:\I386 C:\ and it copied files.  Then it froze.  I killed that window and tried running Start > Programs > File Management > Explorers.  None of the explorer programs would run.  Eventually I realized this was because I had removed the UBCD disc.  I put it back in and tried again.  The explorers still didn't work.  I had belatedly realized that COPY was probably not the best command, so I tried XCOPY X:\I386 C:\I386 /E /H /Y.  It copied lots of stuff, and not the way I intended.  Now all the stuff that should have been in the C:\I386 folder was instead in the root (C:\) folder.  Oops.  I wound up deleting it all and starting over.  There were just a few files in C:\ that I couldn't delete (i.e., biosinfo.inf, bootfix.bin, config.sys, and mstask.inf), and of course several folders (i.e., Documents and Settings, I386, Program Files, and Windows).  Problem:  there was no WINNT.EXE file to be found.  On my other computer, it was in C:\I386, but it was not in that folder on either the laptop or the WinXP CD.  I carried it over via jump drive.  It took UBCD a minute to recognize the jump drive, but it did.  I typed WINNT.EXE and hit Enter.  I got this:

Windows XP Setup

This program does not run on any 32-bit version of Windows.

Use WINNT32.EXE instead.

Setup cannot continue.  Press ENTER to exit.

So, OK, I jumped WINNT32*.* over to C:\I386.  (The USB flash drive was recognized as drive G, as I discovered by feeling around.  That is, I tried D: and got a partition; tried E: and got a partition; tried F: and got an error; tried G: anyway and there it was.)  But it froze.  It would copy the WINNT32.* files, but not the WINNT32*.DLL files, not even one at a time.  I tried running C:\I386\WINNT32.EXE anyway.  It gave me an error:

The file C:\I386\WINNT32U.DLL could not be loaded or is corrupt.  Setup cannot continue.

I didn't have that particular one on the jump drive, so I went back to the source machine and tried to jump it over.  But I got the same problem:  the command window froze and had to be killed.  I rebooted the computer with an Ubuntu 9.10 CD and then copied all of the WINNT32*.* files (and a WINNT32 folder) from the source computer to the laptop's C:\I386 via jump drive.  Back in UBCD, I tried running that same WINNT32 command and got that same "could not be loaded or is corrupt" error.  One post suggested this sort of message might be due to insufficient RAM.  A Microsoft webpage said that I should double-click on WINNT32.MSI.  I wasn't in a GUI, so I just tried typing WINNT32.MSI at the command line.  This opened a dialog asking me what program I wanted to use to open this kind of file.

Since I had a command prompt using UBCD, I tried a different approach.  The command I used this time was:

X:\i386\winnt32.exe /syspart:C: /tempdrive:C: /makelocalsource

But this gave me an error, stating that this command was not recognized.  I tried it again, inserting a BartPE jump drive and replacing X: with H: since H was where the jump drive was.  This worked, but it just gave me the same error message I had gotten a long time earlier:

Setup cannot continue because upgrade functionality is disabled and your copy of Windows XP only allows upgrades.

I tried replacing H with C, since I had already copied I386 to C.  This just gave me the message about WINNT32U.DLL being unloadable or corrupt.  One post led me to think that this problem might be unique to my WinXP SP3 disc, so I loaded an SP2 disc and tried winnt32.exe with that.  That did not seem to achieve anything:  the disc spun up and then down and I was back at the command prompt.  I tried it again with the SP3 CD.  Same result.  Apparently I had mistyped the command previously.

I thought maybe I could run winnt if I could find a 16-bit DOS equivalent.  My search led to FreeDOS, where I downloaded FDFullCD.iso.  I burned it and booted the laptop with it.  I indicated that I wanted to boot FreeDOS, and then chose option 3, FreeDOS Live CD with HIMEM + EMM386.  But I got this error:

Selected page frame e000 not available, searching automatically

No suitable page frame found.  EMS functions limited.

I gathered that EMM386 was not a good option in this case.  I rebooted and tried again, this time choosing option 4, HIMEM only.  This produced a bunch of error messages, but at least it put me to an A: prompt.  Drive B appeared to be a RAM drive.  The program did not recognize drive C.  I thought this must be because it was an NTFS drive, but no, FreeDOS did not recognize any drive, including the CD drive.  I booted FreeDOS again, and this time chose option 5, FreeDOS Live CD only.  I still got some error messages, including "There is no CDROM, or the wrong CD-ROM!"

I guessed that whatever kept this CD-ROM drive from recognizing WinXP was also impairing its recognition of the FreeDOS CD somewhat.     In that case, I wondered if I could install the contents of the WinXP CD from a bootable FreeDOS USB drive.  To make that, I followed instructions to install Unetbootin on my Ubuntu machine, and then used Unetbootin to make a FreeDOS bootable USB stick.  When that was done, I checked its properties and saw that Ubuntu indicated the filesystem type was msdos.  I copied the /I386 folder from the slipstreamed WinXP SP3 CD to the USB stick, put the USB into the laptop, and rebooted.  After a Unetbootin screen, I was back at the FreeDOS menu.  I tried option 3; same errors as before.  I tried option 5.  This time, it recognized the USB drive as drive C.  Then I realized that this was no help; it still couldn't see the partition on the hard drive where I wanted to install WinXP.  Well, could I reformat that partition as FAT32?  I formatted another USB drive as FAT32, put it into the laptop, and rebooted from the FreeDOS stick.  It did recognize the FAT32 USB drive.  Now, could I install WinXP on a FAT32 partition?  It looked like it was supposed to be possible.  I pulled out the USB drives, rebooted the laptop with GParted, and replaced the NTFS partition where I had planned to install WinXP with a FAT32 partition.  (I figured this would be much faster than trying to convert from NTFS to FAT32.)  Of course, now I was wondering whether the FAT32 alternative would also have made a crucial difference with some of the attempts to install from UBCD.  When GParted was done, I rebooted with the FreeDOS stick.  Sure enough, now I could see the FreeDOS stick as drive C and the WINXP partition as drive D.  I tried using XCOPY, but it didn't work.  I wasn't sure how to copy subfolders etc. in FreeDOS.  Rather than research it, I removed the FreeDOS USB, rebooted with UBCD, plugged in the FreeDOS stick, found that WINXP was now drive C and the FreeDOS stick was drive G, and therefore used XCOPY G:\I386\*.* C:\I386 /E /H /Y to copy the I386 folder from the FreeDOS to WINXP.  This time around, that ran very smoothly.  I rebooted with the FreeDOS USB stick.  I went into the I386 folder on the WINXP partition (which was drive D in this case), and typed WINNT.  Windows XP Setup asked me where the XP files were located.  It defaulted to D:\I386, so I left it at that.  Next, it said this:

Windows XP Professional Setup

Setup did not detect SmartDrive on your computer.  SmartDrive will greatly improve the performance of this phase of Windows Setup.

You should exit now, start SmartDrive, and then restart Setup.  See your DOS documentation for details about SmartDrive.

I looked into SmartDrive.  Along the way, I ran across the ingenious suggestion that I could use an IDE to USB adapter and, with that, could use the internal CD drive on a desktop computer as an external drive for some other computer (if I had needed to do that).  (This would require leaving the CD drive's power connected in the host computer.)  SmartDrive itself was an MS-DOS disk cache program, to speed up file transfer times.  It appeared that FreeDOS might have its own cache arrangement, presumably faster if I could get HIMEM and/or EMM386 to load.  The best I could do was to reboot, choose FreeDOS option 3, ignore the FreeDOS boot error messages, and continue past the WinXP setup message about SmartDrive.  WinXP setup next said, "Please wait while Setup copies files to your hard disk."  It copied files for a while, and then froze.  I had heard something about how WINNT would only start the process, so I rebooted with UBCD, went into C:\I386, and typed "winnt32.exe /syspart:C: /tempdrive:C: /makelocalsource" and, this time, it worked!  It gave me "Welcome to Windows Setup" and then asked for my WinXP's product key.  I went through the various options, accepting the defaults (including the offer to upgrade my drive to NTFS), and it began the installation process.  It estimated that it would take 52 minutes, instead of the usual 39.  But then something happened.  I turned away, and when I looked back, we were back at the UBCD prompt.  I ran WINNT32 again, just like before, but this time I said No to the option of upgrading to NTFS.  It didn't matter.  I ran it a third time, and again it crashed, shortly after it finished "Copying Installation Files."  No error message or anything.  I rebooted UBCD and tried installing again from the I386 folder that I had added to the bootable FreeDOS USB drive, using the command "G:\i386\winnt32 /syspart:C: /tempdrive:C: /makelocalsource" (because G was where the system saw the FreeDOS USB drive).

So now I wondered whether I could boot to a very WinXP-compatible 32-bit command line.  I started with Vista.  My Vista installation was not booting at this point, probably because I had told GParted to hide the Vista partition, so I inserted the Vista DVD and rebooted.  I went with its Repair Your Computer option but didn't proceed with the repair, choosing instead the steps necessary to get a command prompt.  I inserted the FreeDOS USB and found it at drive H.  But before trying it, I went to C:\I386 and ran that WINNT32 command again.  It proceeded just as it had done in UBCD, except I didn't recall having to agree to the license agreement in the UBCD process.  It crashed -- it put me back to the command line -- just as it had done in UBCD.  I tried again, this time starting from the I386 folder in the FreeDOS USB.  I even swapped out the Vista CD for the WinXP CD, just in case that would make any difference.  It didn't.  Another crash.  I took out all bootable items, rebooted, and got "Disk error.  Press any key to restart."  So, no, it had not by some magic completed the process.

I rebooted UBCD.  On another computer, I copied C:\Windows\system32\chkdsk.exe to a new Utilities folder on the FreeDOS USB.  I plugged in the FreeDOS USB, navigated to C:, and typed D:\Utilities\chkdsk /r.  It ran.  I told it to force a dismount.  It quickly checked files and slowly checked free space.  It found no problems.  I rebooted with GParted and had it check the filesystem on the WINXP partition.  No problem there either.  I wondered if the presence of even a hidden Vista partition was screwing things up for WinXP.  I deleted both partitions and recreated WINXP.  The WinXP CD would still not boot.  The Vista CD would still boot, and it gave me a command line from which I could run winnt32.  Even so, it crashed again.  I wondered whether the problem was with my SP3 CD.  I made another folder on the FreeDOS USB, naming it I386-SP2, and copied the I386 folder to it from the WinXP SP2 CD that I had used in making the SP3 CD (i.e., having the same product key).  I tried running WINNT32 again from the Vista command prompt, using this I386-SP2 folder as the source.  This gave me an error:

Setup was unable to build the list of files to be copied.

The system cannot find the path specified.

I verified that the WINXP partition was still drive C, and that it contained an I386 folder.  The problem seemed to be that the I386 folder has to be named I386 -- nothing more, nothing less.  I renamed I386-SP2 to be I386 and re-ran the WINNT32 command.  It crashed again, in exactly the same way as before.  I checked C: to see what WINNT32 was actually doing there.  The answer: not much.  It was creating files named $WIN_NT$, with the extensions .~BT and .~LS, along with a file named textsetup.sif, and it had copied NTLDR over.  And that was about it.  I deleted those $WIN_NT$ files and tried WINNT32 again, this time using the product code from my other WinXP CD.  It crashed, of course.

Someone said that a problem something like this one sounded like it might be due to a bad CPU or other hardware.  Of course, that was always possible.  I wasn't ready for that yet; after all, everything else seemed to work OK.  But I was running out of other theories.  Then I stumbled into a search from which I gathered that "downgrade" was an official searchable term, especially where Vista was concerned.  PC Magazine had a two method article, but neither method would work for me since I wasn't able to boot from the XP CD.  I found what looked like the consummate downgrading guide, with specific information for my laptop model.  For a CQ60 with an Intel CPU, it seemed to say that I should slipstream the ICH9 SATA driver (ICH9M-E/M SATA AHCI Controller) into the XP installer using nLite.  To get the ICH9, I downloaded and unzipped f6flpy3289.zip, but I did not understand why the highly regarded CherylG was telling me that I would find my driver inside iaAHCI.inf.  In the process of digging around for the driver she named, I contracted a virus, which prompted me to get up-to-date on Spybot Search and Destroy and on the Web of Trust add-on for Firefox.  I eventually found the driver on an HP webpage (though not the downloads webpage for my laptop).  I ran it on another computer (it was an .exe file) and it tried to install itself but then said the computer didn't meet the requirements, which I assume meant something about its particular CPU.  The conclusion there seemed to be that it would help to run it on a computer whose hardware was very different from the target computer, so that it would just extract but would not install.  I didn't know if it would run on the laptop from the Vista prompt, but anyway this was not the concept of slipstreaming, so I went back to the first one that CherylG had pointed toward.  Then I downloaded nLite and looked at the recommended guide for slipstreaming the driver.  Now that I saw the guide, I understood why CherylG was pointing me toward an .inf file.  She apparently didn't mean that I somehow had to extract the driver from iaAHCI.inf; I just had to include that .inf file in the slipstream.  This seemed to be the only thing I had to slipstream, so I went ahead with it.

The slipstreaming process began by copying the entire SP3 CD to a folder on the hard drive that I called SP3CD.  I started to install nLite, which required the Microsoft .NET Framework 2.0.  Installing that required trying to update .NET Framework 1.1 and then downloading a tool to uninstall it when the updates failed, and then manually doing registry edits etc. to uninstall it when the tool failed.  That ran overnight.  Next morning, when that was done, I followed the MaxEasyGuide to slipstreaming with nLite.  The first time, for some reason, it did nothing.  Second time, it made a file that I called SP3-SATA.ISO, containing the ICH9M-E/M SATA AHCI Controller driver from within iaAHCI.inf -- and now I understood what CherylG was saying.  Next question:  what was I supposed to do with this thing?  I decided to open it with UltraISO and copy its I386 folder to another folder.  Then I ran Beyond Compare to see how different it was from the original slipstreamed SP3 I386 folder.  It looked like there were a couple dozen differences in files.  So, OK, the nLite process seemed to have done something.  I wasn't sure I had done all of these steps right, but I decided to give it a shot.  I used Beyond Compare to synchronize the I386 folder on the FreeDOS USB with the I386 folder I had just extracted from SP3-SATA.ISO.  Whoa.  Many, many differences.  I forgot -- I had been using the SP2 I386 folder.  I changed that around and re-ran the comparison.  Still tons of differences!  Oh, I knew why.  It was because of the timechange.  The files were mostly the same, but some had been created an hour before the others of similar name.  I told Beyond Compare to ignore unimportant differences and did a full refresh, but that made no difference.  I bit the bullet and upgraded 6,992 files on the FreeDOS USB.  While that was underway, I re-ran the nLite and Beyond Compare processes, just to be sure.  Everything looked good.  I put the updated FreeDOS USB drive into the laptop and re-ran the WINNT32 command.  Alas, that wasn't the answer.

I found another thread that seemed to say that CherylG's advice on drivers was for an AMD CPU, whereas my CQ60-420US had an Intel CPU.  But some respondents said they were definitely using the Intel drivers and it still wasn't working.  Unfortunately, the drivers they pointed to were no longer availlable at the Intel website.  Daniel Potyrala advised that I download and run CPU-Z in order to find out not only my CPU type but also my chipset.  I couldn't very well run CPU-Z without an operating system.  Since it seemed that having Vista on the same hard drive did not explain why I could not even run WINNT32, it seemed to be time to restore the Vista partition using GParted and Acronis.  Adam Pash assured me that it didn't matter which came first, WinXP or Vista, so I left the WinXP partition in place (in hopes that it would someday be operational) and just added the Vista partition behind it.  I downloaded the appropriate version of CPU-Z, jumped it over to the laptop, and installed and ran it.  CPU-Z said that my mainboard chipset was an Intel GL40, which meant that I needed to slipstream . . .  the ICH9M-E/M SATA AHCI Controller driver, just like before.  So Mr. Potyrala was wrong; CherylG had given me the right tip.  But then Fernando1 said there were different drivers for 32-bit and 64-bit CPUs.  My T4200 Pentium (Penryn) was a 64-bit.  It was hard to tell the two apart; the driver names were the same.  I repeated the nLite process.  This time, the Textmode driver I selected was the ICH9 SATA AHCI Controller (Desktop ICH9R).  There were, again, some differences, so once again I updated the FreeDOS USB drive and tried it in the laptop, this time typing  "I:\i386\winnt32 /syspart:F: /tempdrive:F: /makelocalsource" because the FreeDOS USB was at I: and the WinXP partition was now at F.  That didn't work, so I tried once more, this time selecting the ICH8R/ICH9R SATA RAID Controller.  That didn't work either.

It was time to quit.  The webpages to remember, for future reference, included Quang Do's post in an HP forum, listing drivers and their sources; ditto Riskyone101; and perhaps a post, by wimb, that I really didn't understand.  The approach to remember was to use Unetbootin in Ubuntu to quickly create a FreeDOS bootable USB drive, if I needed 16-bit support, or just a Vista DVD or UBCD, if I could go straight to 32-bit support; to format the target drive in FAT32 rather than NTFS if necessary; to use nLite to create a slipstreamed ISO, assuming I could find the right drivers, and UltraISO to extract files from that ISO to load via USB drive if necessary.  I didn't know why WinXP could not run on the laptop, and I wasn't sure what else to try at this point.

No Sound on Ubuntu 9.10 and VMware Workstation 7 (again!)

I was running Windows XP Pro in virtual machines (VMs) within VMware Workstation 7 on a 64-bit Ubuntu 9.10 (Karmic Koala) host.  I had repeatedly had problems with no audio in earlier versions of Workstation (e.g., 6.5.2).  Various fixes, reboots, and other efforts had randomly gotten the audio working again within one or more VMs.

Now I had a new situation:  there was no audio in any VM and, when I checked, I found there was also no sound in Ubuntu itself.  Once again, I ran various searches and began trying various suggestions.  I came across an Ubuntu Community Documentation page on Sound, which led me to another Community page on Sound Troubleshooting Procedure.  Step 1 in that procedure led me to Stéphane Gaudreault's long, step-by-step procedure on upgrading the Advanced Linux Sound Architecture (ALSA) (1.0.22.1) on Karmic.  (On WinXP, using another computer, Stéphane's page loaded in Internet Explorer, but not in Firefox.  It loaded slowly in Firefox in Ubuntu.)  I closed Workstation, and then copied and pasted each line of that procedure into Terminal.  (It was possible to copy and paste multiple lines at once, including line ends; they would run one after another.)  One exception:  as far as I could tell, I did not get the "panelw library not found" error he described, so as he advised, I skipped the "symbolic links" part of his instructions.  Everything seemed to go smoothly until his very last command (sudo alsaconf), which opened the ALSA Configurator.  After clicking OK, the Configurator said, "Searching sound cards," and then gave me this error:

No supported PnP or PCI card found.

Would you like to probe legacy ISA sound cards/chips?

So it seemed that possibly I did not need to go through Stéphane's procedure, though I did appreciate how perfectly it went.  I might have just run "sudo alsaconf" in the first place, assuming I already had some version of ALSA loaded on my computer; doing so might have given me this same hardware-related error notice -- unless Stéphane's procedure was its cause.  That seemed possible; maybe my ALSA was now so new that Ubuntu had not yet caught up.  I tried listening to a WAV file, just in case, but no, sure enough, still no sound.  I ran a search for that error message.  This led to a VIA Technologies Release Note (oddly, not found on the VIA website) that said,

When installing driver, if the ALSA Configurator reminds that "No supported PnP or PCI card found", it means the kernel cannot find the pci audio device. Select "No" to exit the installation and uninstall the driver. Please read Notes b des-cription to resolve the problem.

Exiting the Configurator did not seem to uninstall anything, so I interpreted that part of the Release Note to mean that I was supposed to uninstall the driver myself, somehow.  Notes, point b, in that document said this:

Before installation, make sure your linux kernel can find the pci audio device first. If your kernel can not find any pci device with command 'lspci', you'd better add an option in /boot/grub/menu.1st file. At the end of line with "kernel /boot/vmlinuz-xxxx", xxxx is the kernel version, add the following:

pci=conf1

This information appeared to mean that I should have done this before going through Stéphane's procedure.  I didn't know how to undo that procedure, so I decided to poke around a bit more, in search of other possibilities.  I started back at the Sound Troubleshooting Procedures (STP) page.  It gave me several commands to copy and paste into Terminal.  This gave me a link to Stephen Olesen's Pastebin website, where all kinds of information about my system was automatically posted for other people to see and, presumably, help me with.  The last message produced by those commands I cut and pasted was, "Please inform the person helping you."  So apparently I could post a question in a forum somewhere, and include the Pastebin address instead of cluttering up the forum with all that information about my system.

Anyway, the STP page said that the Pastebin file should contain some indication of the "Driver version," the "Library version," and the "Utilities version."  I tried searching the Pastebin file for "Driver version" and, sure enough, there it was, not far from the top.  It said this:

ALSA Version
------------
Driver version: 1.0.22.1
Library version: 1.0.22
Utilities version: 1.0.22

That didn't look like an exact match.  I wasn't sure if 1.0.22.1 was close enough to the others.  The STP page said the numbers needed to be equal.  If they weren't, then (a) one of the ALSA components was not successfully upgraded (which I didn't think was the problem, as I had seen no error messages), or (b) I booted an older kernel version (which wasn't the case either).  Anyway, there seemed to be a mismatch between my ALSA version and my Ubuntu kernel.  So it still looked like I would need to reinstall ALSA.  But then it occurred to me that I hadn't run the lspci command, as suggested by the Release Note (above), to see if my kernel could find a PCI device.  It found a bunch of PCI devices, including "MCP61 High Definition Audio."  Hmm.  Puzzling!

OK, well, the STP page had one more, very long line to copy and paste into Terminal.  If my driver version numbers (above) were acceptably similar to one another, maybe this was all I needed to do.  So I tried that.  It ran, but I couldn't tell for sure if it was happy.  I tried "sudo alsaconf" again.  Still the same result.  Mark Rijckenberg suggested, to someone having a similar problem, that they either revert to an earlier version of ALSA (which hadn't been working for me) or else consider switching from x64 back to 32-bit Ubuntu.  Having had many problems with 64-bit Ubuntu -- orphan problems, especially, that almost nobody else seemed to be having -- and having wrestled with the sound problem repeatedly for the past year, I decided to try my luck with 32-bit Karmic.  I describe the downgrading process in a separate post.

Ubuntu 9.10: Downgrading from 64-bit to 32-bit Karmic Koala

As indicated by numerous posts in this blog over the past couple of years, I had a number of problems with 64-bit Ubuntu installations -- orphan problems, especially, that almost nobody else seemed to be having.  I finally decided to try replacing 64-bit with 32-bit Ubuntu 9.10.  This post describes the steps I took to install and configure the downgrade.

First, I made an Acronis TrueImage backup of my current installation, so that I could quickly restore the 64-bit installation if it turned out that downgrading to a 32-bit system wasn't paying off.  Next, I looked into the possibility of downgrading without doing a complete reinstallation, but the consensus
appeared to be that I would have to completely wipe the 64-bit installation and start from scratch, using 32-bit applications.

A tip from Benjamin Lowenstein led me to a quick method of listing and restoring my installed applications.  First, I typed "dpkg --get-selections > installed-software."  This created a file called "installed-software" in my Home folder.  The contents of that file looked like this:

acpi-support                         install
acpid                                    install
adduser                                install

In my case, there were hundreds of them.  Some that I had installed specially (i.e., outside of Synaptic Package Manager), such as VMware Workstation, were not on the list.  Otherwise, though, I would later be able to use this list to restore the large majority of my programs automatically.  Quite an improvement over Windows!

But first, I had some housekeeping to do.  For one thing, the dpkg command put that "installed-software" file into my Home directory; and since I was in the habit of installing all of my Ubuntu folders into a single partition, I assumed that my Home directory would be wiped out during the 32-bit installation.  So I moved the installed-software file to a different partition.  I already had my other data files, virtual machine folders, etc. on other partitions, with one exception:  my Thunderbird e-mail data was in /home/ray/.mozilla-thunderbird, so I had to copy that over to another drive as well.  My Firefox extensions and settings were backed up to that other partition by the FEBE add-on, so I expected the Firefox part of my reinstallation to go smoothly.

Meanwhile, I was downloading the current version of 32-bit Ubuntu 9.10.  When it finished, I burned it to a CD, inserted the CD in the target machine, and rebooted.  The basic installation did not go too smoothly, though.  For some reason, the newly burned CD booted only once in the target machine.  On later reboots, the machine did not boot from the CD, but instead went on to boot from the hard drive.  I tried booting from the CD with a different program, and in that case the machine booted from the CD as expected.  So I switched to an older Karmic 32-bit CD I found lying around.  That booted without a problem.  But then the system seemed to have gotten confused from the previous efforts, and that installation got hung up and took a long time to get past the partitioning step.  The hard drive was still going, according to the activity light; it was just not going anywhere in particular.

At about the same time, the Internet connection on my secondary computer began acting up.  Suddenly, without warning, I wasn't able to go online.  I decided to try installing 32-bit Ubuntu 9.10 there too, using the newly burned CD.  That installation went fine.  And then it was time to work through a 32-bit version of my typical installation steps, following the process described in my previous posts on installing 64-bit Ubuntu 9.04 and 9.10.

I started by running System > Administration > Update Manager to update the programs installed by the CD.  Then I went into Applications > Ubuntu Software Center > Get Free Software > search for "restricted extras" > Ubuntu restricted extras > Install.  Next, System > Administration > Hardware Drivers searched for available drivers and, for my machine, found NVIDIA accelerated graphics driver (version 185) (because I had an NVIDIA video card) > Activate.  This gave me an error:

SystemError:  Failed to lock /var/cache/apt/archives/lock

I wondered if this was because I had not yet rebooted the machine after downloading and installing the initial batch of updates. A reboot got me past that error, but now I had a new one:

SystemError: installArchives() failed.

I tried installing the older (version 173) driver instead.   That seemed to go OK.  It said, "You need to restart the computer to activate this driver," but meanwhile I had gotten started on the next step, so again I deferred rebooting.  That next step was System > Administration > Software Sources > Ubuntu Software tab > Download From > Other > Select Best Server > Choose Server (whichever one it highlights) > Close > Reload.  Then I went back into Software Sources > Other Software tab > select the two entries that are already there > Add.  To get the APT line it was requesting, I opened Firefox and went to the X-Updates website, clicked on "Technical details about this PPA," specified Karmic, and copied the two deb lines there, one at a time, into the APT line, clicking "Add Source" after each.  Next, on that same webpage, below the deb lines, I found the "Signing Key."  In this case, it was "1024R/AF1CDFA9."  I copied the portion after the slash (i.e., AF1CDFA9) and entered it into Terminal at the end of a one-line command, as follows:

sudo apt-key adv --keyserver keyserver.ubuntu.com --recv-keys AF1CDFA9

This gave me this output in Terminal:

gpg: key AF1CDFA9: "Launchpad PPA for Ubuntu-X" not changed
gpg: Total number processed: 1
gpg: unchanged: 1

I suspected this meant that one or more of my steps had accomplished nothing.  Then I clicked Close > Reload.  (From a previous installation, I had a note to myself:  If you don't get a "Reload" option when you click Close, go back into Third-Party Software and unclick and then re-click some item and try again.  That step was not needed this time.)  Also, by typing "sudo gedit /etc/apt/sources.list," I was able to verify that there were no hash marks in front of the lines for the Universe and Multiverse repositories, which apparently meant they were already available.  The other repository I wanted was the Medibuntu, which I added by using these three commands:

sudo wget --output-document=/etc/apt/sources.list.d/medibuntu.list http://www.medibuntu.org/sources.list.d/$(lsb_release -cs).list && sudo apt-get --quiet update && sudo apt-get --yes --quiet --allow-unauthenticated install medibuntu-keyring && sudo apt-get --quiet update

sudo apt-get --yes install app-install-data-medibuntu apport-hooks-medibuntu

sudo apt-get install libdvdcss2

After installing the Medibuntu repository, I realized that possibly my only reason for having it had been an attempt to make some things work on my 64-bit installation.  But soon I was to discover that I could use it to install Google Earth too.

The next step was to try the other half of the tip mentioned above.  I copied the  "installed-software" file back to my Home folder and maneuvered the Terminal cursor to that location (cd /home/ray) and then entered the needed commands:

    sudo dpkg --set-selections < installed-software

    sudo apt-get install dselect

    sudo dselect

This started dselect.  There, I went into Access and selected APT Acquisition.  It asked whether I wanted to overwrite the sources list mentioned above.  I said no.  This put me back at the next item on the menu, Update; and when I went with that, it updated something and then put me to the next item, Select.  Here, I paged through thousands of packages, not sure of what I was looking for, not seeing anything marked with boldface or "Y" instead of "n."  I bailed out of that -- it wasn't easy, but I used some uncertain combination of Esc, Q, X, space, and Enter -- and that took me to the Install menu option.  This appeared to be what I was looking for.  When I chose this one, it said it was going to get 390MB of archives and use 924MB of additional disk space, which sounded like a lot of installing and updating.  The first couple of items that it seemed to be downloading did appear on the installed-software list, so it all looked good.  But then my network connection died, so I had to start dselect again.  This time, I went directly to the Install option.  It seemed to resume where it left off, and after a while it finished downloading and began adding and removing stuff.   Then it wanted to reboot, and that was fine with me.

Previously, when I had installed 64-bit Ubuntu 9.10, I had manually added a number of programs through System > Administration > Synaptic, including particularly these:  boinc; boinc-manager; dvgrab; fdutils; gparted; mplayer; ntfs-config; ntfsprogs; p7zip-full; sysinfo; and webhttrack.  Now I checked Synaptic to see which of those had been reinstalled through the dselect process. Well, it had worked.  Every one of them had been reinstalled.  I tried System > Administration > Update Manager > Check.  It confirmed it:  everything was up to date.  That dselect process was one smooth play.  What a remarkable improvement over the Windows reinstallation process!

While I was in Synaptic, I installed googleearth (already mentioned above).  I also kept Thunderbird on only one computer because, for the time being, I didn't want to worry about keeping Address Books and Inboxes synchronized across multiple computers.  Also, after I later installed AutoFsck from a .deb download, I discovered that it, too, was in Synaptic.

Next, I installed FEBE and used it to restore my previous Firefox setup.  Unlike my previous attempt, this time I did succeed in using a FEBE backup from Windows XP to restore my Firefox add-ons and settings in Ubuntu.  I installed Google Chrome, checked to verify that Opera was still not available through Synaptic, downloaded it from its website, and double-clicked on the .deb download to install it.

I had just sent an e-mail to VMware, asking if they would allow me to downgrade my recently purchased 64-bit Workstation 7 license into a 32-bit Workstation license.  Hoping to receive a favorable answer from them, whenever they would get back to me, I went ahead and installed the 32-bit version for at least their 30-day trial period. Workstation 7 came as a .bundle file, which required the same installation steps as .bin files.  In Terminal, I navigated to the folder where I had put the download, and then typed these two commands:

sudo chmod +x VMware-Workstation-Full-7.0.1-227600.i386.bundle 

sudo ./VMware-Workstation-Full-7.0.1-227600.i386.bundle

Next, to set up my partitions so that they would be mounted automatically, I used these commands:

sudo ntfs-config
sudo gedit /etc/fstab
sudo gparted [entered in a separate Terminal session]
sudo blkid [entered in a separate Terminal session]

The first one, "sudo ntfs-config," would open a dialog offering to let me include any partitions that were not presently mounted.  It also offered write support for both internal and external devices, which I accepted, and then it modified the fstab file to include lines for ntfs partitions.  The next command, "sudo gedit /etc/fstab," opened the fstab file for manual adjustment.  Then "sudo gparted" opened the GParted program so that I could see what partitions existed, in case I wanted to add any more partitions to fstab, and "sudo blkid" told me what their UUIDs were.  This information resulted in arrangements and additions to fstab so that my partitions were in an order I liked, with explanatory comments (preceded by #), using UUIDs rather than partition names where possible, so that the fstab commands would still work if I renamed the partitions.  Examples of the results looked like this:

# Entry for /dev/sdb2 [a Linux ext3 partition] :

UUID=9cec5b4d-7e72-42a9-86ee-b59c16e6410f /media/VMS ext3 defaults 0 0

# Entry for /dev/sdb3 [a Windows partition] :

UUID=5B56363D59D5E95C /media/CURRENT ntfs-3g defaults,locale=en_US.UTF-8 0 0

Next, I did some configuring.  I went into Nautilus > Edit > Preferences and made changes there.  To prevent icons for mounted drives from appearing on the desktop, I typed "gconf-editor" and went into apps/nautilus/desktop, unclicked volumes_visible, and closed Configuration Editor.

In System > Preferences > Startup Applications, I added Chrome, Firefox, and VMware Workstation.  To get the necessary information for that, I right-clicked on the top panel near "Applications" and chose Edit Menus, then selected the item in question and right-clicked for its Properties.  To configure boinc, I went to Applications > System Tools > BOINC Manager > Next and, in the Choose a Project window, I typed in the URL (in my case, http://www.worldcommunitygrid.org/).  (I had already gone to that site and set up an account.)  Then I logged in, and back in the BOINC Manager I adjusted my preferences.

I wanted Grub2 to boot up whatever operating system I had used last, instead of always defaulting to Ubuntu, so I typed "sudo gedit /etc/default/grub"; I changed one line to say GRUB_DEFAULT=saved instead of GRUB_DEFAULT=0; I saved and closed that file; and then I typed "sudo update-grub."

Reviewing my previous post on scheduling things, I wanted gedit to be my default crontab editor, so I typed "gedit /home/ray/.bashrc" and, at the end of that file, I added a new line that said "export EDITOR=gedit" and then saved and closed .bashrc.  I had developed scripts that I wanted to run on regular occasions, so I put those in a folder on a partition that would not be wiped out if I reinstalled Ubuntu.  Then I set up recurrent entries in Applications > System Tools > Scheduled Tasks.

Among the partitions listed in fstab, I wanted some to be available to ordinary mortals (namely, me) instead of having to become root (i.e., use sudo) to mount and access them.  To do this, I typed "sudo mount -a."  This gave me an error for one partition:  "mount point /media/[partition name] does not exist."  It was an ext3 partition so, in fstab, I changed its options to be like those shown for the VMS partition (above) and then typed the following three lines (using the CURRENT partition as an example):

sudo mkdir /media /CURRENT

sudo mount -t ext3 /dev/sda3 /media/CURRENT

sudo chmod 777 /media/CURRENT

To configure VMware Workstation, I typed "sudo vmware" and went into Edit > Preferences and set as many settings as possible. I verified that the 32-bit version of Workstation was able to open the VMs I had created in the 64-bit version.  I changed Settings for each VM as needed.  (I had to resume and then shut down those VMs that had been merely suspended.)  The 32-bit version of Workstation would allow a maximum of only about 3GB of RAM.  I had hoped that meant "per session," but, alas, that was not the case; the 32-bit operating system was able to recognize only about 3GB total, even though I had considerably more than that in the system.  Within Workstation's Edit > Preferences > Memory, the maximum available for VMs seemed to be 2966MB, and I had set Workstation to use 2500MB, so as to keep some RAM available for processes in Ubuntu.  I preferred to set my VMs not to swap, for speed -- that is, to keep everything in RAM.  So when I opened one VM with 1504MB allotted to it, and then started another session of Workstation and tried to open a VM that needed 1024MB, the second one told me that only 536MB was available.  This suggested that, of the 2500MB I had made available to Workstation, about 2040MB was available for VMs.  So there seemed to be an overhead of about 230MB per VM.  I set each VM to use 1000MB and was able to open two at once.

I then exited that root session of Workstation, restarted Workstation from Applications > System Tools > VMware Workstation, and verified that the VMs worked properly for the ordinary user.  One of the things I had to adjust, in the VMs, was that audio volume was low; I had to turn it up in Ubuntu first, and then adjust it in the Windows XP VM.  I was pleased to see that the stuttering problem I had had in 64-bit Workstation was gone, though there was some undesirable static.  Also, a renamed partition was no longer shared; I had to remove the old one from VM > Settings and add the one with the new name, and then reboot the VM.  I had to change the Network Connection from Bridged to NAT.  Inside the VM, I right-clicked on each partition name to change it from the long form (e.g., "Vms on 'vmware-host\Shared Folders'") to the short form (e.g., VMs).

It seemed likely that I would be continuing to tweak and refine the setup, but for now, this appeared to give me a good working situation.  It seemed that the 32-bit downgrade had been a good idea; I really hadn't encountered any of the strange things that had complicated life in the 64-bit world.

Plugins Needed in Ubuntu 9.10

I was trying to play a .wav file in 64-bit Ubuntu 9.10 (Karmic Koala).  (This was a compressed .wav in 4-bit 22 kHz IMA ADPCM format.)  I double-clicked on it in Nautilus.  Movie Player opened up and gave me this message:

Search for suitable plugin?

The required software to play this file is not installed.  You need to install suitable plugins to play media files.  Do you want to search for a plugin that supports the selected file?

The search will also include software which is not officially supported.

I went with that.  Unfortunately, the next message said this:

No packages with the requested plugins found.

The requested plugins are:

image/vnd.microsoft.icon decoder

I clicked OK.  That gave me another message:

An error occurred

The playback of this movie requires a image/vnd.microsoft.icon decoder plugin which is not installed.

A search for relevant terms led to a thread in which someone asked whether the user had "the w32codecs" installed.  I didn't see that package in Synaptic.  But then someone else in that thread said maybe I wouldn't need it for my 64-bit Ubuntu.  One person pointed toward an extended tutorial in setting up multimedia in Ubuntu.  There was some discussion on whether 32-bit codecs (e.g., w32codecs) were necessary in a 64-bit system; the consensus (supported, of course, by the actual error message on my system) was that they might well be.  The same opinion emerged in another discussion.  The way to get those 32-bit codecs seemed to be, first, to add the Medibuntu repository to my Ubuntu installation.  The simple way to do this was to cut and paste this command into Terminal:

sudo wget --output-document=/etc/apt/sources.list.d/medibuntu.list http://www.medibuntu.org/sources.list.d/$(lsb_release -cs).list && sudo apt-get --quiet update && sudo apt-get --yes --quiet --allow-unauthenticated install medibuntu-keyring && sudo apt-get --quiet update

all on one line.  For additional multimedia options and capabilities and such, it was also recommended that I enter these commands:

sudo apt-get --yes install app-install-data-medibuntu apport-hooks-medibuntu

sudo apt-get install libdvdcss2

sudo apt-get install w64codecs

So I did that.  This all went smoothly.  I was now able to play other .wav files, but I was not able to play that particular one.  I tried playing it in Windows, using IrfanView, and got these error messages:

[filename]:  Can't read file header !

Unknown file format or file not found !

IrfanView: i_view32.exe - Corrupt File

The file or directory [filename] is corrupt and unreadable.  Please run the Chkdsk utility.

So possibly that was why Ubuntu had been unable to play it.  I had checked its properties in Ubuntu, but had not seen any such message.

Long-Term Backup Verification: Beyond Compare, in Windows and Ubuntu

Some time back, I had looked into software that would verify that I was not losing data without realizing it. Data could disappear, as I have discovered, when files become corrupted but continue to look the same (until you try to open them). Data could also disappear if files quietly vanish through unnoticed mistakes (e.g., hitting Delete when an archival folder is highlighted). I had a backup system, in other words, but I lacked a way of checking whether anything might be falling through the cracks. The programs I had examined in my previous investigation had not turned out to be quite what I was looking for, so I still had this need.

Then I became aware of Beyond Compare from Scooter Software. BC had gotten a lot of very positive reviews from programmers and other users here and there. It came with a 30-day free trial offer, after which it would cost me $30. Amid praises that sometimes seemed to come from BC's own friends and/or employees, there were also references to Araxis Merge, which some considered much superior. After expiration of the trial period, it was available for $169/259 (standard/professional), but there was supposedly an academic discount of about 70%. Araxis Merge didn't offer a Linux version. There were also a number of other file and folder comparison tools, some of which were free but few of which offered CRC checksum calculation, which I wanted. I decided to start with BC and see how that went.

First Try: Ubuntu Installation

There were versions of BC for Windows and for Linux. In the spirit of my gradual, long-term effort to move away from Windows, I decided to start by trying the Linux version of the program. I was running 64-bit Ubuntu 9.04 (Jaunty Jackalope). Beyond Compare was a 32-bit program.

The 32-bit version may have been very easy to install. But it seemed I would have to make some adjustments in order to run this program on my 64-bit system. I found two different sets of advice on how to make those adjustments. One was for running BC on 32-bit Kubuntu 8.04. I figured it would probably work, if I wanted to try it. But the other was for Ubuntu 9.04, so I decided to try that one.

Following the latter set of instructions, I downloaded the .tar.gz version of BC. Ordinarily, it seems, it would have been necessary to download ia32-libs and libqt3-mt; but in my way of installing Ubuntu, Synaptic showed that these packages were already installed. I unzipped (technically, I guess, I should say untarred) the file by using the "tar -zxf [filename]" format instead of the "tar -vxf [filename]" format that I had previously decided I should use. (I was definitely still in a learning mode for purposes of Ubuntu commands.) Just out of curiosity, I deleted the resulting folder, went into a WinXP VM, right-clicked on the .tar.gz file, and told 7Zip (one of my Windows XP utilities, with a right-click context menu option) to unzip it. It did. Once again, I had that folder containing a file called bcompare-3.1.4.10554.tar. So if, like me, you weren't smart enough to just right-click on the tar.gz file and select Open with Archive Manager > Extract, you could do it this other way. Actually, in this case, the Windows approach may have been superior, because when I did belatedly try the Archive Manager approach, I got "An error occurred while extracting files." So I went back and did it with Windows again after all. This gave me a much larger .tar archive. I used 7zip in WinXP again on this .tar file. Now I had a regular folder called bcompare-3.1.4.10554.

I decided to continue trying the GUI approach. In Ubuntu's File Browser, I went into the unzipped folder and double-clicked on install.sh. I got a dialog asking, "Do you want to run 'install.sh', or display its contents?" I chose Run. Nothing seemed to happen. I went back to Terminal, navigated into that folder, and (reverting to the instructions) typed "sudo ./install sh". Now it seemed to install. At the end of its various messages, it said, "Please place the following in your .bashrc or .cshrc (etc.): export PATH=/home/ray/bin:$PATH," where "ray" was my username. It also said, "Executable is /home/ray/bin/bcompare." It was apparently telling me that I had to add /home/ray/bin to my computer's path, so that the program would know where to look when I typed "bcompare" (or whatever) to start the program.

I tried just typing "bcompare" right where I was in Terminal, but no joy. So I navigated over to where it said it had installed itself: "cd /home/ray/bin." Sure enough, there was a file called "bcompare." But when I typed "bcompare" there, I just got "command not found." Double-clicking on bcompare didn't do anything either. The installation instructions cited above said nothing about this. Was I supposed to make it executable? I typed "chmod +x bcompare" and then typed "bcompare" again, but this still just gave me "command not found."

It seemed I would have to figure out how to add something to my path, though I didn't understand what good that would be, if the damn thing wasn't executable. I found instructions that seemed to work, or at least they got me to an open .bashrc file. I didn't find any path lines in that file to use as a model, so I gathered that I was just supposed to type exactly what they said. I added it at the end of the .bashrc file as follows:

# add Beyond Compare to path [this is a non-executing comment]

export PATH=/home/ray/bin:$PATH

I saved and closed .bashrc. I opened a new Terminal session and typed "bcompare" at the $ prompt. It said "bcompare: command not found." I navigated to /home/ray/bin and tried again. Same result. I decided to back up and try the approach from that other webpage, the one that was supposed to work in Kubuntu 8.04 with the .deb download. Given ia32-libs and libqt3-mt (above), it now appeared that I had assumed that the installation of these libraries meant that the files I needed were installed in the right places -- that, in other words, Synaptic had already taken care of putting those lib files in their proper places. But now it seemed that I should have copied over program files from one folder to another. Putting this Kubuntu approach on hold, I reverted to the instructions from the approach I had already worked through. Specifically, the first command I apparently needed to enter was:

dpkg-deb --extract libqt3-mt_3.3.8-b-5ubuntu1_i386.deb libqt3-mt

changing the specific libqt3-mt file name as needed. But at this point, not knowing what particular file that might be, I said to hell with it and downloaded the Windows version instead. I then looked for a way to uninstall this version of Beyond Compare from my Ubuntu installation; but since I had not used Synaptic to install it, I did not seem to be finding uninstallation instructions that applied. So it's still installed.

Second Try: Windows XP Installation

I downloaded and ran the WinXP installer. Interestingly, they had an option to create a "portable install," which could apparently be put on a removable USB drive or wherever, without making any changes to the registry. Presumably it would still fail to work after the 30-day trial period unless I bought a license. But if I was going to keep the program, this would definitely be a useful form for it. So I went with that approach. (One special advantage of this approach, for my purposes, was that I could put it on a drive other than drive C, within my computer, and could therefore make it available to all of my virtual machines under VMware Workstation, without having to reinstall it on each VM.)

The program seemed good. I was impressed with the comparisons. When I tried to use its help feature, I got an error message, "Navigation to the webpage was canceled." I searched the database and didn't find anything, so I sent Scooter Software an e-mail about that.

The folder comparison feature was very smooth. Folders were color-coded according to whether they matched or not. Black folders matched -- that is, they were identical. Other colors seemed to indicate some degree of mismatch. Lacking the help feature, I looked for a user's manual on the website. All they had was a bunch of knowledgebase articles. I'm sure these were very helpful for some purposes, but their titles revealed none on the subject of folder contents or colors. Nonetheless, when I clicked on a purple folder, I saw that only one of its subfolders differed. Eventually, I found that I could actually configure my own preferred colors for the following statuses: same (i.e., the folders in the two comparison panes are the same), orphan, older, newer, and different. There were also color options for file comparisons.

Cool feature: when you click on a folder on one side of the comparison screen, the problem automatically opens the parallel folder on the other side. In other words, I'm looking into a subfolder on drive F, and it's opening up that folder for me; but at the same time it's also opening the comparison subfolder on drive H. With just this much knowledge, within about a minute after starting to fool with the program for the first time, I was able to detect that there was one varying file, nested seven layers down, in a folder containing almost 30,000 files. As far as I could tell, the difference was that the filename for the one had been truncated.

One thing that I didn't find was the ability to reload an old comparison log and compare it against a new drive. For example, suppose that, on December 31, 2007, I burn a CD to archive some files. I compare that CD against the source folder on the hard drive. Everything looks good. Then, sometime during 2008, something happens and it appears that I may have lost some stuff from the hard drive. What did I lose? I don't know, because the hard drive has changed by now, and unfortunately I can't find the CD. Ah, but if I could run a comparison of the hard drive's current state against the previously saved log comparing the hard drive and the CD on December 31, 2007, at least I could know what might be missing and take appropriate steps to replace or compensate for it. Another scenario: I back up my data every year, and now I want to see a single list of all the changes in my folders since 2003.

About this time, I realized that I had not actually examined the support forums at Scooter Software. As it turned out, there were several hundred threads in those forums. Some of them appeared to be exchanges between the proprietor of Scooter Software and his chief programmer, but whatever; it was still good to see the effort and interest in the product.

There was a lot more that I wanted to try with Beyond Compare, but I was not quite set up for some of that, so this is where the matter stopped for the time being.

Configuring 64-bit Ubuntu 9.04 with Vista Dual-Boot

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

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

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

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

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