GRUB4DOS更新建议、bug反馈专帖

zxw

grldr.mbr有内置菜单？从来就没有。

dihuo0

唉！我犯了经验主义的错误。今天我修改了wee的内置菜单，又想改改grldr.mbr的内置菜单，结果发现是乱码。

hhh333

如果UD启动转可见区的含内置菜单的grldr，(bd)会是什么？假设内置菜单中不执行set root。近期就碰到一个问题

cat --length=0 /BOOT/GRUB/U16HZ || find --set-root /BOOT/GRUB/U16HZ && command --set-path=()/BOOT/GRUB/
UNIFONT /BOOT/GRUB/U16HZ

这个UNIFONT会执行失败！

后看了一个，这个时候当前盘是可见区hd0,0，而command 的path 是(bd)/boot/grub，再看(bd)实际上＝(ud)，而我的ud中只有一个grldr 和ldlinux.bin，显然会因为找不到unifont而出错！

不是说(bd)总是menu.lst菜单所在的设备，如果内置的，就是被调用的grldr所在的设备吗？bd究竟在什么情况下被改变，要么最好是不改变，最先的bd是什么就是什么，这个更有用！如果bd总是变化的话，那设bd真的没什么用。

上面红色字描述的显然是错误的！

Yonsm

我在这里反馈了一个问题，不知道是不是BUG还是我没做对：http://bbs.wuyou.net/forum.php?m ... &extra=page%3D1

chenall

configfile (hd0,0)/boot/menu.lst

这时bd=(hd0,0)

使用ud启动时内置菜单  bd=(ud)
如果从ud启动之后再转(hd0,0)启动,这是因为ud设备还是有存在的,
如果内置菜单的话bd=(ud)..

因为当初写代码是我只是简单的判断了一下如果(ud)设备存在就认为是从ud启动的.

这一句也许应该这样理解
不是说(bd)总是menu.lst菜单所在的设备，如果内置的，就是被调用的grldr所在的设备

bd boot drive 即启动设备.

一般是指第一启动设备,使用configfile 会改变启动设备.

当然了前面关于从fbinst启动GRLDR,再加载另一个GRLDR,可以算是一个BUG吧.也可以不算是BUG.因为ud和可见区其实是同一个磁盘.

[ 本帖最后由 chenall 于 2011-9-26 17:55 编辑 ]

2011c0

如果grub4dos的menu.lst里某个title项，不记得加boot命令，那么该项就无法在启动时的菜单里选中。这个设定还是觉得不好。还有grub4dos是如何让它无法选中的。

hhh333

设置(bd)的作用是什么？它应该就代表第一次执行grldr时的启动设备，也即相对grldr来说的一启设备，这不是挺好的吗？为什么又要让它随着configfile而变化，这个变化可以说是毫无意义的，因为已经有（）代表当前设备了，何不就让它代表grldr的一启呢？最初设定后只要在它的生命期内总是不变。

不点

configfile 启动一个新的 menu.lst， 相当于一个新的 grub4dos 启动了。启动的设备设置为 menu.lst 所在的设备。也就是说，(bd) 要随之改变。与 menu.lst 处于同一目录的 default 文件（如果存在的话），也要起作用了，它保存的是默认的菜单项的序号。

没有规矩不成方圆。这是以前形成的规范，不是说想改就能改的。

chenall

新版本已经编译上传.
修正了Yonsm报告的问题
http://bbs.wuyou.net/forum.php?m ... &extra=page%3D1

建议更新..

Yonsm

发个建议贴（另外的帖子中提出过）：


我想象中理想的 RAM OS 启动方式应该是, mem 和 img 混合的模式：

1. map --mem --top 一个 IMG，但增加一个参数，--delayRead，即不要立即把所有的文件装载到内存中；但分配好内存空间。

2. 分配好一个专有的标识区域，大小为（mem_drive_sector_size /8 个字节），标识区域清零。
  （1G的内存盘，共0x200000个扇区，即需要0x200000个位来保存读取状态，换成换字节为0x40000，即1G的内存盘，只有256K内存就能报保存这些是否读取的标志了）

3. 增加一个内存磁盘读取的 hook，在读取内存磁盘的时候，如果在专有的标识区域中发现某个sector没有装载过，则先从 img 中读取相应的数据。
（这里只hook mem drive read，write不hook，完全按照传统的memdrive即可）

4. boot 的时候从memdrive启动，基于2+3的功能，IMG文件不会全部装载，而是按需读取并缓存到了RAM DISK中。这时候需要读取的文件实际上是一部分的，不会读取整个 IMG 的所有内容，所以相对于完整装载img会快很多。

