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

emutemp

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

测试起源于这个贴：
"http://bbs.znpc.net/forum.php?mod=viewthread&tid=6720&extra=page%3D1"
按照里面的使用syslinux的gpxelinux引导，但是加载完镜像后，grub.exe不能正确识别镜像并挂载，即无法正确识别镜像CHS参数，map后无法识别文件系统。

grub4dos为目前的最新版“grub4dos-0.4.5c-2013-02-02-2”。
syslinux使用4.0.6,5.0.1版都尝试过。

进一步测试，按照“README_GRUB4DOS_CN.txt”中的使用小的镜像，“grub4dos-0.4.5c-2013-02-02-2”版仍然无法正常引导。
而使用“grub4dos-0.4.5b-2011-12-06”版本，gurb.exe可以正常加载镜像并引导。
引导命令如下：
kernel http://192.168.1.1/grub.exe --config-file="map (rd) (hd0); map --hook; rootnoverify (hd0,0);chainloader (hd0,0)/ntldr"
initrd http://192.168.1.1/hd.img
boot

为了查看镜像加载完后的(rd)设备状态，改为通过如下命令引导，引导执行完map (rd) (hd0)后会停止:
kernel http://192.168.1.1/grub.exe --config-file="map (rd) (hd0);"
initrd http://192.168.1.1/hd.img
boot
再通过map --status命令查看(rd)设备状态，通过cat --hex (rd)+1查看(rd)位置的内容：
发现“grub4dos-0.4.5b-2011-12-06”版中，rd-base起始位置的内容与磁盘镜像内容相符，rd-size的大小也等于镜像的大小；map (rd) (hd0)执行时正确识别了CHS参数；在map --hook后能正确识别文件系统；
而在“grub4dos-0.4.5c-2013-02-02-2”版中，rd-base值很大，起始位置的内容与磁盘镜像内容完全不符，rd-size记不清是否等于磁盘镜像大小了，映像中好像是完全与镜像大小无关。map (rd) (hd0)执行时无法正确识别CHS参数；在map --hook后不能识别文件系统；

目前来看，“grub4dos-0.4.5b-2011-12-06”版，grub.exe能正确设置(rd)的base地址和size，所以能正常引导镜像；
而“grub4dos-0.4.5b-2011-12-06”版，grub.exe不能正确设置(rd)的base地址和size，(rd)的内容完全不是镜像的内容，故mapp (rd) (hd0)时，无法识别内存盘中的磁盘参数和文件系统，故引导失败。

通过测试多个能够正常引导的磁盘镜像，基本可以证实与镜像无关，“grub4dos-0.4.5c-2013-02-02-2”版都无法引导，“grub4dos-0.4.5b-2011-12-06”版可以正常引导。

[ 本帖最后由 emutemp 于 2013-2-26 15:30 编辑 ]

emutemp

另外,通过命令
kernel http://192.168.1.1/memdisk
initrd http://192.168.1.1/hd.img
加载，对hd,img的大小好像没有限制，1G的也可以正常加载；

通过命令
kernel http://192.168.1.1/grub.exe --config-file="map (rd) (hd0); map --hook; rootnoverify (hd0,0);chainloader (hd0,0)/ntldr"
initrd http://192.168.1.1/hd.img
boot
加载，镜像文件hd.img的大小好像不能超过512M,大于这个数值，boot命令就会执行出错，提示好像是XXX error file number.

通过这种模式让grub.exe加载镜像是不是有512M的限制？

不点

你缺少一项测试，试试用 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 编辑 ]

pseudo

楼主反映的问题应该是存在的。
我也早已遇到，偷懒没反馈，也怕累着不点大人。
既然有人提及，我就反馈一下。

最后能用的grub.exe版本为
grub4dos-0.4.5c-2012-02-10.7z及grub4dos-0.4.6a-2012-02-21.7z，
之后
grub4dos-0.4.5c-2012-02-14.7z及grub4dos-0.4.6a-2012-02-27.7z
就不行了。

应该是ChangeLog_GRUB4DOS.txt:
2012-02-13 (tinybit)bugfix on initrd issue (issue 74).
这个变动引起的。就是说，不点大人在处理
Issue 74:  kexec --initrd and "map (rd) (fd0)" problem Error 65
时，引发了本问题。

可以用0PE来简单构造测试环境：
把0PE提供的StartServer.cmd（petools文件夹里）和0PE.ISO两个文件放在xp/03系统下任意文件夹里，运行StartServer.cmd，免配置即完成服务器端部署。
此时可以pxe启动另一台客户机或VMware客户机。

更换C:\WINDOWS\Tftpd32_Server\grub.exe，即可对照不同版本的表现。
目前0PE带的是grub4dos-0.4.5b-2011-02-10.7z版grub.exe，那是我弄错了，其实应该带最后一个可用版grub4dos-0.4.5c-2012-02-10.7z。

