GRUB4DOS更新建议、bug反馈专帖

hhh333

也是，有时还是需要grldr调用改了名的或改了菜单的grldr。
顺便再问一下，这个@boot什么时候能用？

另外，command --set-path=/boot/grub/与command --set-path=()/boot/grub/不等效如何理解？或者干脆改成等效？！

目前，似乎与command --set-path=(bd)/boot/grub/等效，既然有时候bd是不存在的，这么做显然是不明智的，也是不好理解的，一般情况下没有盘只有路径应该认为是当前盘。

[ 本帖最后由 hhh333 于 2011-10-7 07:45 编辑 ]

chenall

/boot/grub 与 ()/boot/grub

在一般情况下是等效的，但是以下情况例外。
指定了root路径比如

root ()/boot/

这时/boot/grub相当于()/boot/boot/grub

()代表当前磁盘根而/是按当前root开始算。

至于(bd)/boot/grub是特指(bd)磁盘的，如果当前盘刚好等于(bd)，就是等效的了。

这个在不修改GRLDR内置菜单，并且使用外置菜单启动的时候会一样

/boot/grub 和 ()/boot/grub 还有(bd)/boot/grub  是属于三个不同的路径，但是在某些情况下这三个的实际路径是一样的。

具体可以去看GRUB4DOS的Readme

chenall

新的版本测试
http://grub4dos-chenall.googleco ... -2011-10-07-test.7z


        1.新增?_Boot变量，访问启动GRUB4DOS的Boot_drive
          add new Variable ?_Boot to access grub4dos Boot_drive.
        2.为了节省代码GRUB4DOS内部不再处理外部命令WENV的兼容性(WENV tuxw版)
        解决办法如下：
          如果需要使用该版本WENV则自己在菜单或批处理中添加以下命令
          write --offset=0x1f8 (md)0x228+1 ?_WENV\0
        3.uuid 命令对于uuid字符的判断不区分大小写。


另外新的版本，初始化变量时只初始化变量表。即只初始化存放变量表的空间（一个扇区）

[ 本帖最后由 chenall 于 2011-10-7 15:25 编辑 ]

zxw

倒，被墙了？无法下载。

[ 本帖最后由 zxw 于 2011-10-7 15:38 编辑 ]

tingyue-wu

可以下载的。你重新试下

是不是这样用
command --set-path=(?_boot)/BOOT/GRUB/

chenall

直接传到论坛上来。。

chenall

?_Boot是一个变量，和其它变量一样使用时直接%?_Boot%就可以了。

注：：：：区分大小写。

sratlf

这么写的话应该是 command --set-path=%?_Boot%/BOOT/GRUB/  注意大小写

zhaohj

几天没来，变化挺大的。
问：?_Boot什么情况下会改变？

chenall

1.启动新的GRLDR，所有的变量都重设了，当然就会改变。
2.直接set ?_Boot=xxx

tingyue-wu

估计调用另一个grldr文件就会变了吧。

zhaohj

呵呵，?_Boot感觉专门为hhh333设计的，不过有这个变量也很不错的。
?_WENV是大写的，?_BOOT还是建议大写，一个变量名大小写混合书写很不方便。另外也与?_WENV统一。
------------
@开头的是grub4dos的内置变量，不区分大小写；
做个记号吧：
@root、@path、@date、@time、@random、@retval
?_WENV、?_BOOT、?_UUID

chenall

?_UUID已经取消，目前的版本只是把?_UUID转换成?_WENV来访问。

%?_WENV%=%?%=%?_UUID%

还在使用?_UUID的请及时更新，建议使用%?%比较简洁。
执行uuid命令后就可以使用%?_WENV%或%?%来得到UUID值。

zxw

启用ud区的grldr呢？未变吧

zhaohj

原帖由 zxw 于 2011-10-7 17:08 发表
启用ud区的grldr呢？未变吧

ud启动，再启动ud区的grldr，虽然经过变量初始化，?_BOOT还是(ud)。要说变也可以，不变也可以。

不过一个grldr再启动另一个grldr，没大必要。
虚拟机测试，grldr再启动grldr一般死机(chainloader --force /grldr)

不点

chainloader 启动 grldr 会死机？

不太可能。

如果有这样的问题，那可是严重 bug。

请确认，未经更改的 grldr 会有这样的问题。测试很简单，启动 grldr 进入命令行，什么乱七八糟的都不要加载，直接 chainloader 它自己。

不点

这个论坛的 bug 已经这么久了，就是不解决：每次到达一个页的整数倍时（比如，最后一个帖子是 1370 时），论坛的帖子序号就混乱了，相差 10。

我发这个垃圾帖子，就是为了 workaround 这个 bug。（这个帖子的序号应该是 1371）

不点

原帖由 chenall 于 2011-10-6 08:10 发表

1.我试了一下，好像是正常的啊，很早的版本就是这样子的，configfile不会改变当前root（这个或许是BUG），很早的时候我就发现了，只是觉得这个是正常的。

   新版的改动
   rd，configfile (rd)+1不改变boot_drive，
   fb,  从fb启动时不会额外处理boot_drive,即恢复原来的样子。
   因为目前没有比较好的办法确定是否从fb启动的，前面的版本只是判断了ud是否存在，处理看起来是正常的，其实有BUG， 从fb启动后，再chainloader 任意一个grldr都不会改变boot_drive,因为(ud)还存在。

2.我试了好像没有问题啊。我没有改动这一部份的内容。

