Windows 7: Problem Copying to eSATA Drive

I was running Windows 7 Ultimate.  I was copying files from an internal SATA hard drive to an external SATA drive via eSATA cable.  The external unit consisted of an internal drive inside a Rosewill RX-358-S SLV external enclosure.  I was copying files just fine, and then suddenly I got this error message:

Problem Copying

An error has occurred.

The destination you have specified does not exist.  It might be an offline network location or an empty CD or DVD drive.  Check the location and try again.

I noticed that the in-use light on the external enclosure was now constantly lit.  I also saw that the external drive was now missing from the folders pane in Windows Explorer.  I had done similar copying operations in recent days.  This was the first time I had had this problem on this new computer installation.

I did a search for part of that error message.  One thread contained a bunch of suggestions that did not apply to my situation, and so did another.  But I did notice a suggestion that looked like it might help.  To apply that suggestion, I had to get the drive back.  To do that, I rebooted and hoped that Windows Explorer would see it once again.  It did.  So the suggestion, in Vista terms, was to right-click on the drive in My Computer (or in the Windows Explorer folders pane) and go into Properties > Hardware tab > select the drive > Properties > Policies tab > select the "Optimized for performance" option.  I didn't have that option.  There was a write-caching option, but that didn't seem to explain the sudden disappearance of an entire drive.  I could have set Control Panel > System > Advanced system settings > Advanced tab for best performance of background services, but (a) I didn't want to change the whole system for the sake of this one task and (b) I didn't want to prioritize background services.

I tried a different search.  This Rosewill unit had both eSATA and USB connectors.  I was using eSATA because it was much faster.  It had the drawback of requiring a reboot to be recognized.  One poster indicated that s/he had the same problem as I, but only when using his/her unit's eSATA rather than its USB connection.  Otherwise, I was not finding a solution.  I restarted the copying process, still using the eSATA port.  The problem did not recur that day.  I decided to wrap up this post and follow it with another if the problem recurred.

Dual-Boot RAID 0: Ubuntu 10.04 and Windows XP

I wanted to set up a SATA RAID 0 array that would function like any other dual-boot system:  I would turn on the computer; it would do its initial self-check; I would see a GRUB menu; and I would choose to go into either Windows XP or Ubuntu 10.04 from there.  This post describes the process of setting up that array.

With no drives other than my two identical, unformatted SATA drives connected, I turned on the computer.  The BIOS for my Gigabyte motherboard did not give me the obvious RAID configuration option I had hoped for.  I hit DEL to go into BIOS setup.  Nothing jumped out at me.  Desperate for guidance, I turned to the manual.  I was looking at an Award Software CMOS Setup Utility.  The manual directed me to its Integrated Peripherals section.  There, I set OnChip SATA Controller to Enabled, OnChip SATA Type to RAID, and OnChip SATA Port4/5 Type to As SATA Type.  I hit F10 to save and exit.

According to the manual, that little maneuver was supposed to give me an option, after the initial boot screen, to hit Ctrl-F and go into the RAID configuration utility.  Instead, the next thing I got was this:

Press [Space] key to skip, or other key to continue...

I didn't do anything.  In scanned my drives and then led on to the Ctrl-F option.  I rebooted and tried it again.  Hitting the space key led to the same result.  Ctrl-F opened the AMD FastBuild Utility.  I hit option 2 to define an array.  This gave me a list of my two drives, labeled as LD 1 and LD 2.  Apparently it wasn't supposed to show anything.  LD was short for "logical disk set."  It was essentially showing two separate arrays, each having one drive.  So although the manual didn't say so, it seemed that I needed to get out of here and go into option 3 to delete these arrays.  I did that and then went back into option 2.  Now I was looking at a blank list of LDs, just like in the manual.

So now I was ready to prepare my array.  In option 2, I hit Enter to select LD 1.  This defaulted to RAID 0 with zero drives assigned to it.  I arrowed down to the Assignment area and put Y next to each of the two drives listed.  Now it said there were two drives assigned.  But now I had a couple of things to research.  The screen was giving me options for Stripe Block, Fast Initialize, Gigabyte Boundary, and Cache Mode.  The manual didn't say what these were.

