GRUB4DOS更新建议、bug反馈专帖

不点

1.改变了以下内存地址的定义(和之前的版本相反)
  0000:82A4 4 (DWORD) no_decompression (no auto gunzip)
  改成了
  0000:82A4 4 (DWORD) do_decompression (do auto gunzip)

这个改动不好吧？这已经使用很长时间了，0.4.4 已经公布使用了。已经公布的东西，想改是要慎重的。一般是不能改的。牵涉的面太广，都不知道有多少开发人员已经在使用了。

忽然想起来，是不是必须要改啊？比如为了支持 LZMA。如果那样的话，倒是可以考虑。如果不是那样，则不适合更改。

开发人员也不是完全自由的，有时也受束缚：不能随便编写程序，影响兼容性。所以，有时候需要 un-document 某些东西，那些 undocumented 东西是可以更改的。能避免的，尽量避免，除非无法避免，才放弃兼容性。

[ 本帖最后由 不点 于 2010-12-15 06:45 编辑 ]

不点

其实现在我也觉得 no_decompress 这个变量的设置不好，应该如 chenall 所说改成 do_compress 才比较自然。但当初没有仔细分析，直接借用了 GNU GRUB 中已经存在了的 no_decompress 变量。但问题是已经公布了，再改的话，会给我们自己引来不少麻烦，比如，若干年之内，可能就会接到很多询问。很多使用 0.4.4 的人，转用 0.4.5，当他发现么莫名其妙的兼容性问题出现时，他得花费不少时间去定位 “bug”。最后他可能发现了我们的 Readme 中已经说明了这个更动，但已经晚了，他耗费了不少的精力才发现这一点。所以，不兼容性的出现是不好的，即使写入 readme 也没有太大的帮助。

这次也是个教训，说明了当初设计一个变量或者一个函数的时候，就应该沉稳，尽量做到不至于将来要返工。说明当初我应该下决心把 no_compress 换成 do_compress。这个事件，对于今后我们的开发，算是一个教训了。

因此，我觉得 asm.S 末尾的接口函数，也得慎重处理。在正式版发布以前，这些接口函数要敲定。我有新的意见，在时空论坛给出。请 chenall 注意去看看。

不点

DOS 是 dirty 的，所以，不要频繁进入 DOS。每进去一次，就多一次机会毁掉内存的敏感信息。进的次数多了，系统自然会挂掉了。除非在那些非常健壮的 BIOS 之下（这么好的 BIOS 现在已经不多了），才可以频繁进出 DOS。

这就是为什么有人想出了不使用 DOS 的招法。

不点

blocklist /wenv
返回应该是：
(hd96)155+45
吧？

你是在光盘上吧？

(hd96) 是 (0xE0)，应该是你的 (cd) 设备。在光盘上，别忘了扇区大小是 2048 字节。就是说，光盘的一个扇区，相当于磁盘上的 4 个扇区。

因此，显示的 (hd96)155+12，是正确的。

11 个大扇区，相当于 44 个小扇区。第45个扇区也要占用光盘的一个大扇区。所以总共是 12 个大扇区，这完全正确。

chenall 在 680 楼的说法好像是不正确的。文件的分配是按簇来分配的，但 blocklist 的时候，仍然是按扇区来做的。比如，如果文件有一个字节，则 blocklist 会显示出一个扇区，而不是一个簇的大小。

不点

问题很严重，请在时空论坛报告详情。

先说说机器是什么时候生产的。再说说各个硬盘的大小。

按照常规，用一个不带 config.sys 和 autoexec.bat 的 DOS 启动，然后运行 grub.exe 看看有什么情况。如果死机，换用 badgrub.exe 来测试。

然后再换用不同版本的 grub4dos 来测试。比如，换用 2009 年的试一试。

不点

无论 (hd96)155+12 还是 (hd96)155+45 都不等于 wenv 文件。

这是因为，(hd96)155+12 和 (hd96)155+45 都是按照扇区对齐的，也就是说，它们的长度都是扇区的整数倍，即 2048 字节的整数倍。因此，无论你使用哪个，都是错误的。有可能你使用 45 时，正好满足了 grub4dos 可执行文件的条件而已。在另外一个环境下，就不一定这么凑巧了。

[ 本帖最后由 不点 于 2011-4-7 18:48 编辑 ]

