GRUB4DOS for UEFI

wuwuzz

首先，向yaya、wintoflash的伟大工作致敬！

其次，补充汇报map iso的问题。
34#、49# w大已经提到了，这里更具体地延伸说一下。grub2 map没有根治，g4d下更重了。
(样例均为同方、海尔笔记本实机测试，AMI aptio系UEFI，我不信任虚拟机)

一、当机器本身就有PE光盘(SATA或USB光驱，均使用MS的boot*.efi),此时，g4d再map U盘上
的其他PE ISO， map可以成功，但chainloader是失败的，fail to load image，boot命令启动
的是光驱里的内容。



grub2下为解决类似问题，提出2个途径：

1、map -x。我追踪了一下，w大在2020年5月提出了map -x (cd?)命令，虽然L版报告虚拟机测试成功，
但我用2020年5月版在实机上测试无效，因为USB-CD被识别成了(hd?)，即使用map -x (hd?)也不能解决
问题。所以放弃。



2、改造PE ISO，使用mkisofs重做，以grub2的boot*.efi代替ms的boot*.efi,然后用wimboot启动wim。
这个可以成功。但此改造后的ISO，在g4d下map启动无效。map、chainloader、boot均无出错提示，但就是
不能进入grub2菜单。




二、U盘量产USB光驱的附加问题
CD+DISK，光驱在前时，DISK上的g4d不能顺利启动到menu，直接进入g4d shell状态，原因不明。
DISK+CD，光驱在后时，DISK上的g4d可以启动到menu。

wuwuzz

哈，原因很简单，巧合。要不是L版你，事情还进展不到测试map -x呢，
我之前压根就不知道新增了这个选项。
==================================================================
w大在2019年底(还是2020年初?)宣布过grub2 map项目中止，帖子不再更新，
并给了github接手地址。自那以后，我就没再关注过原贴。要不是L版你在
这个帖子里谈到grub2 map iso，给了链接，我又心血来潮点链接翻原贴，偶然
发现w大回复说增加了map -x，我还不知道这个事呢！(w大的回复似乎是在最初
宣布项目中止后？) 而且连新版下载在哪也不知道，也多亏你分流了2020年5月版，
否则，连下载测试都成问题！ map -x测试是现炒现卖！
======================================================================
正好yaya和w大都在，且还在考虑要不要增加g4d unmap,反馈在这里也是一样的。
map -x，实体机测试当然有问题，见上面例子。
==========================================================================
深究map iso主要还是考虑适应量产U盘环境。(实体SATA/USB光驱插光盘只是为了测试)
而量产CD+DISK，然后又map DISK上的iso情形较常见，这个时候回避不了已有光盘的
情况。

至于更复杂的U盘量产多光驱(CD+CD+CD+...+DISK)的情况，也依赖于g4d/grub2光盘
引导成功，才能充分发挥作用。
==========================================================================
当然，说到底，这也没什么大不了的，毕竟最低保底办法，改造iso能解决。
主要还是追求完美，g4d for UEFI出来了，不由自主地想看看能不能把以前的遗憾实现啊~

wuwuzz

江南一根葱 发表于 2020-11-5 11:09
量产属于特殊情况，个人认为没必要折腾

很久很久前折腾过一段时间量产，同一u盘，同一量产工具，不同时 ...

呃，量产那是固件范畴，是另外一个庞大的话题，就是因为它，我的知识结构、对事情的看法
才脱胎换骨，不应在此讨论。用它只是作为营造USB光驱环境的工具，为map iso提供测试平台，
为g4d、grub2测试服务。

wuwuzz

江南一根葱 发表于 2020-11-5 13:03
我指的是量产出的cdrom并不能营造真实USB光驱环境
还是有区别的

对USB光驱启动而言，没区别，或者说，足够了。BIOS/UEFI并无特别的方法去区分两者物理上的不同，就是按规范发固件命令，命令结果一样，BIOS/UEFI就认为两者一样。

wuwuzz

