为移动操作系统打造稳健的引导扇区，请参谋

[tin...@tom.com]

为移动操作系统打造稳健的引导扇区，请参谋

最近有三个朋友报告了 bug，反映的问题是 grub4dos 在某些机器上不能读取 USB 移动设备的扇区。

为什么不能读取扇区呢？

我们可以猜测，那是因为，传统的 CHS 模式读取，与 BIOS 认定的 CHS 几何参数密切绑定。很难找到其它原因了，因为代码部分反复核查，没有漏洞。

按照微软的常规做法，引导扇区的 BPB 表中含有 CHS 几何参数。微软的引导扇区，都是依赖这个 BPB 表中的几何参数，来进行扇区访问。

一旦磁盘从一个机器移动到另外一个机器，那么，BIOS 的 CHS 就可能变化，导致启动失败。

有时候设备在“移动”之后能够启动，用户发现不了问题。但有时候，“移动”之后就不行了。当启动文件（比如 IO.SYS 和 GRLDR）处在靠近移动设备开头的一段空间中时，就容易在不同的 CHS 参数下成功启动，而当文件所处的物理扇区位置靠后时，就不容易适应 CHS 参数不同的机器了。

用户一般把 IO.SYS 放在文件系统的开头部分，所以，IO.SYS 容易躲过很多失败的情形。但是，微软的引导扇区是严重依赖 BPB 表的，所以，IO.SYS 也会遇到失败，只是，用户一般自己能容忍微软，总以为是自己弄错了，而不认为是微软的程序有毛病。

既然微软也会失败，那么我们的 GRLDR 的失败也不算什么了。如果这样想的话，其实我们什么也不用做，让用户自己来修改 BPB，保证其
CHS 参数是与 BIOS 的 CHS 参数相一致的。我以前就一直是持有这样的看法的。

但是，现在微软已经把 DOS 抛弃了，我们还能把它一直当做“工业标准”吗？尤其是它的缺点，不能适应移动设备不断变化的 CHS 参数，微软当然不会再去为用户改进了。但是我们仍然可以改进啊。当然我们不是改进 DOS，而是改进 GRUB4DOS。

我们也可以选择不改进，听之任之，等着 USB 设备容量普遍超过 8G 的那一天的到来──到那时 LBA 就成了必然采纳的了，于是 CHS 就不再成其为问题了。

如果我们选择改进，那就要改变现有的某些东西，有一些关键问题需要研究对待。

由于 BIOS BUG 的普遍存在，int13/ah=8 所返回的 CHS 参数根本不可靠。以前我们解决了大量的 USB 问题，其实大多都是因为 int13/ah=8 返回错误的
CHS 参数所造成的。因此，我们不能依赖 INT13/AH=8。这样的话，为了获得可靠的 CHS 参数，我们不得不编写一段程序，来探测主板 BIOS 中 CHS 的值。这段程序要占用不少字节，而现在的引导扇区中已经没有空闲来放置这些字节了。我们的难点就在这里。怎么解决这个难点，是我们今天讨论的主要议题。以下我提两种解决方案。


1. 把设备重新格式化，让设备的“保留扇区”为 2 个。FAT 文件系统的“保留扇区”其实就是引导代码的存放空间。通常这个保留扇区的数目为 1, 也有超过 1 的（主要是在 FAT32 中），但这个最小值 1 用得很普遍。NTFS 没有保留扇区这个概念，但 NTFS 实际上保留了 16 个扇区专门存放引导代码。EXT2 也没有保留扇区这个概念，但 EXT2 实际上保留了 2 个扇区专门存放引导代码。重新格式化，让 FAT 引导扇区的数目最少为 2, 这样做的好处是，我们编写代码比较简单，不需要更动现有 GRLDR 的结构（这样的话，其实 GRLDR 没有任何地方需要更动）。重新格式化的不利之处是，用户是否愿意？用户是否理解引导扇区数目扩大为 2 的必要性和好处？我们可以在 bootlace 中这么做：当发现保留扇区为 1 时，只安装传统的单一扇区 GRLDR 引导代码（没有 CHS 自适应功能），而当发现保留扇区多于 1 时，我们就安装新的两个扇区的 GRLDR 引导代码（具有 CHS 自适应能力）。这样供用户选择。一旦用户遇到启动困难，我们建议他重心格式化移动设备，让保留扇区数目至少为 2 。

