如何把grldr放置到扩容后的MBR中？

不点

这没有技术困难。主要是应该注意安全，谨慎行事。

建议安装 wee63.mbr 或 wee127.mbr 到硬盘的最开头。有很多工具可以安装 wee 到 mbr。比如，bootice，weesetup 等。安装程序会自动保持分区表不变，比较安全。如果手动用十六进制工具进行操作，那就有可能因疏忽大意而毁掉分区表，造成不可挽回的损失。你得保证 MBR 上有足够的空间。如果 MBR 上没有足够的空间，那么你后续手动写入的 GRLDR 就会破坏硬盘分区的数据结构，那就糟糕透了。

wee63.mbr 占据 63 扇区。硬盘最开头的 63 扇区被占用。wee 的安装工具软件通常支持 wee63.mbr 的安装。

wee127.mbr 占据 127 扇区。硬盘最开头的 127 扇区被占用。wee 的安装工具软件通常不支持 wee127.mbr 的安装。因此，你就不要用它了。

然后，你用十六进制工具软件或者 dd 之类的命令，将 GRLDR 或 GRUB.EXE 文件放在 MBR 中剩余的空间里。随便放在哪里都可以。比如，你就放在扇区号 128 的位置，就是说，放置在从 (hd0)128+1 开始的连续空间中便可。

假定 grldr （或 grub.exe）占用 1024 扇区，那么，你的 wee 菜单中就可以用如下一行命令来执行 grldr （或 grub.exe）：

(hd0)128+1024

grldr 和 grub.exe 都是 wee 的命令，直接执行它们便可。其实，NTLDR 和 BOOTMGR 也是 wee 可以认出的命令，因此你也可以用同样的方法来启动 NTLDR 和 BOOTMGR。不过，启动 NTLDR 和 BOOTMGR 之前需要用 root 或 rootnoverify 命令设置当前默认分区为 Windows 启动分区（就是 BOOT.INI 或者 BCD 所在的分区），否则，NTLDR 或 BOOTMGR 就可能找不到启动所需的其他文件，导致启动失败。

由于其中有手动操作的步骤，因此，一定要小心谨慎啊！

不点

能回答的问题，通常大家都愿意回答。不用谢。

grldr 的开头有 16 扇区是用来寻找 grldr 的。这具有历史的原因。NTLDR 通过 boot.ini 加载 GRLDR 时，只能加载 16 个扇区，不能完整加载 grldr 文件。所以，我们需要安排 16 个扇区的引导头，用来搜索 GRLDR 文件，找到后把它完整加载到内存。grldr.mbr 后来独立出来了，其大小是 18 个扇区，专门用来放在 MBR 上，搜索和加载 grldr 文件。然而 grldr 的头部仍然是 16 扇区，并且 grldr 的第一扇区中没有放置分区表的位置了，在分区表的位置上是 grldr 的代码。因此，grldr 的头部已经不能用于 MBR 了，它只能与 GRLDR 构成一个整体而在 boot.ini 中被 NTLDR 使用。用于 MBR 的，只能是 grldr.mbr 文件。

grldr.mbr 的功能是在硬盘各分区根目录下查找 grldr 文件并启动它。这是个很简单的功能，它只有 18 扇区，源代码全都是用 assembly 写成的。它不能用 (hd0)xxxxxx+yyyyyy 的方式加载引导扇区文件，它甚至也不能加载位于某个子目录中的 grldr 文件（只能寻找根目录下的 GRLDR 文件）。

wee63.mbr 就不同了。它实际上是一个简化了的 grub4dos 系统，它具有命令行和简单的菜单功能（就如同一个简单的操作系统那样）。对比一下，grldr.mbr 是没有命令行的，也没有菜单。wee63.mbr 的源代码使用了 assembly 和 C 两种编程语言。编译的结果占用 63 扇区，比 18 扇区大了很多。

结论是，grldr.mbr 无法满足你的需要。需要使用 wee63.mbr 或 wee127.mbr 才行。

