GRUB4DOS更新建议、bug反馈专帖

hhh333

又有问题请教，主菜单中用了unifont，configfile到子菜单怎么就乱码了？
又在子菜单加上
UNIFONT -unload
UNIFONT /BOOT/GRUB/U16HZ

也没有用，不知何故？这个难道还有其他的要求，应该在主菜单加了的，子菜单直接就能上中文的。用的是9月7日的最新版。

chenall

主菜单用UNIFONT

如果了菜单的编码非UTF-8那肯定乱码...

应该是你的两个菜单文件编码不一致..如果是其它情况请截图.

hhh333

确实够大意的，又忘记注意编码问题了
另外，我还想问一个问题，我想用wee127来MAP　IMG来启动，好象不行

1. timeout 10
   
2. default 0
   
3. title 1. Windows
   
4. find --set-root --active command +1
   
5. find --set-root /bootmgr /bootmgr
   
6. find --set-root /ntldr /ntldr
   
7. title 2. MaxDOS
   
8. map --mem /BOOT/IMGS/MAXDOS.IMG (fd0)
   
9. map --hook
   
10. rootnoverify (fd0)
    
11. (fd0)+1
    
12. title 3. GRGHOST
    
13. map --mem /BOOT/IMGS/GRGHOST.IMG (fd0)
    
14. map --hook
    
15. rootnoverify (fd0)
    
16. command +1

复制代码

两个文件都是非压缩的IMG格式，第2个是标准的1.44M

[ 本帖最后由 hhh333 于 2011-9-11 20:46 编辑 ]

chenall

好像wee127的map只支持映射交换...

比如
map (hd0) (hd1)
map (hd1) (hd0)

hhh333

按不点的说法是127的那个主要是增强map的功能的，除不支持压缩具有g4d所有的功能的。

或者用memdsk来仿真，这个菜单应该怎么写？

[ 本帖最后由 hhh333 于 2011-9-12 06:47 编辑 ]

chenall

好像wee127的map --mem有一些机子不支持.

你可以在WEE的命令行中输入map --mem xxxx (fd0)

会有提示..

如果要使用memdisk来仿真用WEE63就够了.

直接(hdx,y)/path/memdisk (hdx,y)/path/file.img

hhh333

刚才试了，好象还是不行
/boot/grub/memdisk /boot/imgs/grghost.img floppy
rootnoverify (fd0)
command +1

实际上我的要求很简单，就是用wee来启动软盘镜像。

chenall

wee和GRUB4DOS的使用方法不太一样的.

不行应该是你的文件有误.

你要确认以上文件存在.

我试了一切正常

只需要一条命令

(hdx,y)/path/memdisk (hdx,y)/path/filename.img
它就直接启动了.

不点

> 两个文件都是非压缩的IMG格式，第2个是标准的1.44M。实际上我的要求很简单，就是用wee来启动软盘镜像。

你忘了 “大” 前提，只记得上面这些 “小” 前提。

大前提：Wee 只能可靠访问硬盘，不能保证访问 USB 时的情况。注意 BIOS 对于 U盘的 LBA 支持情况。

还有一种可能性，你制作的映像，其 BPB 表中的 H、S 以及 drive number、hidden sectors 的设置不正确，导致启动失败。比如，从软盘启动，其 drive number 不是 0，而是 80h；或者 hidden sectors 不等于 0。这都可能造成 Wee 以及 memdisk 失败。

grub4dos 能够自动处理以上问题，自动替用户修补这些缺陷，所以，grub4dos 成功率高。grub4dos 能够把一个逻辑分区映射为软盘，因此，必须自动修正 BPB 参数。也就是说，grub4dos 必须有自动修复 BPB 参数的功能。

你应该检查 IMG 的 BPB 表，确保这些敏感参数设置不会有错。如果有错，那么由于 Wee 和 memdisk 都不能够自动修正，因此都会失败的。

hhh333

我的是用bootmgr启动wee63.mbr，菜单也出来了，用你的方法

/boot/grub/memdisk /boot/imgs/dm.img

好象还是不行，选这一项的时候，屏幕闪了一下wee17，仍然回菜单。

memdisk是用的2006年的那一个。

chenall

建议你使用命令行手工输入完整的路径试试.

闪一下那肯定是文件不存在,如果文件正常存在的话那就会直接启动MEMDISK了.

zhaohj

对虚拟光盘有个想法：
连续的硬盘、软盘(0、1)，是支持find的，(0xa0)~(0xff)一般用在虚拟光盘即2KB的扇区，是否应该定义一个设备号?
map --mem /MYISO.ISO (0xa0) && map --hook
光盘数是否应该加一？
假如我们定义一个(cw0)代表(0xa0)，(cw1)代表(0xa1)，(cw)就可以象硬盘一样(hd)
这样find就可以解决虚拟光盘的查找问题。

