Debian：使用终端创建 Windows 10 可引导安装 USB 驱动器 (dd)

Question

我的目标很简单，标题说明了一切，但我尝试过的每一种方式都失败了。我已经阅读了各种网站上的说明（除了这里），他们似乎都遗漏了一些东西......这就是我所拥有的：

• 16 GB 闪迪 USB 3 驱动器。
• Debian Jessie 机器
• windows 机器，macbook pro

虽然我可以使用 rufus 轻松创建可启动的 Windows 10 USB，但我的目标更具教育意义：我想了解正在发生的事情，以及失败的根源是什么，如果可能的话，让它工作。

当我尝试在终端中创建 Win10 映像时，我尝试了以下命令：

sudo dd if=Windows10.iso of=/dev/sdc1 bs=512k

我得到一个分区，它似乎安装在 Debian 上，但在 Windows 和 mac 上无法识别。Gparted 显示这一点： gparted 报告文件系统未知 ，另一个正常工作的 USB 闪存驱动器（我有 4 个）读取如下： 在此处输入图像描述

我在某些地方读到你不应该输出到分区（sdc1）而是输出到驱动器（sdc），所以我试过这个：

sudo pv Windows10.iso | sudo dd of=/dev/sdc bs=5M

（对于那些熟悉的人来说，这是相同的命令，通过 dd 管道传输，并使用 sdc 代替）。这似乎会破坏整个分区，正如您从 fdisk 中看到的：我的终端输出显示了命令和 fdisk。

这令人沮丧，但我决定重新开始。我重新启动，并运行以下命令

sudo umount /dev/sdc1
sudo wipefs -a /dev/sdc
sudo fdisk -l
sudo fdisk /dev/sdc
n, p, 1, [enter], [enter], t, 7, w

这应该格式化一个新分区并将其从默认（linux）更改为我需要的 ntfs 分区。然后我运行：

lsblk 

并使用以下命令创建 NTFS 文件系统：

sudo mkfs -t ntfs /dev/sdc1

之后，我尝试运行 dd，但有一个额外的选项：conv=f​​datasync（有些人说这可以确保缓存中没有任何内容并且可以解决这个问题）。

pv Windows10.iso | sudo dd of=/dev/sdc conv=fdatasync bs=512k

（如果这是一个问题，我删除了字节大小）。不管我怎么做，我注意到以下几点：

• dd 确实写入文件和文件系统，它在 linux 中是可读的（我可以打开文件）但它没用，而且 lsblk 和 gparted 都说那里什么都没有！
• 我是选择 sdc1 还是 sdc 似乎只会影响驱动器损坏的严重程度。一个会损坏分区，而另一个则使整个驱动器看起来像是未分配的。
• 驱动器很好：我进入 Windows 并使用相同的“损坏的”USB 驱动器，复制同一个文件并验证它可以启动并且工作正常。

请记住 dd 命令适用于gpartedlive。我运行了以下代码：

sudo wipefs -a /dev/sdc
sudo fdisk /dev/sdc
lsblk
sudo mkfs -t vfat /dev/sdc1
pv gparted-live-1.1.0-1amd64.iso|sudo dd of=/dev/sdc bs=4M conv=fdatasync

并获得了一个完全有效的 gparted 实时驱动器。这让我很困惑，所以我想我会寻求帮助。我知道如果我留在 Rufus 身边，我会省去麻烦，但这不是为了简单，而是为了了解正在发生的事情。我知道 linux 上的一些 gui 工具可能会解决这个问题，但是，我再次希望尽可能使用旧的 unix 终端来完成。如果不可能，那么我想知道为什么。总结一下：

1. 为什么它不起作用？我究竟做错了什么？
2. 为什么 dd 破坏了分区，但它似乎与 gparted 一起工作正常？
3. 我在哪里可以详细了解这种将图像复制到闪存驱动器的不太常见的用法？

非常感谢您的帮助！你会为我节省几个小时的头痛！

Answer 1

我想了解发生了什么

Rufus 开发人员在这里。

太多人无法理解的方式是什么，因为 Linux ISO 正在应用这种方法，但这本质上是一个称为“ISOHYBRID”的主要黑客，在大多数情况下，您不能简单地获取 ISO 映像并将其逐字节复制到一个 USB 驱动器，并期望它也能启动。

