中国DOS联盟

这里贴图 报错说空间已满 ：（

感谢 pt 的报告。如果不出所料，那么 2007-10-21 的版本应该解决了此问题。请测试。

发现了 FAT12/16 引导扇区中的一个隐蔽的 bug。

2007-10-21 应该解决了。

请 pt 测试。

PS：感谢 pt 漂亮的 bug 报告！使得此问题能够快速定位于 FAT16 引导扇区。

这是一个长期存在的隐患，自从 FAT12/16 代码写出来的那一天就一直存在了！

通过逐条检查 FAT12/16 引导扇区的代码，终于发现了一个可疑之处。
复制内容到剪贴板

        mulb    0x1a(%bp)       /* nHeads, but maybe a word value 0x100 */

        jnz     1f

        movb    %bl, %ah        /* nHeads=0x100, so AX=sectPerTrack*0x100 */

1:

在相乘操作 MUL 之后，零标志 ZF 是无定义的。所以，用 JNZ 是错误的，必将引发随机失败！这正好是 pt 所遇到的情况。

这同时也显示出 Intel CPU 设计上的一个缺陷（可以说是很大的一个缺陷）。

一个良好的 CPU 设计，应该在执行任何一条命令之后，都不出现“无定义”的标志位。因为这种“无定义”的状态，没有任何用处。注意，“无定义”并不等同于“保持指令执行前的状态”。“无定义”等同于“随机的”。

具体针对 mul 指令来说，当相乘的结果是 0 的时候，就应当设置 ZF 标志（零标志），反之，就应当清除 ZF 标志，而完全没必要把 ZF 搞成“无定义”的状态，从而给程序员带来巨大负担。程序员有了负担，那么程序代码的质量就难以保证。这如果发生在 BIOS 和系统程序设计上，它的危害就更大。（其实 GRUB 就是一个小系统）。

感谢大家的一同努力！相信 grub4dos 会日益完善！

在这个问题上，pt 是一个伟大的贡献者。先前也有几位报告了几个长期存在的问题，他们也是很伟大的贡献者。

朋友们，没有你的参与，grub4dos 的问题就不能得到解决。这就是你的伟大之处！你不是平凡的，你也是开发者的一员。向你致敬！

Last edited by 不点 on 2007-10-21 at 12:55 PM ]

向不点致敬，自由世界只因有了你，才更加精彩！

pt，你得试试在你这个移动硬盘上安装个 DOS，看看 DOS 能否启动，如果能，你就在 DOS 下把硬盘上的文件拷贝到移动硬盘上这个 2G 的分区上，尽量要拷满 2G（可以是多个文件，总共加起来接近 2G 就行）。然后再在 Windows 下把移动硬盘上的文件拷回到硬盘上的某个目录下。用文件比较工具，比较硬盘上原来的文件和从移动硬盘上拷回来的文件是否完全一样。

安装 DOS 的方法：不要使用微软之外的任何工具软件来安装 DOS。请一定完全使用微软的 FDISK , FORMAT, SYS 等命令安装 DOS。不要在 CONFIG.SYS 和 AUTOEXEC.BAT 中加载任何程序。

还有，请报告在 DOS 下是否可以成功启动 grub.exe，如果能，请贴出

debug on
geometry (...) <----这里应该是你的移动硬盘。

的结果。

然后，在 grub 的命令行下，你试试可否访问移动硬盘上的文件。

用 cat 命令访问移动硬盘上的文件，看看输出的结果是不是原来的文件内容。

要多试验一些文件。

又经过仔细的研究，基本确认，pt 所报告的情况，并非由 CHS 的错误引起的。

从 GRLDR 查找过程中的 Try (hd1,0) FAT16: disk error Try (hd1,4) FAT32: NO GRLDR 这些显示信息来看，S 每道扇区数肯定没错，H 磁头数也没错。因为 FAT32 的引导扇区处于 2G 之后，要成功读取该扇区，那么必须 S 和 H 都正确才行。因此断定 S 和 H 都没错。

对于失败的可能原因，那么现在可以做如下猜测：

1. GRLDR 正好处于坏扇区上，读取时发生困难，不能一次读取成功。偶尔也能成功，这就是你遇到的情况。启动扇区由于代码空间紧张，一般只尝试一次读取（无论 DOS 还是 GNU GRUB 0.97 都是如此），而进入 grub 之后，由于此时可以尝试多次，所以，读取成功率加大了。移动硬盘是磁介质，容易受到物理振荡的影响，甚至也容易受到电压不足或者电压波动的影响。而闪盘应该更可靠一些。

2. USB BIOS 可能含有 bug，它对某些扇区号，虽然扇区号码处于合法范围，但它不能读取，或者读取时发生随机失败率较高。可以尝试重新格式化设备，把 grldr 拷贝到设备最开头的物理区域。

PT的问题的确很奇怪，建议使用调试输出的方法，查出出错时的扇区数目。