chenlall 和 不点 能否八一八这个方案有没有可行性？或者有没有现成的能达到目的的、类似的方案（RAM OS+按需装载）？

hhh333

我还是坚持我的观点，前面已经报告了，菜单执行到哪里，(bd)就在哪里的理解也是不对的，内置菜单，当然也是菜单，而事实上只是configfile到哪里，(bd)才到哪里，这个(bd)只能随外置菜单走，似乎不太好说通，我不知道当初设置(bd)是用来干什么的。既然有时候变，有时候不变，那么在什么情况下会用到它呢，我真的想不出来。建议还是代表grldr的一启，更有用。我好象也没有看到谁用这个不确实的(bd)设备，因为多数情况下会用()这个当前设备。

hhh333

另外，我测试了一下，g4d启动后，如果没有改变命令的path缺省的是(bd)/BOOT/GRUB，如果发一个命令command --set-path=/BOOT/GRUB/，再查看确实变了，没有了前面的(bd)，按我们的理解应该是与command --set-path=()/BOOT/GRUB/等效的。然而却不是的，一般习惯是当前目录是省略的。

dihuo0

command --set-path=/BOOT/GRUB/
执行之后，变量path=/BOOT/GRUB/，是与%@root%/boot/grub/等效的，不是与()/boot/grub/等效。
这时path将随着root的变化而变化，一般不这么写，写成command --set-path=()/BOOT/GRUB/更好些。

[ 本帖最后由 dihuo0 于 2011-9-28 19:25 编辑 ]

pseudo

(bd)跟当前设备是两个概念。两个概念都需要，都有用，也已经各有比较明确定义和变化规则。
要支持h兄的需求，需要引入第三个概念而不是改变已有概念。

dihuo0

回复 #1299 chenall 的帖子
我觉得这是一个bug，如果(ud)区和可见区()都有grldr，从(ud)启动后在启动可见区()的grldr，这时应该是(bd)=()，而不是(bd)=(ud)，这不太合理，不符合人们的自觉。

回复 #1305 hhh333 的帖子
这是一个bug，修正这个bug就可以了，没必要改变(bd)的含义，那样动作太大，会带来不兼容的，而且如果固定为一启，引进(bd)设备的意义也就大打折扣了。

(bd)的含义可以这么理解，如果菜单是内置的，那么被调用的grldr所在的设备就是内置菜单所在的设备。

[ 本帖最后由 dihuo0 于 2011-9-28 20:16 编辑 ]

chenall

虽然说是BUG,但没有办法解决,只能修改FBINST.

当时没有考虑都那么多情况,只是为了方便所以才改的.

我看还是恢复原样好了,下个版本的GRUB4DOS将不在处理fb的启动设备...

即启动后.内置菜单
bd=root=可见区

zxw

启动后.内置菜单
bd=root=可见区
=========================
这样改不是很好，有时需要判断是否从ud盘启动就麻烦了。

[ 本帖最后由 zxw 于 2011-9-29 09:09 编辑 ]

chenall

我考虑了一下,还是觉得改一下比较好

如前面贴子所说,目前也没有办法判断是否真的从(fb)启动的.

tingyue-wu

改了之后bd=可见区，那么下面的
ud内置菜单的写法应该就不行了吧。
debug off
default 3
root (bd)
unifont --unload
checkrange 0x80 read 0x8280 && set bd=hd
checkrange 0x0 read 0x8280 && set bd=fd
checkrange 0x9f:0xff read 0x8280 && set bd=cd
checkrange 0x21 read 0x8280 && set bd=pd
checkrange 0x23 read 0x8280 && set bd=ud
gfxmenu ()/BOOT/GRUB/MESSAGE || find --set-root /BOOT/GRUB/MESSAGE && gfxmenu ()/BOOT/GRUB/MESSAGE
configfile (md)4+8

改成这样怎么样？
debug off
default 3
unifont --unload
checkrange 0x80 read 0x8280 && set bd=hd
checkrange 0x0 read 0x8280 && set bd=fd
checkrange 0x9f:0xff read 0x8280 && set bd=cd
checkrange 0x21 read 0x8280 && set bd=pd
checkrange 0x23 read 0x8280 && set bd=ud
root (%bd%)
gfxmenu ()/BOOT/GRUB/MESSAGE || find --set-root /BOOT/GRUB/MESSAGE && gfxmenu ()/BOOT/GRUB/MESSAGE
configfile (md)4+8

hhh333

