通过grub引导gurb.exe并加载镜像在最新版中不可用？

不点

你缺少一项测试，试试用 grub4dos 自己的 kernel （在本地而不是通过网络）加载 grub.exe，情况如何。


另外发现你使用的代码与你提供的原始网页中的不同。原始的代码是这样的：

1. LABEL gpxelinux
   
2. kernel http://192.168.100.254/grub.exe
   
3. initrd http://192.168.100.254/MiniXP350.gz
   
4. APPEND --config-file="map (rd)+1 (hd0); map --hook; chainloader (hd0,0)/ntldr"

复制代码

至少你应该说明，上述代码是否管用。

[ 本帖最后由 不点 于 2013-2-26 10:49 编辑 ]

不点

你们都没有回答我的第一个问题。

用 grub4dos 自身的 kernel 命令加载本地的 grub.exe 和 initrd 映像文件，这样是否成功？

不点

硬盘镜像太大，可能会造成问题。因为你的内存可能不够用。就是说，用 initrd 加载到内存时，又再次用 map 来加载（有内存复制的动作），则有可能出现内存覆盖，导致映像被毁。小的映像文件不存在问题，因为内存复制时不至于产生互相重叠覆盖。

你最好用小映像文件，全面测试后给出一个综合报告。

我看了源代码，但没有发现任何问题。所以，怀疑是内存不够（在拷贝时产生重叠覆盖）引起的问题。也就是说，那本身属于超限使用 grub4dos 所造成的问题，即，grub4dos 没有那么大的能力，却让它干那么大的事，结果，运气好了不出问题，运气不好就出问题。

直接 map --mem 一个硬盘文件，不存在第二次的复制，所以，不至于产生问题。

从 7 楼的软盘映像的成功，可以间接知道，grub4dos 的程序代码是没问题的。只要有一个是成功的（不管是硬盘映像，还是软盘映像），那就说明程序代码的处理是正常的。也就是说，rd 是已经被正确识别的。在识别 rd 的时候，是不区分软盘映像还是硬盘映像的。所以，只要有一个成功（有一例成功），那就没问题。剩下的问题可能与映像的大小有关，或者与 kernel 命令加载映像的位置有关。所以，首先怀疑是映像太大造成了前述的内存冲突。

另外，map (rd) (hd0) 好像是不复制内存映像，但 rd 的内容应该是未压缩的 img 文件。而 map (rd)+1 (hd0) 则会复制映像，这有可能造成内存覆盖。

map (rd) (hd0) 把内存中的 rd 处的映像直接映射为 hd0. 如果 rd 本来就不是压缩的，并且 initrd 命令保证把 initrd 映像放置在内存顶端（在进入 grub4dos 后，rd 就是指向原来的 initrd 映像），那么，用这种方式加载是最好的。否则，需要用 map (rd)+1 (hd0) 的方式。

有些软件的 initrd 命令不把 initrd 映像加载内存顶端，这就不适合用 map (rd) (hd0) 的方式了，而适合用 map (rd)+1 (hd0) 的方式。

使用 map (rd)+1 (hd0) 的方式也有缺点，正如前面所说，它会把映像复制到内存顶端。如果映像本身已经在内存顶端，并且是压缩的，那就糟糕了。因为复制的过程就会破坏映像。所以，使用 map (rd)+1 (hd0) 的场合是：映像在内存低端，并且解压复制到顶端的过程不会产生内存重叠、覆盖。

[ 本帖最后由 不点 于 2013-2-26 21:59 编辑 ]

不点

前面已经解释了，不同软件的 kernel 和 initrd 命令的运作方式不一定相同。就是说，initrd 命令所加载到的内存地址有不同。所以，这个东西就很难比较。

而 BIOS 的内存布局，也影响加载的效果。就是说，内存碎块，也影响加载的效果。情况比较复杂，不能一概而论。

当然，也不能排除新版 grub4dos 引入 bug 的可能。但是，到目前为止的测试，还不能证明新版一定有 bug。倒是似乎能够印证我前一个帖子所作的一些猜测。比如说，映像的大小有影响，这个是证明了的。而不同软件的 initrd 的加载效果也不同，这也有印证。

另外，你没有测试 map (rd) (hd0) 的情况（即，不带 “+1” 的情况）。前面说了，有的软件适合带 +1 的情况，而有的软件不适合带 +1 的情况。

