GRUB4DOS for UEFI

liuzhaoyzz

2011yaya2007777 发表于 2020-10-30 07:14
2011cwj6958:  你的汉字字库缺少英文字母及数字。BIOS版本自带这些字符。花屏是由于显示模式设置不对。图片 ...

虚拟机和实体机都试了下，不能正常显示菜单，menu.lst好像不能放在(ESP)\EFI\boot目录下，与bootx64.efi同目录也不行。放在ESP分区根目录下，menu.lst无论用utf-8还是ansi编码都不行。截图如下：（昨天论坛上不了，测试了很多次）

menu.lst内容：
timeout 5
default 0
graphicsmode -1 800
graphicsmode -1 640:800 480:600 24:32 || graphicsmode -1 -1 -1 24:32
#find --ignore-floppies --set-root /boot/grub/FONT_CN6500.GZ
#font /boot/grub/FONT_CN6500.GZ
font /grub/unifont.hex.gz
#splashimage /grub/lt.jpg
color normal=0x55ffff highlight=0xff00ff helptext=0xffff55 standard=0x55ffff border=0xaaaaaa
setmenu --box x=4 w=60 y=6 h=9 l=2
setmenu --keyhelp=1 --lang=zh
setmenu --auto-num-on
setmenu --keyhelp=1=0x66ff00
setmenu --string=m=2=0x0000000000ffff="G4D维护菜单"
setmenu --string=s=1=0x8800000000ffff="date&time=yyyy-MM-dd  HH:mm:ss"
setmenu --timeout=90=2=0x88000000ffff
setmenu --hotkey -A [F4] commandline

iftitle [find /EFI/Microsoft/Boot/bootmgfw.efi] /EFI/Microsoft/Boot/bootmgfw.efi
chainloader /EFI/Microsoft/Boot/bootmgfw.efi

title /boot/imgs/SXWIN10PEX64_17763_NET20200902.iso
map --mem /boot/imgs/SXWIN10PEX64_17763_NET20200902.iso (cd0)
chainloader (cd0)

title ^Ctrl+d commandline
commandline

title [F3] reboot
reboot

title halt
halt

选择map --mem /boot/imgs/SXWIN10PEX64_17763_NET20200902.iso (cd)这个菜单后，屏幕只有一个光标，似乎卡死了。

liuzhaoyzz

2011yaya2007777 发表于 2020-10-30 11:22
/menu.lst
/grub/menu.lst
/boot/grub/menu.lst

在你昨天57楼和81楼回这个帖子之前，我摸索了好久了。后来我放到根目录下才找到的。而且menu.lst必须要用utf-8编码！这个很关键的问题建议放到一楼。

liuzhaoyzz

xbmc 发表于 2020-10-30 11:28
用纯文本模式是没有问题的。
map 测试 ok.
chainloader 测试 ok.

请上传个unifont.hex我测试下，我用grub4dos的那个unifont.hex不行啊？难道是用grub2的unifont.pf2文件吗？


我刚才注释掉了graphicsmode -1 800这一个语句，可以显示文本菜单了，但是map --mem /boot/imgs/SXWIN10PEX64_17763_NET20200902.iso (cd)加载到内存之后又一次加载到内存，反复如此，无法进入PE。

liuzhaoyzz

2011yaya2007777 发表于 2020-10-30 11:48
就是grub4dos的那个呀

注释掉了graphicsmode -1 800这一个语句，很艰难地进入PE了，原来菜单写的不对！
yaya能否给个demo，把menu.lst，目录结构，字体什么的打包传上来，这些全靠用户自己摸索，太难了！

title /boot/imgs/SXWIN10PEX64_17763_NET20200902.iso
find --set-root /boot/imgs/SXWIN10PEX64_17763_NET20200902.iso
map --mem /boot/imgs/SXWIN10PEX64_17763_NET20200902.iso (cd0)
chainloader (cd0)

GRUB4EFI - GRUB4DOS -
这个帖子里面给的菜单根本就是错的，不能用！
title z.iso
map /z.iso (cd)
chainloader

liuzhaoyzz