不点

你把 45 改成 12 应该也能。如果不能，则表示此处的表示方法的处理中含有 bug。

不点

不客气。你问的问题属于一般人不常接触到的问题。所以，这是应该给予答复的。

不点

从图片看，执行 int13／ah＝2读硬盘时死机。这说明BIOS不支持 CHS 模式的磁盘读。能进入 grub 环境，则表示 LBA 模式没有死掉。

初步怀疑，这是一个 4K 扇区的硬盘，其 BIOS 仿真 512 扇区的工作没有做好，在 CHS 模式有 bug，只能使用 LBA 模式。

===============

发表一点评论。市场制造了这么多的不兼容，这不是有意的，难道会是无意的？这么折腾的结果，恐怕会让 ARM 有机可乘。

如果这是故意的，则表明华硕也卷入了其中，刷新了记录。

[ 本帖最后由 不点 于 2011-4-8 07:20 编辑 ]

不点

总有办法的，你可以先把实模式的内存备份到扩展内存，然后执行 pxe unload，再执行写盘的操作，把扩展内存中的备份写入硬盘文件中。

不过目前要紧的是，先测试 DOS 下能不能用 int13／ah＝2 来访问硬盘扇区。如果不能，我们就知道原因了。如果能，那我们还要继续查明，为何 grub4dos 下不能使用 int13／ah＝2 ？

当然，顺便也可以试试 int13／ah＝42h 的情况。

[ 本帖最后由 不点 于 2011-4-8 12:19 编辑 ]

不点

你只贴了中断向量表，这是不够的。

从 400 - 4FF 也要贴。

由于可能涉及到 PXE 的程序，所以，最好把常规内存顶端的部分也贴出。

如果你实在不知道要贴多少内容，干脆把 640K 常规内存全部贴出来。

补充：暂时先贴 400 - 4FF 吧，其他的不要贴了，因为可能并不需要。

============

从已经贴出的中断向量表，可以看出，只有两个差别：

int1A：pxe=9D3B：0F23 -------- non-PXE=F000：FE6E
int72：pxe=8D55：4EAF -------- non-PXE=F000：EF0F

有可能是 PXE 的 int72 与磁盘的 int13 发生了冲突。也有可能是 int1A 的影响。总之，你可以试着把这两个修改为 non-PXE 时的值，看看是否解决了。不过，修改以后，PXE 应该无法工作了，甚至会死机。 看看这两个中断中的哪个有影响。或者两个同时影响磁盘的读取。

[ 本帖最后由 不点 于 2011-4-8 17:53 编辑 ]

不点

2）重启后，

write 0x1c8 0xf000ef0f
geometry (hd0) 正常
ls (hd0,0)/   正常
pxe 正常

你是说，这个就完全正常了，对吧？

然而我们怎么在 pxe unload 之前知道 F000EF0F 这个正确的中断向量呢？

请思考一下。我们必须把这个值找出来。

========

你再看看 int72 的程序是什么样的？你在 DOS 下可以用 debug 跟踪 int72 的执行过程。我猜它死机了，比如进入了无限循环，或者执行了一条非法指令。

如果确实是这样，那么怀疑这是有意制造的死机。

如果你把 int72 更正以后，一切正常，这就差不多说明是有意制造的死机。

不管如何，这个问题好像没有更好的解决办法。write 0x1c8 0xf000ef0f 大概就是最好的解决办法了。

好了，到此为止吧。

[ 本帖最后由 不点 于 2011-4-9 16:42 编辑 ]

不点

唉，这还差不多，至少说明，这个 int72 还是有用的。

好了，你有事干了：

在 DOS 下，用 debug 跟踪 int72 的执行过程，看看有什么机关？

它应该在某个时候把控制传递给 0xf000ef0f。

你也可以把 int72 反汇编出来。然后我们分析一下它的程序流程。

其实现在你已经明白怎么来对付了：作为一个 workaround，当访问 PXE 时，用 PXE 的 int72, 当访问硬盘时，用 0xf000ef0f。

问题就算解决了。

如果你不想用 DOS 的 debug 来跟踪的话，现在就可以结束了。

[ 本帖最后由 不点 于 2011-4-9 16:52 编辑 ]

不点

你先看看这个程序有多长，上次你上载的内存，没有包括这一部分，所以，我这里没法知道。