不点

另外，谈谈个人的一些观点。

pxe 是 BIOS 本身支持的（主板 BIOS 或者网卡的 BIOS，都属于 BIOS 范畴）。这个 “BIOS” 的字眼，通常就意味着规范和统一。当然，BIOS 制造商也会故意破坏规范，但是，整体来讲，这个规范还是得到了保证，那些破坏掉的部分，都属于偷鸡摸狗的性质，不是光明正大的，只要被曝光、被揭露，就容易得到遏制和解决。这是说一般的 BIOS 问题。具体到 PXE 的 BIOS 问题，似乎问题不太多。报告 PXE 问题的人不多，当然也可能是因为 PXE 的使用者本来就不多。

而 gpxe 以及 ipxe 就不同了。它们属于驱动程序，而不属于 BIOS。驱动程序是软件自带的，而不是 BIOS 硬件所支持的。假如有人想从 BIOS 层面破坏某个开源软件的驱动程序，那应该很容易。故意生产这样的硬件，使得你的软件转不起来，这不是难事。

我在多台真实电脑上试验了 gpxe 和 ipxe，结果竟然没有成功的。而 pxe 却没有失败的。这和我试验 plop 的结果相同。所以，至今 plop 没有大面积被采纳，没有占据某种工业标准的地位。gpxe 和 ipxe 的情况类似，当一个用户遇到一台机器失败时，他本能地就会放弃了。

不点

map (rd)+1 (hd0) 的情况，cat --hex (rd)+1查看 (rd) 的内容，正常吗？

rd 应该与 map 无关。即使没有 map 命令，rd 也应该正确地指向映像文件。除了可以使用 cat --hex (rd)+1 以外，还可以使用  map --status 来查看 rd 的状态。

忽然怀疑 gpxe 的 initrd 把映像加载在 32M 以内了。32M 以内是新版 grub4dos 的保留空间，映像加载在这里，多半会被 grub4dos 自身的代码和数据破坏掉的。

如果确实是这种情况，最好是修改 gpxe，让它的 initrd 命令把映像加载在 32M 以上的空间。

最理想的情况是，gpxe 的 initrd 命令能够把映像直接加载在内存顶端，这样，grub4dos 就可以用 map (rd) (hd0) 来直接映射了，免去了用 map (rd)+1 (hd0) 来再次移动映像文件的步骤。

[ 本帖最后由 不点 于 2013-2-27 02:28 编辑 ]

不点

旧版本可能不使用扩展内存，所以，不破坏 gpxe 放置在 32M 以内的映像文件。

新版本要使用 32M 以内的内存，所以就破坏了 gpxe 所建立的映像文件。

虽然你没有给出 map --status 的结果，但是，我已经可以猜测到了。rd 应该是指向 32M 以内的，这是产生问题的根源。

从 grub.exe 的角度，也可以解决这个问题，就是，首先把 initrd 映像移动到 32M 以上，然后再把控制权交给 grub 主程序。但是，这个移动的动作要浪费时间。不如从 gpxe 入手解决这一问题，即，把映像直接加载在内存顶端。

[ 本帖最后由 不点 于 2013-2-27 02:40 编辑 ]

不点

2012-2-13 的变动，与内存布局无关。以上是就 emutemp  的测试结果来分析的，没有参照你提供的信息。

无论怎样，还是怀疑 ipxe 也把映像放置在 32M 以内了。

不点

原帖由 emutemp 于 2013-2-27 02:25 发表

20130202版的grub.exe，cat --hex (rd)+1查看 (rd) 内容不正确，与镜像文件内容不同。加载1个100MB的镜像，执行时不能识别CHS，采用默认255，63后停顿半天，回到命令行后执行map --status，rd_base=0x83D0FF02;rd_size=0x3476A43D

这好像是 rd base 和 size 被破坏了。你用小的软盘映像，试试是否 rd base 和 size 也被破坏？

你强制设置 rd base 和 size 为正确的值，看看是否解决问题？

rd_base=0x19C00000;rd_size=0x6400000; 这似乎是真正正确的值。你可以用 map --rd-base 和 map --rd-size 来强制设置它们。

[ 本帖最后由 不点 于 2013-2-27 02:57 编辑 ]

不点