1。 你试试 0.4.4 的版本，看看怎样。如果 0.4.4 就已经有问题了，你再试试 0.4.3。

2。 关于 timeout，肯定有问题，但我也没时间专门找毛病。也许不是直接的 timeout 相关代码的问题，而是由其他问题衍生的问题（这样更是问题）。最近好像暴露出了很多问题。因此，我觉得更不能发布正式版。要在不增加任何功能的情况下，纯粹 bug 的发现和修复很久（半年或者更长），才可以发布正式版。

zhaohj

原帖由 不点 于 2011-10-7 21:33 发表
chainloader 启动 grldr 会死机？

不太可能。

如果有这样的问题，那可是严重 bug。

请确认，未经更改的 grldr 会有这样的问题。测试很简单，启动 grldr 进入命令行，什么乱七八糟的都不要加载，直接 c ...

chainloader 启动 grldr 会死机，这是很久以前的事情了。不过是pxe启动下测试的。
PXE下我测试没有一次成功过。

527104427

原帖由 zhaohj 于 2011-10-7 22:08 发表


chainloader 启动 grldr 会死机，这是很久以前的事情了。不过是pxe启动下测试的。
PXE下我测试没有一次成功过。

哈，，这个问题我也遇到过，我是用grldr做PXE启动，子菜单调用了grldr改名的BIN文件，都会死机，后来就放弃了

不点

这倒是有可能。不过，这样做的理由可不能算是 “充分” 的，chainloader 执行 grldr 是多余的操作，本来用 configfile 或者别的方法一样可以达到目的。

但是，死机还是不对的。这还算是 bug。不过，要解决它，那就得等以后确实有时间再弄了。

hhh333

我终于有点理解了：()/xxx/yyy＝当前盘的根/xxx/yyy
                              /xxx/yyy=当前的root/xxx/yyy=当前目录/xxx/yyy
但还是有疑问，是不是所有的以“/”开头的路径都是这么来理解的？

》》刚才试了ls和cat命令与以上理解不矛盾，不知其他的情况怎么样。DOS中可是以不带“\”开头的路径作相对路径的，grub4dos与之有出入，是不是与linux的用法是一致的？

hhh333

原帖由 zhaohj 于 2011-10-7 16:50 发表
呵呵，?_Boot感觉专门为hhh333设计的，不过有这个变量也很不错的。
?_WENV是大写的，?_BOOT还是建议大写，一个变量名大小写混合书写很不方便。另外也与?_WENV统一。
------------
@开头的是grub4dos的内置变 ...

>>>哈哈，chenall还是很给力的！现在要获得启动源，有了这个要方便得多了，不用再写一大堆checkrange之类的命令了！不过这个“?”号开头的变量有什么讲究没有？与用@开头的变量有何区别？我没用过?_WENV，还是不太理解。

zhaohj 老大说得对，如是与?_WENV同一性质还是不要大小写混写，这样很容易出错的。

hhh333

我觉得这个论坛还有个毛病，进最后一页与倒数第二页有时是相同的。

zhaohj

grub4dos中的根目录，可以通过root来重新指定。如：
root (hd0,0)/windows/
ls /                 <------- 显示(hd0,0)/windows/下的文件
ls /system32/   <------- 显示(hd0,0)/windows/system32/下的文件
这里不带()开头分区号的，都是相对root指定而言的。下面带()就不同了：
ls ()/               <------- 显示当前盘根下文件，即(hd0,0)/

相对目录的应用，最早C大的CSPE有应用，但本人建议尽量少用。

chenall

?开头变量属于系统变量，用户可以修改，但一般不建议修改。（只有3个变量空间可用）

另外？开头的变量还有一个特性，SETLOCAL/ENDLOCAL对于?开头的变量无效。即SETLOCA/ENDLOCAL不会处理?开头的变量。

有时候这个就很有用了，像MODBOOT里面就有用到

hhh333

反馈一下?_Boot的情况，其他还好，就是从UD启动时，怎么还是hd0,0，那与bd没有区别了，我现在要检测是否从UD启动还是不能用这个变量，何解？

以前我用find --devices=u来检测是否从UD启动，但听说以后可能不从UD启动也能识别UD，可能这个方法也行不通的了。

我的理解是如果从UD启动，肯定需要grldr放UD内，如果未修改内置菜单，它必定是先在grldr所位于的地方即UD内找menu.lst，在没有找到menu.lst之前，bd和root应该都在ud内，如果UD内有menu.lst，应该就直接执行了，这个时候bd还是在ud中；如果ud内没有menu.lst，这个时候grldr内置菜单中的find起作用，bd和root变到找到的menu.lst。这个是符合逻辑的，如果简单地将从UD启动时的bd和root定义到可见区是不绥的，也是不合逻辑的，因为最先获得控制的grldr是位于UD内的。

感觉这个ud给grldr制造了许多麻烦，也给我们用户带来了很多困惑！但好象又是我现在做U盘启动的首选。

[ 本帖最后由 hhh333 于 2011-10-8 10:51 编辑 ]

chenall

这个是属于FBINST的问题。
FBINST启动UD区的GRLDR时没有传递正确的DL参数过来。

要检测是否从fb启动，只能初次启动的时候检测

如果你启动之后再chainloader另一个GRLDR，这时的检测就不准了。

chenall

前面一直在讨论的就是这个问题，之前的版本由GRUB4DOS内部简单处理，但是造成了其它BUG。

新的版本取消了，不处理。

Plantsoot

能不能给fbinst打个补丁解决传递DL参数的问题，汇编代码像看天书，无从下手。