YUMI Multiboot USB Drive: Adding an Unlisted IMG (not ISO)

I had taken several steps to produce a working YUMI multiboot USB drive.  But I was facing a new problem — or, actually, the return of an old one:  a computer that would just give me a blinking cursor on a black screen when I tried to boot it using an Ubuntu CD or various Linux-based distributions or tools on a YUMI drive.  Even Puppy Linux, which had surmounted previous hardware hurdles, found itself on a leash this time around.

The problem was hardware, I suspected — a motherboard that would cause the Linux bootup process to freeze.  I wondered if a non-Linux-based operating system would do the trick.  I found a list of offbeat operating systems and selected two that seemed most relevant to my situation:  PC-BSD and Haiku.

Following the instructions on the download page as I understood them, I downloaded the USB-compatible version rather than the DVD version of each of those two operating systems.  On revisiting the download pages, I saw that this might have created my problem:  I did have the option of downloading an actual ISO rather than a zipped file that would turn out to contain an IMG file.  But for purposes of this post, I decided to continue to some point with the IMG option.  In part, I continued because the PC-BSD ISO was 3.4GB, which was going to take quite a while to download on my dial-up modem (kidding, but not by much — my AT&T broadband was lame).

The problem with the IMG downloads was that, for the most part, YUMI only recognized ISOs.  I did have one IMG already installed on my YUMI drive:  YUMI’s installer (version recognized Balder FreeDOS, which was an IMG download.  YUMI did offer the option to “Try an Unlisted ISO,” but had no similar option for an unlisted IMG.

There was a possibility that an IMG file, or at least some IMG files, were not suited for the kind of booting that YUMI needed to do.  In that case, fooling around with the IMG download would just amount to delaying the inevitable:  I would ultimately have to go back and download the ISO version anyway.  But I thought I might try these IMG downloads first, before giving up and taking that road.

One possibility, I thought, would be to convert the IMG to an ISO and then use that Unlisted ISO option.  A search led to two “conversion” techniques:  use IMG to ISO (freeware), buy Magic ISO Maker, or (as advised by several sources) just rename the extension from IMG to ISO.  Martin Brinkmann said that sometimes it was not as easy as just renaming the extension, so I opted to try the IMG to ISO freeware.  An alternative was to look at the files on the YUMI drive, see how they had been revised to handle the Balder FreeDOS IMG file, and attempt to do the same thing manually with the PC-BSD IMG file.  A third option would be to create a different USB drive, using some tool other than YUMI.  I was not sure what alternative would be better, but I guessed that it might be helpful to have one that “uses SYSLINUX in addition to GRUB2 and GRUB4DOS,” as I read in a description of MultiSystem, which appeared to be a Linux-based multiboot tool.  It appeared that I might be able to use a Linux-based multiboot tool even if I was only working with a “live” (i.e., not installed) version of Linux booted from a USB or CD drive.

The IMG-to-ISO option might work with the PC-BSD download, but there was another problem with the Haiku file.  Its extension, actually, was not IMG, but rather IMAGE.  (It was what the Haiku people called their “Anyboot” version.)  I guessed that IMAGE might just be another version of IMG, just as HTML could be functionally equivalent to HTM.  I decided to try the IMG to ISO freeware with this Haiku Anyboot IMAGE file first.  I had to set IMG to ISO to look for “Any file”; otherwise, it would only see IMG files.  It said, “Creating vdisk,” and I got a balloon message in the system tray saying, “Microsoft VHD HBA:  Device driver software installed successfully.”  I also noticed, in the Everything file finder, that the reference to VHD apparently explained the existence of a file called imgtoiso.vhd in C:\Users\[username]\AppData\Local\Temp.  (When I eventually killed the IMG to ISO software, that VHD persisted.)  IMG to ISO then said “Format.”  I checked to make sure it was not formatting a whole drive somewhere on my system.  When I went to move its dialog window, its title bar in Windows 7 said “Not Responding.”  I gave it a while.

While that was running, since the IMG to ISO freeware was busy and couldn’t presently be used to convert my downloaded PC-BSD IMG file, I decided to try the option of just changing that download’s extension to ISO.  So now I was trying to install BCBSD9.1-x64-USB-live.iso (not .img) as an Unlisted ISO in YUMI.  YUMI instantly said, “Copy failed.”  So I was going to have to think of some other approach for PC-BSD.

At this point, then, I was waiting for the computer to finish downloading the proper ISO for PC-BSD, just in case I would ultimately have to go that route, and I was also waiting for IMG to ISO to accomplish something with that Haiku conversion, even though it did appear to be hung.  In the meantime, I had already finished downloading the Haiku ISO (not IMG) file, and had burned that onto the YUMI drive as an Unlisted ISO.  So now I tried booting the recalcitrant computer — blinking cursor, black screen — with Haiku on YUMI.  A Haiku option did appear, on reboot, under YUMI’s “Directly Bootable ISOs or Windows XP” menu:  it was listed as haiku-r1alpha4.iso.  I tried running it.  A few commands flashed onscreen, then the screen went black.  Then, amazing to behold, I had a HAIKU logo with seven buttons underneath.  Sadly, it wasn’t recognizing my USB mouse, and unfortunately that computer’s Gigabyte motherboard did not offer two PS/2 jacks, so it looked like the mouse was dead for this purpose.  Tabbing and spacing didn’t seem to highlight any particular buttons, Esc and Enter didn’t work — in fact, the screen was completely unresponsive to a thorough wipe of the keyboard, hitting virtually every key.  It appeared that Haiku was indeed still in its alpha stage.  I tried booting Haiku from YUMI on a laptop, and its touchpad (but not its external mouse) did momentarily seem to highlight one of the buttons under the “HAIKU” logo, but then I got a debugging screen headed with the words, “PANIC: did not find any boot partitions!”

I did eventually have to kill IMG to ISO — it was failing to convert the Haiku IMAGE file — and try it again with the PC-BSD IMG file.  This time, it finished in less than a minute, with a message:  “Done, the output ISO file is [pathname]\PCBSD9.1-x64-USB-live.iso.”  I killed IMG to ISO, tried using Unlocker to delete the VHD from drive C (and settled for its fallback option of deleting the file at the next reboot), and prepared to burn the newly converted PC-BSD ISO to the USB drive in YUMI.  But now — what’s this?  The ISO file didn’t exist.  I tried again to be sure.  Definitely didn’t exist.  There was no converted ISO in the location where IMG to ISO had said it was creating an ISO — nor anywhere else, as Everything confirmed.  The IMG to ISO converter seemed to be nonperforming.

At this point, then, my options were narrowing.  Haiku seemed to be a dud:  I could get it onto the YUMI USB drive, and it would boot, but I couldn’t get past its opening screen.  PC-BSD hadn’t yet been tried as a bootable operating system, because I hadn’t been able to get it into an ISO format that YUMI would recognize.  I would either have to wait for that 3.4GB file to finish downloading, or try something other than YUMI, or manually engineer the YUMI menus so that YUMI would run the PC-BSD IMG file like it ran the Balder FreeDOS IMG file.  Or I could go back to the drawing board and search for some other non-Linux operating system that might get past the bootup hardware barrier on the recalcitrant computer.

I thought about bypassing YUMI, at least temporarily, and just installing the PC-BSD IMG directly onto a blank USB drive.  But I didn’t have an empty USB drive larger than 4 GB, and Windows Explorer was telling me that the IMG download was about 4.5GB — even though the PC-BSD download page had said that the live 64-bit USB drive (version 9.1) was only 1GB.  I could have tried re-downloading a USB image, but that would just slow down the process of downloading that 3.4GB DVD version of PC-BSD, which was increasingly looking like my next option.

I decided to try manually editing YUMI to use the PC-BSD IMG file.  A search led to the PenDriveLinux webpage, where (within the “Known Issues, Troubleshooting, and Additional Help” drop-down section) I found an indication that I would want (using Notepad) to edit \multiboot\menu\menu.lst on the YUMI drive.  I found that file and started by removing the nonfunctioning Haiku entry from its end.  I found the Haiku ISO at \multiboot\ISOS and used Shift-Del to delete that too.  (I wanted it permanently gone, not just put into a recycle bin.)  I didn’t find Balder FreeDOS; it belatedly occurred to me that, well, maybe I hadn’t installed it on YUMI this time around.  But it wasn’t appearing as an option in the YUMI installer selection menu, which ordinarily meant that it had already been selected and installed.  I booted another computer with the YUMI drive and, yes, Balder DOS image (FreeDOS) did appear under YUMI’s System Tools menu, and it did run when I selected it.  So it was definitely on the YUMI multiboot USB drive somewhere.  But where?  I found it in \multiboot — along with another IMG file, hdt.img (Hardware Detection Tool).  (People wanting to follow along could try installing Balder DOS on their own YUMI drives and comparing their results against mine.)

So it seemed that \multiboot was the place for the PC-BSD IMG file.  But where would I find the System Tools menu, so that I could edit it to include an option for PC-BSD?  Notepad told me that \multiboot\syslinux.cfg contained the top-level System Tools menu pick, and that it pointed toward \multiboot\menu\system.cfg for the contents of the System Tools submenu.  In that system.cfg file, I saw that most if not all of the entries began the same, with lines like these:

label Balder DOS image (FreeDOS)
menu label Balder DOS image (FreeDOS)

The tricky part seemed to be what came next.  I had installed a bunch of items in my YUMI System Tools menu, and most had a fourth line that read “kernel vesamenu.c32.”  But the ones for the IMG files varied.  In the case of the Balder DOS menu option, the fourth line was “kernel /multiboot/memdisk”; and for the HDT menu option, the fourth line was “LINUX /multiboot/memdisk.”  Since all the other menu options had a “kernel” line, and since I had just seen that Balder DOS was bootable, I decided that the fourth line for my PC-BSD option would be “kernel /multiboot/memdisk.”

Then there was the question of what to do about the fifth and last line for these menu picks.  Most pointed to a CFG file (e.g., “APPEND /multiboot/menu/gparted.cfg”).  I didn’t necessarily want to have to create a CFG file for PC-BSD, though I figured it would probably just involve some more Notepad work.  And it seemed I might not need to create a CFG file, because the Balder DOS and HDT menu items had a fifth line that was different, resembling one or the other of these:

append initrd=/multiboot/balder10.img
INITRD /multiboot/hdt.img

In other words, it seemed that I could have a KERNEL command on the fourth line and an APPEND command on the fifth line, as in the Balder DOS approach, or I could have a LINUX command on the fourth line and an INITRD command on the fifth line, as in the Hardware Detection Tool menu pick; but, either way, the fifth line would point to the IMG file in the multiboot folder.  Putting it together, my menu item for PC-BSD, modeled after the Balder FreeDOS item, looked like this:

label PC-BSD
menu label PC-BSD
kernel /multiboot/memdisk
append initrd=/multiboot/PCBSD9.1-x64-USB-live.img

I saved system.cfg and made sure that a copy of PCBSD9.1-x64-USB-live.img actually did appear in the /multiboot folder.  Here, we had a new problem.  Windows gave me an error:

File Too Large
The file 'PCBSD9.1-x64-USB-live.img' is too large for the destination file system.

Well, of course it was.  YUMI used a FAT32 file system, which had a 4GB maximum file size limit, and PCBSD9.1-x64-USB-live.img was 4.5GB.  So it seemed I was going to have to use another version of PC-BSD regardless, unless some non-YUMI approach would use a different file system, or unless I wanted to find some other alternate operating system instead of PC-BSD.

By this point, my system had finished downloading the PC-BSD ISO.  It was less than 4GB.  So I decided to skip the PC-BSD IMG approach.  I un-edited \multiboot\menu\system.cfg to remove the reference to PC-BSD, and installed the PC-BSD ISO as an Unlisted ISO in YUMI.  I tried booting the recalcitrant machine with it.  It did appear as the last item in YUMI’s “Directly Bootable ISOs” submenu.  It took some time to load its various lines, but then I had a “Welcome to PC-BSD!” screen.  Or something like that — by the time I had finished typing some of these words, it was moving ahead to its default boot option.  That took another minute and then froze at a line that said, “ums0: at uhub6, port 1, addr 2 (disconnected).”  I wasn’t sure what that meant, but it didn’t sound good.  I rebooted and chose a different bootup option.  It seemed that, last time, it had tried option 1, “Boot [default].”  This time, I tried option 3, “Boot in Safe Mode.”  That caused the system to fiddle around for a minute and then reboot itself.  Hmm.  This was not going well.

While that process was underway, it occurred to me to try to burn that 4.5GB PCBSD9.1-x64-USB-live.img to a DVD, just in case I might want to use that to try booting the uncooperative system.  I ran ImgBurn and chose its “Write image file to disc” option.  It said, “There doesn’t appear to be enough space on the disc to burn this image.”  It didn’t look like the image was terribly oversized — just 161MB over the disc size.  I decided to try the Overburn option.  I got an I/O error, “Logical Block Address Out of Range,” and gave up.

So anyway, on the machine I was trying to boot from USB, I was staring at YUMI’s Directly Bootable ISOs submenu.  I noticed that it had an option for MHDD Win98 Emulator.  I had forgotten that I had loaded that onto the YUMI drive.  I didn’t think I had ever used it.  But if it would run, it would give me the desired non-Windows 7 way of booting the system.  I now began to understand, however, that it was just a low-level hard drive tool, possibly useful for those who knew how, but not obviously relevant to my quest for an operating system, or something, that would boot from the YUMI drive despite the evident Linux hardware incompatibility.  The PC-BSD and Haiku options had not worked.  There appeared to be ways to make an unlisted IMG work on a YUMI drive, but that exploration hadn’t solved my problem.

I decided to try once more to find a non-Linux operating system that might boot the recalcitrant computer.  A search led to multiple positive mentions of Open Solaris, which had apparently been abandoned by Sun/Oracle and taken up by the OpenIndiana project, and of ReactOS.  Both (after unzipping the ReactOS download) turned out to be ISOs, so there was presently nothing further to learn about adding unlisted IMG files to a USB drive.  For the record, however, I found that OpenIndiana gave me an error message when I tried using it to boot the computer that Ubuntu could not boot, and ReactOS gave me its opening logo but then froze halfway through the boot process.

It occurred to me that the latest 64-bit version of Ubuntu (13.04) might have greater hardware compatibility than previous versions, so I decided to download and install that on the YUMI USB drive.  It, too, failed to boot this machine that would not boot with anything but Windows, but Windows was running quite happily.

Troubleshooting brought these additional insights:  (1) disconnect all hard drives except the one containing drive C (the Windows program drive), (2) when setting up the YUMI USB drive, experiment with the Unlisted ISO (install from memory) option, (3) when rebooting the uncooperative computer, consider a complete shutdown with a 30-second pause before restarting, to allow the machine to clear its head, (4) the Windows 7 installation DVD may boot, allowing entry into repair tools (e.g., Startup Repair), even when other DVDs don’t, (5) a system booted from a USB drive may think that the USB drive is the Windows program drive, for purposes of what it attempts to fix with commands like bootrec /fixmbr and bootrec /fixboot:  it may wipe out the boot information on a YUMI drive, and fix nothing on the computer itself.

There were three postscripts worth adding.  First, I suspected that some of the problems of booting that computer from a live CD (as distinct from a USB drive) may have stemmed from the fact that the DVD drive was SATA, not ATA.  The difference was that I had always been able to boot a computer using an old ATA (i.e., IDE) drive (which I no longer had), whereas there had been problems sometimes booting from a SATA DVD drive.  Second, as I continued searching for solutions, it appeared that my motherboard’s BIOS might be an issue, since I was having this problem with a 3TB internal hard drive.  There were no superior BIOS updates available, so swapping motherboards might have been a solution.  Third, as an alternative, even if I couldn’t get Ubuntu to boot from a USB or CD drive, surely I could get it to boot from a hard disk — if, that is, I set up a dual-boot system — though perhaps that would not solve all of my problems.  Another post explores further dimensions of some of these problems.

This entry was posted in Uncategorized and tagged , , , , , , , , , , . Bookmark the permalink.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.