I did a search for information on the Stripe Block size.  I found an old AnandTech article that took the approach of choosing the lowest stripe size where performance tended to level out -- where, that is, increasing the stripe size another notch did not increase performance.  For the RAID controllers they were testing, it looked like performance kept increasing right up to the range of 256KB to 512KB, for those controllers whose options went that high.  Mine only gave me a choice between 64KB and 128KB, so I chose the latter.  A more recent discussion thread seemed to support that decision.

Regarding the "Fast Init" option, a search led to some advice saying that slow initialize would take longer but would improve reliability.  A different webpage clarified that the difference was that slow initialize would physically check the disk and would be suitable if you had had trouble with the disk or if you suspected it had bad blocks.  I decided to stay with the default, which was Fast Init ON.

The "Gigabyte Boundary" option would reportedly make the larger of two slightly mismatched drives in an array behave as though it were the same size as the smaller one.  The concept appeared to be that, if you were backing up one drive with another (which was not the case with a RAID 0 array), you would use this so that the larger drive would never contain more data than the smaller drive could copy.  Mine was set to ON by default.  I couldn't quite understand why anyone would need to turn it off, even if the drives were the same size.

Finally, the "Cache Mode" option was apparently capable of offering different choices (e.g., write-back), but mine was fixed at WriteThru with no other options available.  So I thought about it a long time and then decided this was acceptable to me.  So then I hit Ctrl-Y to save these settings.  Now I was back at the Define LD Menu, but this time it showed a RAID 0 array with two drives and Functional status.  That seemed to be all I could do there, so I exited that menu.  I poked around the other options on the Main Menu.  I seemed to be done with the FastBuild Utility.

Next, the manual wanted me to use a floppy disk to install the SATA RAID driver.  I could have just gone ahead and done that -- I still had a floppy drive and some blank diskettes -- but I thought surely there must be a better way by now.  Apparently there was:  use Vista instead of WinXP.  But if you were determined to use XP, as I was, the choices seemed to be either to go through a complex slipstreaming process or use the floppy.

There was, however, another option.  I could buy a RAID controller card, for as little as $30 or as much as $1,000+, and it might come with SATA drivers on CD.  This raised the question of whether the RAID cards actually had some advantage beyond their included CD.  My brief investigation suggested that a dedicated RAID card could handle the processing task, taking that load off the CPU, but that there wasn't much of a processing task in the case of RAID 0.  In other words, for my purposes, a RAID controller card wouldn't likely add any performance improvement.  Someone said it could even impair performance if it was a regular PCI card (as distinct from e.g., PCIe) or if its onboard processor was slower than the computer's main CPU.  There did seem to be a portability advantage, though:  moving the array to a different motherboard would require its re-creation, in at least some cases, but bringing along the controller card would eliminate that need -- though the flip side was that the card might fail first, taking the array with it.

Further reading led to the distinction between hardware and software RAID.  An older article made me think that the essential difference (since they all use hardware and software) was that software RAID would be done by the operating system and would run on the CPU, and would therefore be dependent upon the operating system -- raising the question of whether dual-booting would be impossible in a software RAID array, as a generally informative Wikipedia article suggested.  To get more specific, I looked at the manual for a popular motherboard, the Gigabyte GA-MA785GM-US2H.  That unit's onboard RAID controller, plainly enough, was like mine:  it depended upon the operating system.  Wikipedia said that cheap controller cards provide a "fake RAID" service of handling early-stage bootup, without an onboard processor to take any of the load off the CPU.  FakeRAID seemed to get mixed reviews.

An alternative, hinted at in one or two things I read, was simply to set up the RAID 0 array for the operating system in need of speed, and install a separate hard drive for the other operating system.  I was interested in speeding up Linux, so that would be the one that would get the RAID array.  I rarely ran Windows on that machine, so any hard drive would do.  A look into older, smaller, and otherwise seemingly less costly drives led to the conclusion that I should pretty much expect to get a 300GB+ hard drive, at a new price of around $45.  Since I was planning to use Windows infrequently on that machine, it was also possible that I could come up with some kind of WinXP on USB solution, and just boot the machine with a flash drive whenever I needed access to the Windows installation there.

I decided that, for the time being, I would focus on just setting up the Ubuntu part of this dual-boot system, and would decide what do to about the Windows part after that.  I have described the Ubuntu RAID 0 setup in another post.

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.

Installing Ubuntu 9.04: External USB Drive

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

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

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

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


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

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

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

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

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

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

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

* * * * *

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

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

Logical C:

Detected file systems:

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

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

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

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

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

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

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

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

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

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