那些不行的版本会进入grub命令行，cat (md)4+8可见菜单，map --status看rd-base和rd-size不对头。

emutemp

原始命令为：
LABEL gpxelinux
kernel http://192.168.100.254/grub.exe
initrd http://192.168.100.254/MiniXP350.gz
APPEND --config-file="map (rd)+1 (hd0); map --hook; chainloader (hd0,0)/ntldr"

修改处：
通过append传递config-file参数，和直接在kerenel命令后传递config-file参数都试了，效果一样。
之所以直接用kernel传递是因为在gPxe中，支持append，在iPxe中不支持append命令。

map (rd)+1 (hd0)和map (rd)+1 (hd0)都试了，效果一样。上面描述中此部分有误，实际测试时基本都是使用的map (rd)+1 (hd0).

不点

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

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

emutemp

测试了下，用20130202版的grldr引导加载本地不同版本的grub.exe和镜像文件。(20130202版和20111206版的grub.exe)

软盘镜像(fd0)测试:
kernel (hd0,0)/grub.exe --config-file="map (rd)+1 (fd0)"
initrd (hd0,0)/ADDS10GUI.IMG
boot
20130202版和20111206版都可以正常执行;在map --hook;root (fd0);chainlaoder (fd0)+1后，镜像文件可以正常启动。
从以上测试来看，加载小的软盘镜像(fd0)是正常的。

硬盘镜像(hd0)测试
我没有小的硬盘镜像文件，只有3个较大的不同大小的DSK硬盘镜像：
1个1G的DSK镜像：
1个534,773,760 字节的DSK镜像；
1个526,417,920 字节的DSK镜像；

用如下命令：
kernel (hd0,0)/grub.exe --config-file="map (rd)+1 (hd0)"
initrd (hd0,0)/ramxp.dsk
boot

1G镜像执行结果：initrd命令后，提示镜像太大不能放入内存；
534,773,760 字节镜像执行结果：initrd命令输入完毕后回车，机器直接重启；
526,417,920 字节镜像执行结果：boot命令后，光标在下一行行头一直闪烁，机器失去响应，热启动键无效，只能硬关机。
20130202版和20111206版执行效果一样。

以上镜像如果使用命令：
map --mem (hd0,0)/ramxp.dsk (hd0)
map (hd0) (hd2)
map --hook
rootnoverify (hd0,0)
chainloader (hd0,0)/ntldr
以上3个镜像都可以正常引导

[ 本帖最后由 emutemp 于 2013-2-26 18:07 编辑 ]

不点

硬盘镜像太大，可能会造成问题。因为你的内存可能不够用。就是说，用 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 编辑 ]

emutemp

用不同大小的硬盘镜像测试了下：
用20130202版的grldr引导加载本地存储的该版本的grub.exe和镜像文件。

100MB、300M、400M都正常；
500MB的执行boot后，光标在下一行闪烁，失去响应。

看来grub.exe能够加载的镜像大小在400MB以上，500MB以下。

但是，如通过gPxe的方式启动，即：
kernel http://192.168.100.254/grub.exe
initrd http://192.168.100.254/100hd
APPEND --config-file="map (rd)+1 (hd0)"

20111206版的grub.exe至少加载100MB的镜像正常；
而20130202版的grub.exe即使加载12MB的镜像都出错，无法识别CHS参数和文件系统。

emutemp

PXE启动如果直接用grldr当然更强大，使用gPxe关键的一点在于tftp协议效率太低，而gPxe支持的http协议在大镜像网络启动时速度很快，但是gPxe功能又弱了点。所以只能结合一下使用。

如果grldr能直接支持http协议那就更好了。

不点

前面已经解释了，不同软件的 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 的情况类似，当一个用户遇到一台机器失败时，他本能地就会放弃了。

emutemp

测试用 map (rd) (hd0)代替map (rd)+1 (hd0)：
本地加载看不出不同，都能正常加载100MB的镜像；

网络gpxe加载:
kernel (hd0,0)/grub.exe --config-file="map (rd) (fd0)"
initrd (hd0,0)/100hd
boot

20111206版的grub.exe加载100MB的镜像正常；
而20130202版的grub.exe加载仍然失败，但稍有变化。

不同之处在于：
使用map (rd)+1 (hd0)时，20130202版的grub.exe加载失败，但是有个识别CHS参数的过程，只不过识别失败，然后使用默认参数255，63；并且使用默认参数后会有较长时间的停顿；然后回到grldr的命令行；
使用map (rd)  (hd0)时，20130202版的grub.exe加载失败，没显示出有识别CHS的过程，直接迅速回到grldr的命令行。ccat --hex (rd)+1查看(rd)内容，与镜像文件内容不符，全是FF。