目前，wee127.mbr 主要是给 map 命令增加了磁盘仿真功能。比如，你可以用 wee127.mbr 建立一个虚拟软盘。

如果你的 MBR 上的空闲扇区足够多，能够放得下一个软盘 IMG 的话，你就可以用 wee127.mbr 来启动这个软盘映像了。

不点

weesetup 即使使用 --force 之类的参数，似乎也有拒绝写入引导记录的情况发生。比如，前次我遇到的 diskgen 的 bug，它创建了一个非法的分区项目，分区 (hd0,3) 的 16 字节分区表项以 55 AA 开头，导致 weesetup 拒绝安装。

拒绝安装是对的。但是，拒绝安装的时候，应该打印出分区表，让用户明白拒绝的原因。否则，没有提示信息，用户一头雾水，还以为安装成功了呢。

weesetup 也应该有个文档吧，建议 chenall 把 weesetup 的文档放在网上，供查阅。

不点

pppfj，大家都是 “草根”、“屁民”，谁也不比谁 “高一头、宽一肩膀”，只是 “爱好有差别、行业有不同” 而已，不必太客气。

grldr 头部的 16 扇区以及 grldr.mbr 的 18 扇区，都只能搜索文件系统中的 GRLDR 文件，不能按照扇区编号去加载 GRLDR 文件。你可以理解为，它的代码量很小，功能很有限。

wee 按照扇区序列加载整个 grldr 到内存之后，grldr 就不需要再搜索自己了。grldr 就直接定位到自己的内核部分，并启动它。grldr 内核一旦接管控制，以前的引导代码（包括 wee 以及 GRLDR 的头部代码）就废弃了，就像火箭把卫星送入轨道之后，火箭就扔掉了。

多级火箭的加载方法，看起来有些 “费劲”。或许有人希望只用一个较大的 wee1024.mbr 就完成 grldr 的加载。这当然是可能的，只是目前还没有人去这么做。现成的东西，比如馒头、香蕉，都可以马上吃掉。而小麦需要进行加工才能食用，那属于 “未来” 的事情。“未来” 怎么样，那是很有变数的，需要有人去做额外的工作才能得到。我们还是主要着眼于 “现实” 吧，“解决问题” 本身就是一个很 “现实” 的事情，不能等到 10 年后去解决。

其实，从某种程度上说，wee127.mbr 就够用了。也就是说，如果你安装了 wee127.mbr，它有比较完善的 map 功能，这样也就基本上不需要 grldr 了。当然，如果你需要显示国际化的 UTF-8 字符，或者其他一些高级功能，那还是需要 GRLDR 的。

不点

多载入的尾部扇区，不影响 grldr 的执行。

天涯海角自己测试成功了吗？我假定天涯海角测试成功了。

那么可能还有什么问题呢？

有啊。我没有看天涯海角的引导代码，但我知道，两个扇区是无法完成加载的。困难在于，当 BIOS 对 USB 设备不支持 LBA 模式的读取时，必须探测正确的 CHS 值，才能成功启动超过一个磁道长度的 GRLDR 扇区序列。光是这 CHS 探测的代码，就要满满地占用 2 个扇区。再加上扇区引导记录也要占用一个或两个扇区，因此，最低的扇区占用是 3 个扇区。如果选择不探测，那么确实能够做到在一个扇区之内完成加载。不探测时，必须由用户在你所规定的位置填写正确的 H 和 S 值，才可以保证成功加载。然而用户确定 H 和 S 是麻烦的，除非用户事先知道 H 和 S 的值。

如果假定 BIOS 支持 LBA，那么只需 1 个扇区即可完成加载。Wee 就是这样做的。Wee 的第一扇区可以加载 127 扇区的引导代码。为什么是 127 呢？那是因为，这个 127 就是 LBA 模式的 BIOS 每次传递的最大扇区数。如果加载的扇区数超过 127，那么需要反复调用 BIOS 多次，可以用一个循环来实现。wee 只调用了一次 BIOS，所以，wee 不需要循环。要读取更多的扇区，必须修改 Wee 的代码，增加一个循环。

