[20150128]自动列表·自动菜单·数字启动

幸运的草

这个确实是这样子，悬除太大了。
你可以在自动列表窗口输入--set-lab=:.img  数字序号。试试可启动不？

幸运的草

没什么本质的区别，封装版把需要的字库，firadisk.img、run封装在一个文件中，便于管理，但使用时要求内存要大一些，脚本版运行速度会稍快一点（一般没感觉）。看个人喜好了。

幸运的草

脚本对处理.ISO及.IMG或IMA的命令方式不一样，脚本处理有难度。其实用户对特殊的格式需要处理时，可加参数，使脚本知道处理成什么格式。

幸运的草

初步测试正常，自动列表下分别加载后缀为LZMA的IMG及ISO镜像，均能启动成功。

幸运的草

这个问题很好解决，你可以使用不同的目录名，比如，你量产分区中已经有了一个/boot/imgs/目录，那么，在其他分区中不要用这个目录名，你可以任意取一个目录名，比如，/imgs/，或/iso/。那么，需要列表时就run --set-path= /imgs/ /imgs/.input;;或run --set-path=/iso/ /iso/.input.
目录名可以任意，但最好不要有同名。

幸运的草

该RUN是运行在g4d环境下，只要是通过grldr引导的就可以使用。

幸运的草

这个版本测试，调用0PE/BIN正常，调用硬盘上的NTLDR正常。因没有WIN7，启动硬盘WIN7无法测试。

幸运的草

这是正常的，如果没指定路径，默认为/boot/imgs/。每个是指定把RUN做为一个G4D外部命令来执行。

幸运的草

执行命令出错，请确定你的RUN文件是否存在以及是RUN所在的目录是否已经设置默认。

幸运的草

你菜单的02、03、04只有02项不能执行？还是这三个都不能执行吗？
如果是这三个都不能执行，你把#command --set-path=(bd)/BOOT/GRUB/这一句前的＃号去掉看能执行不？如不能执行就可能与这个（bd）有关了。
　根据提示，是找不到RUN，或者你进入命令行，输入find /boot/grub/run 看返回什么结果。

幸运的草

你应该说明你的工具包是装在哪个分区的什么目录下，这个很关键。进入命令行下，用find搜索一下RUN，看返回的结果是什么？就知道你的菜单调用RUN的菜单怎么写了。

幸运的草

有这个问题，是封装版还是脚本版？对了，新版加载IMG，原来老版是默认加--mem参数的，后来有网友提出内存测试类的IMG，加载--mem时不合适，建议去掉--mem参数，后来作者就改成默认不加--mem参数，这样的话，原来的菜单就run /xxx.img就会变成直接从U盘读了，速度会慢，特别对于大IMG来说，在ZIP格式的U盘上会更慢。
  解决办法就是在菜单中加上--mem参数 。run --mem /xxx.img。是不是这个原因？

幸运的草

对zip格式的盘处理，在G4D下是非常麻烦的，因为有部分BIOS会自动虚拟出一个并不存在的fd0，为了对付这种情况，在RUN开头有屏蔽的语句，带来的负作用就是可能影响fd仿真。
to ZXW:
   #1461新上传的RUN，经在qemu中测试，当调用镜像不存在，执行出错后，会出现异常。按键后返回菜单乱码。但仍执行这个出错的菜单，返回就可以正常。可能是第一次返回时内存数据不存在或冲突造成的。

幸运的草

是的，这个调用.iso的菜单中的ISO根本不存在，主要是测试返回机制。
原调用点是如下图，这种现象中在第一次调用时是这样，第二次再调用就没问题了。
调用出错后就是上图，在上第二图中再次调用就可以正常返回了。

幸运的草

问题查明:是测试环境的问题，我是用简易启动测试器启动FBA文件，在自带的虚拟机中测试，出现上述问题。再换用u盘，在VM中测试上述问题不再出现。<br />但返回时--set-menu参数失效。直接返回内置菜单，不能返回自定的菜单。也就是返回的是主菜单而不是调用菜单。

[ 本帖最后由 幸运的草 于 2011-7-7 11:49 编辑 ]

幸运的草

经测试：
    1、原#1461上传的版本与#1469新上传的版本，在加载IMG速度上没什么区别，都是14.89秒钟即不到15秒钟。，测试环境：HDD格式的U盘，BIOS识别为ZIP。即本机无论是HDD还是ZIP，均识别为ZIP。
   2、测试在非主菜单中调用不存在的镜像，对不存在的目录列表，无论调用菜单是否加--set-menu=。均返回主菜单。目录列表按M后返回主菜单。
    结论：出错后,实际返回的是主菜单，而不是调用菜单。用户自定义返回菜单变量在调用失败返回时不起作用。