不点

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 编辑 ]

emutemp

本地加载目前除了有镜像大小限制外，没有其他问题。

对于“map (rd)+1 (hd0) 的情况，cat --hex (rd)+1查看 (rd) 的内容，正常吗？”
PXE网络加载，20111206版的grub.exe，cat --hex (rd)+1查看 (rd) 内容正常，与镜像文件内容相符；
20130202版的grub.exe，cat --hex (rd)+1查看 (rd) 内容不正确，与镜像文件内容不同。

机器内存2G。
20111206版的grub.exe，加载1个100MB的镜像，rd_base=0x19C00000;rd_size=0x6400000;
20130202版的grub.exe，加载1个100MB的镜像，执行时不能识别CHS，采用默认255，63后停顿半天，回到命令行后执行map --status，rd_base=0x83D0FF02;rd_size=0x3476A43D

[ 本帖最后由 emutemp 于 2013-2-27 02:48 编辑 ]

不点

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

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

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

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

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

pseudo

用我提供的startserver.cmd免配置试ipxe，只要客户机检测到pxe服务器，有动静，应该能成功。0pe.iso可以用其它iso冒名顶替。
2012.2.10之后的那个变动，跟内存布局关系密切？
楼主测试反馈的失败情况，我也几乎都试过、遇到过。就是说那不止一例。
只跟grub版本有关。

[ 本帖最后由 pseudo 于 2013-2-27 02:48 编辑 ]

不点

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 编辑 ]

emutemp

PXE使用2.88MB的软盘镜像
命令：
kernel http://192.168.1.1/grub.exe
initrd http://192.168.1.1/288disk.img
append --config-file="map (rd)+1 (fd0);"

20111206版的grub.exe，rd_base=0x1FD30000;rd_size=0x2D0000;
20130202版的grub.exe，rd_base=0x83D0FF02;rd_size=0x3476A43D,与加载100MB的镜像地址情况相同。

pseudo

建议不点大人用我提供的cmd免配置搭个环境，用仅含官方grldr的小0pe.iso来测试，这样便于在g4d中观测内存布局。
执行cmd后即完成安装，并在那桌面有卸载快捷方式，可用来完全卸载。

pseudo

我手头没机器，手机上的网，只能由楼主测试反馈了。

不点

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

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

不点

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

emutemp

强制设置 rd base 和 size 为正确的值，
cat --hex (rd)+1查看起始扇区，内容与磁盘镜像内容一致。
尝试启动
2.88MB的小镜像可以正常启动；
510MB（534,773,760 字节）的大镜像启动失败。

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

不点

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 编辑 ]

2013pentium

终于有人讨论这件事了，我提供过程:
ipxe 来自trunk https://git.ipxe.org/ipxe.git
grub4dos  用的grub4dos-0.4.5c-2012-02-01 和 grub4dos-0.4.5c-2012-02-10
tpe_pxe.iso 是50mb的xp pe

#!ipxe
echo +----test----

kernel http://192.168.100.254/pxe/syslinux/grub.exe --config-file="map (rd)+1 (0xff); map --hook; rootnoverify (0xff); map --status; pause; chainloader (0xff);"
initrd http://192.168.100.254/pxe/iso/tpe_pxe.iso

boot

可以顺利启动

而仅换 grub4dos-0.4.5c-2013-02-02-2.7z
或是
grub4dos-0.4.5c-2012-02-14
grub4dos-0.4.5c-2012-02-27
grub4dos-0.4.6a-2012-03-26

则自动跳回grub4dos命令行

[ 本帖最后由 2013pentium 于 2013-2-27 12:13 编辑 ]

2013pentium

在ipxe编译debug模式后

比较 grub4dos-0.4.5c-2012-02-01 与
grub4dos-0.4.5c-2013-02-02-2.7z 的grub.exe 命令行执行过程

syslinux 5.01菜单如下，意图是保留pxe连接并进入g4d环境

kernel pxechn.c32 http://192.168.100.254/syslinux/grub.exe

测试结果是:
2012-02-01的可以打任意字符回车，ipxe协议栈调试明文显示tftp查询文件 ,并cat (pd)/dir.txt可以正确读取。
2013-02-02-2.7z 则ipxe的明文调试信息无，(pd)/dir.txt可以正确读取。


btw: gpxe已基本无维护，ipxe算是前者衍生版保持活跃

不点

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

2013pentium

我已整理27楼测试，看起来是2-10 到2-14期间的变化，引起的现象。


       
grub4dos-chenall 的
Issue 74:        kexec --initrd and "map (rd) (fd0)" problem Error 65

或许和这个修改有关

[ 本帖最后由 2013pentium 于 2013-2-27 12:18 编辑 ]