GRUB4DOS更新建议、bug反馈专帖

roytam1

原帖由 chenall 于 2011-5-29 16:00 发表
比较奇怪，我并没有针对这个作任何的改动呀。

你有空的话可以多试试几个版本。

注：我编译的版本，ROY编译的版本，不点编译的版本。

不点的上传在这里
http://nufans.net/grub4dos/tinybit/

googl ...

說郅最後其實都是UltraISO自己的問題。

tuxw

@chenall
两个内置变量 @root @path 一个后面有/，一个没有
这个是随手写的还是刻意这样的，有什么讲究

另外，批处理标签长度限制是多少？

[ 本帖最后由 tuxw 于 2011-5-30 10:32 编辑 ]

chenall

@root后面是没有'/',因为内部保存的就是没有'/'。
像root (hd0,0)/boot 和　root (hd0,0)/boot/　效果是完全一样的。

@path是后面增加的，为了编程方便有'/'，因为输入不带'/'的外部命令会从这个目录下查找，这样就可以直接简单的把两个字符串连接起来就行了，而不用再特意去加'/'

批处理标签长度没有限制，因为在扫描批处理标签时只是标记了这一行是标签，得到的是一个指针。
另外标签中如果如出现空格、制表符，则只有前面的字符有效。
像
:test abcd
实际上是等于:test
标签不区分大小写，如果有同名的标签，以第一个为准。

不过有其它限制，比如一个批处理中不能超过128个标签，不能超过2048行（注释和标签不算）。

pseudo

@不点
已有不少反映，在新cpu（如i5）双显卡机器上，grub4dos的--mem遇到蓝屏4B问题。
由于新机器渐多，希望能解决此类问题。实现有--mem时也不蓝。


以下P.ISO是普通PE1.x，不含firadisk；A.IMG是1.44的空软盘映像经gzip压缩。全部文件藏入ud。2g内存。

title [1] test 1
find --set-root /P.ISO
map --mem /P.ISO (0xff)
map --hook
rootnoverify (0xff)
chainloader (0xff)
title [2] test 2
find --set-root /P.ISO
map /P.ISO (0xff)
map --hook
rootnoverify (0xff)
chainloader (0xff)
title [3] test 3
map --mem-max=256m
find --set-root /P.ISO
map --mem /P.ISO (0xff)
map --hook
rootnoverify (0xff)
chainloader (0xff)
title [4] test 4
map --mem-max=400m
find --set-root /P.ISO
map --mem /A.IMG (fd0)
map --hook
map /P.ISO (0xff)
map --hook
rootnoverify (0xff)
chainloader (0xff)
title [5] test 5
map --mem-max=400m
find --set-root /P.ISO
map --mem /P.ISO (0xff)
map --hook
map --mem-max=2g
map --rehook
rootnoverify (0xff)
chainloader (0xff)
title [6] test 6
map --mem-max=400m
find --set-root /P.ISO
map --mem /P.ISO (0xff)
map --hook
map --mem-max=2g
rootnoverify (0xff)
chainloader (0xff)
title [7] test 7
map --mem-max=400m
find --set-root /P.ISO
map /P.ISO (0xff)
map --hook
rootnoverify (0xff)
chainloader (0xff)
title [8] test 8
find --set-root /P.ISO
map --mem /A.IMG (fd0)
map --hook
map /P.ISO (0xff)
map --hook
rootnoverify (0xff)
chainloader (0xff)
title [9] test 9
find --set-root /P.ISO
map --mem=0xA0000 /A.IMG (fd0)
map --hook
map /P.ISO (0xff)
map --hook
rootnoverify (0xff)
chainloader (0xff)
title [10] test 10
find --set-root /P.ISO
map --mem=0xC0000 /A.IMG (fd0)
map --hook
map --mem=0xA0000 /P.ISO (0xff)
map --hook
rootnoverify (0xff)
chainloader (0xff)

只有菜单项test2和test7能正常启动不蓝屏，其余全部蓝屏。

其规律是：只要有--mem就蓝。与是哪个pe1.X无关，与firadisk无关。
想通过map --mem-max=400m之类避开内存冲突，没成功。


我手头没有测试环境不便分析，这是让网友测试的结果。

不点

这个报告提供的有效信息太少，无法确定问题的根源。

应该说说 memdisk 是否存在同样问题。

另外，很容易确定，相同的映像，假如只启动 DOS 之类的实模式程序，是否一样死机？

如果实模式没问题，只有保护模式有问题，那怀疑是保护模式的驱动程序本身的问题。也就是说，保护模式的驱动程序，例如显卡驱动、网卡驱动、USB 驱动，声卡驱动，等等，它们与 grub4dos 的内存盘发生冲突。换句话说，这些驱动不遵守 int15 规范。

特别注意：再多的 PE 的死机，也不能证明 grub4dos 有错。

只要有另外一个软件例如 memdisk 不出错的证据，就足以证明 grub4dos 有错。

-----------

补充：