不才 发表于 2020-10-30 13:50
嘿嘿，看来超版对于g4d还是不熟悉呀。
自2011年12月开始，g4d只要开启了VBE模式，菜单文件必须采用utf-8 ...

        我知道g4d用中文+vbe模式需要menu.lst用utf-8的编码啊。

现在是grub4dos-uefi，我试了utf-8编码显示不出来，然后我就用ansi编码进行了尝试，结果也不行。

换用了yaya在91楼分享的unifont.hex，用vbe模式可以正常显示并启动pe.iso了。之前我用了我电脑里面保存的unifont.hex不行，可能是精简版本的。

liuzhaoyzz

xbmc 发表于 2020-10-30 12:18
怎么两个--mem?
还有 --mem应该没用。
我用的命令是

        正式的菜单里面是只有一个--mem，下面是编辑的时候笔误了。

liuzhaoyzz

wintoflash 发表于 2020-10-30 14:18
uefi下不存在vbe模式。
建议统一一下术语，叫 gfx模式吧

        我们业余人士也搞不懂那么专业的术语，大神们说叫什么就叫什么吧。

@yaya，反馈个问题，前面wintoflash大神也曾经反馈过的。
在虚拟机的虚拟光驱里面挂载个pe1.iso镜像，然后uefi设置本地硬盘优先于光驱启动，引导文件就是grub4dos-uefi那个bootx64.efi，菜单如下：
title /boot/imgs/SXWIN10PEX64_17763_NET20200902.iso
find --set-root /boot/imgs/SXWIN10PEX64_17763_NET20200902.iso
map --mem /boot/imgs/SXWIN10PEX64_17763_NET20200902.iso (cd0)
chainloader (cd0)
结果引导的不是这个仿真出来的(cd0)，似乎是虚拟光驱里面挂载的那个pe1.iso，但是有加载到(cd0)的xxxMB的进度。
类似的问题，wintoflash大神在修改grub2的时候曾经碰到过类似的问题，参见152楼,163楼,166楼,303楼已解决，我们也曾经反馈过，这个问题可以稳定重现。
至于原因，wintoflash分析过也提出过改进的办法，主要就是微软的bootmgfw.efi只能支持第一个光驱启动。

liuzhaoyzz

blank007 发表于 2020-10-30 15:56
建议：菜单文件默认在 \efi\grub\ 下，文件名：grub.txt

       其实我一直在想能否和BIOS下的grub4dos共用一套菜单，比如MBR磁盘，根目录下有一个menu.lst，BIOS/UEFI可以共用一套菜单即可。这样子的话，BIOS/UEFI下默认的查找路径都是相同的，menu.lst太多的话，会把人搞晕的。

liuzhaoyzz

2011yaya2007777 发表于 2020-10-30 16:49
UEFI规范好像没有规定菜单放在哪里吧。我觉得当务之急是完善启动任意磁盘（光盘）、启动任意分区的efi文件 ...

确实应该先完善基础的部分，比如启动efi文件。

关于UEFI规范，不同的efi和不同厂商我们当初也讨论过，感觉对于菜单的存放位置，UEFI规范并没有很明确地指明。15楼：http://bbs.wuyou.net/forum.php?m ... 7010&fromuid=298214

我个人更加倾向于grub4dos UEFI版本和BIOS版本采用相同的菜单存放位置，这样子一个菜单就足够了。

另外想问下，grub4dos UEFI版本里面，color语句数值都是6位的hex值，
color normal=0x55ffff highlight=0xff00ff helptext=0xffff55 standard=0x55ffff border=0xaaaaaa

grub4dos BIOS版本，color数值好像是2位的hex值，有区别吗？我试了2位的数值也可以。比如：
color normal=0x07 highlight=0xF1 helptext=0x07 heading=0x02 standard=0x07 border=0x09
这个color语句用于grub4dos UEFI版显示也正常。


感觉一般的命令，grub4dos UEFI版本和BIOS版本大部分是通用的，涉及到内存位置调用可能不同。        

liuzhaoyzz

l3429900 发表于 2020-11-1 22:40
建议efi下menu.lst改成menu.efi，新增的配置都以efi结尾，区别易懂

        efi是UEFI下面的可启动程序，用这个作为扩展名显然不合适！