抱歉，下午单位组织学习，未及时看到帖子回复。

@2011yaya2007777

1、菜单在磁盘上。U盘量产后，相当于是变成2个物理设备，第1设备是光驱，放win10PE；
第2设备是磁驱，放g4d(含菜单)，也放了其他供测试用的ISO。G4D for UEFI如何做光盘启动，
我还不会，所以菜单是放在磁盘上的。


2、新版G4D测试结果如下：

图1是真实的外置USB光驱、SATA光驱均存在的环境中，U盘MAP的情况。(此U盘未量产，是单独的磁驱)



图2是构造了更复杂的环境，除了上面的光驱环境，又增加了量产USBCD，然后U盘DISK部分MAP的情景。

wuwuzz

@wintoflash

新增的map -f选项有效，能够成功将U盘上的ISO与其他光驱ISO区分开。

示例图是有意构造的复杂干扰环境：

USB光驱+SATA光驱+量产光驱都存在的条件下，U盘DISK部分MAP时的情况。

wuwuzz

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

似乎不同的ISO，都不能启动，出错信息也都一样：boot_image_handle not found
参考图见#226

wuwuzz

上传1个测试ISO testiso.7z (1.86 MB, 下载次数: 47)

2020-11-5 20:33 上传

点击文件名下载附件
win10pe
下载积分: 无忧币 -2

wuwuzz

原始ISO是从网上找的，制作软件未知。
删除不必要文件缩小体积、再保存时，用的ultraISO。

wuwuzz

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

现在除了可以启 ...

一、简单环境测试未通过，因此未进行复杂环境测试。
直接chainloader实体机boot失败，现象与11月5日测试版雷同；



map优盘上的ISO,再chainloadr和boot，将启动实体USB光驱内容。
看来这次的代码，未能像W大grub2新增map -first项那样，将选中
的ISO重新排序到第1光驱，以欺骗MS的boot*.efi。



二、有事需要提前汇报。
本周六--周日，单位组织培训，因此将无法及时测试回复，很抱歉。
周日晚或周一将有时间参与测试。

wuwuzz

2011yaya2007777 发表于 2020-11-6 19:17
再一个是，输入 cd3欠妥，应当是 0xa2，或者是 cd（map时），cd-1（chainloader时)。）

结果如下：

wuwuzz

2011yaya2007777 发表于 2020-11-6 19:11
直接启动第一或者第二光盘，看看结果。

所有参与测试的ISO，刻光盘或用grub2 map，都是可以启动成功，进入win10 PE的

wuwuzz

xianglang 发表于 2020-11-8 18:17
下载了一楼的20201029版本试了下，发现不支持 LZMA 压缩格式、map --mem 不支持 --top 参数。还有，使用 ch ...

“测试 G4D 时按 F11 选择 EFI 启动”  ---- 问题可能就出在这里。

yaya的这个版本G4D，我测试的结果，貌似需要纯UEFI环境
(BIOS/UEFI设置里---选择UEFI OS/关闭安全启动/关闭CSM)。
按Fn键从快捷启动菜单中选UEFI是不行的，那样选择的话，
G4D会直接进入命令行状态。

wuwuzz

一个小插曲，关于CHS。

我认为，CHS不可或缺。从流出的BIOS/UEFI源代码来看：

在BIOS下
即使引导软件不用CHS，不代表BIOS不用。BIOS在U盘枚举时，(尚未进入引导阶段时)，
即开始计算U盘逻辑CHS参数(并计算完毕)，等待调用(例如等待用户调用INT 13 Fn8)。

在UEFI下，参见
http://bbs.wuyou.net/forum.php?mod=viewthread&tid=421614

===========
关于windows，记得很久以前，MS的知识库里，谈到NT处理MBR时，有关于
CHS处理方面的内容，时间久远，记不太清了。但有一点，我记得清楚，
实在搞不定硬盘CHS的准确性时，终极办法就是以物理(固件)CHS为基准。