让bd总不变，判断是什么启动设备就简单了，一个菜单经常需要判断它的启动源，如从光盘启动与从硬盘启动，调用的命令是不一样的，因为文件系统就不一样；linux没了办法，干脆用iso/sys/pxelinux来做，把这个事情交给用户，你是什么启动设备就用相应的命令。我们为什么推崇g4d，就是因为用一个grldr解决了所有问题，无论是光盘U盘硬盘还是PXE盘，都可以用grldr来引导，这个自然就会出现需要判断启动源的功能，因此我也一直主张要么(bd)总不变，要么干脆内置一个系统级的变量跟@root一样的，@bd变量，什么checkrange 0x0 read 0x8280 && set bd=fd　　checkrange 0x9f:0xff read 0x8280 && set bd=cd……都不需要了，就来一个if "%@bd%"=="cd" 看起来也直观，可读性也比以前强n倍，毕竟我们这些人都不是专业的程序员，内部的事情由g4d的开发者处理，现在可好，好多事情由用户来做，我要读懂这个“checkrange 0x21 read 0x8280 && set bd=pd”，我必须知道0x8280的值代表什么，0x21代表什么，也许如果chenall老大如果几个月不碰这个，自己也得翻文档吧。在我的心目中grldr应该是最强大的装载器，期望也很高，希望它不只是高手写复杂程序菜单或批处理的利器，也是我们普通使用者最易上手最高效的启动工具。我前面还提到了条件菜单的事情，我觉得这都是使用时最易碰到的事情……请不点和chenall二位能慎重地考虑！

    不知pseudo zhaohj zxw...等g4d的应用高手怎么看？我只是作为一个普通的使用者提一点普通使用者使用g4d时的一些感受，我想各位老大，是不是也到了考虑照顾一下普通使用者的时候了？

    希望能够有好消息！

dihuo0

这是以前形成的规范，不是说想改就能改的，可能会破坏已有的代码，带来不兼容问题。是否需要改，怎么改，这些需要讨论。

现在开发人员这么少，新功能未必能够及时的加入到内核中，也未必适合加入到内核。

我有一个想法，开发一个“函数库”，把这些高级功能封装起来，屏蔽内核的一些变化，给用户提供一个易学易用的形式。当grub4dos升级时，“函数库”随之升级，而批处理可以基本保持不变。

不点

太依赖 bd 是你的错。

本来 bd 就不值得依赖。

设想，当你从 dos 启动 grub 的时候，bd 是什么？当经由 syslinux 启动 grub 的时候，bd 又是什么？当经由 fbinst 启动 grub 的时候，bd 又是什么？当经由 wee 来启动 grub 的时候，bd 又是什么？

基本上说，都是不存在的，或者说，很难确定的。就算确定了，意义也不大。

grub4dos 本身被启动的多重启动方式，必然淡化某一种 “确定” 的思维方式。正如物理学中的 “不确定性” 一样。

不要把自己的思维 “固化”。

hhh333

不点可能总是从如何实现上考虑，我们多是从应用需求上去考虑，思维也许有点固化，既然有bd这个概念，就要尽是让它清晰，而不是因为一些不确定因素而废弃。bd提出来总是要它派上用场的不是？

不点

错。

bd 不是 “提出来” 的，而是 “遗留” 的。

GNU GRUB 存在一个 “安装” 的问题，它只安装在一个分区，安装的时候，要填写启动的分区。这个启动分区，就是现在所称的 bd。

由于 gnu grub 采用 stage2，所以，安装 stage2 的时候，也修改 stage2 的头部，把启动分区也 “固化”。

grub4dos 已经废除了这个启动逻辑。采用的是动态启动策略。没有固定的启动分区。所以，那个 bd 的性质已经变了，作用也不重要了。只有在引导 GRLDR 的时候，才有确定的 bd。如果通盘来考虑，bd 是没有意义的。前面举例说明的情况，就是如此。

而且，bd 是可以控制的，意思是，可以改变的。用户只要通过 configfile 命令，就可以改变 bd。这本来是灵活性的一个表现，而在你看来，反而是不方便了。

如果你非要让 bd 固定，也有你自己的变通办法。你可以备份 bd（比如备份到某个内存变量），随时就可以找到 bd 在哪里。

而你要求改变 configfile 的逻辑，让 configfile 不再改变 bd，那是制造不兼容。

这下子你该明白了吧？

zhaohj

@hhh333:
      你提出的问题，我以前同样也提出过，这是在引入变量之前。如configfile、(bd)等问题，在SRSF6返回模块DOS版本中，grldr->io.sys（DOS）->grub.exe尤为明显。
    后来引入了变量及setlocal、endlocal，configfile的问题（改变了(bd)及()设备），解决就变得简单了。
    我们也可以理解，(bd)很早就有的，为了保存兼容性，不可能做很大的改变，既然这样，就用现有的功能也是可以解决的。在SRSF6返回模块（菜单版）中有很多configfile，最新版就是通过setlocal、endlocal解决(bd)问题的。