liuzhaoyzz

wintoflash 发表于 2020-11-1 22:06
部分论坛上的朋友和reboot.pro那边的一些网友，想启动 RamOS 的 VHD。
但是目前的 Windows 驱动，比如 SVB ...

        如果UEFI下面能够实现map --mem xxx.vhd或者map xxx.vdf并启动，那UEFI-RAMOS就非常有意思，有前景了！现在wintoflash修改的grub2-UEFI可以实现的是map --mem xxx.vhd到内存，但是windows不认识这个磁盘，所以无法启动，已经迈出了第一步。

liuzhaoyzz

2011yaya2007777 发表于 2020-11-2 11:04
bios 版本就可以实现上述功能。测试了一下，uefi 版本同样可以实现。
vdf静态：map xxx.vdf (hd)
vdf动 ...

        UEFI下面，map xxx.vdf (hd0)这个的确可以实现，主要问题是实现之后，windows无法从这个(hd0)上面继续启动，windows不认识这个磁盘，无法继续启动，卡在BCD那里出错了，错误代码忘记了，原因不明。

liuzhaoyzz

2011yaya2007777 发表于 2020-11-2 13:48
那增加--mem加载到内存，windows认识吗？

也不认识啊。

liuzhaoyzz

wintoflash 发表于 2020-11-2 19:18
试了一下，通过UEFI环境变量传递内存盘地址是可行的。
如图，我写了个小程序，在windows下获取grub2创建 ...

        我对底层的东西完全不懂，对于UEFI-RAMOS领域，需要的是懂得操作系统启动流程的大神们继续研究才行，现在的思路和原理似乎有两个：
1、grub4dos_UEFI或者grub2_UEFI的map --mem xxx.vdf (hd0)加载vdf到内存，配合UEFI下的内存盘驱动，让windows识别这个内存盘，并从这个内存盘上面启动。这个启动流程类似于grub4dos的map --mem+firadisk/winvblock/subus磁盘仿真启动。这个需要人写驱动，估计需要很深的驱动开发、操作系统底层开发功底才行，这类人才估计也很少，这条路走下去有一定的难度，而且驱动速度的优化和提升可能还有很长的路要走。
2、grub4dos_UEFI或者grub2_UEFI的map xxx.vdf (hd0)加载vdf到虚拟磁盘C:盘，windows从这个虚拟磁盘C:盘接着启动，加载内存盘驱动，比如primo驱动，由primo驱动把xxx.vdf加载到内存盘比如R:盘，这个xxx.vdf里面互换了C:盘和R:盘的mounteddevice，windows可以从这个内存盘C:盘继续启动，这个primo驱动是现成的，速度很快。这条路的问题是第一步grub4dos_UEFI或者grub2_UEFI的map xxx.vdf (hd0)加载vdf到虚拟磁盘C:盘，windows不认识这个虚拟磁盘C:盘，在BCD那里卡住了，后面的启动流程无法继续，这个仍然需要有懂得操作系统启动流程、对于RAMOS启动原理理解的大神做进一步的研究。

这两条路的区别是，第1个方案内存盘是由grub4dos/grub2创建的，而第2个方案内存盘则是由primo驱动创建的，相比较来说，第2条路似乎更有前景，因为驱动已经有了，万事俱备只欠东风，东风就是让windows识别grub4dos_UEFI或者grub2_UEFI的map xxx.vdf (hd0)仿真出来的虚拟磁盘，正常引导BCD。

为什么BIOS下面，grub4dos的map xxx.vdf (hd0)，搭配内置了primo驱动的xxx.vdf，windows的bootmgr就能够正常识别这个(hd0)并继续启动BCD，而UEFI下面bootmgfw.efi就不能正常识别这个(hd0)并继续启动BCD？这个谜底如果被破解，那就很有玩头了。

BIOS下面grub4dos加载vdf的启动菜单是这样子的：
default 0
timeout 0
title vdf/SX100624
find --set-root /vdf/SX100624/D-RAMOS-2020-0915-15521.vdf
map --read-only /vdf/SX100624/D-RAMOS-2020-0915-15521.vdf (hd0)
map (hd0) (hd1)
map --hook
chainloader (hd0,0)/bootmgr