Windows Boot Manager

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

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

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

Ubuntu 9.04: Error While Copying; Folder Contents Not Displayed; Input/Output Error

I was using Ubuntu 9.04 (Jaunty Jackalope) with an internal drive and an external USB hard drive. The latter was a Seagate SATA in a Rosewill RX-358-S SLV enclosure. I copied and pasted a 16GB folder from the internal drive to the USB drive. Those 16GB consisted of 13 files, among which was one large (15GB) VMware virtual disk. The folder I was copying was named VMs. When I copied that folder from the internal drive to the external drive, I got this message:

Error while copying to 'VMs'.

There was an error getting information about the destination.

When I showed more details, it said this:

Error stating file '/media/OFFSITE/VMs': Input/output error

I didn't know what it meant when it referred to "stating" file. Regardless, when I clicked on the target (external) folder, I got this message:

The folder contents could not be displayed.

Sorry, could not display all the contents of [folder name]: Input/output error.

I got the same error message when trying to view the contents of other folders on the external drive. Its contents were visible to Windows XP running on a different computer. The computer on which I was having this problem was able to detect the existence of the external drive and could show its folder tree in Nautilus; it just couldn't show the contents of any particular folder on the external drive. Meanwhile, the internal drive seemed to be working normally.

The Rosewill enclosure had eSATA as well as USB connectors. The same error messages came up with both. One source suggested that the external enclosure's power supply could be malfunctioning. Since Windows could read the drive, I doubted that was the explanation. I had had this problem previously, and had used ntfs-config to solve it, which is why I had installed ntfs-config when setting up the system this time. But the procedure I had most recently used didn't solve the problem this time. Reviewing earlier efforts, I typed "df -h" and confirmed that the external drive (/media/OFFSITE) was indeed at /dev/sdd5, as I had indicated in /etc/fstab. In that case, the advice of pablopancho would be to type "sudo ntfsfix /dev/sdd5" (which should run, at least, because ntfsfix was part of ntfsprogs, which was another program that I was now learning to install when setting up the system, anticipating that I would have NTFS drive problems at some point). This gave me error messages stating a number of failures (e.g., "Failed to determine whether /dev/sdd5 is mounted: No such file or directory" and "Failed to startup volume: No such file or directory") and concluding with this advice: "Volume is corrupt. You should run chkdsk."

So, OK, I connected the external drive to the WinXP machine again and rebooted it from the Windows installation CD. I went into Recovery Mode and ran "chkdsk /r." Chkdsk got only 54% of the way through the job and then stopped and said, "The volume appears to contain one or more unrecoverable problems." I rebooted with the Gparted live CD and told it to check the external drive. It did not complete that operation; instead, it said, "An error occurred while applying the operations." Fortunately, this occurred on a backup drive, so I was able to skip the attempt to recover its data; I figured I would just repartition it and start over.

Before repartitioning, though, just out of curiosity, I booted my laptop into Vista, connected the external drive to that, and was able to copy data from the external drive to the laptop. I assume I would have been able to do the same from a Windows XP machine, but I didn't try. As had happened to me previously, I was finding that Ubuntu seemed to be more concerned about drive imperfections than Windows was. I wanted the drive to be fixed, of course, so I went looking for the way to repair hard drives in Vista. It seemed that Vista was similar to XP in this regard: in Windows Explorer, I clicked on the external drive, right-clicked and selected Properties > Tools > Error-checking. I ran both the "Automatically fix" and the "Scan for" options. It began processing files, one at a time, very slowly. It took hours. In fact, after six hours, judging by its progress bar, it had only processed about one-tenth of the total contents of the drive. Granted, it was a 1TB drive with about 800GB of data. Vista might have finished with a 300GB drive, at this rate, in 24 hours or less. I wasn't inclined to let it churn away for a week, so I canceled. If this process was actually succeeding in recovering data, then I had to say that Vista seemed, at this point, to include an impressive file-recovery capability. But whatever.

