|
本帖最后由 wuwuzz 于 2024-10-9 11:06 编辑
问题已解决。没用multimbr,用的g4d做中介跳板。
过程有反转戏剧性。事后我才发现,2023年1月与yaya、求道者讨论时,我们都没意识到,当时实际已经到了解决的门口,就差临门一脚,但因话撵话分散了注意力,遗憾地擦肩而过、失之交臂。直到2024年我家神兽在做USB协议分析仪解码器课题时,因1楼问题是典型应用案例,又拾起研究,才被重新发现。“踏破铁鞋无觅处,得来全不费工夫”。
其思路是:既然问题是USB-HDD(因BIOS BUG)缺失固定设备属性、只能当FDD引起的,那么,能不能把缺失的固定设备属性,再重新加回去?能加上的话,USB-HDD就满血复活,Ventoy引导区或UD隐藏引导区等复杂磁盘布局,其识别就能和以前正常的USB-HDD识别一样,迎刃而解。恰好yaya的g4d内置USB驱动,在设计时留了这样一个口子:驱动会将盘号0x00映射到0x8x---这就等于是加上了固定设备属性。
实际操作就很简单了:
1、原有的Ventoy或fb盘,引导区布局和内容无需做任何改动。在存放数据的普通可见分区(PBR)上,加装g4d(bootice写入)。这样是为了顺着buggy BIOS,将计就计,由PBR上的g4d引导,进入g4d布下的陷阱。
2、关键的一步。在g4d的menu.lst ,加usb --init语句,激活g4d内置USB驱动,重新识别和映射USB-HDD盘,恢复固定设备属性,如下图示。USB-HDD盘号被重新映射为0x81,不再使用(fd0),而是使用(hd1),此时,UD隐藏区可正常识别了。
同理,ventoy盘用同样的方法,也可以恢复识别。
[注:此处0x80、(hd0)为本机内置SATA硬盘,应忽略]
3、后续就以ventoy、UD各自的关键字标识文件,搜索相应分区-重新跳回UD或ventoy控制。
#如:ud,以fb.cfg为关键字,搜索启动
find --set-root /fb.cfg
chainloader (hd1)+1
boot
#如:ventoy,以usbhdd.flg为关键字,搜索启动
find --set-root /usbhdd.flg
chainloader (hd1)+1
boot
|
|