那是因为 ISO 格式和它使用的底层文件系统（ISO9660或UDF）是为光学启动而设计的，这与常规 HDD 或 USB 启动完全不同。一方面，光学媒体，因此（常规）ISO 映像，没有分区表，这（通常）对于 HDD 或 USB 启动必不可少，而且它们（通常）也没有主启动记录，也就是MBR，这是 BIOS 启动必不可少的。

这意味着，如果您将常规ISO（例如 Windows 的 ISO）以 1:1 的比例复制到磁盘上，并尝试启动，将会发生以下情况：

• Legacy/CSM 模式下的 BIOS 系统或 UEFI 系统将看不到任何 MBR，尤其是它看不到 MBR0x55 0xAA的最后 2 个字节中的序列，表明磁盘是 BIOS 可引导的。因此它将无法在 BIOS 模式下启动该磁盘。
• 一个UEFI系统（通常）未安装UDF或ISO9660从磁盘或闪存驱动器的媒体的分区，因为，即使它具有这些文件系统，创建生成的磁盘将丢失的驱动程序MBR或GPT分区表。引导普通磁盘时，UEFI 旨在首先查找分区，然后/efi/boot/bootx64.efi在该分区上查找引导加载程序（例如）。因此，如果媒体上没有分区表MBR或GPT分区表（常规 ISO 就是这种情况），那么 ISO 是否包含引导加载程序文件并不重要，因为 UEFI 固件将无法挂载它所在的分区在。

因此，在从完全标准的光学媒体映像 Windows ISO 创建可启动磁盘媒体时，像 Rufus 这样的实用程序所做的是：

• 创建一个分区表，MBR或者GPT根据用户选择的内容，并至少创建一个分区，该分区通常将用作FAT32或NTFS作为文件系统（请注意，它使用与 ISO 使用的文件系统完全不同的文件系统）。
• 如果MBR使用，则在MBR相关MBR分区上定位辅助引导加载程序中的一些代码，该代码旨在从该分区以磁盘模式启动 Windows 内核的执行。哦，它还确保0x55 0xAA在末尾添加引导标记，MBR以便 BIOS 将磁盘视为可引导。然后它还将 ISO 的内容复制到一个FAT32或NTFS分区上。
• 如果GPT使用，Rufus 会验证是否确实存在 UEFI 引导加载程序文件，例如 /efi/boot/bootx64.efi（好吧，实际上它在允许您选择 GPT 之前这样做，因为如果没有，尝试创建 GPT 可引导驱动器没有多大意义UEFI 引导加载程序），然后将其与 ISO 文件的其余部分一起复制，通常复制到一个FAT32分区上，因为从FAT32分区引导是 UEFI 的强制性要求（但这并不意味着 UEFI 无法引导，NTFS或者exFAT如果您有相关的 UEFI 驱动程序，如果您有一个文件大于 4 GB 的 Windows ISO，它会派上用场，因为 FAT32 无法容纳此类文件）。

现在，上面只能当辅助引导程序（即来自于Windows和它鲁弗斯不会修改的）被设计为支持两个光学和定时开机，这通常意味着他们需要同时处理UDF或ISO9660和FAT32或NTFS文件系统，以及从磁盘启动与从光学启动时出现的其他差异。但是微软确实为此设计了它的引导加载程序，这是明智的做法，因为，如果您的目标系统是 UEFI，这意味着您（通常，只要 4 GB 的最大文件大小问题FAT32不会引起它丑陋的头脑） ) 不需要实用程序来将 ISO 转换为可启动 USB，但您只需将该 USB 格式化为 FAT32 并将 ISO 文件复制到其上（文件复制，不是字节复制），并且您有一个可启动媒体。

现在我们已经完成了以上所有内容，我可以开始咆哮并解释为什么我认为通常比这更聪明的 Linux 发行版维护者实际上正在对他们的用户造成一些伤害，即使他们正在尝试帮助他们：

几乎所有最近的 Linux 发行版都使用名为“IsoHybrid”的主要 HACK，有人设法想出一种方法，将ISO9660光学映像伪装成常规磁盘映像，带有分区表，MBR以及所有内容......换句话说，大多数您现在发现的 Linux ISO 正在滥用ISO9660 文件系统，使其看起来像从未设计过的样子：双磁盘和光学映像。