[ 本帖最后由 zhaohj 于 2011-9-13 11:38 编辑 ]

zxw

嗯，虚拟光驱的find一直让人头痛。
最好如(hd)一样增加一个(cd)就好了。

不点

你搞错了。

ATAPI CDROM 是指经由 cdrom --init 获得的真实 cdrom。它不包括用 ISO 虚拟的 CDROM。

ATAPI 是硬件规范，不是 INTxx 这类软件接口。

不点

find 命令可以很容易改变。问题只在于：究竟是否应该改变，以及有多少人需要改变。

同时仿真 2 个 iso 的情况并不多见。

由于仿真了的 ISO，其盘号可以在一个范围变动，而且是已知的，它就是 map 命令指定的盘号，因此，不适合用 find 命令。直接指定它的设备名即可。

-------------------

另外，关于 cdrom 的盘号，这是“规范制造者”们没有确定的事情。本来没有规范的事情，我们也不能创造一个规范。假如我们创造一个规范，且不说有没有人遵守、承认，就算有人接受了，那“创造规范”这件事本身，是否属于“添乱”，恐怕还是一个疑问，也可能会遭到指责。

我们知道，BIOS 数据区中有软盘的个数以及硬盘的个数。谁听说过有什么规范指定 CDROM 的个数吗？假如我们制造一个规范，把 BIOS 数据区中的某个字节作为 cdrom 个数的记录，那么这会不会与某个主板相冲突呢？有谁会承认呢？这都是问题。

[ 本帖最后由 不点 于 2011-9-13 12:01 编辑 ]

zxw

我觉得可以考虑增加显示：
cd_orig=0,cd_curr=0的信息。
不管是否真实、虚拟的光驱。

不点

cd_orig=0 什么意思？本来在 BIOS 数据区就不存在 cdrom 个数，而你这个 cd_orig 从哪里得到？

zxw

汗，原来是这样。谢谢指教。

不点

规范的制定者没有规定 CDROM 的盘号用哪个，也没有规定有多少个 CDROM。

如果主机有两个 CDROM 驱动器，你都插上可启动的光盘盘片。此时，从光盘启动后，你预先不知道

（1）BIOS 把启动盘的盘号设置在哪个盘号上。
（2）BIOS 承认几个光盘。如果光盘格式不是 no-emulation 模式，那么有可能 BIOS 不承认所有的光盘。也就是说，有可能没有一个光盘被分配盘号。即使两个光盘都是 no-emulation 模式，也不能保证两个光盘都获得盘号，只能保证启动盘获得一个盘号。那个非启动的光盘，BIOS 可能对它视而不见，不给它分配盘号，用户也就无法访问，除非使用驱动程序。

chenall

汗,,又发现一个BUG,上次改错了..

附件的版本修正了以下BUG.
直接insmod filename时,如果这个filename在默认的path目录下时,会失败.

另外新的版本对于输出重定向也有一些变动..

一个比较实用的例子(命令行下)
set a=b
set b=12345
call echo %%a%%
将会得到12345


先放着测试一下,晚上再上传.

hhh333

(hd0,0)/boot/grub/memdisk (hd0,0)/boot/imgs/dm.img通过
或者find --set-root /boot/grub/memdisk /boot/grub/memdisk /boot/imgs/dm.img也行

看来这个wee还是与g4d有较大区别。难道它没有当前盘的概念，所以每条语句前都要有find？

又：经过测试，用最新的memdisk（我是从syslinux中取用的）比老的好使，用老的对于非标准格式的盘会出错。
另外memdisk就仿真来说还是比wee127的MAP命令强，用map提示bios不支持mem之类，功能较弱和限制较多，还不如wee63与memdisk。wee127确实有点鸡肋。

[ 本帖最后由 hhh333 于 2011-9-14 06:48 编辑 ]

hhh333

我看现在g4d的功能已经很强大了，但我一直没有找到，让菜单条件显示的方法，譬如在预执行区根据某个条件来控制下面的菜单的隐藏或显示，或者使失效和可用？这个应该是很有用的。

zhaohj

原帖由 hhh333 于 2011-9-14 06:59 发表
我看现在g4d的功能已经很强大了，但我一直没有找到，让菜单条件显示的方法，譬如在预执行区根据某个条件来控制下面的菜单的隐藏或显示，或者使失效和可用？这个应该是很有用的。

你可以用动态生成菜单的方法。

chenall

可以使用变量控制菜单是否可用的.比如以下菜单.

