标题: 发现一个问题，GNU GRUB 能启动，而GRUB4DOS却不能 [打印本页]
作者: ptptptptptpt 时间: 2007-10-9 20:39 标题: 发现一个问题，GNU GRUB 能启动，而GRUB4DOS却不能
时空论坛上不了，突然想起这里，呵呵
把 grldr.mbr 装入 USB 移动硬盘 0 磁道，grldr 和 MENU.LST 文件放在移动硬盘第一主分区（FAT，2G），在多数机子上能启动，但在一精英主板上发生了问题，10次仅有一两次能启动，其余都是在搜索GRLDR时，显示 （hd0，0）：disk error ，最后找不到。还有一次显示到（hd0，0）： 时死机了
以老的 GNU GRUB 方式安装 GNU GRUB 0.97 到移动硬盘，stage2 等文件也放在 第一主分区 ，却可以正常启动
而且进入 GRUB 环境后，可以正常访问 移动硬盘第一主分区 ，说明分区没有问题
怀疑是不是 grldr.mbr 中的 fat 文件系统代码有不完善？？
作者: fujianabc 时间: 2007-10-9 22:37
10次仅有一两次能启动？
随机的，不能重复的结果？
作者: ptptptptptpt 时间: 2007-10-9 22:43
比较随机，没发现什么规律
换插口、断电、热启、冷启、先开机再插 USB 、先插USB再开机，都试过了，有时候连着几次都行，有时候怎么都不行
这个主板也比较垃圾，SIS 760 GX 芯片组，USB 移动硬盘 在 BIOS 下只能识别 8 G
作者: 不点 时间: 2007-10-10 11:22
如果 grub4dos 有毛病的话，我猜八成启动总是失败，而不是有时失败，有时成功。
不过，这也提醒我再检查一下相应部分的代码。
作者: ptptptptptpt 时间: 2007-10-10 12:53
恩
而且目前的情况是，G4D 有时失败，有时成功 ，而 GNU BRUB 却总是成功，
这对 号称要干掉 GNU GRUB 引导方式 的G4D来说，是不能容忍的
作者: ptptptptptpt 时间: 2007-10-10 13:00
其实 GNU GRUB 的方式，也就是 stage1 + stage1.5（文件系统代码） 的方式仍是有优势的，因为它可以通过不同的 stage1.5 支持几乎所有分区格式
而 GRLDR.MBR 仅支持 fat ntfs ext —— 主要是 win 的文件系统， 所以在 linux世界 很难吃得开
其实，如果把 stage1 + stage1.5 中加入搜索功能，而不是像现在这样 只能从指定分区加载 stage2 ， 兼容性就会大大提高
限于0磁道容量， grldr.mbr 不可能支持所有文件系统，但可以做出对应不同文件系统的 grldr.mbr ，供用户选用
作者: bean 时间: 2007-10-10 19:21
GRUB4DOS的版本是什么？如果是2007-08-27(r53)或更新的版本的话，建议也测试一下2007-08-16(r52)。
作者: ptptptptptpt 时间: 2007-10-10 21:33
试了，(r52) ，但是8-17的
还有更老的6-16 也试了，问题依旧
这两次试验 我是用 ntldr 加载 grldr.mbr，进而搜索移动硬盘上的 grldr
估计把 grldr.mbr 装进移动硬盘 也会是一样的结果
作者: ptptptptptpt 时间: 2007-10-10 21:34
开始用的版本是最新的
作者: 不点 时间: 2007-10-11 11:58
初步猜测，该主板 BIOS 的 int13 随机地破坏了不该破坏的某些寄存器（或者甚至是破坏了内存中的数据！！）
我们可以在 int13 前后加上 push pop 来规避它对寄存器的破坏，但是对内存的破坏就不容易 workaround 了。
作者: ptptptptptpt 时间: 2007-10-11 12:24
可是为什么用 GNU GUBR 方式安装，每次都能启动成功呢？？
作者: 不点 时间: 2007-10-11 15:58
我们以前遇到的 U 盘问题，也都是死机之类的问题，并且证明都是 BIOS 的 BUG。
可是那些 U 盘运行 DOS 却没有问题。你这次无非就是说运行 GNU GRUB 没问题。
所以这些的成功，对于判断失败的原因，基本上没有什么帮助。
一般而言，应该属于 BIOS BUG 的问题。
GRUB4DOS 的代码也可能有问题，不过那应该主要是因为它没能适应 BIOS BUG 造成的。
作者: ptptptptptpt 时间: 2007-10-11 16:21
dos 毕竟是事实的工业标准，而 GNU GRUB 则不同
而且一直以来 GRUB4DOS 的一个目标就是提高启动成功率，在成功率方面超过 GNU GRUB
GRUB4DOS 中也有提示：
“ Notice: the two commands SETUP and INSTALL will be removed soon! Please use the OS utility of BOOTLACE.COM to install GRLDR boot record to the MBR or to the boot area of a specified partition. ”
可是现在新方法却不如老方法，这是没法向用户交代的
所以我认为这个问题不容忽视
作者: 不点 时间: 2007-10-11 18:32
当然不能忽视这个问题。不过，也许还需要等待更多的报告，才能判断问题在哪里。
同时，报告者自己也可以研究这一问题。研究源代码。
不要说不懂源代码。如果你说不懂源代码，你提交给有些软件开发者的问题，很可能根本不理睬。有些开发项目事实上只接受补丁。当然我们不会这样的，我们是很重视用户的反馈的。
作者: ptptptptptpt 时间: 2007-10-15 10:23
geomertry 的信息照了照片，可是时空论坛又不能访问了 ：（
作者: ptptptptptpt 时间: 2007-10-15 10:24
这里贴图 报错说空间已满 ：（
作者: 不点 时间: 2007-10-21 12:02
感谢 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 所遇到的情况。jnz 1f
movb %bl, %ah /* nHeads=0x100, so AX=sectPerTrack*0x100 */
1:
这同时也显示出 Intel CPU 设计上的一个缺陷（可以说是很大的一个缺陷）。
一个良好的 CPU 设计，应该在执行任何一条命令之后，都不出现“无定义”的标志位。因为这种“无定义”的状态，没有任何用处。注意，“无定义”并不等同于“保持指令执行前的状态”。“无定义”等同于“随机的”。
具体针对 mul 指令来说，当相乘的结果是 0 的时候，就应当设置 ZF 标志（零标志），反之，就应当清除 ZF 标志，而完全没必要把 ZF 搞成“无定义”的状态，从而给程序员带来巨大负担。程序员有了负担，那么程序代码的质量就难以保证。这如果发生在 BIOS 和系统程序设计上，它的危害就更大。（其实 GRUB 就是一个小系统）。
感谢大家的一同努力！相信 grub4dos 会日益完善！
在这个问题上，pt 是一个伟大的贡献者。先前也有几位报告了几个长期存在的问题，他们也是很伟大的贡献者。
朋友们，没有你的参与，grub4dos 的问题就不能得到解决。这就是你的伟大之处！你不是平凡的，你也是开发者的一员。向你致敬！
[ Last edited by 不点 on 2007-10-21 at 12:55 PM ]
作者: gmy 时间: 2007-10-22 09:35
向不点致敬，自由世界只因有了你，才更加精彩！
作者: 不点 时间: 2007-10-24 17:41
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 命令访问移动硬盘上的文件，看看输出的结果是不是原来的文件内容。
要多试验一些文件。
作者: 不点 时间: 2007-10-29 11:47
又经过仔细的研究，基本确认，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 拷贝到设备最开头的物理区域。
作者: bean 时间: 2007-10-29 12:32
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
这样就可以看到每次读取的扇区了。
作者: 不点 时间: 2007-10-29 14:26
bean， 正式版的问题，我又觉得没必要动它了，由它去吧。反正还没有见到有人报告 ext2 查找 grldr 的 bug，说明很少有人用。既然用的人少，就没必要为此单独出一个版本了。
你自己衡量吧，你愿意把 0.4.3 更换掉也行，发布 0.4.3.1 或者 0.4.4 也行，或者不理睬这个 ext2 问题也行。
--------
调试 FAT 就不做了吧，调试它也没什么特别大的意义。主要是 FAT 扇区增大之后，ext2 分区就要推后了，所以，代码很乱。
--------
自动探测 CHS 方面，你有没有代码？如果你有时间，不妨先写出一些片断函数。或者你谈谈怎么做也行。
作者: ptptptptptpt 时间: 2007-11-1 16:14
重新分了区，第一分区只分了512M，只放一个grldr，还是出错 ：（
其他测试待俺逐步做来
提醒不点兄：GNU GRUB 一直成功，不点兄可以研究下它的 stage1.5_vfat ，看能否发现什么
作者: 不点 时间: 2007-11-2 08:22
还想找 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 那样吗？未必是合适的吧？
无论什么方法，都有碰巧不适应的情况发生。只要问题不是普遍的，而是个案，我们就不必去管了。
作者: ptptptptptpt 时间: 2007-11-2 10:29
恩，说的是
我再多找些硬盘和电脑测试
作者: ptptptptptpt 时间: 2007-11-2 12:42
又做了个测试，在移动硬盘前1G 分了6个FAT16分区，每个里面放一个grldr，仍旧找不到
另外，证实了 GNU GRUB 确实是通过文件系统 而非 绝对扇区 来加载 stage2 的：把原来的 stage2 改名，重新拷进去一个不同版本（自己编译的）的 stage2 ，启动成功
回头在找别的机子试试
作者: davidxxw 时间: 2007-12-8 19:42
我用移动硬盘采用MSDOS＋GRUB.exe在我的IBMT61上启动后，运行IMG文件失败，今天移动硬盘采用MBR＋GRLDR同样在IBMT61启动后，运行IMG文件成功。(c采用最新12-05版本)。其实在别的机器（非IBMT61）上两种情况都能成功。我的理解是Grub4Dos 的容错性较差。就像当年的win98，一有问题就蓝屏，而2k&XP就好的多了。Grub4Dos要走的路还很长...