为了加载 GRLDR，可以假定 GRLDR 为 512K，即 1024 个扇区。GRLDR 不可以超过 512K。超过之后，GRLDR 就有可能无法被成功加载，或者在某些情况下（例如 PXE 启动时）产生内存冲突（内存覆盖），导致死机或运行失常。要知道，机器的最大可用常规内存也达不到 640K。所以，512K 的 GRLDR 就已经很大了。

用 BIOS 加载扇区，当不支持 LBA 模式时，最大的困难就是 H 和 S 的确定。如果这个没问题，那基本上就不会有问题了，顶多还有一个 “扇区号过大，超出 BIOS 加载能力” 的问题，不过这不会出现，因为我们这里的扇区都是在磁盘最开头，都在 1M 以内，是最安全的了，没有理由加载失败。

不点

进一步的引申。假如你为 MBR 保留 8M 以上的扇区数，那么你可以安装 fbinst 了。

fbinst 能够保证万无一失。fbinst 失败的情况，都可以通过调整安装参数（例如是否复制 BPB）来解决。到目前为止，没有见到一个真实的、经过确认的失败报告。理论上，fbinst 也可能成为主板 BIOS 攻击的对象，不过，从实践来看，却没有人给出一个确认无误的失败报告。

不点

没有几何参数的探测适应过程，也就不能保证有较高的成功率。虽然在一部分机器上测试成功，但不能大面积推广。

前面提到，要么采用 fbinst，要么集成 grldr.mbr 末尾的几何参数探测代码。否则不能应付各种主板变态的、五花八门的 CHS 值。

感觉采用 fbinst 是最根本的，因为它的成功率最高。

不点

如果只是给自己用，知道自己的电脑支持 LBA，那么根本问题就不存在了，很容易做。因为 LBA 是线性地址，是一维的，是 “全球通用” 的。这一点就好比 UTF-8 语言字符编码也是全球通用的那样。而 CHS 是三维的，即，所谓的 “几何参数”，太复杂，不同的机器就不一样。所以，只要支持 LBA，那程序的编写就太简单了。本地硬盘是可以保证支持 LBA 的。

看到几位不是在本地硬盘上使用，而是在 U 盘上使用。假如主板不支持 LBA，那么其中有些方案就不行了，必须用 fbinst 才能保证最大的成功率。尤其是，Wee 也是依赖 LBA，所以，Wee 不能应付 USB 上的复杂情况。

除了 LBA 这个 “大问题” 以外，还有 “扇区数极限” 这个小问题。靠近磁盘开头的扇区容易被 BIOS 支持，而靠近磁盘尾部的扇区，就可能因 BIOS 的 “能力不济、鞭长莫及” 而无法访问了。即使是本地硬盘，其 BIOS 的扇区访问能力也是有极限的，有很多主板（是大量的主板），其 BIOS 只能访问 137G 的硬盘空间，不能访问超出这个极限的其他那些扇区数据。在 U 盘上，其极限值可能还要低。就是说，在支持 LBA 的情况下，仍然有 “扇区数极限” 的问题。不要以为，只要支持 LBA 就 “万事大吉” 了。

不点

如果用 wee 的第一扇区，前面说了，由于要读入超过 127 个扇区，那么，你得修改 wee 的代码，增加一个循环。而至于说要读入多少个扇区，那就不必细算了，统一读入 1024 个扇区（也就是 512K）即可，这也就是 GRLDR 的最大理论长度。wee 的第一扇区是引导代码。第二扇区是空白，这与 grldr.mbr 一样，是用来放置 “备份的 MBR 扇区”。第三扇区开始，就是 GRUB 的核心 pre_stage2。

不过，既然天涯海角给出了成功的办法，也就没必要用 wee 了。更因为这些办法都不能处理针对 CHS 的兼容性，所以，只要有一种就行，多了也就没有太大的意义。