建立可引導CD和DVD往往是一個簡單、直接的過程，但為什麼建立可引導快閃記憶體驅動器時會更復雜呢？兩者真的有那麼大的區別嗎？今天的超級使用者問答帖子回答了一位好奇的讀者的問題。

今天的問答環節是由SuperUser提供的，SuperUser是Stack Exchange的一個分支，是一個由社群驅動的問答網站分組。

問題

超級使用者讀者William想知道為什麼建立可引導USB驅動器比建立可引導CD更復雜：

Creating a bootable CD is really simple in my opinion, all you need to do is burn an ISO file to a disc and it is bootable. Now when it comes to USB drives, you have lots of opti***. Could someone explain the difference between the two and maybe give a brief overview of the different opti***?

為什麼建立可引導USB驅動器比建立可引導CD更復雜？

答案

超級使用者貢獻者Akeo為我們提供了答案：

Rufus developer here. First of all, a lot of the opti*** you mention are only listed when running Rufus in Advanced Mode (when the Advanced Opti*** Section is displayed), because they are intended for people who already know what they are for.

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 applicati*** 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 distributi***, 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 **aller 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 reas***, 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 **aller “USB media” square hole. How does that relate to the list of opti***? 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 provisi*** 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 opti***. 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 **art 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 opti*** 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 zilli*** 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 opti*** 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 partiti***, 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).

有什麼要補充的解釋嗎？在評論中發出聲音。想從其他精通技術的Stack Exchange使用者那裡瞭解更多答案嗎？在這裡檢視完整的討論主題。

圖片來源：威廉（超級使用者）