GRUB4DOS for UEFI

2011yaya2007777 · 发表于 2020-12-23 10:16:44

好的。一直在等待。喜欢g4d的轻量高效。

修改了 G4E 外部命令模板，再测试一下。我这里正常。要使用里边那个 BOOTX64.EFI，是配套的。
另外我想了解一下，以前测试，是不是启动了 GRUB2，然后由 GRUB2 启动的 G4E？

dave496 · 发表于 2020-12-23 10:25:56

给力，支持，很需要这个

liuzhaoyzz · 发表于 2020-12-23 10:39:53

本帖最后由 liuzhaoyzz 于 2020-12-24 08:04 编辑

2011yaya2007777 发表于 2020-12-23 10:16
修改了 G4E 外部命令模板，再测试一下。我这里正常。要使用里边那个 BOOTX64.EFI，是配套的。
另外我想 ...

romex官网已经回复了，primo申请的内存没有连续性要求。他的回复不是很详细，我理解应该是内存不要求连续，可用即可。请问下primo内存盘占用的内存，是否连续？ - Romex Software 中文论坛 [url=请问下primo内存盘占用的内存，是否连续？ - Romex Software 中文论坛 https://forum.romexsoftware.com/zh-cn/viewtopic.php?f=34&t=5165&p=10263#p10263

wintoflash · 发表于 2020-12-23 10:49:07

2011yaya2007777 发表于 2020-12-23 10:16
修改了 G4E 外部命令模板，再测试一下。我这里正常。要使用里边那个 BOOTX64.EFI，是配套的。
另外我想 ...

以前测试，是不是启动了 GRUB2，然后由 GRUB2 启动的 G4E？

我是这样的。

修改了 G4E 外部命令模板，再测试一下。我这里正常。要使用里边那个 BOOTX64.EFI，是配套的。

分别测试了3种情况，都是虚拟机报错。
(1) grub2->grub4dos

(2) uefi shell->grub4dos

(3) 直接固件设置页面启动 grub4dos

2011yaya2007777 · 发表于 2020-12-23 10:54:50

一、svbus搭配g4e/grub2有两种模式

谢谢你，这么详尽的解答，受教了！

1、在直接map模式下，要求被仿真的镜像必须在硬盘上连续存放

G4D早已实现了有碎片的文件直接map。这个理解有误会。

svbus是否支持“碎片”，这个问题感觉问得不对

无论是直接map文件，还是map --mem文件到内存，都是由g4e/grub2这样的引导器所做的，这是对的。
svbus是个磁盘驱动，它获得了G4D映射插槽的信息。当它的上级windows访问磁盘时，它进行了拦截，利用G4D映射插槽的信息，转而调用SCSI指令直接访问磁盘，然后再传回上级。
在这点上，类似于G4D的map仿真。就和grub4dos-0.4.5c一样，只支持文件连续的仿真。它完全可以做到有碎片仿真。
我没有仔细研究，如果它自己又新建了一个仿真盘，而没有使用map --mem的内存盘，那是极大的内存浪费。如果是这样，那就更应当支持碎片仿真了。

我还有一个疑问。就是RAMOS是内存操作系统，那就是要把文件也好，镜像也好，加载到内存，那就应当使用map --mem ，为什么有时候还要单独使用 map?

wintoflash · 发表于 2020-12-23 11:04:26

2011yaya2007777 发表于 2020-12-23 10:54
谢谢你，这么详尽的解答，受教了！

我没有仔细研究，如果它自己又新建了一个仿真盘，而没有使用map --mem的内存盘，那是极大的内存浪费。如果是这样，那就更应当支持碎片仿真了。

SVBus 的虚拟盘，内存还是 grub4dos分配的。磁盘参数之类的好像都是自己弄的。
非内存盘，如果文件不连续，由于 SVBus 只从内存中读了文件头部的偏移，还有文件的长度，那SVBus 的虚拟盘里面的数据就是坏的，有乱码。

liuzhaoyzz · 发表于 2020-12-23 11:20:24

本帖最后由 liuzhaoyzz 于 2020-12-23 12:01 编辑

2011yaya2007777 发表于 2020-12-23 10:54
谢谢你，这么详尽的解答，受教了！

如果它自己又新建了一个仿真盘，而没有使用map --mem的内存盘，那是极大的内存浪费。

从使用上来看，svbus没有占用另一份内存啊，就是g4e map --mem那一份儿内存。

就是RAMOS是内存操作系统，那就是要把文件也好，镜像也好，加载到内存，那就应当使用map --mem ，为什么有时候还要单独使用 map?

哦，这一点，我在873楼那个帖子回复过了，我编辑了，所以时间上显得穿越了。

2011yaya2007777 · 发表于 2020-12-23 12:57:28

wintoflash: 外部命令测试，是死机了，还是可以回到命令行?

wintoflash · 发表于 2020-12-23 13:18:04

2011yaya2007777 发表于 2020-12-23 12:57
wintoflash: 外部命令测试，是死机了，还是可以回到命令行?

虚拟机报错，强制重启。
实体机是死机。

2011whp · 发表于 2020-12-23 13:19:36

hilsonma · 发表于 2020-12-23 13:45:32

2011yaya2007777 发表于 2020-12-23 10:16
修改了 G4E 外部命令模板，再测试一下。我这里正常。要使用里边那个 BOOTX64.EFI，是配套的。
另外我想 ...

我测试g4e_wb 是使用 g4e_wb-2020-12-23.rar 中的bootx64.efi 和 g4e_wb ，bootx64.efi放在U盘作为主引导，qemu和实体机都依然是死机，但这次qemu不再出现错误弹窗。

liuzhaoyzz · 发表于 2020-12-23 14:01:56

本帖最后由 liuzhaoyzz 于 2020-12-25 08:52 编辑

我特意查阅了下相关资料：

UEFI系统的启动过程_daydayup_668819的博客-CSDN博客_uefi启动过程
https://blog.csdn.net/daydayup_668819/article/details/90172355
UEFI系统的启动过程（1）
UEFI系统的启动遵循UEFI平台初始化（PlatformInitialization）标准。UEFI系统从加电到关机可分为7个阶段：
SEC（安全验证）→PEI（EFI前期初始化）→DXE（驱动执行环境）
→BDS（启动设备选择）→TSL（操作系统加载前期）
→RT（Run Time）
→AL（系统灾难恢复期）
图1-2展示了UEFI系统从加电到关机的7个阶段（以图中竖线为界）。
前三个阶段是UEFI初始化阶段，DXE阶段结束后UEFI环境已经准备完毕。
BDS和TSL是操作系统加载器作为UEFI应用程序运行的阶段。
操作系统加载器调用ExitBootServices()服务后进入RT阶段，RT阶段包括操作系统加载器后期和操作系统运行期。

SEC的执行又分为两大部分：临时RAM生效之前称为Reset Vector阶段，临时RAM生效后调用SEC入口函数从而进入SEC功能区。
其中Reset Vector的执行流程如下。
1）进入固件入口。
2）从实模式转换到32位平坦模式（包含模式）。
3）定位固件中的BFV（Boot Firmware Volume）。
4）定位BFV中的SEC映像。
5）若是64位系统，从32位模式转换到64位模式。
6）调用SEC入口函数。

SEC阶段之后，CPU已经进入了保护模式了，后面的PEI、DXE都已经是保护模式了，BDS和TSL是操作系统加载器作为UEFI应用程序运行的阶段。TSL是操作系统加载器作为UEFI应用程序运行的阶段，这应该是g4e/grub2作为bootloader运行的阶段，附图已经很清楚，UEFI应用和UEFI-SHELL、前期OS加载器、操作系统加载器都运行在这个TSL阶段，这个阶段当然是保护模式。进入到操作系统也是保护模式。

所以，我上面的回答有点错误，BIOS下面实模式/保护模式切换与UEFI下面似乎不同，grub4dos_BIOS版本工作在实模式下，g4e/grub2-UEFI的map和map --mem应该直接工作在保护模式，在g4e/grub2环境下用EFI_RESERVED_MEMORY类型向系统申请的内存地址，不存在实模式/保护模式切换的问题，一直都是保护模式，所以这块内存可能不会释放，这跟BIOS下面grub4dos的map --mem仿真占用的内存地址进入windows保护模式之后失效完全不同，BIOS下如果没有firadisk/winvblock/svbus这一类的驱动加持，map --mem占用的内存在windows中会被释放；有了这一类的驱动加持，map --mem占用的内存在windows中就不会被释放。

wintoflash之前做的grub2 map --mem测试，好像也证明了内存没有被释放（与内存类型有关，与驱动无关）。
167楼：http://wuyou.net/forum.php?mod=redirect&goto=findpost&ptid=422652&pid=4168247&fromuid=298214
267楼：http://wuyou.net/forum.php?mod=redirect&goto=findpost&ptid=422652&pid=4170933&fromuid=298214
sunsea241楼：http://wuyou.net/forum.php?mod=r ... 0676&fromuid=298214

是否正确，难道诸位大神就没有人点评下吗？

2011yaya2007777 · 发表于 2020-12-23 17:22:37

在UEFI环境下，g4e/grub2直接map模式仿真出一个虚拟磁盘→windows从这个虚拟磁盘启动→加载primo驱动→primo驱动把vdf直接加载到内存→完成后续windows启动流程。

map仿真出来的虚拟磁盘是vdf吗?然后从vdf启动?是像svbus一样，首先引导windows，由windows加载驱动，如svbus或者primo，然后由primo驱动把vdf直接加载到内存（在此处与svbus的工作内容不同）。

2011yaya2007777 · 发表于 2020-12-23 17:28:10

liuzhaoyzz: 钻研精神值得学习！我觉得这次对G4E的解读非常到位。

sht123960585 · 发表于 2020-12-23 19:23:10

2011yaya2007777 发表于 2020-12-23 09:40
我使用你的菜单测试,没有任何问题。
你是不是简简单单的电脑直接启动G4E？

电脑直接启动G4E，没有经过中转，相同的参数 --auto-num-on ，在G4D下又可以正常，UEFI下又不正常，我也不知道为什么会出现这个现象

artour · 发表于 2020-12-23 20:43:50

2010sya 发表于 2020-12-21 12:19
上传一个

上面的模板直接拿来就可以用吗？比如我想在UEFI下启动论坛上的 slitaz5.0中文版，之前的代码应该改成什么才行呢？

下面是在之前旧版的Grub4DOS 下启动论坛上的 slitaz5.0中文版的ISO

title 00. MAP slitaz5.0cn-202012.iso My partition D >>>
map --mem (hd0,4)/slitaz/slitaz-rolling-core64-cn.iso (0xff)
map --hook
chainloader (0xff)
boot

nivigo · 发表于 2020-12-23 21:27:40

在一个俄文网站发现的，他们也在讨论grub4dos_for_uefi：https://usbtor.ru/viewtopic.php?t=2023
D:\火狐截图_2020-12-23T13-23-59.080Z.png

liuzhaoyzz · 发表于 2020-12-23 21:34:15

2011yaya2007777 发表于 2020-12-23 17:22
map仿真出来的虚拟磁盘是vdf吗?然后从vdf启动?是像svbus一样，首先引导windows，由windows加载驱动，如sv ...

差不多是这样子。

2011yaya2007777 · 发表于 2020-12-23 21:57:18

本帖最后由 2011yaya2007777 于 2020-12-23 21:58 编辑

如果差不多，那就可以进一步讨论了。vdf启动后，它读自己这个虚拟盘，是通过G4E的。如果vdf有碎片，此事不影响读虚拟盘。问题是如果vdf有碎片，不能成功启动windows。原因在于读虚拟盘的任务，由G4D交给了primo。而primo不支持有碎片的磁盘仿真。它有改进的余地。

wintoflash · 发表于 2020-12-23 22:46:49

本帖最后由 wintoflash 于 2020-12-23 22:47 编辑

wjia 发表于 2020-12-23 14:01
看帖回帖。。。。。

请不要大量发无意义回复。
http://bbs.wuyou.net/forum.php?m ... &extra=page%3D2

liuzhaoyzz · 发表于 2020-12-24 07:50:29

本帖最后由 liuzhaoyzz 于 2020-12-24 07:57 编辑

2011yaya2007777 发表于 2020-12-23 21:57
如果差不多，那就可以进一步讨论了。vdf启动后，它读自己这个虚拟盘，是通过G4E的。如果vdf有碎片，此事不 ...

应该不是这样子的，g4e map xxx.vdf的时候，实战上来讲，如果vdf有碎片，g4e就会抛出too many fragments这样的错误，我的意思是g4e抛出来的，不是primo抛出来的，文件是否连续应该是g4e要求的吧。primo是个商业软件，黑盒子里面的东西只能从结果反推外加瞎猜原因了，直观感觉上来说，primo加载vdf应该对于碎片没有要求，因为在windows下面，primo驱动有GUI界面，在界面里面关联打开一个vdf，无论他是否有碎片，都可以正常地在windows里面加载打开，加载后就是加载到了内存中。这个加载虽然是在windows后期加载的，但是我们通过修改primo的主驱动文件FancyRd的驱动组到Event log组，让这个驱动在windows启动前期就加载了，驱动加载的早晚，对于文件是否有碎片是否能加载应该是无差别的。

另外，不说vdf，就说svbus驱动搭配g4e map xxx.vhd，实战来讲好像有碎片的文件g4e也容易抛出too many fragments，为了方便，我一般都是直接先复制粘贴重命名消除碎片之后再尝试加载启动，规避问题。

2011yaya2007777 · 发表于 2020-12-24 10:58:50

我看过前面论述primo的贴子，提到vdf有碎片，g4e就会抛出too many fragments这样的错误。
可是到底有没有碎片，没有确切的答案。
最好是遇到有碎片，并且提示too many fragments时，重启，进入命令行，执行 blocklist /xxx.vdf 看看，到底有没有碎片，或者有几个碎片。

在保证有碎片，且 g4e 不报错，即 g4e 完成他的加载使命，然后才能讨论有碎片时，primo 表现如何。

liuzhaoyzz · 发表于 2020-12-24 12:06:00

本帖最后由 liuzhaoyzz 于 2020-12-24 12:07 编辑

2011yaya2007777 发表于 2020-12-24 10:58
我看过前面论述primo的贴子，提到vdf有碎片，g4e就会抛出too many fragments这样的错误。
可是到底有没有 ...

我在839楼，866楼，有反馈，但是忘了截图来说明问题。以后碰到情况再说吧。

2011whp · 发表于 2020-12-24 12:16:30

本帖最后由 2011whp 于 2020-12-25 11:44 编辑

看了liuzhaoyzz 关于 primo 驱 vdf 理解如下：（直接map）

1.  p驱是以磁盘文件名  作为握手的
2. 从过程上看，p驱起作用以前  依靠引导
      这时候  碎片支持与否  是看 g4e 是否支持（读资源靠 g4e）
3. P驱起作用后，这时，与碎片，存在与否，没有关系了（P驱直接用文件了）

2011whp · 发表于 2020-12-24 12:34:52

本帖最后由 2011whp 于 2020-12-24 12:36 编辑

关于cpu模式：

初期确实是  加电是 16位的，以csm为主  模拟出dxe
我觉得现在主流是：加电 64位的，模拟出csm

版本低的uefi  ，以前 shell.efi 还得加个 APPs目录（里面有 .efi工具，其中 load.efi都是外置的）
   那人时候  echo %path% 里还有  \apps 存在
新版 uefi， Apps的功能全内置了，只要一个shell.efi即可

估计，版本低的  dxe  加载  版本高的 ntfs.efi 会出错。

liuzhaoyzz · 发表于 2020-12-24 14:37:20

2011whp 发表于 2020-12-24 12:16
看了liuzhaoyzz 关于 primo 驱 vdf 理解如下：（直接map）

1. p驱是以磁盘文件名作为握手 ...

你的分析应该是对的。

liuzhaoyzz · 发表于 2020-12-25 08:22:12

本帖最后由 liuzhaoyzz 于 2020-12-25 09:07 编辑

大神们，我又要报告重复的问题了，这个问题似乎可以绕路解决，但是感觉终究不是解决问题的根本办法，我更希望大神们能够直接想办法解决。@2011yaya2007777 @wintoflash

同一个vdf，grub2引导正常，g4e引导又出现了诡异的boot_image_handle not found，Press any key to continue...的问题，估计还是bootx64.efi的问题，这跟基于svbus驱动的方案有点类似，svbus下面用load /EFI/grub/ntfs_x64.efi，或者用激活的FAT32+NTFS双分区，就能够规避“boot_image_handle not found”的问题，详见770楼，现在我碰到的情况是primo驱动的vdf双镜像，启动原理说起来比较复杂，出现这个问题我分析可能还是g4e对于bootx64.efi的查找加载方案有点小问题。（双镜像的问题，我还要好好研究下怎样才能绕路解决。）

wintoflash说，518楼，
http://wuyou.net/forum.php?mod=redirect&goto=findpost&ptid=417233&pid=4194527&fromuid=298214
grub2 不会按文件系统搜索虚拟盘内部。如果虚拟的是硬盘，它就先读 mbr，找激活分区，强制加载里面的 bootx64.efi。如果是 gpt，就强制加载 ESP 分区里面的 bootx64.efi。如果加载失败，就遍历 device path，只要是虚拟盘或者里面分区的 device path，就挨个试一遍。
我所说的 "加载" 其实是固件提供的启动服务里面的 "LoadImage"。

对于g4e,我发现如果优先查找NTFS里面的bootx64.efi会出错，提示“boot_image_handle not found”，就是VHD里面双分区FAT32/NTFS，似乎会优先查找NTFS分区里面的bootx64.efi？感觉上来说，如果能够根除“boot_image_handle not found”的问题就好了！说不定网友报告的chainloader /EFI/Microsoft/Boot/bootmgfw.efi失败的问题也会迎刃而解。

双镜像的启动原理，大概是这样子（可能有错误，我自己也说不太清楚准确，只是大概原理）：
g4e/grub2加载第一个vdf小镜像之后，然后primo驱动把大镜像vdf加载到内存中，大小镜像具有相同的磁盘签名，在g4e从UEFI的TSL阶段切换到windows-RT阶段保护模式之际，直接map的那个vdf小镜像会失效，vdf大镜像“狸猫换太子”，由于和小镜像具有相同的MBR（大小镜像不是同时加载的，同时加载相同磁盘签名的镜像会冲突，小的vdf镜像工作在TSL阶段，大的vdf镜像工作在RT阶段），大小镜像被windows认为是同一个磁盘，所以能够继续加载。有点复杂。
这样做达到的最终效果是C盘的大小就等于内存大小，内存动态回收，内存即硬盘，硬盘即内存。

wuyouman01 · 发表于 2020-12-25 09:42:40

可以运行 ntboot 吗？

2011yaya2007777 · 发表于 2020-12-25 10:26:51

再次测试G4E外部命令。

2011yaya2007777 · 发表于 2020-12-25 10:29:33

本帖最后由 2011yaya2007777 于 2020-12-25 10:49 编辑

对于g4e,我发现如果优先查找NTFS里面的bootx64.efi会出错

你使用905楼的bootx64.efi测试一下，这次是优先从MBR活动分区查找。

		自动登录	找回密码
密码			注册

[原创] GRUB4DOS for UEFI

点评

点评

点评

点评

点评

点评

点评

点评

点评