要不你把这段内存再上载一下？从 7000:0000 到 A000:0000 之间的内存，应该包含了 int72 的代码了。

其实我也懒得看它了，毕竟我们已经知道怎么 workaround 了。

------------------

也有可能华硕在 PXE 的情况下，故意禁止用户对于硬盘的访问。问问华硕的工程师，看看是不是这样。请华硕的工程师解决好了，我们实在没必要去折腾了。

[ 本帖最后由 不点 于 2011-4-9 17:12 编辑 ]

不点

你只上载了很少一部分内存，你看看就知道了。你是以文本方式上载的，所以，整个文本有 640K，但实际显示的内存信息，远远低于 640K。

算了，不用重复上载了。我觉得研究它们，没有太大的意义。请华硕工程师解决，则是正道。

不点

又是无效的上载。

你只上载了 0 － 9FFF 的值。实际需要的是 0 － 9FFFF 的值。

分析 int72 的程序，是一个很辛苦的活。这应该是 BIOS 工程师的事。我们不应该无偿为他们服务。

到此为止吧，也不用上载了。

我们其实已经为他们做了不少工作了，还不知他们是否领情呢。

不点

1. 000923FF FA                             cli
   
2. 00092400 1E                             pushw   %ds
   
3. 00092401 06                             pushw   %es
   
4. 00092402 0F A0                          pushw   %fs
   
5. 00092404 0F A8                          pushw   %gs
   
6. 00092406 66 60                          pushal
   
7. 00092408 2E 8E 1E DA 4D                 movw    %cs:0x4DDA, %ds # DS=0x89C0
   
8. 0009240D 83 3E C8 38 FF                 cmpw    $0xFFFF, 0x38C8 # [8D4C8]=000A
   
9. 00092412 74 4A                          jz      0x0009245E
   
10. 00092414 C7 06 22 00 00 00              movw    $0, 0x0022
    
11. 0009241A C7 06 24 00 01 00              movw    $1, 0x0024
    
12. 00092420 1E                             push    %ds
    
13. 00092421 68 22 00                       push    $0x0022
    
14. 00092424 6A 14                          push    $0x14
    
15. 00092426 C4 1E A8 38                    les     0x38A8, %bx # ES:BX=9D3B:0070
    
16. 0009242A 26 FF 5F 10                    lcall   *%es:0x10(%bx)
    
17. ........................................此处还要 call far 9D3B:0080，就比较麻烦了。那又是一段很长的程序。
    
18. ........................................估计错误就在那里面。
    
19. 0009242E 83 C4 06                       add     $0x06, %sp
    
20. 00092431 83 F8 00                       cmp     $0x00, %ax
    
21. 00092434 75 08                          jnz     0x0009243E
    
22. 00092436 A1 24 00                       movw    0x00000024, %ax
    
23. 00092439 83 F8 00                       cmp     $0x00, %ax
    
24. 0009243C 74 02                          jz      0x00092440
    
25. 0009243E EB 1E                          ljmp    0x0009245E
    
26. 
    
27. 00092440 A1 C8 38                       movw    0x000038C8, %ax
    
28. 00092443 8A D0                          mov     %al, %dl
    
29. 00092445 B0 20                          mov     $0x20, %al
    
30. 00092447 80 FA 08                       cmp     $0x08, %dl
    
31. 0009244A 72 04                          jc      0x00092450
    
32. 0009244C BA A0 00                       mov     $0x00A0, %dx
    
33. 0009244F EE                             out     %al, %dx
    
34. 00092450 BA 20 00                       mov     $0x0020, %dx
    
35. 00092453 EE                             out     %al, %dx
    
36. 
    
37. 00092454 66 61                          popal
    
38. 00092456 90                             nop
    
39. 00092457 0F A9                          pop     %gs
    
40. 00092459 0F A1                          pop     %fs
    
41. 0009245B 07                             pop     %es
    
42. 0009245C 1F                             pop     %ds
    
43. 0009245D CF                             iret
    
44. 
    
45. 0009245E 2E 83 3E DE 4D 00              cmpw    $0, %cs:0x4DDE
    
46. 00092464 74 26                          jz      0x0009248C
    
47. 
    
48. 00092466 FB                             sti
    
49. ................................................# 此处的 pushf ; call far 就对应于访问磁盘的情况。
    
