GRUB2 UEFI 下的磁盘仿真

wuwuzz

wintoflash 发表于 2020-12-13 10:09
这里写的是 0x9d000，你在执行 "boot" 之前，执行 "hexdump (mem) -s 0x9d000" 查看一下内存。
还有 ...

以前图示中用的是楼层里的grub2,该grub2没有包含hexdump。

因此，又从github下载了grub2,把hexdump包含进去，使用该grub2 map，
write grub4dos drive map slot地址变为0x57000，相关截图如下：









先g4d map ramos.vhd，然后chainloader grub2后的截图如下：

wuwuzz

补充发现：

1. g4e map启动成功，像是“假”成功。她只能map引导刚解压出的、全新ramos.vhd成功
(即第一次map，这次map引导会出现：正准备设备进度提示)，之后热启、冷启后再
map引导ramos.vhd(不再出现正准备设备提示),将蓝屏。

2.我的fixwtg.vhd，热启、冷启用G4E map引导成功后，能够看到SVbus virtual磁盘设备，
而用grub2(仅限楼层中发布的1212版)热启、冷启map引导成功后，看不到SVbus virtual
磁盘设备。如下图对比:

G4E:



grub2:

江南一根葱

假设一下，直接map不mem启动后,vhd会产生碎片吧，

liuzhaoyzz

江南一根葱 发表于 2020-12-13 15:00
假设一下，直接map不mem启动后,vhd会产生碎片吧，

       只是启动下VHD，读写一般不多，临时文件基本不怎么影响碎片的，很早以前g4d+firadisk就是这样子，不会产生什么碎片。 大不了就用wincontig整理下。

江南一根葱

liuzhaoyzz 发表于 2020-12-13 16:49
只是启动下VHD，读写一般不多，临时文件基本不怎么影响碎片的，很早以前g4d+firadisk就是这样子， ...

我只不过往vhd加了几个文件，就产生碎片了
直接就蓝屏，

2011yaya2007777

看来，让SVBUS支持碎片，很有必要。

wintoflash

wuwuzz 发表于 2020-12-13 11:52
以前图示中用的是楼层里的grub2,该grub2没有包含hexdump。

因此，又从github下载了grub2,把hexdump包 ...

你发的图片上的数据不科学啊。

这个是不是 grub4dos 启动 grub2 ，再 map 的？


这个是不是在 grub4dos 下 map，进grub2，在 grub2 下又执行 map 了？

我的fixwtg.vhd，热启、冷启用G4E map引导成功后，能够看到SVbus virtual磁盘设备，
而用grub2(仅限楼层中发布的1212版)热启、冷启map引导成功后，看不到SVbus virtual
磁盘设备。

grub2 和 grub4dos 在 map slot 里面写的信息不同，可能被 SVBus 当作不同类型的设备了。因为我觉得 grub4dos 写的有点问题。这个不重要。

wintoflash

liuzhaoyzz 发表于 2020-12-13 11:48
好消息，用你在499楼分享的grubx64.efi.tar.gz，成功搞定了grub2+svbus+WIN7X64-UEFI-RAMOS!

1、在499 ...

2、感觉grub2读盘速度一直较慢，不稳定，感觉不如g4e稳定，请看下还有没有提升的空间。

如果文件无碎片，可以加 -l 参数，先转成 blocklist 格式加速读取。
如果文件有碎片，可能可以，也可能不行。

3、还有个问题：启动vhd-ramos的时候，能否优先搜索FAT32/ESP分区里面的bootx64.efi，如果找不到再找NTFS分区里面的bootx64.efi？
对于g4e,我发现如果优先查找NTFS里面的bootx64.efi会出错，不知道grub2是怎么考虑处理的？

grub2 不会按文件系统搜索虚拟盘内部。如果虚拟的是硬盘，它就先读 mbr，找激活分区，强制加载里面的 bootx64.efi。如果是 gpt，就强制加载 ESP 分区里面的 bootx64.efi。如果加载失败，就遍历 device path，只要是虚拟盘或者里面分区的 device path，就挨个试一遍。
我所说的 "加载" 其实是固件提供的启动服务里面的 "LoadImage"。