比较简单的判断,只是让菜单执行失败了..exit命令因为菜单不支持这个命令所以就失败了.

if exist (hd0,0)/windows/system32/version.dll && set title0=exit
if exist (hd0,1)/windows/system32/version.dll && set title1=exit

title 0. (hd0,0) test
%title0%
chainloader (hd0,0)+1

title 1. (hd0,1) test
%title1%
chainloader (hd0,0)+1

隐藏菜单,只能隐藏菜单文字,同样使用变量
像下面的例子只要设置title的值为空菜单文字就不显示了,但用处不大.

title %title%
xxxx
xxx

hhh333

以上chenall提供的方法，显然不太合要求。

一般情况下，我们还是用菜单的，复杂的批处理真正派上用场的情况不多，也多数是高手在玩。而菜单功能我觉得确实有强化的必要，象上面我讲的条件显示菜单功能，我曾经这么用过，显然不行：

if not %bd%==cd set cls=clear

title 3.EasyBoot
%cls%
chainloader /easyboot/loader.bin

如果实现条件显示或隐藏，有些程序真的可以简化，譬如上面的，if not %bd%==cd  hideitem 3　很直观易懂的。

[ 本帖最后由 hhh333 于 2011-9-14 16:22 编辑 ]

chenall

你可能没有测试过吧,我上面提供的是菜单的而不是一个批处理,可能你看到开头的批处理就没有去试了.

用我上面的方法可以使个某个菜单(失败)

至于强化,我目前没有什么好的办法,如果你愿意的话可以写一个补丁.

zhaohj

有点意思，根据条件显示或隐藏某个菜单项，还是有点实用价值的。

hhh333

我不是说你的方法是批处理，第一种显然不合要求，第二种刚才试了一下，是可行的，但只是空一行，或者用第二种再结合第一种，反正不够完美，如果多几个隐藏的，菜单就会变得很难看，而且光标也能够停留在空行上。

hhh333

近期发现一个问题：grldr.mbr似乎不能识别NTFS？！
是这样的，以前我是用NTLDR-->avldr-->bootmgr-->win7pe，但发现一个问题，就是启动区是FAT32时，出现boot image corrupt.....错误；后改用NTLDR-->grldr.mbr-->bootmgr-->win7pe通过。
那知道一回到NTFS分区grldr.mbr又不灵了，总提示各个分区都没有发现bootmgr！不作任何改变只换回avldr就OK了。可见并不是不存在，而是grldr.mbr发现不了NTFS分区根下的bootmgr，也不是大小写的问题，这是怎么回事？

不点

@hhh333

拿出当年获得诺贝尔奖的勇气，抓住 bug 不让跑掉。

你的报告有很多不清楚的地方。

1、 grldr.mbr 的版本？可别像前几天的报告那样，你还在用 5 年前的 memdisk（2006年的）。所用的 NTLDR 的版本呢？

2、 是不是你修改 grldr 的程序有 bug，导致它改错了地方，让 grldr.mbr 失效了？

3、 你用未加更改的 grldr.mbr 能找到 GRLDR 吗？

4、 你是在什么设备上执行这些操作的？是 USB 设备呢，还是普通硬盘？


补充说明，如果是 USB 设备，则任何事情都可能发生。当 CHS 识别错误时，一切都不用再继续了。安装 fbinst 是一个 “上上” 之选，因为只有 fbinst 能够把 100% 准确无误的 CHS 传递给 grldr。

在 USB 上，如果你的目的仅仅是利用 grldr.mbr 作为一个（中间）工具来启动 bootmgr，我个人认为，你搞错了。你应该直接用 bootmgr 作为第一启动，而不是 NTLDR。也就是说，要么你用 fbinst，要么你用 bootmgr 作为第一启动。


---------

你的 avldr 之所以在 FAT32 上失败，我怀疑，也正是因为它在 CHS 上搞错了。而 avldr 在 NTFS 上成功的情况，则也是因为在 CHS 上“弄对了”。只要 BIOS 的 CHS 是 “混乱不堪”的，没有一个软件能够正确应对（fbinst除外，只有采用与 fbinst 等价的技术，才能突破这个障碍）。无论是 avldr，还是 grldr.mbr 都不行。可以肯定地说，syslinux 等其他软件也都不行，甚至连微软的也包括在内，也都不行，它们都不能应付如此复杂的 USB 环境。大家早就用实践“证明”了，没有一个万能的启动软件。fbinst 之所以也不是万能的，是因为 BIOS “封杀”它，不让它接管控制。否则的话，fbinst 将是不折不扣的“万能启动”。

[ 本帖最后由 不点 于 2011-9-15 08:24 编辑 ]