grub4dos 在 GPT 盘上有 bug

不点

http://reboot.pro/topic/21905-grub4dos-and-gpt-support/page-2

来自俄罗斯的 tte 报告了他的两个 GPT 盘上的 NTFS 分区无法被 grub4dos 识别。

他从 USB 启动，能够正常访问 USB (hd0) 以及本地的第一块硬盘 (hd1)，但不能访问 (hd2) 和 (hd3) 的分区上的文件。他有一个分区，正好是 2T 的长度。有可能是这个 2T 的分区，让 grub4dos 表现失常了。

cat --hex 能够访问 (hd2) 或 (hd3) 上的扇区数据（测试 100G 处的一个扇区是可以访问的）。我已经让他提供 BIOS 可访问的最大扇区号，但目前他还没有提供此数据。

另外，当他使用 vol 命令的时候，死机了，只能按 ctrl-alt-del。这说明，vol 命令就有 bug 了。我猜是 vol 访问某个靠后的扇区时，BIOS 产生了死机。但也可能是 vol 的代码有 bug。

不点

不点

vol 命令输出，第二张图片

不点

vol 命令输出，第三张图片

不点

vol 命令输出，第四张图片

这张应该是死机时的图片了。

不点

从图片可以看到，vol 命令先查找软盘，从软盘 0 一直查到软盘 A。这是一个错误。

看 vol 执行过程中的这段代码：
  /* Search in hard disks first, since floppies are slow */
        for (drive = 0; drive <= 0xff; drive++)

在注释中说，先查找硬盘，但实际的代码，却是先查找软盘。

第二个错误是，当启动盘是 (hd0) 而不是 (fd0) 的时候（这也正是报告者的实际情况），grub4dos 会在 bios 数据区中设定软盘个数为 0, 有效屏蔽掉软盘操作。但 vol 和 uuid 命令不管软盘个数的设置，直接使用软盘 0 ～ 10。

第三个错误是，bios 的软盘个数不可能超过 4 个，而 uuid 和 vol 命令使用了 11 个软盘（软盘0 ～软盘10，也就是图片中显示的软盘 0 ～ A，十六进制）。

所查找的这 11 个软盘，正好与 uuid 和 vol 中的代码是吻合的：

        if ((drive > 10 && drive < 0x80) || (drive > (*((char *)0x475) + 0x80) && drive < 0x9f))
                        continue;

可能还有其它错误。

11 个软盘查找结束后，该去查找硬盘了。然而此时却死机了。就不知道，究竟是访问硬盘时死机了呢，还是在没开始访问硬盘之前就已经死机了。

这个 BIOS 确实在误导我们。它没有那么多软盘，却让那么多软盘的 EBIOS 接口返回成功。

而且，所有的软盘，其扇区 0 都是可读的，而且，能够从其扇区 0 计算出 H=255, S=63。怀疑这全都是 USB 硬盘的数据。就是说，这个 BIOS 让所有的软盘的扇区 0 的数据，都取自 USB 硬盘的扇区 0。

此时估计一下，死机的原因。

当 grub4dos 去访问不存在的那些软盘的时候，BIOS 本身可能发生了错乱（或者是 BIOS 故意自杀），导致此后在访问硬盘时死机。这个可能性较大。当然，死机还可能是别的原因。


补充：

刚刚看了 0.4.5c 里面的 uuid 命令，是正确的，不存在上述问题。

不点

最新进展——

报告者不耐烦了，他表示不想继续提供报告了，他说他已经提供了足够的信息。但他并没有充分地回应大家的要求，他是一种敷衍了事的态度。针对他的表白，我也给出了同样的表示。我说，如果你放弃，我也放弃，就当成不曾发生过这些 issues/bugs/reports。

我原打算在 wuyou 和 reboot.pro 之间当个翻译（传话筒），方便开发者和 bug 报告者互相交流、对话。现在不需要了。我可以把节省下来的时间用在别的方面了。

不点

2011yaya2007777 发表于 2019-6-27 07:39
已经对vol做了些改进，正在测试中。

vol  的毛病只是一个小毛病，不影响大局。真正的问题是，grub4dos 无法访问那个 4T 大硬盘上 GPT 里面的分区中的文件。yaya 若有时间，可以去那里看看。如果能解决问题，当然是最理想的了。

不点

2011yaya2007777 发表于 2019-6-27 09:01
我看了，但是无法发言。建议他把vhd放到第一分区，如果能找到，就肯定是读2T扇区的问题。现在虽然可以读64 ...

我暂时抽不处时间弄这个事了。