2011yaya2007777

SVBus只认最高处的搜索字符串，其他的没有起作用。

liuzhaoyzz

江南一根葱 发表于 2020-12-13 17:06
我只不过往vhd加了几个文件，就产生碎片了
直接就蓝屏，

不会吧？！你的vhd是不是放在ssd上面？ssd有FTL中间层会影响碎片。

liuzhaoyzz

wintoflash 发表于 2020-12-13 17:29
如果文件无碎片，可以加 -l 参数，先转成 blocklist 格式加速读取。
如果文件有碎片，可能可以，也 ...

        grub2查找bootx64.efi的方案很不错！这正是我们想要的。对于MBR分区就找活动分区里的bootx64.efi，一般地来说UEFI搭配MBR硬盘启动的时候，bootx64.efi这样的引导文件肯定是会放在活动分区里的。

感觉上来说g4e似乎没有这个机制？对于MBR硬盘活动FAT32分区+NTFS分区的情况，总是优先找到的是未激活的NTFS分区里的bootx64.efi。用户侧的确可以删除NTFS分区里的bootx64.efi规避问题，如果在开发侧考虑这个就好了。

wuwuzz

wintoflash 发表于 2020-12-13 17:20
你发的图片上的数据不科学啊。

这个是不是 grub4dos 启动 grub2 ，再 map 的？

“这个是不是 grub4dos 启动 grub2 ，再 map 的？”
----不是的。这个应该是先前做过什么操作，然后热启动，单纯grub2引导、map。

“这个是不是在 grub4dos 下 map，进grub2，在 grub2 下又执行 map 了？”
---没有再map。这个也是热启动之后，g4e下map，进grub2后截图，grub2没执行map。

怀疑热启动没清干净一些内容。
================================================
换用冷启动，重新进行操作，截图如下：
grub2 map





g4d map后，进grub2, hexdump

wuwuzz

@W大：

能不能发一个带hexdump、带ctl+alt+f12截图功能的grub2 ?  
我重做的grub2不带截图功能，发图效率低...

wintoflash

wuwuzz 发表于 2020-12-13 21:09
@W大：

能不能发一个带hexdump、带ctl+alt+f12截图功能的grub2 ?  

grubx64.zip (656.91 KB, 下载次数: 9)

2020-12-13 21:22 上传

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

github上已经发布了，你可以自己改模块。crscreenshot 是截图的模块。

怀疑热启动没清干净一些内容。
================================================
换用冷启动，重新进行操作，截图如下：

这样看起来正常了。估计以前一些重启bug就是这个导致的。

wuwuzz

wintoflash 发表于 2020-12-13 21:23
github上已经发布了，你可以自己改模块。crscreenshot 是截图的模块。

ok

liuzhaoyzz

wintoflash 发表于 2020-12-13 17:29
如果文件无碎片，可以加 -l 参数，先转成 blocklist 格式加速读取。
如果文件有碎片，可能可以，也 ...

刚才用秒表测试了下，从选择菜单开始计时，把一个8GB的VHD放在普通ssd硬盘，完全加载到内存到100%为止停止计时。
g4e用了55秒，grub2用了1分23秒。
g4e加载速度比grub2快了(83-55)/83=34%

以前只是主观感觉慢，卡表看了下确实慢。
没有用--blocklist参数。

2011npwjm

谢谢楼主的分享

liuzhaoyzz

wintoflash 发表于 2020-12-13 21:23
github上已经发布了，你可以自己改模块。crscreenshot 是截图的模块。

好消息！
用你在524楼分享的这个grubx64.efi，成功地直接map win7.vhd启动成功，win7.vhd里面有svbus驱动加持。
menuentry "SX70211.vhd" "/VHD/SX70211.vhd" {
       search --no-floppy --set --file $2
       map $2
    }


