疑似grub4dos比较大的bug

不点

提醒一下，5月21日至6月24日之间没有编译结果。怀疑死机是由 daven  5月24日的改动造成的。

不点

因为 daven 的改动，我粗略看了代码，当时就有一种感觉，改动太大，有可能造成启动时便发生死机的问题。chenall 说他已经检验过了。但我怀疑 chenall 并未彻底检验。

其他改动，都不至于影响到启动死机的问题。如果找不到导致死机的原因，并且能够确定是 daven 的改动引起的，那只好废除 daven 的改动。等待 chenall 安排一个测试流程，确定到底是什么原因导致死机的。

不点

chenall 发表于 2013-6-29 11:58
首先看了第一个问题,这个应该是内存溢出了(冲突了),以前的版本没有体现出来.(这个文件太多的话建议还是分段 ...

6144 改成 0x8000，肯定没错。估计是你生成 ISO 的方式不对。

不点

这条mkisofs命令，似乎也没错。再加上 -boot-load-size 4，据说能够适应于所有的 bios。

你生成的 iso，在别的虚拟机下能启动吗？在真实机下能启动吗？

如果能，那就说明我们刚好又碰上了 vmware 的某个未知 bug 了。

不点

chenall 发表于 2013-6-29 15:38
这个是没有打R348补丁的0.4.5c版本.

你都已经证明 r348 有问题了，何必再让 sratlf 去测试？

真正有意义的，是测试别的虚拟机以及真实机下的情况。

我前面提到，mkisofs 中应该有参数 -boot-load-size 4，成功率最高，也就是说，bios 适应性最高。请添加这个参数，然后在各个虚拟机和真实机下测试，以便能够找出问题的根源。

把 6144 改成 0x8000 是没错的。问题是碰上 bios 适应性问题了，怀疑有些 bios 不能适应这个改动，而另外的 bios 应该是没问题的。一步一步来，我们先通过测试，确定这一点，然后根据测试的情况反馈，再安排下一个测试。

不点

好的，关于启动失败，请 sratlf 测试多个虚拟机，最好能测试一台真实机。目的是找出一个成功启动、不死机的机器。暂时怀疑，某些 BIOS 占用堆栈空间大，与加载的 grldr 代码发生了冲突。

EDIT：

发现我的代码改动有遗漏，请终止测试启动失败问题。等待我给出修复。

不点

已经修复，附件是修复后的 grldrstart.S 文件，适用于 0.4.5c，不适用于 0.4.6a。

如果测试成功，请 chenall 直接提交。

不点

死机的问题解决了，那么 chenall 接下来应该删除 0.4.5c-2013-06-24 的下载，以免别人再下载这个已经被证明是有问题的版本。

不点

我记得不点大已经取消了stage1及stage1.5，应该更加精简啊。

完全是两回事。源代码精简了，不等于执行码能精简。

我们的执行码中，一直都不存在 stage1 和 stage1.5，所以，执行码根本不受影响。

不点

感觉 有关 0.4.6 的 grldr 格式问题，最好由 yaya 来解决。yaya 原来都解决过一次了，这次又出问题，需要再次解决。正如 bootlace64 需要重新解决那样，grldr 格式问题应该也需要重新解决。

不点

2011yaya2007777 发表于 2013-7-2 08:49
关于 0.4.6a 的 grldr 格式识别问题已经解决。

是不是修改了 chainloader 命令，让它识别 0.4.6a 的 GRLDR 格式？

如果这样做，那么老版本的 grub4dos 还是无法用 chainloader 加载 0.4.6a 的 GRLDR。

最好是修改新版的 GRLDR 的格式，让它可以被老版本的 chainloader 加载。除非根本做不到这一点。

不点

zhaohj 发表于 2013-7-2 09:41
if (arg_len > 0x8000)
        {
            errnum = ERR_WONT_FIT;  //Error 28: Select item cannot fit into mem ...

列文件所占的空间，32K 绝对不够。即使预留 1M 也不够。这应该属于 “超限使用 grub4dos” 的范畴吧。

不点

2011yaya2007777 发表于 2013-7-2 10:14
是的。错误源于判断原 0x2000 处的内核头部 4 字节 EA 70 82 00 。现在 0x2000-0x33ff 插入 usb 驱动代码 ...

为何要插入到内核头部之前？在 asm.S 中实现，不是更好吗？

挪动内核头部，只怕会带来一连串的不兼容问题。

给 0.4.5c 打补丁，那么老版本就放弃支持了？这个思路是不对头的。假如实在没有办法了，只好这么做。问题是，我很怀疑这是 “实在没办法” 了。

幸亏原来的代码检查内核头部，否则你这个改动所带来的混乱，不知道会等到何时才能发现。

当我们能够保持兼容性的时候，就不要破坏兼容性。除非是做不到，或者代价太高。

这个 USB 驱动也属于内核吧？那么他就应该放在内核头部之后。

grldr 的头部只有 8K 是可以被 NTLDR 加载的。你的 0x2000-0x33ff 的代码，不可能被 ntldr 加载到。所以，它放在这里没有意义，不如放在内核头部之后好。



背景：

内核起始于 grldr 偏移 0x2000，是固定的。内核头部有很多控制变量，是用户可以读写的。用户甚至在启动 grldr 之前可以动态修改内核头部中的变量，比如，启动盘的 drive number 以及启动盘的 chs 信息。你把头部一挪动，那原来的外部程序就要写错位置，失效了。

内核头部还记录了 preset menu 的位置。外部程序可以读出内核头部的指针，计算出 preset menu 的位置。头部被挪动到 0x2000 之后，那些外部程序都要泡汤了。

甚至 grldr 自己的头部代码（位于 grldr 第2扇区的代码）也写内核头部信息（有关 PXE 启动的控制信息）。头部一挪动，就好像没有坐标了，所有的东西都得改。

我们的文档早都公开过了（虽然是零零散散公开的），内核头部起始于 grldr 的偏移 0x2000 处。头部的变量也公布了。外部程序都把这当成依据了。此时再挪动，那不就是自乱阵脚吗？连文档也得修改了。

现在忽然想起，论坛上报告 bootice 写 preset menu 竟然会导致程序死锁，写入的结果 grldr 文件竟然达 4G 之多！我感到很疑惑：怎么会呢？这下子终于可以猜到原因了：内核头部被挪动造成的。

不点

2011yaya2007777 发表于 2013-7-3 07:25
好吧，那就在 asm.S 中实现。
那只能是在加载 grldr 之后，从菜单中加载 usb 驱动了。
怎样从菜单加载？即 ...

不知情者，不为过。其实那很简单啊。asm.S 的第一条指令就是 JMP 指令。你顺着 JMP 指令走，看看你的代码适合插入在什么地方，就可以插入了。你的代码不长，只有几个 K 的大小，可以插入。还可以把你的代码放在 asm.S 中的某个位置，然后用 call 指令调用你的代码便可。

在 asm.S 的 618 行，有如下注释和代码：

/* transition to protected mode */
call EXT_C(real_to_prot)

这显然是必经之路，切换到保护模式。所以，如果你的实模式代码插入到这个之前，肯定会执行的。这只是举例而已，其实可插入的地方很多，你自己看究竟插入到什么地方最合适，就插入到什么地方。如果你不知道插入到哪里最合适，那就插入到这里吧：

1:
#endif /* !STAGE1_5 */

你的 USB 实模式处理程序插入在这里

/* transition to protected mode */
call EXT_C(real_to_prot)


asm.S 在切换到 32 位保护模式并做适当的准备工作后，就要调用 common.c 中的 C 语言程序 init_bios_info () 和 stage2.c 里面的 cmain()。

call EXT_C(init_bios_info)
call EXT_C(cmain)

如果你的代码可以转换成 32 位的 C 语言代码，你也可以把它插入到 call init_bios_info 之前，或者插入在 call init_bios_info 和 call cmain 之间。cmain 就是开始处理菜单的地方，也就是真正的 grub4dos 的核心主程序。