50. 00092467 9C                             pushf
    
51. 00092468 2E FF 1E DC 4D                 lcall   *%cs:0x4DDC
    
52. 0009246D BA 21 00                       movw    $0x21, %dx
    
53. 00092470 8B 1E                          movw    0x38C8, %bx
    
54. 00092472 C8 38 80 FB 08                 cmp     $8, %bl
    
55. 00092477 72 03                          jb      0009247C
    
56. 00092479 BA A1 00                       mov     $0x00A1, %dx
    
57. 0009247C 8A 1E 1A 00                    movb    0x001A, %bl
    
58. 00092480 EC                             in      %dx, %al
    
59. 00092481 F6 D3                          not     %bl
    
60. 00092483 84 C3                          test    %al, %bl
    
61. 00092485 74 05                          jz      0x0009248C
    
62. 00092487 F6 D3                          not     %bl
    
63. 00092489 22 C3                          and     %bl, %al
    
64. 0009248B EE                             out     %al, %dx
    
65. 0009248C EB C6                          ljmp    0x00092454

复制代码

程序很复杂，错误在里面，但只有硬件工程师才能定位。

这是中断共享的冲突问题。我估计硬件工程师忘了在 int13 的程序开头设置一个开关，用于通知 int72，让它执行硬盘的访问，所以，才出现这样的问题。

总之，基本能够确定是 BIOS 的 bug，而不是故意制造的死机。

＝＝＝＝＝＝＝＝＝

顺便说，华硕的工程师很负责的，只要你报告，他们会解决的。这问题对于他们来说，其实是很小的，很容易就解决了。估计几个小时就能解决。



好了，我们尽力了，无法解决。还是用我们自己的 workaround 吧，那既简单又管用。

[ 本帖最后由 不点 于 2011-4-9 22:32 编辑 ]

不点

你咋不说说从什么版本开始引入的 bug 呢？

不然的话，很难确定问题在哪里。

不点

谢谢。如果有进一步的发现，也请继续报告，而且希望有更细致的报告，尽量要给出证明，不是自己的使用方法错误所导致的。看看在什么条件之下会出现此类问题。因为大多数人都碰不上这个问题，所以，这个问题的出现，应该是有条件的。

我们之所以要延迟发布正式版，也就是想进一步锤炼代码，发现问题，排除暗藏的故障隐患。

也请 chenall 留意这个报告。

不点

你的报告不够细致。建议 chenall 忽略这个报告。

你缺乏有关你的系统的详细说明。我认为，在你所报告的这些方面，出问题的可能性很小。

你没有把出错的条件说清楚。而关于这一点，却是必须的，否则很难猜测。

就是说，你自己得摸索出在何种情况下能够出现此问题，而何种情况下又正常了。你得把失败与成功的界限找出来。

如果你只是说：“我这样一个镜像，在我这样一个测试环境失败了。” 那是远远不够的。因为，你的测试环境，开发人员可能永远都不会接触到。

因为你严重缺乏证据，所以，我严重怀疑是你自己的问题。

还有一种可能性。你使用的是软盘镜像，把它交给虚拟机作为虚拟机的软盘来启动。虚拟机通常有 bug，大多数虚拟机都只能认得软盘开头的 1.44M，其余的都不认。这是虚拟机的毛病，完全不是 grub4dos 的毛病。当你碰巧把文件放在 1.44M 以内的时候，grub4dos 可以访问到它。当你碰巧把文件放在 1.44M 之外的时候，就要失败了。这统统都是因为虚拟机的 1.44M 的极限造成的。 换句话说，这本来就不是问题，你如果把这样的问题拿过来当作问题来提交，则有故意添乱的嫌疑。

不点

报告问题要敬业一点。不要故意隐瞒什么东西，来吊开发人员的胃口。像你这种情况，你一开始完全可以说明白。你自己也完全可以告诉大家，你用其他方式启动这个IMG都没问题，唯独以这样的条件启动的时候才有问题。说清楚了，大家该怎么答复的，就会接帖答复了。你 “吊胃口” 的结果，是没人应答，都以为那是很难答复的问题，等待开发人员来解决 “bug” 呢。你可能是无意之间吊了大家的胃口，不过，客观上起着不良的作用。

