I was using YUMI to install multiple ISOs on a multiboot USB drive. All of its top-level menu picks worked correctly except one. That one, “Directly Bootable ISOs or Windows XP,” gave me a rapidly scrolling list of “Fatal! Inconsistent data read from” errors. After each iteration of “inconsistent data read from,” it would name some kind of numerical address (e.g., 0x80 3272020888+127). After a number of these iterations, it would put me at a GRUB prompt. This post describes my efforts to fix that problem.
I began with a search that led to solutions that looked likely to be complex and very time-consuming. I wondered if the problem was due to YUMI 0.0.8.1. I searched for a copy of 0.0.7.9, which I had used with more success previously. My search was unsuccessful. I restored a copy from backup and tried starting over with that. I had to reformat the YUMI multiboot drive with Windows in order to wipe out and redo from scratch; the YUMI formatter did not overwrite the drive.
Unfortunately, switching to 0.0.7.9 did not fix the “Fatal!” error. I tried the YUMI drive in another machine, as I should have done before. It did not seem to scroll the same “Fatal!” errors, but it may have done so very rapidly; all I saw was a flash and then the GRUB prompt. I concluded it was indeed a problem with the YUMI drive. Yet that was puzzling. I had used this same 16GB USB drive for a YUMI installation previously, and it had worked on these same machines, using this same version of YUMI. These computers would still boot into Windows with no problem.
Since the problem arose from one particular menu pick within the multiboot drive, I decided to try to understand YUMI’s menu setup. A look at the multiboot drive in Windows Explorer showed me the following contents at the root level (i.e., H:\). All of these items were the names of folders; there were no filenames in the root directory.
The .disk folder contained only an “info” file that contained only one word: “This.” The antivir and avupdate folders seemed to belong to the Avira antivirus ISO that I had installed on the multiboot drive. The fsecure folder obviously belonged to the F-Secure antivirus ISO. The multiboot folder contained subfolders for various ISOs (e.g., GParted, Ubuntu, Knoppix). It also contained certain files that appeared to be key system files for the YUMI system (e.g., grub.exe, syslinux.cfg). I was not quite sure what the system folder was about. The tables folder seemed to belong to the Ophcrack ISO. Files in the TRK folder (e.g., memtest.x86, trinity.ico) suggested that it was for some of the other ISOs I had installed on the USB drive. I guessed, but could not tell for sure, that the trk3 folder was related to the TRK folder.
From those candidates, the multiboot folder seemed to be the place to start. I figured out that the .cfg files in that folder, and in its menu subfolder, were individual menu entries in the YUMI system. The top-level .cfg file seemed to be syslinux.cfg. Viewed in Notepad, its contents were as follows (with line breaks added here for readability, mostly reflecting the appearance in Notepad):
# Menu Entry Created by Lance http://www.pendrivelinux.com for YUMI – (Your USB Multiboot Installer) default vesamenu.c32 prompt 0 timeout 300 menu title Your Universal MultiBoot Installer menu background yumi.png MENU TABMSG http://www.pendrivelinux.com MENU WIDTH 72 MENU MARGIN 10 MENU VSHIFT 3 MENU HSHIFT 6 MENU ROWS 15 MENU TABMSGROW 20 MENU TIMEOUTROW 22 menu color title 1;36;44 #66A0FF #00000000 none menu color hotsel 30;47 #C00000 #DDDDDDDD menu color sel 30;47 #000000 #FFFFFFFF menu color border 30;44 #D00000 #00000000 std menu color scrollbar 30;44 #DDDDDDDD #00000000 none
label Boot from first Hard Drive
menu label Continue to Boot from ^First HD (default)
label Linux Distributions
menu label Linux Distributions ->
MENU INDENT 1
label Antivirus Tools
menu label Antivirus Tools ->
MENU INDENT 1
label Directly Bootable ISOs
menu label Directly Bootable ISOs or Windows XP ->
MENU INDENT 1
label System Tools
menu label System Tools ->
MENU INDENT 1
The very long (wrapped) first line seemed to provide general formatting instructions for how the menu would appear onscreen, among other things. As noted above, the lines that were causing me problems seemed to be under the “Directly Bootable ISOs” label, toward the end of the list. Unlike the others, that item referred, not to kernel vesamenu.c32, but rather to grub.exe. Also, unlike the others, that item’s APPEND command did not link to a subordinate .cfg menu; instead, it named menu.lst. So it seemed that my problem might be connected to either grub.exe or menu.lst.
Advice from RMPrepUSB led me to understand that I was winding up at a Grub4DOS prompt. I hit Esc and found myself at a basic GRUB4DOS window with options for “find /menu.lst” etc., commandline, reboot, or halt. I tried commandline. RMPrepUSB suggested that I might type in the commands and see what would happen. I tried with “KERNEL /multiboot/grub.exe,” though I suspected that would achieve nothing because, as I say, I was already looking at the “grub>” prompt. It said, “Warning! No such command : KERNEL.” I now realized that I could already have told that it would say something like that, because onscreen advice said that hitting the Tab key would give me a list of commands, and — talk about persnickety — kernel was listed there, but lowercase. So, alright, I tried again: “kernel /multiboot/grub.exe.” This time, it gave me “Error 25: Disk read error.” That seemed pretty close to the “Inconsistent data read” error message that had commenced this expedition. But why was it happening?
Had grub.exe or menu.lst somehow become corrupted? I had tried two separate installations, using YUMI 0.0.7.9 and 0.0.8.1, and had wound up with the same “Fatal” error in both cases. In between, I had reformatted the USB drive. And 0.0.7.9 had created successfully working YUMI installations on this same USB drive previously. That didn’t seem like the answer.
I took a look at H:\multiboot\menu\menu.lst. (H was the YUMI drive.) I didn’t know much about how it was supposed to look, but in Notepad it did not look obviously corrupted. It seemed, tentatively, that my problem was with grub.exe, not with menu.lst. I wondered if I could download a replacement for grub.exe. I renamed H:\multiboot\grub.exe to be grub.old, figuring that this would keep it around (in case I needed it) but would render it non-executable. A search led to a recent webpage where I was able to download a copy of grub.exe. Putting that into H:\multiboot changed the situation, but did not solve the problem. That is, I still wound up at a grub> prompt, but without the “Fatal! Inconsistent Data Read” errors. The fact that something had changed suggested that the commands were finding grub.exe, at least.
It seemed that, somehow, two different versions of Grub were operating. As just noted, I had to use “kernel” as a lowercase command, but YUMI was successfully using it (above) as KERNEL. Likewise, the commands shown above use “config-file,” with a hyphen, but pressing Tab at the Grub prompt told me that the proper command was “configfile.”
I tried typing “ls” (that’s lowercase LS) at the grub prompt. It said, “Error 25: Disk read error.” So both the simple file listing command (ls) and the foregoing reference to grub.exe failed because of a disk read problem. Why was Grub unable to read my USB drive?
I tried creating another YUMI drive, using a different USB drive; and on that other YUMI drive I began by just adding one of the items that would appear in the “Directly Bootable ISOs” section. It was the Windows 7 32-bit System Recovery CD. The menu worked properly in this case. So now it appeared the problem might be related to the USB drive — even though that USB drive had functioned correctly in the past.
I repeated the same steps with the problematic drive as with the one that had just worked correctly: reformat it in Windows Explorer, start YUMI, add the Win7 Recovery CD as an Unlisted ISO. When attempting to reformat, I got an error. It said, “Windows was unable to complete the format.” It was showing “Unknown capacity” in the format window. There was something wrong with this drive. A search led to the advice to use Start > Run > diskmgmt.msc > right-click on the USB drive. It was showing as Unallocated, so I selected New Simple Volume. But nothing happened. I plugged it into another computer. It offered to format the USB drive. I accepted the offer. But it was still showing unknown capacity, and Windows was unable to complete the format there too. I tried the HP Drive Key Boot Utility. This was apparently different from the HP USB Disk Storage Format Tool. I wasn’t sure if a USB drive had to be manufactured by HP to use these tools, but this one was. The boot utility said it was not supported for installation on my Windows 7 system. But the format tool worked. When it was done, I successfully reformatted in the usual way, in Windows Explorer, and then installed the Win7 32-bit System Recovery CD on this newly rescued HP USB drive. I tried booting the other computer with that, and it worked.
* * * * *
Update: I spoke too soon. It worked at first, and then stopped working. It stopped working in a weird way. When I would boot with the HP USB drive, it would give me a black screen with just this part of a word showing: “figuration.” It did it consistently, over a half-dozen reboots, so it didn’t seem that the drive was just decaying or something. I wondered whether (a) I had screwed up a menu so that this was all that would show or (b) this had something to do with whatever Steve Si was saying in the December 18 (3:30 AM) comment (below) that he had just posted in response to the foregoing paragraphs.
It didn’t seem like it was a case of a menu screwup on my part. I hadn’t edited syslinux.cfg, which I believed was the first menu that would appear, and anyway the “figuration” string did not appear in that file. It wasn’t getting to menu.lst, not that I had edited that either.
I decided to try to figure out Steve’s comment. RMPrepUSB Tutorial No. 7 said that I could test a USB drive quickly (using the Quick Size Test option in RMPrepUSB) or thoroughly (using H2TESTW). I didn’t want to spend the hours that the latter would take (but did download a copy anyway). I had made a backup of the files on the HP USB drive, so I tried RMPrepUSB, which was going to wipe the disk during its test. Using RMPrepUSB involved obtaining RMPrepUSB. I downloaded RMPrepUSB_Portable_2.1.648wee.zip. (I wasn’t sure why there was a “wee” in the filename.) I extracted the files from the ZIP and ran RMPREPUSB.exe. I selected the HP USB drive and clicked Quick Size Test. For some reason, it minimized several other windows I had open on the screen, including the browser window in which I was typing these notes. But it didn’t close them, so I resumed. The test ran. It indicated that it was going to take about 27 minutes — much more than the 6-10 minutes estimated on the RMPrepUSB website for a drive of this size. I suspected the time required might depend on the condition of the drive — that, in other words, RMPrepUSB might be finding problems on the USB drive. But no, at the end of 27 minutes, it reported that my drive passed the quick test. So, pending a more thorough test, USB drive corruption did not appear to be the reason for my problems.
Steve suggested trying the QEMU Emulator button in RMPrepUSB. I tried to restore the bootable image to the USB drive, using Acronis True Image Home 2011. This would be about the time when I discovered that Acronis did not see USB drives as targets for image restores, at least not without the Universal hardware-independent option which I know I had bought and thought I had installed. So, oops, I guess I may have used the wrong form of backup. A search led to an idea for another search which led to going into Acronis (in Windows 7) and choosing Tools and Utilities > Mount Image > select the image etc. Now I had the Acronis TIB image loaded as a virtual drive and could use Windows Explorer to copy its contents to another folder. In the spirit of experimentation, I copied those files to the newly reformatted HP USB drive. I realized this would not be bootable. I was hoping to achieve a “Boot error” message, because that’s what I had managed to achieve on the other, 32GB Patriot USB drive by this point. Symmetry. That’s what it’s all about: symmetry. Anticipating some such development, while the files were copying — and, anyway, to try to rescue that Patriot drive — I did a search and formed the belief that the problem could be in the BIOS settings on the computer I was trying to boot. But the computer in question at this moment was an ASUS Eee PC with virtually no options to adjust. I had already tried setting the boot flag on the Patriot in GParted, with no luck.
The situation at this point was overwhelming, not to say fubar. With a whiff of desperation in the air, I resorted to the possibility of biting the bullet and doing this the hard, painful RMPrepUSB way. The logic, here, was that I had used the HP tool on an HP drive and yet said drive was still recalcitrant, whereas good Steve quoth that this was not surprising. He seemed to have the answer. I examined that possibility in another post.
* * * * *
Later (after the comment shown below), I came back here. RMPrepUSB had not turned out to be my preferred tool after all. I knew that YUMI had worked for me. It seemed my problem had to be with the USB drive, or somewhere else in the process. One thing I noticed was that YUMI did not always actually format a USB drive when I checked the Format option. It would just flash an error message and proceed on to load the requested ISO onto the USB drive. So I had to do a separate formatting process to be sure. I also noticed that Windows Explorer > right-click > Format sometimes had problems formatting. I found it handy to use MiniTool Partition Wizard to be sure. There also seemed to be a situation where the computer would get confused, and it would be better to take such steps after rebooting, or on another machine. I wasn’t sure about all this; these were just impressions or possibilities.
I was not entirely sure what caused the problem to be sorted out, in the end. My sense was that proper formatting of the USB drive was a factor. At some point, the problem disappeared, apparently due to continued tinkering along the lines described above.