rd base 和 size 被破坏了。这究竟是被谁破坏了，是个疑问。

试试强制设置正确的 rd base 和 size，看看好了没有？

不点

暂且没有时间做这些工作。先处理  emutemp 的报告吧。估计这是可以弄清楚的。

不点

2.88MB的镜像，intird放的地址是rd_base=0x1FD30000;rd_size=0x2D0000；
510MB的大镜像，initrd放的地址是rd_base=0x200000;rd_size=0x1FE00000；

看看映像的结尾 rd_base + rd_size = 0x20000000 即 512M 处。所以，可以猜测，无论如何，gpxe 都不会把映像放在 512M 以上，而这个 512M 就是上限。

但是，510M 的映像，起始地址在 2M 处，已经位于 32M 以内。根据前面的分析，32M 以下的部分会被 grub4dos 破坏掉。这就是为什么它启动失败的原因了。

这个测试表明，映像本身被 gpxe 放在内存中了，但是，grub.exe 却不能得到正确的地址（需要你强制设置才行）。很蹊跷的问题，这原因还得继续考证。

还得麻烦你找出，从何时开始，grub4dos 开始出现这个问题，以便确定，究竟是什么改动造成了问题。


趁此空闲的时间，顺便再谈谈 initrd 这一方法的局限性。initrd 是属于古老的 Linux 规范。这一规范本身使用 4 字节的整数来记录 initrd 的映像的地址。这就是说，映像一定在 4G 以内。这就是 initrd 的天然局限性。grub4dos 的 initrd 命令当然也存在同样的局限性。

从 gpxe 的角度，可以开发出另外一条命令，比如叫做 myinitrd，这条命令可以把映像放置在任意空闲地址处，并且它不再把地址记录在 Linux 头部的数据结构中（因为如果映像在 4G 以上，就无法记录在 Linux 头部的数据结构中了），而是用户可以控制 myinitrd 命令所加载到的地址。这样，用户进入 grub4dos 以后，就可以自己设置 rd base 和 size 了。

grub4dos 本身除了 initrd 这个有着 4G 局限性的命令以外，还有别的方法可以把映像放置在 4G 以上。

当然了，刚才这番话讲的是技术本身可以达到的高度。而技术本身有没有必要做下去，则是一个权衡问题。如果 gpxe 在硬件上不能保证兼容性，失去推广的意义，那么在我看来，技术本身也就没有必要继续搞下去了。说得更极端一点：如果 BIOS 被取缔，连 XP 都不能运行了，也就不存在以上这些启动 XP 的需求了。即使想启动 Win8 之类的系统，也难了，因为 gpxe 也依赖 BIOS，因此连 gpxe 都转不起来了，至少 gpxe 需要大修才行。

[ 本帖最后由 不点 于 2013-2-27 08:25 编辑 ]

不点

楼上，没有成功与失败的精确分界线，很难找到失败的原因。相差一年，太模糊了。

不点

楼上的结论与 pseudo 的一样，都是说 2012-2-13 的改动有问题。然而改动本来就很少，仔细检查之后，发现完全没问题。

所以，这可能又是一个编译器造成的问题。

2月10日前后是 chenall 编译的。请 chenall 看看吧。

在 chenall 给出结果之前，诸位也可以自己用某个旧版的编译器来编译新版本，猜测应该可以解决。

不点

gcc 4.5.2 编译最新版本的 grub4dos，试试吧：

不点

试试我在 2012 年 2 月 13 日的编译结果：

http://bbs.znpc.net/forum.php?mod=viewthread&tid=6197

不点

这是 gcc 4.5.2 编译 r261，怎么样？

不点

再把 gcc 4.5.2 编译 r260 也上载：

不点

好了，谢谢，这证明确实是 r262 引入的 bug。等我上载修复。

回去吃饭，今晚再弄。

[ 本帖最后由 不点 于 2013-2-27 18:29 编辑 ]

不点

文件 dosstart.S 修改好了，我现在没有编译环境，请能编译的人，编译一下。

下载附件，解压后，得到源代码文件 dosstart.S。

用它替换最新版的 grub4dos 里面的 dosstart.S ，然后编译即可。

不点

既然成功，就可以提交了。

更新记录可以这么写：重新解决 issue 74。

意思就是，上次解决 issue 74 时不小心，有疏忽和漏洞，这次真正解决了。