其实从标题就能看出来我有多蛋疼了。我不期望还有别的人和我有同样的奇怪需求,但是希望本文的一部分或几部分能对部分折腾者有一定有作用。
一、为什么会有这样的需求
要 BIOS 不要 UEFI
虽说现在的主板都采用 UEFI 了;虽说 BIOS 是很古老的东西了……但是,我实在不喜欢 UEFI 的复杂设计。说是 Unified 但是我感觉它一点也不统一。最重要的是:UEFI 对 Linux 不够友好。
要 GPT 不要 MBR
虽说严格来说 GPT 也是 UEFI 的一部分,但是我对它的印象好多了——MBR 只支持 4 个主分区而 GPT 默认情况就能支持 128 个分区,再也不用小心翼翼地折腾扩展分区和逻辑分区——这也是我所讨厌的。
要 Steam.exe 不要 Steam.deb
虽然我已经用惯了 Arch Linux;虽然 Valve 也有出 Steam for Linux 甚至 SteamOS,但是至少到目前为止,毕竟 Windows 才是正经的玩游戏的操作系统。
二、BIOS + GPT
2009 年之后的主板基本是 BIOS + UEFI 双配置,为了不让 UEFI 来瞎捣乱,我在主板设置里会选择 BIOS Only 以堵死 UEFI 的路。至于 2009 年以前的那些不支持 UEFI 的主板,倒有些需要小心:虽然理论上,只要不是古董电脑,都能支持 GPT,但是有一小部分有问题的 BIOS 会无法从 GPT 启动。 GPT 的分区工具首选 gdisk,不要用太旧的版本,默认就能 4k 对齐。
三、GRUB + Linux
虽然受到软件无政府主义的困扰,但是 GRUB 依旧是一款功能强大且十分流行的引导器。本文所指的 GRUB 一律指 GRUB 版本 2,而不是曾经的 GRUB Legacy。 要想让 BIOS + GPT + GRUB 工作,你需要一个 EF02
分区。由于没有了 post-MBR gap,这个分区是给 GRUB 放置它的core.img
的,不需要文件系统。事实上,把 core.img
放在一个单独的分区里比放在 post-MBR gap 里稳定、整洁多了。在 gdisk 里新建分区时将分区标识符改为 EF02
即可,大小的话,2 MiB 足够了。 创建完 EF02
分区之后,其他的分区正常创建即可,比如我这样:
Number Start (sector) End (sector) Size Code Name 1 2048 6143 2.0 MiB EF02 BIOS boot partition 2 6144 20977663 10.0 GiB 8300 Linux filesystem 3 20977664 230692863 100.0 GiB 8300 Linux filesystem 4 230692864 500117503 128.5 GiB 0700 Microsoft basic data
然后使用 grub-install
即可自动将 core.img
嵌入那个迷你小分区。 至于 Linux 的安装,无需多言。
四、+ Windows
如无特别说明,以下提到的 Windows 指 NT 内核 6.0 以上版本。本文以 Windows 8.1 为例。
傲娇的 Windows
MSDN 明确指出,Windows 只能安装于 BIOS + MBR 或是 UEFI + GPT 的组合上,而 BIOS + GPT 和 UEFI + MBR 是不允许的。这实在是太傲娇了——因为 BIOS + GPT + GRUB + Linux 是完全没有问题的。事实上,我的笔记本电脑刚安装的时候并没有考虑到往硬盘里灌 Windows,因此之前一直是 BIOS + GPT + GRUB 的配置,在这样的情况想让 Windows 入驻,简直是逼我上梁山…… 为什么 MSDN 声称 Windows 不能在 BIOS + GPT 工作?经过我的试验,发现其实只是 bootmgr 读不了 GPT 而已。直到 bootmgr 被唤醒之前,一切都是没有问题的,而 bootmgr 应该去读取 \Boot\BCD
然后再根据 BCD 去加载 \Windows\System32\winload.exe
和 ntoskrnl.exe
。可是 bootmgr 读不了 GPT,直接导致它找不到 \Boot\BCD
…… 那么怎么办呢?
- 换一个能读 GPT 的引导器,读取 BCD 之后正常加载 Windows 内核。——不好意思,这样的引导器不存在。在得出这个结论之前,我吃了很多苦。
- 将 BCD 放在 bootmgr 能读的地方。——比如一(小)块 MBR 存储设备,它不一定要是物理的,也能是虚拟的。在得出这个结论之前,我流了很多泪。
而 Windows 默认的安装程序要求又高、功能又弱,根本不会给你选择启动文件安装到哪里的,所以必须要手工安装。
要 imagex 不要 Setup.exe
Windows 默认安装框架是在 Windows PE 里使用 Setup.exe。该程序会运行一系列烦人的检查并增加一堆不合理的限定,比如要求 .NET Framework,比如强制添加 300 MiB 的系统分区等。而实际上它所做的事情也不过是:解压 install.wim
到指定分区、写入引导扇区、写入 BCD 这三样。可是这三件事,能自定义的部分还很少或很麻烦,那为啥不自己来呢?所以我更喜欢的方法是启动到 Windows PE 之后手工安装。
Windows PE 哪里来?TechNet 提供的方法是从 WAIK 里生成。但前面说了,Windows 的安装框架是 Windows PE,而 Windows 安装镜像文件也不过就是 Windows PE 和 install.wim
的组合而已,所以直接从安装镜像里就可以释放一个 Windows PE 出来。用 wimlib 提供的mkwinpeimg
可以很方便地做到这一点,能直接从 Windows 安装镜像中获取 Windows PE 所需的 boot.wim
并制成可启动的镜像文件。如果你懒得自己提取 Windows PE,那么这里有我做好的两份。两份 Windows PE 除了添加了一个 imagex.exe
之外没有任何改动,十分纯洁干净:(其实不添加也行,用更加高大上的 dism
也能释放文件)
install.wim
哪里来?Windows 安装镜像里就有,使用 7z e Windows.iso sources/install.wim
即可把它解压出来。在移动存储设备里保存install.wim
而不是完整的 iso,甚至能省下 500 MiB 以上的空间。
接下来就是安装了。通过可启动媒体启动进 Windows PE,用 diskpart
进行合理的分区。以下为带注释的操作过程:
# 确认当前硬盘情况 DISKPART> list disk # 假设系统硬盘为 Disk 0 (Windows 将安装于此) # Windows PE 所在的盘为 Disk 1 (请忽略) # 过会儿要创建的 VHD 为 Disk 2 (Windows 启动文件将安装于此) DISKPART> select disk 0 DISKPART> list partition DISKPART> select partition 4 DISKPART> format label="Windows 8.1" quick DISKPART> assign letter=c # 以上命令格式化要安装 Windows 的分区并分配卷标 C: # 接下来创建并挂载 VHD DISKPART> create vdisk file=c:\bootmgr.vhd maximum=32 type=fixed DISKPART> attach vdisk # 然后在 VHD 里创建并激活分区。offset 不是必须的,但是我喜欢 DISKPART> select disk 2 DISKPART> create partition primary offset=1024 DISKPART> active DISKPART> format label=bootmgr quick # 分配一个卷标 B: DISKPART> assign letter=b # 退出 diskpart DISKPART> exit
然后就是安装 Windows 和 Windows 启动文件了:
# 解压文件,注意根据实际情况选择 index,此处为 1 X:\> imagex /apply install.wim 1 c: # dism 的等效命令是:(长多了) X:\> dism /Apply-Image /ImageFile:install.wim /Index:1 /ApplyDir:C:\ # 写入启动代码和启动文件 X:\> bootsect /nt60 b: /mbr X:\> bcdboot c:\Windows /s b:
至此 Windows 部分就算完成了,可以在 diskpart 里 detach vdisk
然后重启进 Linux 继续操作。
用 MEMDISK 引导硬盘镜像
在上一节中,我们得到了一个装好了 Windows 的分区,以及一块 32 MiB 的虚拟硬盘镜像,这块虚拟硬盘采用 MBR,有且只有一个主分区,主分区里装着大约 19 MiB 的 Windows 启动文件。其实这些启动文件真正核心的只有不到 1 MiB,其他的都是语言包和字体等,如果你闲得无聊可以挂载来删除它们,当然硬盘镜像文件大小不会自动缩小就是了。
那么,MEMDISK 能直接引导 vhd 么?我一开始也觉得不能,因此查到了用 VirtualBox 或 QEMU 来把 vhd 转成 raw image 的方法:VBoxManage clonehd --type raw bootmgr.vhd bootmgr.img
。但是后来经 @tjmao 的提醒,我才发现原来当 type=fixed
的时候,vhd 其实就是 raw image 加上 512 字节的 footer。切掉这个尾巴之后,得到的东西和 dd 式的 raw image 是一模一样的。而就算不切掉尾巴,这一部分也会被认为是未分区空间从而被忽略掉。所以,其实 type=fixed
的 vhd 是不用转换,直接可以当 raw image 用喂给 MEMDISK 的。
那么怎么喂呢?根据调用 MEMDISK 的方法不同,具体的语法也有一定差别,完整的叙述可在这里找到。以下是 GRUB 的方法:
menuentry "bootmgr.vhd" { linux16 /boot/syslinux/memdisk harddisk initrd16 /boot/bootmgr.vhd }
把这一段复制到 /boot/grub/grub.cfg
中即可使用。如果要使它可在 grub-mkconfig
后自动生成的话,复制到 /etc/grub.d/40_custom
中即可。
至此 Windows 的引导就算是做好了。重启计算机在 GRUB 菜单中选择对应的 menuentry 即可进入。第一次进入的时候会自动安装驱动等,安装完自动重启,然后就功德圆满了。
五、一些可以改动的部分
如导言中所说,有和我完全一样的需求的人应该不存在,但是本文的思路可用于一些别的折腾过程中。以下列举了部分可以改动的部分,适用于不同的具体情况。
Linux 不是必须的
如果你只是想安装 BIOS + GPT 的 Windows,自然不用装 Linux。但是你可能需要备一个 Notepad.exe 在 Windows PE 环境中,用来编辑引导器的配置文件。
GRUB 可以换成别的
如果不装 Linux 了,那单独装个 GRUB 也没啥意思,还不如换点别的引导器。诸如 Syslinux, Grub4Dos 等,都可以用来加载 MEMDISK。具体的语法依然戳这里。不过如果换成别的启动器的话,那个启动器得要像 GRUB 一样对 GPT 有支持……
VHD 的大小问题
在想到 VHD 的方法之前,我曾试过的是把装的引导分区的 U 盘整个 dd_rescue
复制下来。这是一个较老的 U 盘,容量只有 4 GB,但是就这样产生的镜像文件也太大了,无法被 MEMDISK 正确加载。虽然最后我成功地把这个镜像挂载之后缩小文件系统和分区使它「瘦身」,但步骤较复杂。想到 VHD 的方法之后就简单了,直接创建一个小一点的 VHD 然后在里面操作即可。现在已知镜像文件不能太大,否则 MEMDISK 加载不了,那么它最小能多小呢?
核心的 Windows 启动文件只有 bootmgr
和 Boot\BCD
这两个,加起来不到 1 MiB。我也试过,引导分区里只放这两个文件,依然能正常引导,但是实际上 VHD 不能只有 1 MiB。这是因为:
- 用
bcdboot
复制启动文件的时候,默认会复制那些语言包和字体,总共 19 MiB 左右 - NTFS 分区最小需要 8 MiB
我实验成功的最小大小是 10 MiB 的 VHD,里面装着一个 8 MiB 的 NTFS。
当代的计算机大部分都是 4 GB 和 8 GB 的内存了,所以不用克扣这么一点点空间(毕竟它引导完就被释放掉了),所以创建 VHD 时选择 32 MiB 是个比较好的选择。记得 type=fixed
就行。
六、吐槽和尾巴
好久没写有关 Windows 的博文了。本来以为自己的对 Windows 的需求在 VirtualBox 里就能完全满足了,因此笔记本电脑安装系统的时候并没有为 Windows 考虑过,直接就是 BIOS + GPT + Linux 的组合了。可是自从 2014 年初在迷上了 Call of Duty 之后就入了 Steam 的大坑了,因此对独立的 Windows OS 的需求再次浮现。之前尝试 BIOS + GPT + Linux 既有配置下再塞个 Windows 怎么都没成功,因此选择了 Windows To Go 的解决方案——将整个 Windows 及其引导文件装到外置 USB 硬盘里。可是 USB 机械硬盘的速度又怎么能和 Samsung 840 Pro SSD 相比……于是发愤图强,努力研究,终于实现了 Windows 本体安装在 GPT SSD 里而把引导文件装到 MBR U 盘里的方法。慢慢地这样的方法又不能满足我的要求了,于是继续发愤图强,在各种来源都说这是不可能的情况下,我最终还是曲线救国成功了。
于是便有了本文。
转载请注明出处: https://wzyboy.im/post/1049.html