Within the past 24 hours, I had known the thrill of a working USB drive via YUMI and the agony of watching that very same drive crash and burst into flames. Well, not really flames. But now it wasn’t working anymore.
The current concept was that YUMI could set up a USB drive that would seem like it should boot, and maybe it even *would* boot, but then, later, it would change its mind and become hopeless, producing nothing but error messages and despair. I was not too sure how this could happen. But it did seem to be the case at present. In response to that scenario, I wondered if RMPrepUSB, despite its complex appearance, might ultimately give me a more reliable and easier-to-maintain alternative.
RMPrepUSB was advertised as offering many potential uses. At the moment, I was interested in the one that seemed to be covered by RMPrepUSB Tutorial No. 21: How to Make a Grub4DOS Multi-Boot Drive. That intimidatingly long tutorial was blessed with a link to Tutorial No. 72: A Grub4DOS Multiboot USB Drive That Is Easy to Maintain.
As with most if not all RMPrepUSB tutorials, it seemed, the process involved the RMPrepUSB graphical user interface (GUI). That GUI seemed to be like a Swiss Army Knife of the bootable USB world. Having already downloaded and run RMPrepUSB, I went to the part of Tutorial 72 that showed the necessary settings. I clicked the Prepare Drive button as shown there. As in my previous use, RMPrepUSB annoyingly rearranged several of the windows I had open onscreen. Next, I clicked the Install Grub4DOS button. I was not entirely sure what happened here: I got a command window telling me to “Press ENTER to continue.” As I was typing these words, I also got some kind of dialog. It vanished too quickly to read, possibly because it swallowed a couple of these keystrokes and choked. Whatever: I pressed ENTER to continue. Here was another dialog, possibly the same as before somehow: “Copy grldr file to drive H?” Continuing as instructed, I said OK and then downloaded the Easy2Boot files in the form of Easy2Boot-grub4dos_v0.4.zip. These files consisted of two folders: _ISO and grub. I copied both to the USB drive. That gave me those two, plus a file called grldr, in the root of the USB drive.
That, it seemed, was supposed to be all I needed to do, to have a bootable RMPrepUSB drive. Also, if I understood correctly, I was supposed to be able to press the button that said “Test using QEMU Emulator (F11),” there in the RMPrepUSB interface, and that would show me what this bootable drive looked like when it actually ran. I tried that. It gave me a dialog asking what size I wanted the new virtual hard drive to be. I didn’t know what to enter. I tried leaving it at 1, the default. Now, another dialog: “.\qemu\harddisk.img file does not exist – would you like to create a 1GiB virtual hard disk?” I said Yes. Now it wanted to know how much RAM I wanted to make available. Again, I went with the default. It slowly staggered through various steps, uttered several error messages, and then quietly died at a grub prompt. So, OK, maybe it wasn’t supposed to be ready to run in QEMU yet, or maybe I had entered the wrong settings.
The _ISO folder, I now saw, was empty: it had five subfolders, but nothing in them. Apparently I could get an example of what was supposed to be in one of those subfolders by using the YLMF example provided in the next part of Tutorial 72. As instructed, I downloaded the YLMF ISO and YLMF_OS_3.0.mnu.zip, and put them into the previously empty _ISO\Linux subfolder on the HP USB drive. In RMPrepUSB, with the HP drive still selected, I hit Ctrl-F2 and said Yes when it asked, “Run WinContig to make all files on Drive contiguous?” The existence of what looked like two spaces after “Drive” suggested that it might have been trying and failing to identify the drive letter for the HP drive, even though the selection box showed that it was drive H. Anyway, after I hit Yes, it gave me an error: “Cannot load the language file” followed by the file path and name of a file. The dialog didn’t word-wrap, so the file name did not appear, but I assumed it was the Readme_EN.txt file in the WinContig folder in the RMPrepUSB program folder. I clicked OK. It repeated that message maybe four times and then, again, it died.
I was probably getting something wrong. I decided to post this writeup in its present form, notify Steve, and see if he had any suggestions. One was to use the latest beta version of RMPrepUSB. “Beta,” to me, tended to mean bleeding edge, not stable, but I guess it could also mean more better, less worse. So now I was inching up from version 2.1.648 to 2.1.651Beta, and transitioning away from the portable to the full install. I also noticed that I had left the volume label unchanged previously; now I wondered if RMPrepUSB would work only if the volume was named Easy2Boot. I renamed it to that in diskmgmt.msc (i.e., the Windows 7 Disk Management program). Steve wondered if I had not waited long enough for WinContig to finish. So I clicked the Prepare Drive button again, and when it was done I clicked the Install Grub4DOS button, and when that said “Press ENTER to continue” I did, and then okayed the copy of grldr to drive H. Then I recopied the Easy2Boot files onto the HP USB drive, and redownloaded and recopied the YLMF files into H:\_ISO\Linux. Next, in RMPrepUSB, with the EASY2BOOT drive selected (i.e., my HP USB drive), I hit Ctrl-F2 to run WinContig. This time I noticed that it reported its progress in small red print at the bottom of the RMPrepUSB window. When it said “OK – ALL FILES ARE CONTIGUOUS,” I clicked on “Test using QEMU Emulator (F11).” As before, I went with the defaults. It wound itself up slowly, but after a minute or so I did have what appeared to be a working (emulated) session based on the USB drive, with an introductory menu screen similar to the picture shown there in Tutorial No. 72: painting of a church and some other buildings and mountains on a snowy night. hit PrintScreen to capture the image. That provoked QEMU to proceed on to a YLMF intro screen, and that’s as far as it went. I wasn’t sure what, if anything, to make of that, as I was not familiar with YLMF. I didn’t intend to use it anyway, so now that I had worked through a more or less successful demo, I removed the YLMF files from H:\_ISO\Linux.
So now I thought I understood the basic concept. After doing the initial setup in RMPrepUSB, I would add a .mnu and an .iso file for each program that I wanted to install onto the USB drive. The options would appear on that introductory menu/snowy night screen. I didn’t especially like the picture, and I wanted options to structure the menu and the underlying directory structure, but those changes weren’t essential. The key for me, at this moment, was that possibly RMPrepUSB would get this HP USB drive to boot a computer, where the YUMI installation described in the previous post had failed.
That raised a question: I had the ISOs, but what was involved in finding or creating the MNUs? Tutorial No. 72 linked to a Reboot.pro thread where it appeared that a few people were posting MNU files, but mostly it just looked like a discussion of problems with trying to create MNUs. An exchange of emails with Steve set me straight on this: the tutorial did have instructions on changing the menu, and these tentatively appeared manageable, and the tutoral also offered a list of MNUs for about 25-30 different ISOs. The list did not include MNU files for many of the programs listed in my previous post, however, including some (e.g., Ubuntu, Acronis, GParted) that I used frequently. There were alternatives in some cases — for example, Tutorial No. 46 explained how to work with several earlie versions of Ubuntu — but these looked considerably more complex than the YUMI approach.
I was here because I had run into difficulties with YUMI. Now it appeared that I was going to have to invest a significant amount of time in an effort to replace YUMI with RMPrepUSB. I might ultimately have to do that. I was impressed with the capabilities of the RMPrepUSB interface. But I knew I’d had a working YUMI drive. At this point, before investing that amount of time into RMPrepUSB, it seemed that I would be better advised to try again with YUMI, possibly using different USB drives or otherwise varying my approach.