假定 grub4dos 没错，出错的是某个软件（无论它是实模式还是保护模式的程序）不遵守 int15 内存规范，那么，grub4dos 无法应付这类情况（本来就不支持这种情况，甚至在 grub4dos 方面，也没有任何 workaround 可以作为应急措施）。grub4dos 之所以能够顺利启动很多 DOS 的 IMG，那也是因为这些 DOS 的 IMG 中的软件，全都遵守 int15 内存规范。为了验证这个说法，作为一个练习，你自己可以写一个故意不遵守 int15 规范的 DOS 程序，只要运行这个程序，grub4dos 下的仿真就一定会死机。

[ 本帖最后由 不点 于 2011-5-31 10:35 编辑 ]

zhaohj

原帖由 chenall 于 2011-5-29 23:57 发表
为了支持(fdx,y)的格式的后遗症。

或者制作软盘镜像时，把第一扇区的分区表位置的值清零就不会了 ...

这个后遗症尽管不影响使用，但感觉实在不好。
按照你的方法，做了两个f6.img，一个只生成(fd0)格式的，另一个生成(fd0)、(fd0,0)的。
我把它使用在srsf6中。

chenall

需要空白软盘镜像可以用fat。
map --mem (md)+2880 (fd0)
map --hook
fat mkfs (fd0)

另外使用fat mkfs (fd0)格式化的磁盘可用空间也比较大（因为它只使用了一个FAT表，而非正常的两个，所以就节省了一个FAT表的空间）

[ 本帖最后由 chenall 于 2011-5-30 16:28 编辑 ]

zhaohj

C大，对下面的网卡，chkpci能否识别？

http://bbs.wuyou.net/forum.php?mod=viewthread&tid=179738&page=49#pid2244053

要怎么写才能识别？

因为是服务器，我现在无法重启。

[ 本帖最后由 zhaohj 于 2011-5-30 17:37 编辑 ]

chenall

这个我也不懂，应该会有类拟的VEN_XXXX&DEV_XXXX的吧，你可以chkpci列出所有PCI看一下。

tuxw

if exist (hd0,0)/WINDOWS && echo ok

如果 (hd0,0) 是 FAT 格式，判断会返回假
如果 (hd0,0) 是 NTFS 格式，判断会返回真，它将NTFS上的目录当文件处理了。我试过用 open 函数去打开一个 NTFS 上的目录，函数会成功打开一个长度为 0 的文件

jianliulin

map iso 好像有些问题

chenall

试了一下，好像确实如此，不过这是小问题影响不大。

@jianliulin
这是正常的，find命令查找光盘只会查找(cd)或当前root的光盘设备。

所以你这个是肯定找不到的。

jianliulin

map --unhook 好像也有些问题

hhh333

我现在是这样做盘的：做出UD后，只将grldr拖到UD内，其他放可见区（当然menu.lst也在可见区）
在我的一台gf3的机器上，可见区识别成了(fd0,0)
menu菜单的预执行区有如下语句
......
set bd=hd
checkrange 0x0 read 0x8280 && set bd=fd
checkrange 0x9f read 0x8280 && set bd=cd
checkrange 0x21 read 0x8280 && set bd=pd
checkrange 0x23 read 0x8280 && set bd=ud
#UD启动如可见区识别为fd0,0则映射为hd0
if %bd%==ud checkrange 0 read 0x82a0 && map (fd0) (hd0) && map (hd0) (hd) && map --hook && rootnoverify (hd0,0)
......

直到23日的版本这么用都是可以的，8280中为23，82a0中是0；

28日的版本ud启动时8280中也变成0了，这怎么又变了？

现在究竟有什么最快捷的方式检测可见区为(fd0,0)？

====
刚才又到另一台机子上启动了一下，8280和82a0中均为80，也就是可见区识别成了hd0，目前我这种形式难道新版本没办法检测是不是从UD启动的？我这种形式的U盘应该还算是(ud)启动的吧？

[ 本帖最后由 hhh333 于 2011-5-31 20:04 编辑 ]

chenall

你把menu.lst放在可见区那是肯定会一直变的，因为0x8280其实就是当前使用的menu.lst所在的磁盘。

如果把menu.lst放在ud那就一直都会是23.

要检测是不是从ud启动的，其实只要检测(0x23)是否存在就行了..

用以下命令就可以检测
find --devices=u && set bd=ud

[ 本帖最后由 chenall 于 2011-5-31 21:49 编辑 ]

不点

find 找到 (hd32)，是因为它是当前设备。但此时 (hd32) 已经 unhook，所以，不再有实际的 “介质”。

你可以试试

1. find     +1

复制代码

就是说，找一个扇区，如果成功，则表示该设备实际是存在的。如果不成功，就表示该设备不可访问。

hhh333

以前的版本好象不是这样的。反正不管了，fd0,0是最恼火的，一旦出现，PE不能启动，必须映射为hd方可，有什么好的检测fd0,0是否存在的办法？或者有更好的处理方法？

pseudo

"fd0,0是最恼火的，一旦出现，PE不能启动，必须映射为hd方可"
好像不是这样的。几年前这个问题就解决了的。