------------
      开发者与使用者考虑问题的角度可能有些不一样，但兼容性与实用性要做到完全统一是不可能的。(bd)按照理论，就是启动设备，但我们（使用者）可能需要更进一步，想知道“是什么启动设备？”。理论都有了，怎样实践也有了，慢慢的也会变得局部统一。

不点

正如 pseudo 所说，hhh333 需要的是另外一个功能（新功能），而不是改变现有的功能。

改变现有功能的结果，就是制造不兼容。这点很明显，不用多说。

有关 bd 的问题，属于历史遗留问题。

grub4dos 在最初的时候，只有 grub.exe，而没有 grldr。那时候，grub.exe 运行于 DOS 下，而由于 grub.exe 可以位于任何磁盘上，甚至可以位于 DOS 的 RAMdisk 内存盘上，所以，bd 是不存在的。grub.exe 启动以后，就把 bd 设置为固定的 (hd0,0)，这个分区有可能根本不存在。

因此，grub4dos 从开发之初的那一天起，就没有确定的 bd 。后来使用 find --set-root 确定当前目录。大家在很长一个时期主要也就是使用当前目录，不使用 bd。

bd 是很晚由 chenall 封装的。原来虽然有 bd 这个逻辑概念，但用户无法访问。chenall 把它封装以后，用户也可以访问 bd 了。

大概在 grub.exe 诞生一年以后，出现了 grldr。当从 MBR 启动 GRLDR 时，很幸运地，可以确定 bd。bd 就设定为 grldr 所在的分区。

实际上，这个 bd 是由 MBR 代码确定的。MBR 找到哪个分区的 grldr，就把哪个分区设置为 bd。

在其他启动方式的情况下（例如 grub.exe 运行于 DOS 下），仍旧没有确定的 bd。

当 configfile 命令运行时，要从头开始执行 grub4dos 的代码（代码重用，可以节约代码的编写），相当于执行一个新的 grub，进入一个新的 grub 环境。

新的 grub 运行时，它就要检查 bd 等的设置（这是 GNU GRUB 的启动逻辑，只能按照它的逻辑办事，因为我们是基于它的，否则，修改成自己的逻辑，光是哪个设计就不是很容易的，也许需要 n 多年）。所以，我们运行 configfile，就顺便把 bd 设定为 menu 文件所在的分区。想象一下，本来 bd 是不确定的，现在执行 configfile 之后，bd 变成确定的了。这对于大多数情况的使用来说，是大大方便了。大家在 menu 中无需指定 boot 和 root，直接用 /... 就可以指定与 menu 处于同一分区的文件了。这个逻辑已经被广泛使用了 n 年，有 n 多人都在用。如果要取消这个逻辑，指不定会有多少人要 “骂娘” 呢。

mygamexxx

FBINST启动盘，configfile U盘可见分区的菜单文件后，(bd)是UD区。

不点

原帖由 dihuo0 于 2011-9-28 19:38 发表
回复 #1299 chenall 的帖子
我觉得这是一个bug，如果(ud)区和可见区()都有grldr，从(ud)启动后在启动可见区()的grldr，这时应该是(bd)=()，而不是(bd)=(ud)，这不太合理，不符合人们的自觉。

我认为，启动可见区的 grldr 的时候，应该把 bd 设置为 grldr 所在的分区。这属于 fbinst 的工作。在启动 grldr 之前，应该给 grldr 传递正确的 bd 信息。

这样，grldr 启动以后，会在正确的 bd 下寻找 menu。

不过这个工作可能也是比较费事的。而且弄不好，依然存在 “兼容性” 问题（因为很可能已经有人在使用 fbinst 目前这个 “特性” 了）。

zxw

(bd)=可见区
＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
这样改一下也好，以前要判断finst启动盘被识别为什么设备，总是很麻烦。改成这样应该比较方便判断了。
＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
纠结于(bd)是否稳定，不如转向记录启动之初的当前设备，目前的grub4dos应该比较方便。

fdd_ds

title [ A ] RamOS RamXP_sp3
  find --set-root /RamXP3.vhd
  map --mem --heads=255 --sectors-per-track=63 /RamXP3.vhd (hd0)
  map (hd0) (hd1)
  map --hook
  rootnoverify (hd0)
  chainloader +1
  boot

本机内存4G

RamXP3.vhd大小2,362,442,240 字节，是用“grub4dos-0.4.5b-2011-06-19”和“WinVBlock”安装的XP ，在不加“--mem"情况下，启动正常。加之则不行！

用“grub4dos-0.4.5b-2011-09-28 ”启动，不论“--mem" 加否，均黑屏，出现滚动条后黑屏，无光标，三键重启失效。

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