比较下UEFI下面，似乎没有实现磁盘映射map (hd0) (hd1)的功能？但是我试了，不要这一句map (hd0) (hd1)，RAMOS也能够正常启动，不明白这一句作用倒底是什么。

liuzhaoyzz

虎大（2012wuzhong）曾经探索过UEFI-RAMOS，好像是0xc00000e错误。
uefi单镜像p驱ramos关键性突破 - RAMOS - 无忧启动论坛 - Powered by Discuz! http://bbs.wuyou.net/forum.php?mod=viewthread&tid=411965

UEFI-RAMOS是一个系统工程，需要很多懂得相关知识的人才和大神齐心协力才能成事，包括引导器层面、驱动层面、操作系统底层等等。

liuzhaoyzz

sunsea 发表于 2020-11-3 11:54
如果已经UEFI下做到了，那就非常好，我们只需要接着搞磁盘驱动那一层了——我觉得修改SVBus使其能够从UEF ...

SVbus是开源的，如果你能够修改直接修改源代码，编译即可，不需要hack吧。

目前只要确定bootmgfw.efi能够正确从g4d uefi中map的磁盘里正确读取bcd，SYSTEM等几个文件，那么剩下的事情非常简单，但是考虑到map还分非mem和mem，那么imdisk可能会比较麻烦，还是SVBus比较好，只需要hack一下获取map信息的方式就好了……

确实这一块是比较难的，bootmgfw.efi都是黑盒子。

签名问题应该可以通过bcd设置解决。

驱动签名问题不难，有驱动签名工具，论坛里就有分享的，对于WIN10的话，用的BCD方案解决肯定不合适。

liuzhaoyzz

sunsea 发表于 2020-11-3 14:11
说的就是直接改源码。有时间我去看看M$有没有在核心模式下读UEFI环境变量的。然后请yaya设计一下信息传 ...

        答主厉害啊！静候佳音了！

liuzhaoyzz

sunsea 发表于 2020-11-3 14:21
有个小小的问题，ExGetFirmwareEnvironmentVariable这个核心API只在Win8和以后有，也就意味着win7不受支 ...

1、对于早点的电脑，一般地可以支持LEGACY BIOS启动，制作XP、WIN7系统的RAMOS制作肯定没问题。
2、对于较新电脑的电脑，很多都是支持安装WIN8 10的，随着微软的垄断与强推，新硬件对于WIN7的支持越来越差，驱动越来越难找，上WIN10基本上是没有选择的选择。
所以无论从哪个方面来说，能实现UEFI下WIN8、WIN10-RAMOS就不错了。

liuzhaoyzz

2011yaya2007777 发表于 2020-10-29 19:09
/menu.lst
/grub/menu.lst
/boot/grub/menu.lst

1、反馈个问题，yaya在57楼和81楼说的菜单搜索顺序似乎不对，优先级似乎是：
/boot/grub/menu.lst
/grub/menu.lst
/menu.lst
因为我这几个目录都有menu.lst文件，在测试字体文件unifont.hex的时候发现，只要/boot/grub/menu.lst菜单不对，就无法正确加载字体，导致启动失败，即必须优先修改/boot/grub/menu.lst才行。请yaya检查下。
这有点不符合逻辑，逻辑上应该从根目录到子目录：
/menu.lst
/grub/menu.lst
/boot/grub/menu.lst


2、另外我有个疑问，为什么图形模式下，连基本的26个英文字母和阿拉伯数字都不能正常显示，还需要字体unifont.hex的支持？按道理上来说不应该啊！前面也有网友也碰到类似的问题，都是因为字体文件导致的。

liuzhaoyzz

2011yaya2007777 发表于 2020-11-4 10:58
原先就这样。菜单可以放在这3个地址，没有考虑顺序问题。如果你3个地址都放置了菜单，那就有个顺序问题 ...

BIOS下的grub4dos，菜单优先级的确是：
/menu.lst
/boot/grub/menu.lst
/grub/menu.lst
优先搜索的是根目录，找到的也是根目录下的menu.lst。

但是UEFI下的菜单搜索顺序真的不同，我在实体机和虚拟机都测试过了。
        

