GRUB4DOS更新建议、bug反馈专帖

zxw

这个正常了。....

chenall

上面的是测试用的,还没有整合.

chiannet

由2011-7-9版grldr升级到2011-8-9版grldr后，在一台865PE芯片组的老机上变得不能启动了，表现为map --mem ISO到内存后，启动PE时黑屏失去响应。

原来的旧版本可正常启动。

zhaohj

原帖由 chiannet 于 2011-8-9 12:04 发表
由2011-7-9版grldr升级到2011-8-9版grldr后，在一台865PE芯片组的老机上变得不能启动了，表现为map --mem ISO到内存后，启动PE时黑屏失去响应。

原来的旧版本可正常启动。

这种情况正好可以测试新版G4D的map --e820cycles=-1后的memcheck，具体可以看看：
http://bbs.znpc.net/viewthread.php?tid=6146&page=6&fromuid=14583#pid48710

chiannet

title  Windows 2003 PE
checkrange 0x30001:-1 read 0x8298 && map --mem (bd)/AXPE/WINPE.ISO (0xff) ! map (bd)/AXPE/WINPE.ISO (0xff)
map --e820cycles=0
map --hook
chainloader (0xff)
以上会在那台865机器黑屏死机

改成下面，就正常启动了
title  Windows 2003 PE
checkrange 0x30001:-1 read 0x8298 && map --mem (bd)/AXPE/WINPE.ISO (0xff) ! map (bd)/AXPE/WINPE.ISO (0xff)
map --e820cycles=-1
map --hook
chainloader (0xff)



补充说明，启动这些之前，都已加载了P大的USB auto accelerator

[ 本帖最后由 chiannet 于 2011-8-9 14:46 编辑 ]

zhaohj

原帖由 chiannet 于 2011-8-9 14:42 发表
title  Windows 2003 PE
checkrange 0x30001:-1 read 0x8298 && map --mem (bd)/AXPE/WINPE.ISO (0xff) ! map (bd)/AXPE/WINPE.ISO (0xff)
map --e820cycles=0
map --hook
chainloader (0xff)
以上会在那台 ...

你这种情况说明你的机器很正常！
默认情况下，map --e820cycles=-1

chiannet

哦，那么

map --e820cycles=x

x该怎么确认？有没有一个推荐的数字？

zhaohj

map --e820cycles=-1适用于正常的机器（默认可不写）；
对于bios有缺陷或bios严重bug、故意为之的变态产品，x是多少只能碰运气了。

zxw

建议扩展%~*，去掉引号。

zxw

发现一个bug，如图：


＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
明白了，是去掉引号的算法在作怪。以紧邻的引号配对。

[ 本帖最后由 zxw 于 2011-8-18 21:22 编辑 ]

zxw

故意将设备名大写..

chenall

设备名错误，那得到的结果肯定也是错的，这个好像之前有提过．

zxw

以前也是我提过，后来也纠正了。
从2011-07-05版本开始又反复了。


[ 本帖最后由 zxw 于 2011-8-22 10:03 编辑 ]

chenall

下次再改一下吧,错误的设备名就保留原样不处理.

zhaohj

发现一个bug：取变量值后多出一个空格
8.9版本
-------------------
再次测试，改成set /a m=1就ok!
---------------------

!BAT
......
set m=1
echo disk%m%="S&R&S%m% Installation Disk",\disk,\  >> (fd1)/T.OEM
echo driver=disk%m%,%IDN%.sys,%IDN% >> (fd1)/T.OEM
echo inf=disk%m%,srs%m%.inf >> (fd1)/T.OEM

[ 本帖最后由 zhaohj 于 2011-8-23 09:21 编辑 ]

zxw

set m=1
1后面有个空格吧？

zhaohj

原帖由 zxw 于 2011-8-23 09:04 发表
set m=1
1后面有个空格吧？

可能是吧。不小心行尾加了个空格。但%m%是否应该去掉前后空格？
我记得以前是去掉前后空格的，不知什么时候开始变成目前这样了。
--------------
测试了一下，目前只会去掉前端空格。
肯定是bug，不过这样也挺不错的，哈哈。
---------
但这样行尾及连写的时候要特别小心了。
连写的时候两个空格其中一个空格会赋值给变量
set a=abcd  && set b=1 #&&前有两个空格
if "%a%"=="abcd" echo ok
不成功。

[ 本帖最后由 zhaohj 于 2011-8-23 10:03 编辑 ]

chenall

这是正常的，SET命令后面的空格不会被删除。影响不是很大，如果修改了可能会影响到之前的脚本，
我记得我之前写的脚本就有使用这个特性。