I bailed out and took a look at the drive, or tried to. Now Vista said, "Location is not available. F:\ is not accessible. Access is denied." So I tried reformatting the drive. But formatting itself looked like it was going to take hours, so I tried to cancel. Unfortunately, Vista said, "The format could not be interrupted. To attempt to quit formatting again, click Retry. To quit immediately, click Cancel." Retry didn't work, so I used Cancel. I rebooted from the Vista installation CD and went into the Repair Your Computer > Command Prompt option. Chkdsk /? gave me the idea of trying "chkdsk f: /f," but that said "Cannot open volume for direct access." Rebooting back to regular Vista, I clicked on drive F in Windows Explorer. It was now showing as just "Local Disk (F:)," not as the OFFSITE drive. When I clicked on it, Vista said, "You need to format the disk in drive F: before you can use it." So I went with that. But after running all night, and showing what looked like progress to completion on its progress bar, it said, "Windows was unable to complete the format." I rebooted into Ubuntu and tried Partition Manager (Gparted) again. It still showed the drive as being partitioned, but in an unknown format. Since I was no longer trying to save the data, I deleted the partition on that drive and then created a new extended partition and a logical partition, within the extended partition, filling the whole drive, in NTFS format. But the second step didn't complete; instead, Gparted told me that I had to run Windows chkdsk /f twice on this drive. I did that. Then I booted into WinXP and tried copying some data to the drive. I got this:

Windows - Delayed Write Failed.

Windows was unable to save all the data for the file H:\$Mft. The data has been lost. This error may be caused by a failure of your computer hardware or network connection. Please try to save this file elsewhere.

As it turned out, I had two separate problems here. First, my hard drive was full. I doubt I had ever emptied out the root trash, and it turned out that was the bulk of the problem. I've explored that, and other aspects of making drive space in Ubuntu, in a separate post.


Second, I had to play around by trial and error with some technical steps involved in getting the external drive mounted. I worked through that in a forum post. But now I had a new problem. When I tried now to run an rsync backup process, I got this:

rsync: writefd_unbuffered failed to write 4 bytes [sender]: Broken pipe (32)
rsync: connection unexpectedly closed (490 bytes received so far) [sender]
rsync error: error in rsync protocol data stream (code 12) at io.c(600) [sender=3.0.5]

I had to interrupt this troubleshooting for a couple of days. When I came back to it and tried to run the same rsync backup process, I now got a number of error messages along these lines:

rsync: failed to set times on "/media/OFFSITE/[subfolder]": Input/output error (5)
rsync: recv_generator: failed to stat "media/OFFSITE/[subfolder]/[filename]": Input/output error (5)
*** Skipping any contents from this failed directory ***
rsync: recv_generator: mkdir "/media/OFFSITE/[subfolder]" failed: Input/output error (5)

Taillessmonkey found that the problem disappeared for him/her when s/he replaced the external hard drive enclosure. I happened to find another external drive enclosure on sale at about this time, and bought that. While waiting for it to arrive, I tried connecting the hard drive internally within the computer I was attempting to back up. When the computer started up, it recognized it immediately as the OFFSITE drive, but I still got some instances of that same "recv_generator" error. Actually, just one. Instead, this time I got dozens of "Input/output error" messages arising from an "rsync: rename" attempt to rename nonexistent files. For instance, one of those input/output errors arose from an attempt to rename a file called "DW_B9154.wav.Mw21w0" to be DW_B9154.wav. But there was no Mw21w0 file, or at least there should not have been. I could only guess that rsync was creating temporary copies of files, during its backup process, and was then losing track of those files before it could delete them. I wasn't sure if that was the case, or what to do about it if it was.

I did wonder, though, whether this might be a problem with the source partition rather than the target. With the backup OFFSITE drive still inside the computer, I ran an rsync to back up another partition to OFFSITE. This one worked just fine. I tried another. That one went with only one error. These same drives had produced numerous error messages when I had tried to back up to them in the external drive enclosure. It seemed that maybe I had two problems: one source partition was messed up, and also the external drive enclosure was no longer cooperating with Ubuntu.

Although that other partition had shown only one error in Terminal when I was running rsync with OFFSITE as the target drive, I was in for another surprise. When I checked the folder on OFFSITE to which that partition's contents had supposedly been copied, Nautilus reported that there were no files in that folder. Yet when I tried to manually copy files over from that partition to that folder on OFFSITE, I got a message indicating that the first of the files being copied already existed on the target. (I had set Nautilus to show hidden files, and anyway these were not hidden.) I went ahead and told it to overwrite the files already existing on the target (OFFSITE); and when it was done, what I saw on the target was

[This is as far as I got on this item.  I am only now getting around to replacing the external hard drive enclosure.  Other external drive bays seem to be doing fine with that same hard drive, so I assume the enclosure was much of the problem.]

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.