幸运的草

新版测试出错返回结果，如果有自定义的MENU变量时，返回自定义菜单。如果无自定义变量，返回的是主菜单。
　基本达到预期效果。

幸运的草

分别在vm及实机中测试，结果：1、内置菜单中调用RUN对存在的目录列表，正常情况下，按M返回菜单后，内置的主菜单私乱码。如果在RUN调用ISO.IMG时出错，倒计时三秒后返回主菜单私乱码。
2、如果使用外置菜单，无论是一级或二级，RUN调用ISO,IMG出错倒计时返回，有定义的MENU变量，则返回定义菜单，没有则返回调用菜单。达到设计标准。
3、无论是内置菜单还是外置菜单，只要运行RUN对目录列表，则返回到最后调用的目录列表而不是返回调用菜单。不对目录列表，则外置菜单返回同2，内置菜单返回同1.
      测试环境中使用GFXMENU命令。无加载中文字库。

幸运的草

经测试，达到预期。辛苦了。

[ 本帖最后由 幸运的草 于 2011-7-8 14:44 编辑 ]

幸运的草

量产应该按光盘对待吧，除了绝对路径不同外，其他调用应该没什么不同吧，写为（cd）（bd）应该都行吧。但不能写（ud）

幸运的草

测试新版基本调用，无发现异常，返回时如果有自定义返回则返回定义，如果无，则返回主菜单。只是在自动列表窗口中，自定义返回菜单参数失效，出不知从何时开始失效，记得原来是支持的。

幸运的草

严格的说是RUN找不到文件会返回主菜单或自定义的菜单。而不是启动某文件出错时返回。因为文件启动出错已经超出了RUN的应用范围。

幸运的草

首先你的命令调用有问题。
路径变量参数后面要有空格断句，run --set-path=(hd0,0)/imgs/ .automenu或(hd0,0)/imgs/.automenu

你也可以这样试试。
run /imgs/.automenu
因为（hd0,0）这种绝对路径变数很大，并不通用。如果你的imgs目录不是唯一的，你可以在可见区IMGS目录中用一个特定的文件xxx作为定位文件。使用FIND。
find --set-root /imgs/xxx
run /imgs/.automenu

[ 本帖最后由 幸运的草 于 2011-7-26 09:48 编辑 ]

幸运的草

你是在那里进行测试的，第二句中的(hd0,0)是否是命令行下的返回结果？
find --set-root /imgs/kejian.f
ls /imgs/看有什么提示？

幸运的草

你怎么乱用空格。把.automenu前面的空格去掉就正常了。变量后与路径前要有一个空格，路径及命令中间不能有空格。
run /imgs/.automenu。
run --set-path=/imgs/　/imgs/.automenu
run --set-path=/imgs/  .automenu
以上调用都是正确的。但不能run /imgs/ .automenu
注，空格只要一个就行。为了区分，在例子中多加了一个空格。

[ 本帖最后由 幸运的草 于 2011-7-27 14:04 编辑 ]

幸运的草

你把firadisk.img在ISO目录中放一个，看还有没有这个问题。

幸运的草

如果这也看不懂，那还有什么能看懂的？还是不要太浮躁的好。要想使用得心应手，潜心学习是关键。

幸运的草

不解，启动0PE为什么这样启动？直接RUN　/0PE.ISO就可以了。如果在UD区有MENU.0PE，那么调用这个MENU.0PE就行了。RUN　/boot/grub/menu.0pe。

幸运的草

新版RUN使用了新版G4D的一些新特性，在某些方面处理进行了简化，而老版RUN对于相同处理由于没有新版的这些特性，采用了一些特殊方法，故G4D以后的更新如果引起了BUG，则会造成新版RUN也有BUG。
　最近的多次更新都是测试新版G4D的新特性，功能上没有什么大的更新，所以除非BUG方面，无必要跟进更新RUN。

幸运的草

这个语句用在这里并不合适，因为RUN在调用pemenus.lst时，如果出现找不到该文件而调用失败，RUN自己会自动返回出错处理模块，返回到主菜单或自定义返回菜单。不会自动调用||后的语句。
所以应该这样写：
find --set-root /HYTOOLS/GRUB/MENUS/PEMENUS.LST
command run //HYTOOLS/GRUB/MENUS/PEMENUS.LST