hex_out:
pushw %bp
movw %sp, %bp
pushaw
movb $0xE, %ah
movw $7, %bx
movw $4, %cx
movw 4(%bp), %dx
1:
rol $4, %dx
movb %dl, %al
andb $0xF, %al
cmpb $10, %al
jb 2f
subb $('0'-'A'+10), %al
2:
addb $'0', %al
int $0x10
loop 1b
movb $' ', %al
int $0x10
popaw
popw %bp
ret $2

我在调试NTFS分区时用的是上面这个函数，需要的地方把WORD值压入堆，然后调用hex_out就行了，如果压入DWORD的话，需要两次hex_out调用。在readDisk函数开始，可以加上：

readDisk_nt:
push eax
call hex_out
call hex_out

这样就可以看到每次读取的扇区了。

bean， 正式版的问题，我又觉得没必要动它了，由它去吧。反正还没有见到有人报告 ext2 查找 grldr 的 bug，说明很少有人用。既然用的人少，就没必要为此单独出一个版本了。

你自己衡量吧，你愿意把 0.4.3 更换掉也行，发布 0.4.3.1 或者 0.4.4 也行，或者不理睬这个 ext2 问题也行。

--------

调试 FAT 就不做了吧，调试它也没什么特别大的意义。主要是 FAT 扇区增大之后，ext2 分区就要推后了，所以，代码很乱。

--------

自动探测 CHS 方面，你有没有代码？如果你有时间，不妨先写出一些片断函数。或者你谈谈怎么做也行。

重新分了区，第一分区只分了512M，只放一个grldr，还是出错 ：（

其他测试待俺逐步做来

提醒不点兄：GNU GRUB 一直成功，不点兄可以研究下它的 stage1.5_vfat ，看能否发现什么

还想找 grub4dos 的毛病啊？难。

stage1, stage1.5, stage2 看过无数遍了，没有发现任何新的、可以借鉴的东西。应该说，我们的程序是更健壮一些，比如说，对 INT13 的调用，我们还特别对寄存器进行了保护。

就像我前面说的那样，你的情况，不要再浪费精力去琢磨了，因为我们已经琢磨过了，而且琢磨得很详细，连 mul 指令后的 ZF 使用不当都发现了，但现在已经证实，问题并非是由此错误用法引起的。（不管怎样，找到 ZF 使用不当的错误，当然是一大收获。）

要琢磨的话，必须换个角度，换个思维，否则就是重复劳动，不会有效果，也没有意义。

你应该换个同型号的硬盘，看看是否OK？如果OK了，就证明你的这块旧硬盘是有物理问题的。纵然 GNU GRUB 发现不了它的问题，但我们的 grub4dos 发现了。

如果要我们去解决、应对 BIOS 的 BUG，那是义不容辞的。但是，要我们对付各种各样有物理损坏的故障设备，你可以想想，那可能做到吗？应该去做吗？

你是不是还感到不服？你是不是有疑问：为什么 GNU GRUB 老的安装方式总是成功呢？

一个有故障的设备，它是什么稀奇古怪的事情都可能会发生的，因此，发生了你所看到的情况，不足为怪。

先假设一种情况（记住，实际可能发生的，远远比这里的假设要复杂得多）。

我们的 GRUB 引导扇区，要先读取 FAT16 文件系统中的 FAT 表。这个 FAT 表是磁盘文件的索引表，非常重要。这个 FAT 表要占用很多扇区，最大有 128K，也就是有大约 250 个扇区。如果读取 FAT 表失败，那么 GRUB 就会报告 disk error。

为什么 GNU GRUB 老的安装方式没有问题呢？

它可以不读取 FAT 表。就是说，它在读取 FAT 表失败时，还可以直接读 stage2 的第一扇区，那里记录了整个 stage2 文件的扇区列表，与文件系统无关，于是跳过 FAT 表了。

假若情况就是上面说的这样，那么为了你这个情况，就让我们改成 stage2 那样吗？未必是合适的吧？

无论什么方法，都有碰巧不适应的情况发生。只要问题不是普遍的，而是个案，我们就不必去管了。

恩，说的是

我再多找些硬盘和电脑测试

又做了个测试，在移动硬盘前1G 分了6个FAT16分区，每个里面放一个grldr，仍旧找不到

另外，证实了 GNU GRUB 确实是通过文件系统 而非 绝对扇区 来加载 stage2 的：把原来的 stage2 改名，重新拷进去一个不同版本（自己编译的）的 stage2 ，启动成功

回头在找别的机子试试

我用移动硬盘采用MSDOS＋GRUB.exe在我的IBMT61上启动后，运行IMG文件失败，今天移动硬盘采用MBR＋GRLDR同样在IBMT61启动后，运行IMG文件成功。(c采用最新12-05版本)。其实在别的机器（非IBMT61）上两种情况都能成功。我的理解是Grub4Dos 的容错性较差。就像当年的win98，一有问题就蓝屏，而2k&XP就好的多了。Grub4Dos要走的路还很长...