U盘也是同样的道理，BIOS/UEFI计算的基础，就是U盘物理(固件)CHS。

wuwuzz

sunsea 发表于 2020-11-9 01:14
很好奇一个问题，保留CHS除了兼容旧软件之外的意义在哪里？难道有固件或者软件到现在了线性寻址也给不出 ...

是的，兼容老标准这个原因是确定无疑的。只要INT13还在，CHS就如影相随。
从代码上看，到了UEFI，似乎也没能把CHS完全剔除掉，历史的遗产(包袱)
太多了。

wuwuzz

sunsea 发表于 2020-11-9 09:41
可还行……那为什么不统一H255S63然后内部转成线性地址呢……还是有老的/不规范固件给不出正确结果还是咋 ...

U盘(USB存储设备)内部都是转成LBA访问。
就目前知道的情况，磁盘类设备有很多种(FDD、ZIP、HDD)，HS不会一样的...
而新版UEFI又新增了usb key这种(由于没有对应版本的代码可看，所以不了解它是怎么个算法)

wuwuzz

2011yaya2007777 发表于 2020-11-9 10:42
可以测试 SVBus 了。

2020-11-09版的G4D,经测试：

1、已解决了多光驱(量产或实体)干扰条件下，MAP 磁盘上的(win10 PE)ISO，正确启动问题。
2、以G4D为光盘引导程序，为PE ISO加壳，形成新ISO(即ISO嵌套)测试成功。

==================
3、测试SVbus

看上下文，SVbus是为VHD启动准备的，对SVbus/VHD不太熟。以前测试W大grub2的
run.efi、ntboot时，准备了一个win10 to go的fixwtg.vhd，能测试通过。


在g4d下，
map (hd1,1)/fixwtg.vhd (hd2)
chainloader (hd2,0)
boot

进入VHD时失败，提示0xc000000e错误。测试 svbus是不是对VHD有什么特定要求，比如要
装svbus for windows驱动之类。

wuwuzz

2011yaya2007777 发表于 2020-11-10 08:33
fixwtg.vhd 是固定尺寸的，还是动态尺寸的？如果是后者，要加 --mem

固定尺寸

wuwuzz

wuwuzz 发表于 2020-11-10 09:53
固定尺寸

出现新问题。

此fixwtg.vhd用grub2的run.efi或ntboot启动，成功进入win10，然后重启(冷启或热启)
电脑，在G4D下MAP，chainloader出现failed to load image/boot_image_handle not found
错误。手动chainloader bootx64.efi再boot，无反应。

不能重现350#的场景了。

wuwuzz

g4e似乎不支持USB-FDD(1.44M软盘)、USB-ZIP(250M大软盘,FAT32/可移动)。

这2种设备，如果装的是MS的bootx64.efi，则可以正常进入shell命令行状态。
如果装的是g4e的bootx64.efi，则：

1、USB-FDD启动，黑屏无反应；
2、USB-ZIP启动，则直接进入g4e命令行状态(似乎是不能正常挂载分区所致?)

wuwuzz

2011yaya2007777 发表于 2020-11-21 07:35
这两种设备，在UEFI环境里，还有什么实际的意义?我不知道。

跳转测试需要。

除了要测试各种USB设备类型这个兼容性考虑之外，有这种实际情形：

在一个U盘上实现了CD+HDD+ZIP+FDD各种设备类型共存之后，那么，如果menu.lst存放在fdd/zip上，而要启动存放在HDD上体积庞大的PE、LINUX时，需要fdd/zip本身的g4e能正常运行……

wuwuzz

AMI系UEFI内部保留了USB-FDD、USB-KEY（ZIP的后裔，见下面解释）支持；
Phonenix系、Insyde系UEFI怎样不清楚，因为没有源代码流出。

我能掌握的最后确切信息是：
Phoenix BIOS流出的源代码保留了USB-FDD、USB-ZIP支持。
尤其是其代码注释中对ZIP的释义有很大参考价值。