2. 我们仍然只用一个扇区的引导代码。这样，当把这个扇区中加入 CHS 自动探测的代码后，就无法装入完整的 GRLDR 到内存了，而是只能装入 GRLDR 的第一扇区到内存。这样的话，GRLDR 第一扇区中还得编写继续装入 GRLDR 其余部分的代码。这样的话，GRLDR 的结构和代码就都需要做调整了。即便这能够做到，那么代码空间的使用仍然是十分紧张的。空间紧张的话，将来遇到 BUG，就没有足够的空间来缓冲、排解所遇到的 BUG。

因此，我觉得第一种方案更好控制，我更倾向于第一种。

好了，请大家发表一下各自的意见，帮助我做出分析判断。

=============================================== 快来和我一起享受TOM免费邮箱吧！ 看看除了1.5G，还有什么？ 看看女人都在聊什么? 美图尽赏 聊天世界 明星金曲免费送(http://mm.tom.com/ivr/)：周杰伦 林俊杰 庞龙 张惠妹 劲爆歌曲尽情点(http://mm.tom.com/ivr/)：霍元甲 吉祥三宝 人质 曹操 炫酷彩铃免费送(http://mm.tom.com/cailing/)：周杰伦帮你接电话 麻烦女朋友 七里香 小城故事 ===============================================

[Bean]

1. 把设备重新格式化，让设备的"保留扇区"为 2 个。FAT 文件系统的"保留扇区"其实就是引导代码的存放空间。通常这个保留扇区的数目为 1, 也有超过 1 的（主要是在 FAT32 中），但这个最小值 1 用得很普遍。NTFS 没有保留扇区这个概念，但 NTFS 实际上保留了 16 个扇区专门存放引导代码。EXT2 也没有保留扇区这个概念，但 EXT2 实际上保留了 2 个扇区专门存放引导代码。重新格式化，让 FAT 引导扇区的数目最少为 2, 这样做的好处是，我们编写代码比较简单，不需要更动现有 GRLDR 的结构（这样的话，其实 GRLDR 没有任何地方需要更动）。重新格式化的不利之处是，用户是否愿意？用户是否理解引导扇区数目扩大为 2 的必要性和好处？我们可以在 bootlace 中这么做：当发现保留扇区为 1 时，只安装传统的单一扇区 GRLDR 引导代码（没有 CHS 自适应功能），而当发现保留扇区多于 1 时，我们就安装新的两个扇区的 GRLDR 引导代码（具有 CHS 自适应能力）。这样供用户选择。一旦用户遇到启动困难，我们建议他重心格式化移动设备，让保留扇区数目至少为 2 。

2. 我们仍然只用一个扇区的引导代码。这样，当把这个扇区中加入 CHS 自动探测的代码后，就无法装入完整的 GRLDR 到内存了，而是只能装入 GRLDR 的第一扇区到内存。这样的话，GRLDR 第一扇区中还得编写继续装入 GRLDR 其余部分的代码。这样的话，GRLDR 的结构和代码就都需要做调整了。即便这能够做到，那么代码空间的使用仍然是十分紧张的。空间紧张的话，将来遇到 BUG，就没有足够的空间来缓冲、排解所遇到的 BUG。

因此，我觉得第一种方案更好控制，我更倾向于第一种。

好了，请大家发表一下各自的意见，帮助我做出分析判断。

第一种方案可能会有麻烦，目前可以指定保留扇区数的格式化程序好像不多吧，用户也许不知道如果操作。而且，也不排除一些buggy的程序，在处理FAT时直接假定保留扇区数为1，这些程序在遇到不标准的FAT时就会出问题。况且，目前出现这个问题的硬件还是少数，而FAT分区使用1个扇区的是多数，如果规定多数用户要去将就少数用户，似乎不太好吧。

如果从MBR或者NTLDR引导GRLDR，这样可以在GRLDR里运行CHS自动探测的代码，在分区里就不需要重复了。因此，出现问题的情况是要把GRLDR启动代码直接安装到FAT分区里。我想分区代码可以基本保持原样，如果空间允许的话，可以使用INT 13/8来获得CHS参数。如果从GRLDR里调用，则使用GRLDR里的完整的探测的代码，而把分区里的INT 13/8代码屏蔽掉。即使是把分区代码直接写到启动扇区里，也有一层简单的保护。而对于例外的情况，则使用特殊的FAT启动代码，它里面包含完整的探测代码，空间可能不止一个扇区。不过，它只有当使用特定参数（例如--safe-chs） 运行bootlace.com时，才会被安装到FAT里。

--
Bean

[tin...@tom.com]

保留扇区数是可变的，这是 FAT 的灵活性。虽然多数情况下保留扇区是1, 但是例外情况一直存在，因此 buggy 的软件应该没有。退一步说，即使存在一些 buggy 的软件，用户也可以权衡，究竟是要 grldr 的启动，还是要那个软件。如果 grldr 的启动是重要的，用户可以不要那个软件，反之如果那个软件是重要的，用户可以选择 grub.exe，这个总是可以在 DOS 下运行的，用户就不需要 grldr 了。

保留扇区在 BPB 中的位置，是微软公开的标准，不曾发生过问题。我记得我曾经要求用户上载引导扇区，结果，有好几个用户上载的都是保留扇区为 2 的 FAT16 系统。虽然它的保留扇区为 2 ，但第二个扇区全都是 00 字节，没有用上。这说明这是一个普遍现象，不会引起问题。

int13/ah=8 实际上是不能用的，它不可靠，尤其对于软盘（DL < 0x80）来说，失败率更高。硬盘(DL >= 0x80)也有失败，但相对较少。不过 USB 硬盘的失败率就增大了。

所以，无论硬盘还是软盘，都不能相信 int13/ah=8 的返回值。有的 int13/ah=8 总是返回 H=255, S=63，但实际上用这个几何去读扇区，却失败了，或者读错了位置。也有的 int13/ah=8 （尤其是在作为软盘时）总是返回 h=2, S=18，而实际上 int13/ah=2 的读操作完全与此无关，可能按照 比如 H=64, S=32 来操作，等等，五花八门。

所以要真正做好的话，必须加入一个扇区的代码来做探测的工作。

不用担心，通常用户用常规的方法就够了，他可能不会遇到问题。对于那些遇到问题的用户，我们才要求他按照我们的要求重新格式化他的移动设备。我们可以给他推荐一款这样的工具。这应该是有的，我们只需要搜索到这样的工具，从中选一个比较好的来推荐便可。这不是强迫的，而是针对那些遇到问题的用户所采取的补救措施。这是给用户多一个选择罢了。

当然，如你所说，这只在 bootlace 安装到软盘的时候才需要。对于硬盘，我们的探测代码在 grldr.mbr 中进行。

上面已经说了，int13/ah=8 这层简单的保护，是不能称其为保护的，因为这本身就是个很普遍存在的问题（对于 USB 设备尤其如此）。也就是说，用了它，可能更糟糕，其失败率甚至会超过简单依赖 BPB 表的情况。

而运行 bootlace 时，只要发现保留扇区数目超过 1, 就可以利用了，无需再用 --safe-chs 之类的参数。

我们甚至还可以告诉用户，那些移动的设备，即便它是软盘，也可以格式化为硬盘，因为 grldr.mbr 目前已经可以有 BPB 表了。用户损失了一个磁道（最多只有 32.5K 罢了），却换来了“软硬兼可”的一个特殊的磁盘格式（硬盘、软盘双重格式）。如果此设备被 BIOS 当做“软盘”来启动，那么，这个“软盘”第一磁道上的 GRLDR.MBR 仍然可以成功获得控制，从而能够执行 CHS 自动探测代码，极大地提高启动的成功率。