以前的版本直接map好像蓝屏了。

江南一根葱

liuzhaoyzz 发表于 2020-12-13 18:19
不会吧？！你的vhd是不是放在ssd上面？ssd有FTL中间层会影响碎片。

这么高深，我确实是ssd上的，trim后才正常，
不过我以前在机械硬盘操、作，也不靠谱

liuzhaoyzz

wintoflash 发表于 2020-12-13 21:23
github上已经发布了，你可以自己改模块。crscreenshot 是截图的模块。

好消息！本人亲测，SVBUS+WIN7.VHD，vhd内部单分区，MBR分区，启动成功：
menuentry "SX70211.vhd" "/VHD/SX70211.vhd" {
        efiload /EFI/grub/ntfs_x64.efi
        search --no-floppy --set --file $2
        map --mem --rt $2
}

建议在发布的时候，加上efiload模块，这个模块很重要！没有这个模块，VHD-RAMOS单分区无法启动。
F:\bak\grub2\grub2-latest2020-12-17\arch\x64\builtin.txt
加上 efiload


我看了下帖子， 2019-11-9日，早在一年之前，118楼、119楼，我们早就讨论过了ntfs.efi驱动的加载了，单分区NTFS-svbus-RAMOS用grub2加载出错，我们早就应该想到加载ntfs.efi驱动的。


g4e也是因为缺乏这个ntfs.efi驱动导致无法正常加载单分区VHD。

liuzhaoyzz

江南一根葱 发表于 2020-12-14 14:04
这么高深，我确实是ssd上的，trim后才正常，
不过我以前在机械硬盘操、作，也不靠谱

        根本用不着trim，WIN7以上的系统对ssd好像是自动开启trim的。ssd如果因为死机强制关机出现索引错误和交叉链接错误，chkdsk /f有时候都不一定能够完全修复，最简单直接暴力的办法是：备份ssd里面的主要文件，然后把ssd格式化，再把备份文件拷贝回去，各种怪异的问题基本都能够解决，很多时候不是UEFI固件“疯了”，而是ssd存贮“疯了”。

wuwuzz

liuzhaoyzz 发表于 2020-12-17 01:43
好消息！本人亲测，SVBUS+WIN7.VHD，vhd内部单分区，MBR分区，启动成功：
menuentry "SX70211.vhd" "/VH ...

“g4e也是因为缺乏这个ntfs.efi驱动导致无法正常加载单分区VHD”

是的，原以为G4E有内置NTFS支持，就没往这方面去想。实际上是我自己有模糊认识。

江南一根葱

liuzhaoyzz 发表于 2020-12-17 07:56
根本用不着trim，WIN7以上的系统对ssd好像是自动开启trim的。ssd如果因为死机强制关机出现索引错 ...

trim可以解决，格式化那吃不消，几百G的文件

ahxx

感谢分享，学习下

wintoflash

liuzhaoyzz 发表于 2020-12-17 01:43
好消息！本人亲测，SVBUS+WIN7.VHD，vhd内部单分区，MBR分区，启动成功：
menuentry "SX70211.vhd" "/VH ...

我觉得这个问题大家应该都知道啊，结果发现你们都不知道。。。多试试就能发现的。。。
建议慎用这个 ntfs 驱动。保险起见，最好有 FAT 分区。


另外，今天的版本修复了 vhd 模块的一些毛病。现在应该可以直接 map 或 loopback 挂载动态 vhd 了。
还有删掉了 fdlibm 模块，同时禁用浮点数，这个一般人不会关心吧。

你们在 BIOS 下用 grub4dos 启 RAMOS VHD，是不是喜欢用 lz4 压缩？
GRUB2 是否有必要支持 lz4 ?

江南一根葱

wintoflash 发表于 2020-12-17 14:31
我觉得这个问题大家应该都知道啊，结果发现你们都不知道。。。多试试就能发现的。。。
建议慎用这个 ntf ...

个人认为，在这论坛“玩”ramos的，“大部份”32G内存起步，
压缩，影响他们的心情，，，