不过以后还是尽量不要使用这个特性，因为空格看不出来，复制代码的时候很容易出错。

需要带空格的建议使用“ ”

hhh333

这个在DOS中也是有空格的

chenall

嗯，不过因为这样在看代码的时候不直观。

特别是如果一些编辑器会自动清除行首和行尾的空格导致出错。

qdaijchf

不知道是grub4dos的bug还是plpbt的bug？

测试环境：u盘量产成两个hdd，grub4dos从ud启动。
第一台电脑：
不加载plpbt，u盘可见分区被认作成fd0，执行find --set-root /windows/system32/ntoskrnl.exe能找到文件。
加载plpbt，u盘可见分区被认作hd0，执行find --set-root /windows/system32/ntoskrnl.exe，提示找不到文件，然而当先执行root (hd3,0) || root (hd2,0) || root (hd1,0) || root (hd0,0)后再执行find --set-root /windows/system32/ntoskrnl.exe却能在（hd1,0）上找到文件。
不知道是grub4dos的bug还是plpbt的bug？

第二台电脑：
不加载plpbt，u盘可见分区都被认作hd0，而且执行find --set-root /windows/system32/ntoskrnl.exe在（hd1,0)上找到文件。
加载plpbt，u盘可见分区被认作hd0，而且执行find --set-root /windows/system32/ntoskrnl.exe在（hd2,0)上找到文件。

顺便问一下下列语句怎么写？
先root (hd0,0) || find --set-root /windows/system32/ntoskrnl.exe，要是找不到文件就root (hd1,0) || find --set-root /windows/system32/ntoskrnl.exe，直到找到文件为止。

[ 本帖最后由 qdaijchf 于 2011-8-28 20:48 编辑 ]

chenall

感觉你没有明白find的作用,胡乱使用.

建议你看看说明

1.这个你可以搜一下论坛的贴子,记得之前就有人说过这个问题,如果这个论坛没有那应该在时空里面.
如果不懂得找可以去我的主页,文章顶部有一个GOOGLE的自定义搜索,输入plpbt应该就可以找到答案了.

2.直接find --set-root /windows/system32/ntoskrnl.exe
就可以找到GRUB4DOS所有能识别的磁盘中包含以上文件的磁盘,并设为root.

我猜测你可能是因为第一点所以才需要这样吧.

mygamexxx

C大第2点好像说漏了几个字，是找到该文件的第一个磁盘分区，并设为root，可能多个磁盘分区有相同文件，呵呵！！

tingyue-wu

疑是bug
不确定

问题是U盘量产后，启动，找不到U盘量产后的剩余分区。用的是chenall的搜索模块，搜索h、f、以及其它,都不能找到剩余第一分区上面的文件

几天前是可以识别的，用的量产镜像是同一个。不过grub4dos版本不同，上次量产是一个月前了，量产后剩余分区有两个（量产设置），第一个识别为(hd0,0)第二个识别为(hd1,0) 而本机硬盘上的分区识别为(hd2,X)，启动无数次都是这样的识别结果。

今天把镜像中的grub4dos更新成最新版（8.25），其它什么也没动，重新量产，之后发现无法找到剩余的第一个分区，只能找到剩余第二个分区，并发现剩余第二分区识别为(hd1,0) 而电脑硬盘上的分区识别为(hd0,X) ，然后以为是量产错误，再次量产多次，把量产剩余分区设置为一个，也找不到。

想来想去，要么我的电脑主板出问题了，要么grub版本的bug。
暂时没有别的电脑测试，只能怀疑，向大家报告一下。有人遇到相同情况吗？

chenall

嘻嘻,是少了几个字...

@tingyue-wu
需要更详细的报告,
可以自己操作一下.用find命令不带参数,看看列出的磁盘.再配合cat --hex (hdx,y)+1来查看指定分区的引导扇区.

U盘的问题,和电脑主板有很大关系的

tingyue-wu

怪事，今早起来  可以发现量产后剩余分区了。

大概主板bios昨天抽风了。

[ 本帖最后由 tingyue-wu 于 2011-8-29 06:38 编辑 ]

qdaijchf

u盘量产成两个hdd，两个hdd上分别建立了ud分区，grub4dos从ud启动。在u盘第一个hdd上放上文件usb.1,第二个hdd上放了文件usb.2，并用find --set-root进行分别查找（未加载plpbt），结果如下：
第一台电脑：usb.1在(fd0,0)，usb.2在(fd1,0)
第二台电脑：usb.1在(hd0,0)，usb.2未查到。

zxw

@chenall:
新版有bug:

chenall

我试了是正常的,看起来好像你写错了吧,

把%~d1写成了%~dl

zxw

晕啊，还真是写错了。