看看，还得让 chenall 亲自浪费精力和时间来测试。浪费别人的时间，等于谋财害命。你应该认识到，你实际上给大家造成了损失。

不点

难道说，新版本的 VMWARE 更 robust 了？也就是说，它能够根据软盘的 BPB 来确定正确的 CHS 了。

不点

原帖由 chenall 于 2011-4-11 22:36 发表
看来好像不点又挖出了一些东西...

给你一个 Linux 下的好软件: http://udis86.sourceforge.net/

你在 Linux 下执行

udcli -16 io.sys > io.asm

你会发现，这就是 DOS 所有的源程序:-)

你在源程序中搜索 int 0x13，就可以找到 DOS 对于 int13 的全部调用。

而且你还可能发现很多惊人的东西......这就是挖掘了:-)

不点

你真有门，居然想到升级。

既然如此，我怀疑主板制造商是受命禁止 PXE 安装 PE 的一个举措。它让 grub4dos 以及 dos 都能通过，但让各种 PE 死掉。

想想是不是很合理？假如 PE 像 Java 一样到处运行，那微软还要不要再做 Windows 了？

PE 就是 PE，它不可以遮掩了 Windows 的光辉。所以，PE 该失败的时候，还是应该适当地、适时地失败几次的。

不点

新版的 grub.exe 在偏移 0x1F0 处（一个字节），存放了头部 dosstart.S 所占用的扇区数。

grldr 的头部永远占用 16 个扇区（也就是 0x2000 个字节）。

去掉头部，就是 pre_stage2 了。pre_stage2 的开头便是 asm.S 的编译结果。

[ 本帖最后由 不点 于 2011-4-15 14:24 编辑 ]

不点

从磁盘上获取 grldr 文件最可靠。内存中运行着的，有些变量已经改变了，不是启动之前未初始化的状态了。甚至连代码都移动了。

不点

诸位，问题在哪里，还是没能定位。都是猜测。要准确的定位。

比如说，在虚拟机下用同样的过程，看看有问题吗？如果有问题，那就是grldr的bug。如果在虚拟机上测试没问题，那就是真实机器BIOS的bug。

这很容易确定的，不难啊。怎么就没得到一个确定的答复呢？

对于同样内存的机器（不管是虚拟机还是真实机），只要有一台启动正常，就表明grldr没有问题（因此判断出是故障机器的 BIOS 的问题）。如果用虚拟机，请把虚拟机的内存设置为所希望的内存，与真实机器的情况一样。

如果在所有的情况下都出现问题，那就可以判断是 grldr 的问题了。

就是说，先把大的方向搞明白，确定问题的性质，然后再细化研究，是哪一部分的问题，就解决哪一部分的问题，很清晰。

而现在的情况是，大的方向不明，胡乱猜测。

[ 本帖最后由 不点 于 2011-4-21 10:42 编辑 ]

不点

我觉得，如果 Roy 找不出 gcc 的问题，我也很难找出来。我对编译器的熟悉程度，比 Roy 差远了。

另外，看到 Roy 在用 ubuntu，忽然想到，也许是 ubuntu 的问题吧？新版的 ubuntu 似乎不如老版的 ubuntu 兼容性好。

我用 ubuntu 9.04，编译什么都很顺利。但是没有试验过 chenall 的外部命令。

不点

对于 Linux 发行版来说，有些发行版的开发很活跃，这本身是好事。可是，由于开发者可能来自世界各地，有可能带来很难以排解的冲突（ bug）。一个小软件，倒是比较容易排解 bug。但是像操作系统这样的综合软件，则很难排解 bug。假如还有那么一两个恶意的捣乱者，混入开发团队的话（我个人倾向于认为存在这种可能性，而且，如果不存在的话，反而不正常，在我看来），那就更不容易对付了。

不点

我认为楼上 chenall 的说法，似乎不完全准确。

jianliulin 贴出的图片，说明主分区是存在的。而这一点，正是 grub4dos 对待主分区的一个特殊处理。在 grub4dos 看来，所有的主分区，都是“存在”的。

当然了，如果事先判断分区表是否合法，只有对于合法的分区表，再来执行分区枚举，这样就不会有问题了。

分区表合法性，可以用 probe_mbr 函数来检查。不过，这个函数的检查很严格，一个稍稍有错的分区表，都通不过检查。