个人认为，他们对16G以下内存的用户是非常不屑的

liuzhaoyzz

wintoflash 发表于 2020-12-17 14:31
我觉得这个问题大家应该都知道啊，结果发现你们都不知道。。。多试试就能发现的。。。
建议慎用这个 ntf ...

        NTFS.EFI驱动，大家确实早就知道有这回事，我很早之前，在uefishell下也尝试过加载这个驱动，尝试用它解决UEFI-RAMOS的问题，然而有谁能够把vhd加载错误和这个驱动联想到一起呢？我的华硕电脑原生支持NTFS驱动，g4e带有NTFS驱动，对于WIN10-SVBUS-RAMOS-NTFS单分区启动没问题，可是WIN7/WIN8单分区启动就失败，用FAT32+NTFS双分区启动就可以成功。ntfs.efi的问题，的确没有想到。

你不说ntfs.efi驱动的稳定性，大家还真的都不知道，我在reboot.pro上面看到alacran汇报说，从不同网站下载的ntfs.efi这个驱动有失败的情况，可能是最新版本的问题，这个驱动倒底哪个版本更加适配g4e？我看有从refind下载的，有从github下载的，我找不到github那个下载地址了。

今天的版本修复了 vhd 模块的一些毛病。现在应该可以直接 map 或 loopback 挂载动态 vhd 了。

谢谢提醒，有的时候一些新功能，如果不去使用他，很容易就忘记了，grub2的efiload这个命令我去年知道有这么回事，也尝试过，后来完全没有印象了。
很多时候，开发者写了程序或者更新了bug，对于终端用户来说，根本不知道程序更新之后对于使用有什么变化，如果不是当初你@我，说reboot.pro上面有人成功用svbus制作了UEFI-RAMOS，我还真不知道去尝试，完全不知道要尝试，因为不知道svbus不需要做任何改动的情况下，单边改动g4e就能把g4e和svbus驱动对接上，并且成功启动UEFI-RAMOS。

BIOS下面用grub4dos引导的，实战上来讲，我基本没有用Svbus+vhd驱动这个方案，用的是primo驱动+vdf方案，用的是直接map  xxx.vdf的方案，vdf内部是采用compact压缩的，好处是primo这个软件能够直接保存（热备份）更新vdf里面的内容。vdf内部是压缩的，vdf外部再次压缩对于我个人来说，没有太大的必要。事实上我的内存用不完，压缩不压缩，对我来说真心不重要。RAMOS要想玩起来，不能完全依靠各种压缩技术，加内存条最简单最实在。

我看reboot.pro的alacran似乎有这个需求，可能他代表了部分网友吧。是否跟进lz4模块，完全看大神你的兴趣爱好了。

对于svbus-vhd-uefi-ramos，如果支持gz/lz4，加载时间应该能够减少不少，这会加快RAMOS启动速度。

liuzhaoyzz

江南一根葱 发表于 2020-12-17 19:23
个人认为，在这论坛“玩”ramos的，“大部份”32G内存起步，
压缩，影响他们的心情，，，

        也不能这么说，不同的人爱好不同，兴趣不同，无可非议，没有什么看不起之说。

江南一根葱

liuzhaoyzz 发表于 2020-12-18 09:42
也不能这么说，不同的人爱好不同，兴趣不同，无可非议，没有什么看不起之说。

我都是个人认为，玩ramos的，1111M/s的读写速度和2222M/s的读写速度在使用个小软件上都能感觉出区别。。。这个我是做不到的

liuzhaoyzz

江南一根葱 发表于 2020-12-18 12:22
我都是个人认为，玩ramos的，1111M/s的读写速度和2222M/s的读写速度在使用个小软件上都能感觉出区别。。 ...

        这个速度区别的确感觉不出来。问题是电脑方面，对于速度的追求是没有止境的，就好像cpu，主频速度翻了近百倍，还在持续发展，存储速度也是一样。管他有没有感觉，更快的当然更好。