The Mission at Hand
Using ImgBurn to Create the ISO
Getting etfsboot.com from WAIK
Getting etfsboot.com from Another USB
Wrap-Up; Further Possibilities
I was using Windows 10. I had a couple of single-purpose bootable USB drives. When I say “single-purpose,” I mean they were not multiboot drives. Popular tools for creating single-purpose bootable USB drives included Rufus, Universal USB Installer (UUI), WinSetupFromUSB, and UNetBootin.
A multiboot USB drive was capable of booting multiple programs, selected from a menu after booting the multiboot tool. My YUMI multiboot drive had maybe 15-20 different utilities loaded on it. By contrast, a single-purpose USB drive would do just one thing: it would boot a Windows or Linux installer, or a drive partitioning utility, or some other tool, but it would not give the user a choice among a number of such tools, all contained within a single USB device.
YUMI (4.6 stars from 304 raters at Softpedia) was not the only choice for creating a multiboot USB drive. I also had some experience with SARDU (4.0 stars from 260 raters) and XBoot (4.1 stars from 234 raters). Other multiboot tools included MultiBootUSB (4.9 stars from 308 raters), WinSetupFromUSB (4.2 stars from 1,044 raters), and Easy2Boot (4.7 stars from 22 raters).
Bootable USB drives could be created from ISO files. There were many ISOs available for download. These included ISOs to install various versions of Windows, Linux, and related tools. As detailed by Raymond (2017) (who also provided checksums to verify valid downloads), sources of Windows ISOs included Microsoft itself (for Windows 8 and Windows 10, optionally without using the Media Creation Tool or USB/DVD Download Tool, and also for Windows 7 owners with retail (i.e., not OEM, not the sticker-on-the-computer) licenses) as well as various third parties. Those third party options included the Windows ISO Downloader (a/k/a HeiDoc’s Microsoft Windows and Office ISO Download Tool), the Universal Windows Downloader, and a download website operated by AdGuard, among others. I tried each of those third-party options. I found that either they did not work or they provided ISOs with invalid checksums. But possibly they would work on other days, or for other combinations. Sources of Linux and other ISOs included LinuxFreedom, Easy2Boot, and LiveCDList.
I created my most commonly used multiboot USB drive by using YUMI to load multiple ISOs, one after another. There was an ISO for Linux Mint, an ISO for a Samsung hard drive utility, and so forth. Thus, the ISOs were essentially drive images or backups capable of being installed onto a USB drive in bootable form.
Booting a USB drive, whether single- or multiboot, required a computer that was willing to boot it. In my experience, the primary concern here was whether the BIOS (i.e., the UEFI or BIOS interface, or setup utility) was set to recognize bootable USB drives. Getting into the BIOS typically required the user to hit a key, once or perhaps repeatedly, when the system was first starting up. That key was usually F2, but on some systems it could be DEL or some other key. There was also commonly an option to hit some other key (usually F12) to bring up a menu of all bootable devices.
Those keys would typically be active when the system’s splash screen first appeared. For instance, on my Acer laptop, the time to hit F2 or F12 was the moment when the word “Acer” appeared onscreen, right after bootup. Some systems would allow five seconds or longer, but on this Acer, I had only one or two seconds. If I didn’t hit F2 or F12 within that timeframe, the system would proceed to boot whatever drive was listed first in its BIOS drive priority setting.
BIOS and UEFI options had changed, over the years. At this writing, on this Acer system, obviously designed with Windows 10 in mind, the options were limited. The essential choice appeared on the Boot menu, in the BIOS setup utility. It was a choice between UEFI and Legacy modes. My YUMI drive, and others discussed here, would only boot if the BIOS was set to boot in Legacy mode.
The Mission at Hand
My present need was to convert a couple of bootable single-purpose USB drives to ISOs. That is, for each of these USB drives, I wanted an ISO file, stored on my computer, to capture the contents of the USB drive. In this enterprise, I had two purposes in mind:
- I wanted to produce an ISO that I could add to my YUMI drive, so that I would have most if not all of my bootable USB tools on one USB drive. This was more convenient and less expensive than having to create, label, and store a different USB drive for each tool that I might want to boot.
- I wanted to produce a better form of backup. I had tried a half-dozen different programs that were supposed to create backup images of USB drives. Among those, as noted in a previous post, I had some success with AOMEI Backupper Standard and PassMark ImageUSB, but I wanted something more reliable. My collection of ISO files had served as a good form of backup: I had often used them to create single- and multitool USB drives.
So the idea here was to start with a bootable USB; make an ISO from it; and then test it. I would want to test it in two ways: create a single-purpose bootable USB drive from it, using Rufus or UUI, and also add it to my YUMI drive, and see if it would run from there.
Note that this was not the normal way of accumulating ISOs to put onto a USB drive. Normally, I would either download the ISO from the developer’s webpage or create the ISO by running a program and using its option to create bootable (a/k/a rescue) media. But there were times when those approaches wouldn’t work. For example, some programs wouldn’t create bootable media.
The example motivating me this time was different. My laptop manufacturer had just sent me a Windows 10 recovery CD, except that it wasn’t a CD: it turned out to be a USB drive. Unlike a CD, a USB drive could easily get corrupted. So before using that USB drive on the laptop, I would want a good backup — and, as just noted, I would also prefer to run it from the YUMI drive, saving the original for emergencies and in any case being able to look to my multibootable YUMI for all such purposes.
I wasn’t eager to screw up the laptop recovery USB drive, so I decided to practice with a different USB drive. I started with the free downloaded ISO used to create a USB from which the user could boot MiniTool Partition Wizard 9. (Note that, at least in MiniTool Partition Wizard 10, the option to create bootable media was available only in the professional (i.e., paid) version.)
I used Rufus (with default settings, including “MBR partition scheme for BIOS or UEFI”) to quick-format (FAT32) and install that free downloaded MiniTool ISO onto a single-purpose bootable USB drive. During the installation process, Rufus notified me that the ISO was using an obsolete version of a file called vesamenu.c32. I approved Rufus’s offer to download and use a newer version of that file. Rufus then completed the installation. I verified that the USB drive would boot the laptop and run MiniTool Partition Wizard 9. So now I had a bootable USB drive, comparable to the recovery USB drive from my laptop manufacturer. Now the question was, can I create an ISO from this USB drive, and use that ISO to create another bootable USB drive, or add that ISO to a multiboot drive?
Using ImgBurn to Create the ISO
For the task of creating one bootable USB drive from another, the first step was to find a tool or procedure that would create an ISO file from the source USB drive (e.g., my newly created bootable MiniTool drive). For that purpose, multiple sources recommended ImgBurn. With ImgBurn running and the source USB drive plugged into the computer (using Windows 10, here), I interpreted the steps recommended by various sources as follows:
- In ImgBurn, select the option to “Create image file from files/folders.” If that option is not visible, go to ImgBurn’s menu > Mode > Ez-Mode Picker. That should make that option visible.
- Mouse over the folder icon next to the Source box. If ImgBurn is the active window, you should get a tooltip saying, “Browse for a folder.” Click on that folder icon. Navigate to the drive letter for the source USB drive. Select the drive, not its folders.
- Click the folder icon next to the Destination box. Indicate where you want to save the resulting ISO, and give the ISO a name.
- At the right side of ImgBurn, in the Options tab, the items checked should be Preserve Full Pathnames, Recurse Subdirectories, Include Hidden Files, and Include System Files.
- In Advanced tab > Bootable Disc tab, check Make Image Bootable. My default values here, which worked, were Emulation Type = None (Custom), Platform ID = 80×86, and Load Segment = 07C0. As instructed, I typed Developer ID, type “Microsoft Corporation.” I wasn’t sure that was necessary.
- In that same tab, click the folder icon next to Boot Image, and browse to and select the etfsboot.com file found in the boot folder of the USB drive. (Mine didn’t have one. Read on.)
- If the size of the etfsboot.com file was 2KB, the correct value for Sectors to Load would be 4. If etfsboot.com was 4KB, Sectors to Load would be 8. Mine was 4KB, so I entered 8 here.
- Click the icon in the lower left of the main ImgBurn window. This is the icon that symbolizes a change from a folder to a disc image (tooltip: “Build”).
- Approve ImgBurn’s offer to add a Volume Label.
In other situations, I had noticed that plugging and unplugging USB drives could disrupt other USB operations. I tried to refrain from such activity while the USB drives were active in this project.
Those steps would produce both an output ISO and an accompanying MDS file with the name I had specified. Sources (e.g., an ImgBurn forum) indicated that I would not need the MDS file for my purposes.
For me, the preceding instructions had one problem: my USB drive didn’t have an etfsboot.com file. When I tried to get by without one, I got an error: “You have not selected a file to act as the boot image!” It seemed I would have to find a copy of etfsboot.com somewhere else.
A search of my system using Everything revealed that there were actually six etfsboot.com files scattered around my Windows C drive. DoubleKiller indicated that four of them — the ones not found in subfolders of a folder named C:\Boot\macrium — were identical. I guessed those were probably the type of etfsboot.com file needed in this case. Going through the preceding instructions, then, I selected one of those etfsboot.com files when I got to that step (above).
ImgBurn produced an ISO, as desired. I used UUI to install the output ISO onto an empty USB drive, choosing FAT32 format. But when I tried booting the laptop with it, it failed with an error:
Booting ‘Boot swdl’
Error: partition table is empty.
find –set-root %ISO%
File not found
(Later realization: Error 15 went away, at least in some cases, when I removed spaces from the names of the ISO files.)
I tried going to that website, but it gave me a 404. I saw that the output USB drive’s program files were slightly larger, altogether, than those of the source USB drive. I tried comparing the two drives using FreeFileSync 6.2 (not 9.9, per advice from PortableApps), but I found that I was more familiar with Beyond Compare, so I used that. It showed me which files differed, but of course it didn’t explain why they were different.
Just out of curiosity, I tried using Beyond Compare to synchronize the two USB drives, so that the output USB drive had the same files as the source USB drive. An attempt to boot the laptop using the output drive then produced
SYSLINUX 4.07 EDD Load error – Boot error
A search produced only a handful of English-language hits addressing that error, and most of those just advised using a different boot creation tool. But I didn’t think that was the issue. UUI had been pretty reliable.
Getting etfsboot.com from WAIK
One old source said etfsboot.com was included in the Windows Automated Installation Kit (WAIK or AIK), now known as the Windows Assessment and Deployment Kit (WADK or ADK). As of April 2017, that download (for Windows 10, version 1709) was 3.8GB. (Note: it was a somewhat weird download. It started with a small adksetup.exe file; when I ran that, it commenced the large download; and that large download seemed to continue downloading after Firefox reported that it was finished.) Meanwhile, the Windows 7 AIK (downloaded as KB3AIK_EN.iso; also available at Softpedia) was 1.7GB.
While the AIK and ADK were downloading, I reflected on the fact that the source USB drive was booting just fine without an etfsboot.com file. If that drive didn’t need it, presumably my output ISO didn’t need it either. A search for information on this phenomenon produced only a few hits. Apparently ETFS was short for El Torito File System (see Wikipedia). A participant in a Technet discussion said, “El Torito is only required for BIOS systems, and is not necessary for uEFI.” This suggested that perhaps no etfsboot.com file was installed in the boot folder on the source USB drive because I had created that drive on a UEFI system. I tried booting an old BIOS (i.e., non-UEFI) computer with the source USB drive. It booted. I didn’t expect that. So why was ImgBurn demanding something like etfsboot.com?
By this point, the WAIK and WADK had finished downloading, so I went back to the project of digging a copy of etfsboot.com out of them. In the end, I wouldn’t do anything with the WADK, but I did try a couple of approaches with WAIK (i.e., KB3AIK_EN.iso). My first approach was time-consuming and brainless: I used 7-Zip to extract the files from that ISO to a folder; then I extracted the contents of compressed files (all .cab files; I didn’t find any .rar, .7z, or .zip files) in those extracts repeatedly, until there were no more compressed files. But this did not turn up a copy of etfsboot.com.
Trying again, a WinReflection discussion of creating a Windows Pre-installation Environment (WinPE) suggested that (a) a person interested in creating an ISO bootable on a UEFI system (and possibly also on an older BIOS system, though possibly not on a YUMI drive) might want to use efisys.bin rather than etfsboot.com, and (b) both such files would be accessed by mounting the Windows AIK ISO.
To mount the WAIK ISO, a search led to (1 2) sources recommending, among others, DVDFab Virtual Drive (4.0 stars from 92 raters at Softpedia). During installation of DVDFab, there was a question as to whether I wanted to install dvdfab.cn Storage Controllers. I couldn’t find any guidance on that. I said Install. That seemed to turn out OK. With DVDFab installed, double-clicking on the WAIK ISO produced a Windows 10 option of using DVDFab to “open” it. Alternately, right-clicking on the ISO presented an option of mounting it as a drive (in this case, drive I). I took that alternate route. Now the contents of the WAIK ISO were viewable in File Explorer. WinReflection told me to double-click on StartCD.exe in the ISO’s root folder. That opened a WAIK dialog. The advice was to choose Windows AIK Setup, within that dialog, and proceed through WAIK installation. That created and populated a folder called C:\Program Files\Windows AIK. That folder contained two copies of etfsboot.com.
DoubleKiller confirmed that the contents of these newly created etfsboot.com files were identical to the etfsboot.com files I had already tried. In short, WAIK gave me an etfsboot.com file identical to most of those already existing on my Windows 10 system.
There was the alternative, just mentioned, of using efisys.bin rather than etfsboot.com. My desktop computer had nine copies of efisys.bin. In this case, however, DoubleKiller found only two actual duplicates, neither of which was in the newly created Windows AIK folder. I was not sure which I would want to choose, among these eight variations.
Getting etfsboot.com from Another USB
It occurred to me to check the boot folders of another bootable USB drive. That one did have a version of etfsboot.com. I tried using that one in ImgBurn. This time, I got an error:
Cannot open file J:\System Volume Information\IndexerVolumeGuid
Reason: Access is denied.
Drive J, in this case, was the source USB drive, the one I was attempting to convert to ISO. Microsoft explained that the System Volume Information folder was “a hidden system folder that the System Restore tool uses to store its information and restore points.” I had noticed that Windows automatically created that folder on each drive.
Following advice from Sumit Dhiman, I went to Start > Run (or Ctrl-R) > SystemPropertiesProtection.exe, in hopes of turning off System Restore for this USB drive. Unfortunately, my USB drives were not listed there. I believed the System Volume Information folder would not be missed, so I canceled this procedure, went back to ImgBurn, and looked for an option to exclude folders. No such option. Well, one possibility was to select folders individually, instead of selecting the drive. Instead, I went back through the steps just described, and when I got to the System Volume Information error, instead of canceling, I clicked the Continue button. ImgBurn then gave me the same error for a specific file within the System Volume Information folder: WPSettings.dat. I clicked Continue again. It seemed to proceed: almost instantly it said, “Operation Successfully Completed!” And I did indeed have a resulting ISO.
Now the question was whether this ISO would work where the previous one failed. I used Rufus to create a bootable USB from this ISO. And that worked: the USB drive was bootable, and MiniTool ran. In other words, it was possible to create a bootable USB drive from an ISO made from a bootable USB drive. Interestingly, the single-purpose ISO that booted successfully did not have a copy of etfsboot.com in its boot folder. As I then discovered via DoubleKiller, the version of etfsboot.com that worked, for this purpose, was byte-for-byte identical to the one I had tried previously. So that was puzzling.
I decided to try to keep track of the copy of etfsboot.com that worked this time. I put it into a storage folder, with a note explaining why it was there. I also calculated its SHA-256 hash, for purposes of determining whether other copies of etfsboot.com were identical. How-To Geek (Hoffman, 2017) recommended this procedure for calculating the SHA-256 hash for a file: open PowerShell in the folder where the file is located and type Get-FileHash [filename]. One way to open PowerShell was to run C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe. Another (in Windows 10) was to go to Start > right-click > Windows PowerShell (Admin). In this case, with PowerShell focused on the folder where the working copy of etfsboot.com was located, the PowerShell command was simply Get-FileHash etfsboot.com. The resulting value was as follows:
I verified that that was also the SHA-256 value of one of the etfsboot.com files created in the WAIK folder. So any copy of etfsboot.com having that SHA-256 value would apparently work as the “boot image” file for ImgBurn.
I tried using the same ISO on the YUMI drive: I added the ISO to the YUMI drive and booted again with that. YUMI started, but this MiniTool option failed with an error: “CDBOOT: Couldn’t find BOOTMGR.” Other tools on the YUMI drive ran as usual; it was just this particular ISO. A search for that error led to only a few English-language sources. The only one offering an explanation, among those sources, reported that the error might be caused by a corrupted ISO. That seemed unlikely: the ISO had just worked successfully on a single-purpose USB drive.
I wondered if the problem was specific to YUMI. I decided to try MultiBootUSB 9.2, the highest-rated among the alternatives to YUMI listed above. MultiBootUSB offered an interesting feature: when I indicated which ISO I wanted to install, it identified details about that ISO, including “Boot: False.” Elsewhere, I noticed that people were getting “Boot: True” from that indicator. I wondered if it was telling me that the ISO was not bootable (at least not in MultiBootUSB) and, if so, why it did boot on a single-purpose drive. Unfortunately, the MultiBootUSB Guide did not provide insight, and a search turned up nothing useful.
Anyway, after selecting the USB drive and the MiniTool ISO at the top of the MultiBootUSB dialog, I went down to its MultiBootUSB tab (open by default) > Install distro. That offered to proceed with installation. I clicked Yes. When it was done, it said the ISO was “successfully installed.” I tried booting the laptop with it. I got an error:
File for drive emulation must be in one contiguous disk space
A search for that error produced nothing. I wondered if maybe the USB drive just needed to be reformatted before installing MultiBootUSB. As advised by the Guide, I formatted the USB drive using FAT32. For some reason, it defaulted to a 16KB allocation unit size. I went back to the MultiBootUSB tab and clicked Install Distro again.
MultiBootUSB had the very useful feature of offering to test the ISO or the bootable USB drive in a virtual machine (VM). To test that, I went to the Boot ISO/USB tab. The Boot ISO button didn’t seem to do anything. I tried the Boot USB button. This time, it said, “An operating system wasn’t found. Try disconnecting any devices that don’t contain an operating system.” I didn’t have any other devices connected, so that wasn’t the answer. But at least we had progressed to a different kind of fatal error. Possibly formatting did resolve Error 60 (above). Additional attempts with a different USB drive, formatted to 4KB, made no difference, except that in one retry the error was slightly different: “Missing operating system. No bootable device.”
At that point, I got some sleep. When I returned to this post, I went back through the preceding paragraphs, repeating each step and editing my remarks for clarity. In that process, among other things, I created a new ISO via ImgBurn. I continued on until I got to this point. I tried once again to use MultiBootUSB to put the MiniTool ISO onto a new multiboot USB. And for some reason, this time it worked. It worked in MultiBootUSB’s Boot USB virtual machine test, and it worked when I plugged the resulting USB drive into the laptop and rebooted. Using the same (albeit reformatted) USB drive as before, this time MiniTool booted from the USB drive and ran on the laptop. Don’t ask me why. It still didn’t run from YUMI, regardless of whether I told YUMI to run it from RAM or via GRUB or SYSLINUX.
That raised the question of whether MultiBootUSB might be a better multiboot tool than YUMI. As reported in another post, my attempt to look into that possibility resulted in a pretty quick No to that question. It did seem that MultiBootUSB was able to create a single-purpose USB drive to boot the MiniTool ISO, and I believed that MultiToolUSB would probably also support other ISOs. But it not only failed to support the full set of ISOs I had installed successfully in YUMI; it allowed those ISOs to corrupt the USB drive, or was otherwise incapable of handling them, such that the resulting USB drive was competely unbootable.
Wrap-Up; Further Possibilities
This post describes attempts to convert a bootable USB drive into an ISO, and to add that ISO to a single- or multiboot USB drive. The conclusions reached here are that the single-purpose result was relatively straightforward, once I worked out the kinks, but the multiboot outcome was iffy at best. As noted in the other post, YUMI and MultiBootUSB weren’t the only multiboot tools: I might have had better luck with Easy2Boot, WinSetupFromUSB, XBoot, or SARDU, or possibly with a different computer, a different USB drive, or a less ambitious effort (i.e., installing only a few selected ISOs, rather than attempting to add the resulting ISO to a YUMI drive already containing at least 40 ISOs). Those would be matters to work out by myself and/or others as the need arose.
It is worth mentioning that there were other possible ways to proceed. Previously, for instance, I had achieved success with an XBoot multiboot DVD, on a system that was not booting USB drives. Note also that the contents of an ISO could be mounted and read (but would not be booting a system) with the aid of tools like DVDFab Virtual Drive (above). Some ISOs might also be able to boot a system within a virtual machine on a computer, even if they wouldn’t boot the computer itself. I did not experiment with booting via MicroSD card, but that was another possibility. There was also the option of setting up a computer for dual- or triple- (or quad?) booting (i.e., actually installing multiple operating systems onto the system’s hardware, and choosing among them from a menu presented at bootup).
If it was just a matter of using one bootable USB drive to produce another, there were other ways to proceed. One was to use a backup tool, like those mentioned above (i.e., AOMEI Backupper Standard and PassMark ImageUSB), to clone the source to the target drive. In Linux, multiple sources recommended the dd command, with the caveat that a simple typing error could wipe out the wrong drive. Disks was a GUI alternative.
I started this post with the intention of creating an ISO, from a bootable USB drive, and using that ISO to create another single-purpose USB drive, and also to add another bootable option to a multiboot USB drive. I tested the possibilities by starting with an easily reproduced MiniTool ISO, installed onto a single-purpose USB drive. Now that I had worked through the process, I tried it with the laptop manufacturer’s Windows 10 recovery CD. As detailed above, I used ImgBurn and a known good etfsboot.com file to produce an ISO.
I didn’t want to let Windows 10 grab onto any actual computer systems, so I planned to test it in a virtual machine (VM). Unfortunately, VMware’s advice did not work for this ISO: it would not boot as expected or hoped. As an alternative, I used MultiBootUSB to put the ISO onto what could become a multiboot USB drive, and then used MultiBootUSB’s option to Boot USB in a VM. That caused MultiBootUSB to crash. I tried again. With the USB drive still inserted in the computer, evidently MultiBootUSB knew where to look. This time, using the default amount of RAM, that option produced an error (no. 0xc0000017): “There isn’t enough memory available to create a ramdisk device.” MultiBootUSB was unresponsive with RAM set to 2048MB, and its QEMU VM crashed at anything less. It seemed that testing the final outcome would have to await access to a computer that I could wipe after testing.
As reported in a later post, I had better results using AOMEI than Passmark, for purposes of creating an image backup of a bootable ISO. I tested both the AOMEI backup and the ImgBurn ISO created, in that later situation, by restoring them to a different USB drive. Depending on which laptop I used them in, both were able to run a live USB session and retained persistent memory of previous configurations.
A different post reports that I did not succeed in a brief attempt to use the method described in this post (involving ImgBurn etc.) to produce an ISO, made from a USB drive produced by AOMEI, that I could then install in another USB drive. It was not clear whether that failure stemmed from an error in the use of ImgBurn, from a problem due to the different nature of the bootable tool involved in that case, or from some other factor. But see another later post for success.