liuzhaoyzz

wuwuzz 发表于 2020-11-4 19:40
首先，向yaya、wintoflash的伟大工作致敬！

其次，补充汇报map iso的问题。

        grub2下面wintoflash添加map -x (cd?)命令之后，我虚拟机测试过挂载个光驱map --mem pe.iso启动可以成功，实体机现在有光驱的很少了，有光驱也不会在里面放一张光盘影响启动，所以实体机我没有测试过，应该没问题，我只是本着求真务实的目的在虚拟机进行了几次测试。量产优盘我也没有尝试过，你说的map -x (hd?)也不能解决，怎么之前没见你在grub2的那个帖子反馈过？有反馈wintoflash才能做针对性地改进啊！

liuzhaoyzz

wuwuzz 发表于 2020-11-5 10:47
哈，原因很简单，巧合。要不是L版你，事情还进展不到测试map -x呢，
我之前压根就不知道新增了这个选项。
...

       哦，原来是这样子的。但是改造iso解决的办法，不是根本解决问题之道。还是从引导器层面解决更好，不然还要规避这样子的问题，比如就有人有真实光驱。

liuzhaoyzz

2011yaya2007777 发表于 2020-11-5 15:02
菜单在光盘上，还是在引导软盘镜像上？应当在光盘上。

麻烦你再试一试这个。

       怎么这个版本，连普通的pe.iso都启动不了了？

liuzhaoyzz

2011yaya2007777 发表于 2020-11-5 16:33
我实机测试正常。请增加 debug 3测试后截图。

忘了上图了。虚拟机只有一个GPT分区的虚拟硬盘，(hd0,0)是ESP分区，(hd0,1)是第二个NTFS主分区。(0xa0)应该是挂载了WEPE.ISO的光驱。

liuzhaoyzz

2011yaya2007777 发表于 2020-11-5 17:04
你的光盘启动镜像是硬盘模式？怎么那么大，一个是 0x18d2d， 一个是 0x36b0b 扇区？
按光盘规范，视乎尺寸 ...

虚拟机里面挂载的光驱是微PE2.0X64，196MB。还有个仿真出来的光盘是438MB。
其他的我不懂

liuzhaoyzz

2011yaya2007777 发表于 2020-11-5 20:02
这个PE2.0X64比较小，如果不能启动这个盘，可否压缩发上来?

https://cloud.189.cn/t/6VvmQvV3EFvy
微PE2.0
在虚拟机里面随便挂载一个PE都可以测试啊。
本地硬盘设置优先引导PE1.ISO，虚拟机里面挂载另一个wepe2.0.iso，就能重现问题。

liuzhaoyzz

2011yaya2007777 发表于 2020-11-5 21:15
问题找到了。是启动光盘制作不规范。请问，是所以什么软件制作的？

      不知道微PE打包ISO用的是什么软件。  

liuzhaoyzz

yizhen 发表于 2020-11-5 13:23
我刚初学，请教各位大佬前辈，怎么启动启动 bootmgfw.efi 文件，然后启动装好的系统，谢谢呀
chainloader  ...

title /EFI/Microsoft/Boot/bootmgfw.efi
find --set-root /EFI/Microsoft/Boot/bootmgfw.efi
chainloader /EFI/Microsoft/Boot/bootmgfw.efi

liuzhaoyzz

2011yaya2007777 发表于 2020-11-6 16:04
麻烦你在简单的，复杂的环境测试一下，我这里可以从众多 cdrom 中选择任意一个引导。

现在除了可以启 ...

还是不行啊。
title /boot/imgs/SXWIN10PEX64_17763_NET20200902.iso
find --set-root /boot/imgs/SXWIN10PEX64_17763_NET20200902.iso
map --mem /boot/imgs/SXWIN10PEX64_17763_NET20200902.iso (cd0)
chainloader (cd0)

liuzhaoyzz

2011yaya2007777 发表于 2020-11-6 16:59
liuzhaoyzz：你已经有了一个光盘 0xa0，它就是 cd0，你不能再虚拟一个光盘也是 cd0。

不对呀，我试过了map到(0xff)也不行啊？