Creating bootable CDs and DVDs tends to be a simple, straightforward process, but why is it more complex when creating bootable flash drives? Is there really that much difference between the two? Today’s SuperUser Q&A post has the answer to a curious reader’s question.
Today’s Question & Answer session comes to us courtesy of SuperUser—a subdivision of Stack Exchange, a community-driven grouping of Q&A web sites.
The Question
SuperUser reader William wants to know why creating a bootable USB drive is more complex than creating bootable CDs:
Why is creating a bootable USB drive more complex than creating bootable CDs?
The Answer
SuperUser contributor Akeo has the answer for us:
Have something to add to the explanation? Sound off in the comments. Want to read more answers from other tech-savvy Stack Exchange users? Check out the full discussion thread here.
To start with, you have to understand that the ISO format was never designed for USB booting. An ISO file is a 1:1 copy of an optical disc, and optical disc media are very different from USB media, both in terms of how their boot loaders should be structured, what file system they use, how they are partitioned (they are not), and so on.
So, if you have an ISO file, you simply cannot do with USB media what you can do with an optical disc, which is read from every single byte of the ISO file and copied as is, in sequence, onto the disc (what CD/DVD burner applications do when “working” with ISO files).
That is not to say that this kind of 1:1 copying cannot exist on USB media, just that 1:1 copies on USB media will be completely different from 1:1 copies on optical discs and are therefore not interchangeable (outside of using ISOHybrid images that are crafted to work as 1:1 copies on USB and optical media both). For the record, in Rufus terminology, a 1:1 copy on USB media is called a DD Image (you can see that option in the list) and some distributions, like FreeBSD or Raspbian, actually provide DD Images for USB installation, alongside ISO files for CD/DVD burning.
Thus, we have established that ISO files are actually poorly suited to create bootable USB media because they are the equivalent of providing a round peg to fit a smaller square hole, and therefore, the round peg must be altered to fit it.
Now you may be wondering, if ISO files are so poorly suited for creating bootable USB media, why are most operating system distributors out there providing ISO files instead of DD Images. Well, outside of historical reasons, one of the issues with DD Images is that because they are a partitioned file system, if you create a 1:1 copy on USB media that is larger than the one used by the person who created the image, then you will end up with the apparent “capacity” of your USB media reduced to the size of the one used in creating the original DD Image.
Also, whereas optical discs and therefore ISO files can only ever use one of two file systems (ISO9660 or UDF), both of which have been very well supported in all major operating systems for a very long time (and allows you to take a peek at the image content before or after you use it), DD Images can literally use any of the thousands of different file systems that exist. That means that even after you create your bootable USB media, you may not be able to actually see any content on it until you boot it up. For instance, this will be the case if you use FreeBSD USB images on Windows. Once the bootable USB media has been created, Windows will not be able to access any content on it until you reformat it.
This is why providers tend to want to stick with ISO files where possible, as it (usually) provides a better user experience across all operating systems. But that also means that some conversion must (usually) occur so that our round ISO peg can fit nicely into the smaller “USB media” square hole. How does that relate to the list of options? We are coming to that.
One of the first things that usually needs to go is the ISO9660 or UDF file system that ISO files use. Most of the time, this means extracting and copying all of the files from the ISO file onto a FAT32 or NTFS file system, which is what bootable USB flash drives tend to use. But of course that means that, whoever created the ISO system must have made some provisions to support FAT32 or NTFS as a file system for live use or installation (which not all people, especially the ones who rely a bit too much on ISOHybrid, tend to do).
Then there is the actual boot loader itself, the first bit of code that executes when a computer boots from USB media. Unfortunately, HDD/USB and ISO boot loaders are very different beasts, and the BIOS or UEFI firmware also treats USB and optical media very differently during the boot up process. So you usually cannot take the boot loader from an ISO file (which would usually be an El Torito boot loader), copy it to USB media, and expect it to boot.
Now comes the part that is relevant to our list of options. Because Rufus will have to provide a relevant boot loader piece, it simply cannot obtain it from the ISO file. If we are dealing with a Linux based ISO file, then chances are it will use GRUB 2.0 or Syslinux, so Rufus includes the ability to install a USB-based version of GRUB or Syslinux (since the ISO file usually only contains the ISO specific version of those).
This is usually done automatically when you select and open an ISO file since Rufus is smart enough to detect what kind of conversion it needs to apply. But if you want to play around, Rufus gives you the choice to also install some blank boot loaders that enable you to boot to a GRUB or Syslinux prompt. From there, if you are familiar with these types of boot loaders, you can create/test your own config files and try your very own Syslinux or GRUB based custom boot process (because at this stage, you only have to copy/edit files on the USB media to do that).
So, we can now go over the options you find in the list:
MS-DOS: This creates a blank version of MS-DOS (Windows Me edition), which means you will boot to an MS-DOS prompt and that is it. If you want to run a DOS application, you will need to copy it to your USB media. Note that this option is only available on Windows 8. 1 or earlier, but not Windows 10 since Microsoft removed the DOS installation files from Windows (and only Microsoft can redistribute these files). FreeDOS: This creates a blank version of FreeDOS. FreeDOS is a free software version of MS-DOS, which is fully compatible with MS-DOS, but also has the advantage of being open source. Compared to MS-DOS, anyone can redistribute FreeDOS, so the FreeDOS boot files are included in Rufus. ISO Image: This is the option you should use if you have a bootable ISO file and want to convert it to bootable USB media. Keep in mind that because a conversion (usually) needs to occur and there are zillions of ways to create a bootable ISO file, there is no guarantee that Rufus will be able to convert it to USB media (but it will always tell you if that is the case). DD Image: This is the method you should use if you have a bootable disk image, such as the ones provided by FreeBSD, Raspbian, etc. Files with a . vhd extension are also supported (which is Microsoft’s version of a DD Image) as well as compressed ones (. gz, . zip, . bz2, . xz, etc. ).
The four options above are the only ones you will see in Regular Mode. But if you run Rufus in Advanced Mode, you will also have access to the following choices:
Syslinux x. yz: Installs a blank Syslinux boot loader which will get you to a Syslinux prompt and not much else. You are supposed to know what you need to do from that point forward. GRUB/Grub4DOS: Same as above, but for GRUB/Grub4DOS respectively. It will get you to a GRUB prompt, but it is up to you to figure out the rest. ReactOS: Installs an experimental ReactOS boot loader. Since the last time I checked, ReactOS does not boot that well from USB media. It is there because it was easy to add, and done with the hope that it can help with ReactOS development. UEFI-NTFS: This requires NTFS to be selected as the file system and installs a blank UEFI-NTFS boot loader. This enables booting from NTFS in pure UEFI mode (not CSM) on UEFI platforms that do not include an NTFS driver. Because it is blank, you will need to copy your own /efi/boot/bootia32. efi or /efi/boot/bootx64. efi onto the NTFS partition for it to be useful. UEFI-NTFS is automatically used by Rufus to work around the 4 GB maximum file size of FAT32, which for instance, allows the installation of Microsoft Server 2016 in UEFI mode without having to split its 4. 7 GB install. wim file.
Hope that helps. This is a simplified overview, so I hope people will not start nitpicking on aspects that were deliberately dumbed-down or kept silent (such as knowing it is possible to have USB flash drives without partitions, to have USB and optical media use the same file system, and that some boot processes have the capability to extend the partition size on USB media in order to solve the lower apparent capacity issue).
Image Credit: William (SuperUser)