检测fd0，0的一种方法是检测其上文件：
if exist (fd0,0)/WXPE/SETUPLDR.BIN echo (fd0,0)。

hhh333

在我的这台NF3的机器上，hdd被识别为ZIP，如果从UD启动，则出现可见区为fd0,0，如果启动PE，则出现detect错误，有更好的不用映射能够启动的办法吗？

另外，检测文件当然为一种方法，但似乎没有通用性。

chenall

很早就一直这样子了。

检测是否(fd0,0)用新版的比较简单
if "%@root%"=="(fd0,0)" echo (fd0,0)

如果对GRUB4DOS比较熟悉的话检测的方法还有很多种。关键是变通。

pseudo

全藏入ud时，你怎么启动？
放在fd0,0，就用类似方法启动。

顺便问一下，当出现fd0，0时，先执行root (hd0,0)，然后find还能找到fd0，0么？

[ 本帖最后由 pseudo 于 2011-6-1 11:56 编辑 ]

hhh333

这种ud中放grldr，可见区放menu.lst，在我的NF3机上的启动情形可以这么来理解：
1、mbr-->ud中grldr获得控制权后，bd=(ud)（即*0x8280＝0x23）；root=(fd0,0)（即*0x82A0＝0）。这时，当前目录为可见区；而多数其他类型的机器可见区会被识别为hd0,0，即*0x82A0＝0x80
2、执行内置默认菜单-->configfile /menu.lst，则会执行可见区的menu.lst，这个时候grldr将根据menu.lst所在的设备重置bd，由于这时可见区设备为0，则*0x8280＝0；这个时候在menu.lst中根据8280的值来判断初始启动设备则是不正确的，这也就是说，到这步已经没有办法来判断初始启动设备了，因为8280中的值已经由于执行menu.lst而被重置！

有几个问题：
1、如果上述我的理解是正确的，在grldr中是否还有内存位置保留有最初启动的设备号？如果没有，有不有必要增加一个位置来保存最初启动设备号，这个位置的值只要不人为改变，在grldr的生存期内应一直保持不变。
2、我这台机器U盘不做成UD的形式，会识别成fd0，启动PE等无异常。究竟fd0与fd0,0有什么区别？是不是只有用UD启动时才会出现fd0,0的情况？
3、可不可以说fd0,0实际上是一种错误的格式或者MS的启动文件无法识别的格式？因为毕竟它会造成启动失败。这个我也测试过，fbinst菜单中启动syslinux，也出现detect错误，而syslinux没办法处理这种情况，只能启动失败；而g4d可能将fd0映射为hd0来启动。从这一点来看g4d也够强！
4、或者说fbinst本身有问题，导致产生了fd0,0这样的设备？

[ 本帖最后由 hhh333 于 2011-6-1 17:32 编辑 ]

hhh333

1、全藏入ud是另外一种情况不是我讨论的主题，但方法我目前只有两个：要么整体启动，要么拷入内存盘启动（实际上从原理上看是一种，即把启动文件挂入内存盘启动）。P大有更先进的方法吗？
2、这个似乎是没有了，明天我再试一下；不过好象我在menu.lst中写了一句root (bd)，似乎find中已经没有可见区了hd0是硬盘上的东西。

zhaohj

理解正确！
为何不把menu.lst放在(ud)区呢？这样(bd)还是0x23，()是可见区。

tuxw

将 (bd) 解读为启动设备有很大的误导性，任何时候，(bd)都是当前菜单（没有菜单时它是内置菜单grldr）所在的设备，这样通过(bd)来引用跟当前菜单在同一设备上的文件很方便

在 Grub4Dos 中，要获取“第一启动设备”几乎是不可能完成的任务，虽然在指定环境应用下有些办法，但都有很大的局限性，因为 grldr 也有可能不在“第一启动设备上”。自动搜索grldr提高了启动的“成功率”同时也赠送了一些副作用。

hhh333

虽然绝对的“第一启动设备”可能确实不好确定，但可不可以将获得控制的grldr所在的设备定义成“第一启动设备”，即grldr确定它自己所在的设备，也即“内置菜单”所在的设备，这个有困难吗？

zhaohj

那得修改内置菜单，在加载外置的menu.lst前，设置一个变量。这个变量不要被外置菜单覆盖就可。
如：set  bootdrv=%@root% 或 set /a bootdrv=*0x8208

hhh333

这个倒是一个办法，但应该是set /a bootdrv=*0x8280吧？

[ 本帖最后由 hhh333 于 2011-6-1 22:39 编辑 ]

zhaohj

原帖由 hhh333 于 2011-6-1 22:31 发表
这个倒是一个办法，但应该是set /a bootdrv=*0x8280吧？

是的，一不小心，搞混了。

我认为你的情况，菜单内置是最好的解决办法。你的菜单也不超过4K。

hhh333

我觉得有必要将获得控制的grldr所在的设备（即相当于grldr的“第一启动设备”）在固定的位置保存下来，看chenall的意见。既然8280会随menu.lst的位置而变，因此也应该有位置来保持原始值。

[ 本帖最后由 hhh333 于 2011-6-2 09:04 编辑 ]