原始的Iomage ZIP早就死了，但其理念却保留了下来，严重影响
着 BIOS(UEFI)的设计思路。说白了，就是类似于G4D中map fd的方法，
ZIP可以切换，成为固定盘设备(HD)或者移动盘设备(fd)。

在UEFI引导菜单中频繁出现的USB-KEY设备(从字面理解就是U盘)，
实质(支持代码)在AMI环境中，应该就是ZIP切成fd设备的延续。
而对于Phoenix环境，则另有其特定算法。

wuwuzz

“2011whp  内部 子方案有吧，比如 光盘还挂个img ，也变味了，借鉴 架构理念。 biso整体方案，应该是不提倡了。”

----与想象中的BIOS-UEFI巨大差异不同，
实际上UEFI内部USB启动算法没有大变，例如AMI UEFI，归根结底，其实
就是 BIOS中的汇编代码用C又重新实现了一遍，重合度很高。

wuwuzz

同一U盘，同一Win10 PE ISO，

在AMI UEFI     (海尔S4笔记本)，  MAP、chainloader后启动成功；
在Insyde UEFI (HP  G4笔记本)，   MAP、chainloader后出错boot image handle not found。

原因不明。

wuwuzz

wuwuzz 发表于 2020-11-21 22:34
同一U盘，同一Win10 PE ISO，

在AMI UEFI     (海尔S4笔记本)，  MAP、chainloader后启动成功；

补充Debug信息，两种UEFI似乎对G4E处理不同。

wuwuzz

2011yaya2007777 发表于 2020-11-22 09:05
在命令行先输入
debug 3
之后再测试一下

472#就是debug后信息。两种UEFI对G4E出错提示，似乎处理不同

wuwuzz

补充：
AMI UEFI机，无内置光驱。Insyde UEFI机有内置sata光驱，未放光盘。
潜意识以为新版g4e已调整光盘顺序，就没考虑这个因素。

wuwuzz

2011yaya2007777 发表于 2020-11-22 10:01
wuwuzz 提供的 Insyde UEFI (HP  G4笔记本) 测试结果（472#第一张图），其中光盘路径是:

VenHw(160B07E4 ...

后面是\EFI\BOOT\BOOTX64.EFI 。CDROM后面一长串字符与AMI UEFI环境下相同。

wuwuzz

2011yaya2007777 发表于 2020-11-22 10:01
wuwuzz 提供的 Insyde UEFI (HP  G4笔记本) 测试结果（472#第一张图），其中光盘路径是:

VenHw(160B07E4 ...

考虑到G4E map和grub2 map同源，又回溯追查了grub2 map的情况,以获取更多的提示信息。

1.在AMI UEFI下grub2 map启动成功，在Insyde UEFI下失败。grub2 map的设备路径里也有[0:]。






2.grub2早期版本设备路径里没有[0:]，在后期版本出现。在2019年测试过程中，已经暴露了
Insyde UEFI下失败情形，但由于当时注意力集中在多光驱排序，还没关注到有没有其他因素
影响。(当时的内容在http://bbs.wuyou.net/forum.php?m ... page%3D1&page=6)







现在看来Insyde UEFI本身可能存在问题。

wuwuzz

wintoflash 发表于 2020-11-24 18:12
跟"[0:]"没什么关系。我觉得主要还是Eltorito软盘镜像的问题。
CD(1,12b,5a0) 是grub2通过解析ISO文件数 ...

ISO就是本坛这个帖子中的win10PE V17763
http://bbs.wuyou.net/forum.php?mod=viewthread&tid=414556
(WinPE10 x64、x86 17763 [分享] 【经典 P10】Win10PEx64、x86，含常规工具＋制作个性(PE)工具，网络、BIOS＋EFI 双启)  


里面有个efisys.bin镜像，大小为2880KB。镜像里的bootx64.efi大小为1323KB。


Efisysbin.7z (999.08 KB, 下载次数: 8)

2020-11-24 18:55 上传

点击文件名下载附件
镜像
下载积分: 无忧币 -2