Debian:使用终端(dd)创建 Windows 10 可启动安装 USB 驱动器

Debian:使用终端(dd)创建 Windows 10 可启动安装 USB 驱动器

我的目标很简单,标题说明了一切,但我尝试过的所有方法都失败了。我读过各种网站上的说明(除了这里),它们似乎都缺少了一些东西……这就是我所拥有的:

  • 16 GB SanDisk USB 3 驱动器。
  • Debian Jessie 机器
  • Windows 机器,Macbook Pro

虽然我可以轻松使用以下方法创建可启动的 Windows 10 USB鲁弗斯,我的目标更具教育意义:我想了解发生了什么,以及我失败的根源是什么,如果可能的话,让它发挥作用。

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

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

我得到一个似乎在 Debian 上安装的分区,但在 Windows 和 Mac 上无法识别。

Gparted 显示:

gparted 报告文件系统未知

相比之下,另一个正常工作的 USB 闪存驱动器(我有 4 个)读取如下:

正常工作的 USB 闪存盘读取如下

我在一些地方读到过,你不应该输出到分区(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,但附加了一个option:conv=fdatasync(有些人说这可以确保缓存中没有任何内容,可能会解决这个问题)。

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. 在哪里可以了解有关将图像复制到闪存驱动器这一不太常见的用途的更多信息?

非常感谢您的帮助!您将为我省去很多麻烦!

答案1

我想了解发生了什么

Rufus 开发人员在这里。

很多人不明白,因为 Linux ISO 正在应用这种方法,但这本质上是一种重大黑客攻击,称为“ISOHYBRID”,在大多数情况下,您不能简单地获取 ISO 映像并将其逐字节复制到 USB 驱动器,并期望它能够启动。

这是因为 ISO 格式及其使用的底层文件系统(ISO9660UDF)是为光盘启动而设计的,这与常规 HDD 或 USB 启动完全不同。一方面,光盘介质(因此是常规)ISO 映像没有分区表,而分区表(通常)对于 HDD 或 USB 启动必不可少;另一方面,它们(通常)也没有主引导记录(又称 MBR),而主引导记录(又称 MBR)对于 BIOS 启动必不可少。

这意味着,如果你复制一份常规的ISO(例如 Windows ISO)放到磁盘上,然后尝试启动,将会发生以下情况:

  • BIOS 系统或处于 Legacy/CSM 模式的 UEFI 系统将看不到任何 MBR,尤其是它将看不到0x55 0xAAMBR 最后 2 个字节中指示磁盘可 BIOS 启动的序列。因此它将无法在 BIOS 模式下启动该磁盘。
  • UEFI 系统通常不会从磁盘或闪存驱动器介质安装UDFISO9660分区,因为即使它具有这些文件系统的驱动程序,您创建的结果磁盘也会缺少MBRGPT分区表。在启动常规磁盘时,UEFI 旨在首先查找分区,然后在该分区上查找引导加载程序(例如)。因此,如果介质上/efi/boot/bootx64.efi没有MBR或分区表,GPT对于常规 ISO 来说也是如此,那么 ISO 是否包含引导加载程序文件并不重要,因为 UEFI 固件将无法挂载它所在的分区。

因此,Rufus 等实用程序在从 Windows ISO(一个完全标准的光学媒体映像)创建可启动磁盘介质时会执行的操作是:

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

现在,上述方法仅在辅助引导程序(即来自 Windows 且 Rufus 不会修改的引导程序)设计为支持时才有效两个都光盘启动和常规启动,这通常意味着它们需要处理UDFISO9660FAT32NTFS文件系统,以及从磁盘启动与从光盘启动时出现的其他差异。但微软确实为此设计了引导加载程序,哪个是明智的做法因为,如果你的目标系统是 UEFI,这意味着你(通常,只要 4 GB 的最大文件大小问题FAT32不会出现)不需要实用程序将 ISO 转换为可启动的 USB,但你可以将该 USB 格式化为 FAT32 并将 ISO 文件复制到其中(文件复制,不是您将获得一个可启动媒体。

现在我们已经完成了上述所有的事情,我可以进入一个咆哮并解释为什么我相信 Linux 发行版维护者通常比这更聪明,但实际上却在损害他们的用户,即使他们试图帮助他们:

几乎全部最近的 Linux 发行版使用重大黑客攻击称为“IsoHybrid”,有人设法找出一种方法,使ISO9660光学映像伪装成常规磁盘映像,带有分区表、MBR和一切……换句话说,你现在找到的大多数 Linux ISO 都是滥用ISO9660 文件系统使其看起来像它从未设计过的样子:双磁盘和光学图像。

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

  • 许多 Linux 发行版维护者不想费心使用 Windows 可以挂载的辅助文件系统(例如,他们将用作ext其上的“辅助”文件系统ISO9660),这意味着很多首次使用 Linux 创建可启动驱动器的 Windows 用户非常困惑,为什么他们无法再访问闪存驱动器的内容。如果“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 这一“黑客技术”,这意味着您不太可能能够使用dd它来创建可启动的 USB 媒体,因此,如果您想从 ISO 创建 Windows 可启动媒体,您可以:

  • (UEFI)需要使用 Windows 可以从中启动的文件系统格式化驱动器(NTFS以及FAT32最近exFAT)并提取 ISO文件到它上面。现在,如果使用NTFSexFAT,你可能必须也做一些额外的工作...
  • (BIOS/Legacy)需要使用 Windows 可以从中启动的文件系统来格式化驱动器(NTFS或者FAT32——exFAT将不起作用,因为微软从未为其发布 BIOS 引导加载程序),然后创建相关的引导加载程序链,从 MBR 引导代码到卷引导记录。

实际上,这并不是那么复杂,但比从 ISO 文件进行 1:1 复制确实需要更多工作。

希望这能回答你的问题。

答案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

答案3

以此见解为动力找到一种方法来建立一个Windows 服务器 2019可启动 USB 驱动器苹果系统。问题是你需要一个 GPT 格式的磁盘作为 FAT32,并且文件大小上限约为 4GB,你需要使用wimlib-imagex扩展来解决。我最初尝试使用dd实用程序- 但很快意识到该磁盘格式不能用于 WinOS 启动。

在 MacOS 上创建 Windows Server 2019 可启动磁盘

brew install wimlib 
diskutil list 
diskutil eraseDisk MS-DOS "WIN2K19" GPT /dev/disk2 
hdiutil mount en_windows_server_2019_updated_sep_2020_x64_dvd_2d6f25f2.iso 
rsync -vha --exclude=sources/install.wim "/Volumes/SSS_X64FREV_EN-US_DV9\ 1" /Volumes/WIN2K19 
wimlib-imagex split "/Volumes/SSS_X64FREV_EN-US_DV9 1/sources/install.wim" /Volumes/WIN2K19/sources/install.swm 4000
diskutil eject /dev/disk2 
diskutil eject /dev/disk3

相关内容