显然，目标是创建一个也可以与dd命令一起使用的 ISO，即使 ISO 永远不能以这种方式工作。我同意，理论上，这听起来很棒，因为能够将单个图像用于完全不同的用途对用户来说应该是很好的，但在实践中，这会导致经常被忽视的问题：

• 许多 Linux 发行版维护者不想使用 Windows 可以挂载的辅助文件系统（例如，他们将ext用作其上的“辅助”文件系统ISO9660），这意味着很多Windows 人员正在创建第一次使用 Linux 的可引导驱动器，对于为什么他们无法再访问其闪存驱动器的内容感到非常困惑。如果“IsoHybrid”还包括一个 EFI 系统分区 (ESP)，那就更糟了，因为那样这些用户会觉得他们的驱动器的大小已经完全缩小了。如果你去 reddit 或其他地方，你会看到很多用户的帖子，他们对他们的 USB 媒体发生了什么完全感到困惑，这不会给 Linux 留下很好的第一印象......
• 由于许多 Linux 发行版维护者非常关注使 ISOHybrid 工作，以至于他们完全忽略了通过简单地将内容复制到FAT32格式化分区来创建 UEFI 可启动媒体的选项，这实际上应该始终是创建 UEFI 可启动驱动器的首选方法（因为与使用dd命令相比，格式化分区然后复制文件的风险通常要小得多）。正因为如此，我们已经看到一些问题导致 Manjaro 和 Ubuntu 的用户体验不佳......这实际上是我与“ISOHybrid”争论的主要观点：它不应该作为放弃既定方式的借口创建可启动媒体！
• GPT 和“ISOHybrid”可能会出现问题，因为在使用时辅助 GPT 表将被视为已损坏dd......这实际上会导致 Windows 7 上的 BSOD（但这实际上是 Windows 错误而不是 ISOHybrid 问题）。尽管如此，对于创建可启动驱动器的 Windows 人员来说，这并不是最好的体验......
• 最后，因为“ISOhybrids”被呈现为好像它们是世界上最自然的媒体（他们当然不是），像你这样的人被引导相信每个 ISO 图像都可以使用dd，当它是例外而不是比规则。这是非常不幸的，因为它造成了大量的用户困惑，一些 Linux 用户告诉想要创建 Windows 可启动媒体的人，他们应该能够使用dd，而这肯定永远不会奏效！此外，如果您选择 10 年前的任何 Linux ISO，我非常有信心您会发现它们中几乎没有一个实际上可以用于创建可启动媒体，dd因为这种“IsoHybrid”实际上是最近的发展。

据我所知，微软没有计划为他们的 Windows ISO 切换到 ISOHybrid 的“hack”，这意味着你不太可能使用它dd来创建可启动的 USB 媒体，因此，如果您想从 ISO 创建 Windows 可启动媒体，您可以：

• （UEFI）需要一个格式化驱动器与文件系统Windows可以从开机（NTFS，FAT32以及最近exFAT）和ISO解压文件到它。现在，如果使用NTFSor exFAT，您可能还需要做一些额外的工作......
• (BIOS/Legacy) 需要使用 Windows 可以启动的文件系统格式化驱动器（NTFS或者FAT32--exFAT将无法工作，因为 Microsoft 从未为它发布 BIOS 引导加载程序），然后创建相关的引导加载程序链，从 MBR 引导代码到卷引导记录。

实现它实际上并不复杂，但它确实比从 ISO 文件中 1:1 复制需要更多的工作。

希望这能回答你的问题。

Answer 2

dd不是创建 Windows 可启动 USB 的正确工具。最简单的方法是使用woeusb.

安装：

sudo apt-get install devscripts equivs gdebi-core
cd WoeUSB
./setup-development-environment.bash
mk-build-deps
sudo gdebi woeusb-build-deps_3.3.1_all.deb
dpkg-buildpackage -uc -b
sudo gdebi ../woeusb_3.3.1_amd64.deb

现在，软件包版本是3.3.1，如果软件包更新，该命令./setup-development-environment.bash将打印当前版本，您应该在上述命令中替换它。

用法：

您可以使用 GUI，woeusbgui从终端运行。或者您可以使用 CLI：

卸载 USB 设备（重要）。然后运行：

sudo woeusb -v --device /path/to/windows.iso /dev/sdc