无忧启动论坛

 找回密码
 注册
搜索
系统gho:最纯净好用系统下载站广告联系 微信:wuyouceo QQ:184822951
楼主: wintoflash
打印 上一主题 下一主题

[原创] GRUB2 UEFI 下的磁盘仿真

    [复制链接]
91#
发表于 2020-12-17 01:43:28 | 显示全部楼层
本帖最后由 liuzhaoyzz 于 2020-12-17 07:59 编辑
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。
回复

使用道具 举报

92#
发表于 2020-12-17 07:56:37 | 显示全部楼层
江南一根葱 发表于 2020-12-14 14:04
这么高深,我确实是ssd上的,trim后才正常,
不过我以前在机械硬盘操、作,也不靠谱

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

使用道具 举报

93#
发表于 2020-12-17 21:14:45 | 显示全部楼层
本帖最后由 liuzhaoyzz 于 2020-12-18 21:16 编辑
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启动速度。



回复

使用道具 举报

94#
发表于 2020-12-18 09:42:58 来自手机 | 显示全部楼层
江南一根葱 发表于 2020-12-17 19:23
个人认为,在这论坛“玩”ramos的,“大部份”32G内存起步,
压缩,影响他们的心情,,,


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

使用道具 举报

95#
发表于 2020-12-18 14:35:04 | 显示全部楼层
本帖最后由 liuzhaoyzz 于 2020-12-19 15:03 编辑
江南一根葱 发表于 2020-12-18 12:22
我都是个人认为,玩ramos的,1111M/s的读写速度和2222M/s的读写速度在使用个小软件上都能感觉出区别。。 ...


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

使用道具 举报

96#
发表于 2020-12-18 18:44:02 | 显示全部楼层
本帖最后由 liuzhaoyzz 于 2020-12-18 18:48 编辑

        
你这个 vdf 里面没有 bootmgfw.efi 啊,没法测试。

这个用于BIOS-PRIMO-RAMOS里面的,之前我以为你只需要测试下vdf文件是否能够正常用map加载,所以发了个我现在实际在用的。所以没有bootmgfw.efi。
我现在用于测试的SX7.vdf,有8GB,你的内存放不下。等下我重新制作个WIN8,小点的,带UEFI引导的,确保能放在你的内存,分享到网盘,问题是这个vdf是面向我的电脑的,在我这边都不能成功启动,在你的电脑也是不可能启动成功的,其实我也不知道发给你之后,你那边倒底要怎么测试,我有点发懵。

这个 vdf 怎么连bios引导代码也没有?

这个vdf之前是用g4d在BIOS下面加载的,用g4d直接map,所以不需要引导代码,g4d菜单如下:
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
g4d加载这第一个小镜像之后,然后primo驱动把大镜像vdf加载到内存中,大小镜像具有相同的磁盘签名,在g4d从BIOS的实模式切换到windows保护模式之际,直接map的那个vdf小镜像会失效,vdf大镜像“狸猫换太子”,由于和小镜像具有相同的MBR(大小镜像不是同时加载的,同时加载相同磁盘签名的镜像会冲突,小的vdf镜像工作在实模式,大的vdf镜像工作在保护模式),大小镜像被windows认为是同一个磁盘,所以能够继续加载。有点复杂。
这样做达到的最终效果是C盘的大小就等于内存大小,内存动态回收,内存即硬盘,硬盘即内存。

vdf里面的 bcd 好像也有问题。
指定的磁盘不对,0x20 处全是 0

vdf里面的bcd采用的是boot/locate自动定位模式,自动定位到primo虚拟内存盘那个分区,自动定位的意思,我估计是primo启动之后,加载vdf到了内存盘,然后才会有定位目标吧。大概是这样子:



点评

primo 是怎么知道大镜像vdf的位置在哪呢?注册表写死的?  详情 回复 发表于 2020-12-18 19:03
回复

使用道具 举报

97#
发表于 2020-12-18 19:28:54 | 显示全部楼层
wintoflash 发表于 2020-12-18 19:03
primo 是怎么知道大镜像vdf的位置在哪呢?注册表写死的?

primo是遍历了所有的磁盘,查看磁盘签名,通过磁盘签名确定vdf所在的路径,我记忆中是这个样子,官方论坛有说过,一时找不到。
好像不是通过注册表,primo驱动启动组是SCSI class group,这个组是很早的,这时候注册表好像还没有被载入呢。
我只能凭以前primo官方论坛里面帖子的记忆来回答问题,回答不一定很准,但是总体方向肯定是对的

点评

和哪里的磁盘签名作比较?vdf吗? 也就是说 vdf 要和它所在硬盘的磁盘签名一致? 文件路径呢?  详情 回复 发表于 2020-12-18 20:05
回复

使用道具 举报

98#
发表于 2020-12-18 21:14:38 来自手机 | 显示全部楼层
wintoflash 发表于 2020-12-18 20:05
和哪里的磁盘签名作比较?vdf吗?
也就是说 vdf 要和它所在硬盘的磁盘签名一致?
文件路径呢?

        romex官方论坛很不稳定,很难访问,我找了半天没找到那个帖子,我试图发帖,半天发不出去,郁闷。


当时官方的回复大概是这样子,primo驱动加载后,把d:\vdf\xxx.vdf加载到内存,好像是绝对路径写死的,具体写死在哪里不太清楚,可能是注册表,但我在注册表搜了下也没搜到,对于软件后台的东西不太清楚,还需要咨询他们哪些信息?我晚点在romex官方论坛发个帖子。
回复

使用道具 举报

99#
发表于 2020-12-18 22:10:16 | 显示全部楼层
本帖最后由 liuzhaoyzz 于 2020-12-19 15:02 编辑
wintoflash 发表于 2020-12-18 14:47
看了一下,vdf 没有文件头,和固定大小vhd差不多。
你这个 vdf 里面没有 bootmgfw.efi 啊,没法测试。
...

链接: https://pan.baidu.com/s/1gbTRQiwgrLbF04SciMBp-Q 提取码: dwe7

上传了个2.34GB的FT81.vdf完全镜像用于测试,这是单镜像模式,你的内存足够了吧。

感觉grub2需要采用类似NTBOOT的那套机制,确保能过BCD。


点评

没看到? NTBOOT的哪套机制?我怎么不知道? ntboot, wimboot, map 创建虚拟盘用的是同一套东西。  详情 回复 发表于 2020-12-19 23:05
回复

使用道具 举报

100#
发表于 2020-12-20 08:12:14 | 显示全部楼层
本帖最后由 liuzhaoyzz 于 2020-12-20 09:07 编辑
wintoflash 发表于 2020-12-19 23:05
没看到?

NTBOOT的哪套机制?我怎么不知道?

我说的是在内存中建立个img启动镜像,里面放bootmgfw.efi,bcd这些,只要过了BCD,加载system之后,img启动镜像的任务就完成了,这是我纯粹瞎猜,不懂瞎说的。你在NTBOOT移植的时候,说了下原理。

技术细节
wimboot 可以生成一个 bootmgfw.exe/bootmgr.exe 可识别的单分区 FAT32 虚拟盘, 将 bootmgfw.efi, bcd 等文件放入其中即可启动。BCD 文件为 bootmgfw.efi 读取的启动配置文件,其格式为 REGF (Windows 注册表)。关于 REGF,可以到这里了解更多。boot.sdi 文件为 bootmgfw.efi 启动 WIM 必须的 System Deployment Image 文件,可以到这里了解更多。wimboot 内置了一个 REGF/BCD 解析器,可以解析并自动修改 BCD 的内容;同时也内置了 boot.sdi 生成工具,可以自动生成所需的 boot.sdi。wimboot 启动方式与 NTBOOT 启动方式的主要区别是 wimboot 启动时,WIM 文件也放入FAT32虚拟盘中,而 NTBOOT 启动时,WIM 不在启动盘中。因此,wimboot 方式可以虚拟修改 WIM 内容,向其中插入文件而不用改变实际文件内容,NTBOOT 则不可以。wimboot 会将除了 bcd, boot.sdi, WIM 自身之外的所有文件都射入 WIM 的 \Windows\System32 目录下。但是由于 VHD 启动过程中需要从真实硬盘读取 VHD,所以 wimboot 方式无法启动 VHD。

点评

grub里面 (或者说 UEFI,以及操作系统) 都是要把硬件/硬件上的数据抽象化,是一层一层的。 文件这一层级的下面是文件系统,文件系统的下面是分区、分区表、磁盘。 wimboot/NTBOOT 创建的 FAT32 盘并不是真实存  详情 回复 发表于 2020-12-20 11:06
回复

使用道具 举报

101#
发表于 2020-12-20 09:06:48 | 显示全部楼层
本帖最后由 liuzhaoyzz 于 2020-12-20 09:36 编辑

另外,我说为啥访问romex论坛速度这么慢,原来他们的论坛服务器在国外,上个论坛还需要翻墙,发个帖子都发不了,发email杳无音讯,真难啊!https://forum.romexsoftware.com/zh-cn/viewtopic.php?f=35&t=2060&p=10254#p10254
为什么现在上主页得翻墙?否则打不开??连激活都得翻墙,否则打不开也激活不了
服务器是在国外的,可能是最近qiang的原因。。。




primo更新建议 - Romex Software 中文论坛 https://forum.romexsoftware.com/zh-cn/viewtopic.php?f=35&t=1695
a277383761 » 周一 7月 11, 2016 10:09 am
不知道官方是怎么想的,都过去了4年了,更新了一下5.7版本却只是这点小修复

官方难道不知道primo现在民间许多人用来制作ramos么,就是把c盘克隆进ramdisk盘里了。

我只是提个小小的意见如下,不管官方看不看的见,反正我是提了再说了

1.希望默认关联镜像为VHD格式--方便挂载或修改
2.希望生成的关联镜像无绝对路径。比如C:/XXX/XXX.VDF 未来把vdf复制到D:/XXX/XXX.VDF也可以启动
3.希望取代民间的ramos玩法自带克隆c进ramdisk盘中。

Support » 周二 7月 12, 2016 10:19 pm
谢谢您的建议!
5.7 版本主要是为了确保软件的稳定性,仅对发现的严重问题进行修复,不涉及到软件架构的改动。
目前我们正在开发6.0版本,将重新设计软件架构,优化性能并修复其它问题。您的建议我们也会逐步实现中。谢谢!

民间的ramos玩法是将c盘克隆进vdf,再修改注册表,然后利用G4D加载这个vdf启动。如果改用VHD为关联格式应该可以直接使用BCD这个VHD了。也同时解决了G4D不兼容UEFI启动的问题。




希望关联的镜像不要绝对路径 - Romex Software 中文论坛 https://forum.romexsoftware.com/zh-cn/viewtopic.php?f=35&t=1565
希望关联的镜像不要绝对路径
帖子  由 a277383761 » 周四 10月 16, 2014 4:26 pm

我们修改BCD时或者用G4D时,都能自动搜索加载 比如 E:\VHD\WIN7.IMG文件 可以直接写成 \VHD\WIN7.IMG

但我们的E:\VHD\P.VDF文件就不一样了,这必须是绝对路径,有时候我们机器发生了改变,盘符变了,它就挂载失败了。

以上这些细小的不同在固定的电脑上使用倒是没什么大问题的。

但把VDF文件关联到U盘上制作好的系统后,再将这个系统和VDF一起复制到另一个U盘上,百分百搜索不到此VDF文件了。希望PRIMO软件加载开机自动查找某文件夹里的VDF文件并自动挂载好哈哈哈哈

只是来提小意见的,只是希望下一个版本能有这方面的改进

谢谢建议!

不过这样也可能产生一个问题就是如果在不同分区下存在相同的镜像文件,可能就会产生混淆。另外一个问题就是软件实现上可能存在一定问题,不过这个我们会想办法解决。

希望下一版有这样的功能变化 - Romex Software 中文论坛 https://forum.romexsoftware.com/zh-cn/viewtopic.php?f=35&t=1682
帖子  由 a277383761 » 周日 5月 22, 2016 8:57 am

我只是随便提提,能有当然最好。不能就算了

1.直接采用vhd为关联镜像
2.没有绝对路径的要求,可以开机扫描每一个盘符的xxx.vdf镜像名加载
3.修复动态回收机制,目前的动态回收好像不可控也不是时时的
4.自动对齐4K

感谢您的建议!第1~2点我们有在考虑增加,第3点我们已经在改进了,不过涉及到底层结构改动比较大,所以还需要一段时间。第4点对于ramdisk来说,4K对齐没有必要,现在的方式是为了最大向下兼容。


primo 是怎么知道大镜像vdf的位置在哪呢 - Romex Software 中文论坛 https://forum.romexsoftware.com/ ... php?f=34&t=5164
由 liuzhaoyzz » 周日 12月 20, 2020 9:35 am

您好,grub4dos和grub2 UEFI版本需要与primo驱动进行对接,需要了解以下方面的信息:

primo 是怎么知道大镜像vdf的位置在哪呢?注册表写死的?
是通过磁盘签名确定磁盘的是吗?
和哪里的磁盘签名作比较?vdf吗?
也就是说 vdf 要和它所在硬盘的磁盘签名一致?
文件路径呢?

能否详细地说明下?越详细越好,谢谢!

romex官方论坛不能在国内建个镜像站吗?上个网站还要翻墙,翻墙软件都没有。太难了!



回复

使用道具 举报

102#
发表于 2020-12-20 12:06:51 | 显示全部楼层
本帖最后由 liuzhaoyzz 于 2020-12-20 12:16 编辑
wintoflash 发表于 2020-12-20 11:06
grub里面 (或者说 UEFI,以及操作系统) 都是要把硬件/硬件上的数据抽象化,是一层一层的。
文件这一 ...

看起来似懂非懂的。

grub2直接map xxx.vdf好像能够正确加载BCD,只是在进一步启动的时候winload.efi出错,可能是winload.efi不能正确加载grub2仿真虚拟磁盘里面的文件。也有可能是BCD不能正确加载它所指向的grub2仿真虚拟磁盘里面的winload.efi,导致抛出那个0xc0000225或者0xc000000f错误。


winload.efi我们是动不了了的,只有看下grub2在仿真磁盘方面能否单方面修改,以适配windows的BCD,winload.efi这些启动文件,骗过windows,达到启动的目的。


要么就想办法绕路解决,map一个img/vhd作为引导镜像:map --nb boot.img (hd0),但不启动,然后再map xxx.vdf (hd1),用img引导镜像里面的去启动xxx.vdf,chainloader (hd0)。不知道这样子加个img/vhd作为引导镜像中转与直接map xxx.vdf (hd1)启动,有没有区别,现在都是摸索着前进,前面没有路,没有理论。




点评

应该是你的vdf上bcd的配置不对。因为不存在你说的这种适配,winpe, VHD 都能正常启动。 BCD 上路径不应该用 BOOT/LOCATE。  详情 回复 发表于 2020-12-20 12:25
回复

使用道具 举报

103#
发表于 2020-12-20 15:07:55 来自手机 | 显示全部楼层
本帖最后由 liuzhaoyzz 于 2020-12-20 17:00 编辑
wintoflash 发表于 2020-12-19 23:05
没看到?

NTBOOT的哪套机制?我怎么不知道?

链接: https://pan.baidu.com/s/1gbTRQiwgrLbF04SciMBp-Q 提取码: dwe7

不好意思,我上传的时候改了个名字,上传到原目录了,UEFI目录有个2.34GB的FT81.vdf完全镜像用于测试,这是单镜像模式

BCD指向的问题,我晚点再试试。但是BIOS下面用boot/locate定位primo内存盘没问题呀,为啥UEFI下面不能定位?BIOS下面查找0x80,UEFI下面不是的吧?因为VHD用grub2直接map启动,好像没有磁盘序号的问题啊。

顺便问下,直接map模式,有没有各种类型之说?

点评

有区别。比如光盘启动,BIOS下 BOOT/LOCATE 读的是bootmgr同分区的文件,而 UEFI 下则是第一个 CDROM 设备里面的文件。硬盘可能也有这种区别。 现在grub2的map,如果不指定设备类型,会自己判断。优先级如下  详情 回复 发表于 2020-12-20 17:25
回复

使用道具 举报

104#
发表于 2020-12-20 20:44:53 | 显示全部楼层
本帖最后由 liuzhaoyzz 于 2020-12-20 20:51 编辑
wintoflash 发表于 2020-12-20 17:25
有区别。比如光盘启动,BIOS下 BOOT/LOCATE 读的是bootmgr同分区的文件,而 UEFI 下则是第一个 CDROM ...

非常感谢wintoflash大神详细的指导!

重大好消息!win8.1-primo-uefi-ramos成功启动!!!wintoflash大神给RAMOS-er打开了一个全新世界的大门!一个全新的UEFI-RAMOS时代即将到来!
世界上第一个基于primo单驱动+grub2制作的UEFI-WIN8.1RAMOS单镜像制作成功!
双镜像制作在路上!
WIN7、WIN10-primo-uefi-ramos在路上!


g4e启动失败,0xc000000e错误,原因不明。

win8.1-primo-uefi-ramos.jpg (212.32 KB, 下载次数: 108)

win8.1-primo-uefi-ramos.jpg
回复

使用道具 举报

105#
发表于 2020-12-22 19:51:21 来自手机 | 显示全部楼层
本帖最后由 liuzhaoyzz 于 2020-12-22 19:57 编辑

好消息!g4e/grub2成功启动WIN10-PRIMO-UEFI-RAMOS!

但是g4e/grub2直接map有碎片的文件好像都不行。g4d提示too many fragments,grub2好像是直接返回主菜单了。

点评

你说这个没意义啊。要手动执行命令,看报错。  详情 回复 发表于 2020-12-22 20:10
回复

使用道具 举报

106#
发表于 2020-12-22 21:22:24 | 显示全部楼层
wintoflash 发表于 2020-12-22 20:10
你说这个没意义啊。要手动执行命令,看报错。

以后再试试看,文件碎片我已经消除了,我对MS-DOS还算熟悉,在g4e/grub2界面,就是两眼一抹黑了,记不住命令,记不住文件路径,TAB命令补全有时候路径好像不行。

点评

tab补全区分大小写。  详情 回复 发表于 2020-12-22 21:28
回复

使用道具 举报

107#
发表于 2020-12-23 07:47:45 | 显示全部楼层
本帖最后由 liuzhaoyzz 于 2020-12-23 07:48 编辑
wintoflash 发表于 2020-12-22 21:28
tab补全区分大小写。

哦,知道了。

另外,我看到命令里面有fucksb“干掉安全启动”这样子的命令,是不是不那么雅观,Bypasssb,skipsb不好吗,就不担心国际友人笑话吗?

点评

我总感觉很多国人还是有一种自卑感,跟洋人交流时总是小心翼翼的,生怕洋人笑话。 看点好玩的: https://github.com/nvbn/thefuck https://github.com/sorellabs/fuck-you https://www.bilibili.com/video/av883  详情 回复 发表于 2020-12-23 09:09
回复

使用道具 举报

108#
发表于 2020-12-23 10:45:31 | 显示全部楼层
本帖最后由 liuzhaoyzz 于 2020-12-23 10:48 编辑
wintoflash 发表于 2020-12-18 20:05
和哪里的磁盘签名作比较?vdf吗?
也就是说 vdf 要和它所在硬盘的磁盘签名一致?
文件路径呢?

经过论坛询问和email咨询,romex官方很保守,说的不详细。

您好,grub4dos UEFI版本需要与primo驱动进行对接,需要了解以下方面的信息:
primo 是怎么知道大镜像vdf的位置在哪呢?注册表写死的?
是通过磁盘签名确定磁盘的是吗?
和哪里的磁盘签名作比较?vdf吗?
也就是说 vdf 要和它所在硬盘的磁盘签名一致?
文件路径呢?

您好!
是需要做RAMOS吗?Primo Ramdisk是根据创建ramdisk时指定的镜像文件的路径(盘符)加载镜像的。
如有问题,欢迎来信来电。
谢谢!
Romex Software 技术支持

是保存在注册表中的,不能修改的。您现在遇到的是什么问题?

具体是保存在注册表那个位置的?能否详细讲下?我没有搜索到,现在制作UEFI-WIN10-RAMOS失败,需要了解primo驱动的一些底层问题。

PrimoRamdisk创建ramdisk时使用的数据包是私有格式的,很抱歉这是不公开的。


无所谓了,已经做成功了,不需要知道那么底层的东西了。


回复

使用道具 举报

109#
发表于 2020-12-23 10:54:07 | 显示全部楼层
wintoflash 发表于 2020-12-23 09:09
我总感觉很多国人还是有一种自卑感,跟洋人交流时总是小心翼翼的,生怕洋人笑话。
看点好玩的:
https: ...

Linus Torvalds真的是什么都敢怼!怼天怼地怼宇宙的。

我感觉以前的boot-land,现在的reboot.pro上面,聚集了很多自由软件的技术大神、牛逼人物,你们似乎都挺喜欢在上面混的,我上这个论坛很少,网页打开慢,牛人很多,但我都没怎么打过交道,所以也不敢胡乱说话。
回复

使用道具 举报

110#
发表于 2020-12-27 20:35:39 | 显示全部楼层
本帖最后由 liuzhaoyzz 于 2020-12-27 20:51 编辑

大神,请问下这是怎么回事?grub2的crscreenshot模块截图反馈问题真的太爽了!


g4e情况类似。

27165416.png (8.83 KB, 下载次数: 129)

27165416.png

点评

map之后,再ls一下看看。 map之后的盘符默认是 vdX,比如 (vd0)。启动分区比如是 (vd0,1),启动这里面的efi试一试。  详情 回复 发表于 2020-12-27 21:00
回复

使用道具 举报

111#
发表于 2020-12-28 07:47:16 | 显示全部楼层
本帖最后由 liuzhaoyzz 于 2020-12-28 07:57 编辑

直接上图,好像没有成功。
另外,请问下,grub2有没有类似g4e的vol这样子的命令,用于快速确定盘符?

28074436.png (15.45 KB, 下载次数: 125)

28074436.png

点评

chainloader 没有报错啊。你得执行boot命令才能启动。 看你这种情况,应该是ntfs驱动没有正常工作吧。进efi shell看一下就知道了。 在控制台输 ls (hd0,1) 就可以显示各种信息。输入 ls (hd0 然后按 tab,就可  详情 回复 发表于 2020-12-28 09:56
回复

使用道具 举报

112#
发表于 2020-12-28 10:34:19 | 显示全部楼层
本帖最后由 liuzhaoyzz 于 2020-12-28 10:49 编辑
wintoflash 发表于 2020-12-28 09:56
chainloader 没有报错啊。你得执行boot命令才能启动。
看你这种情况,应该是ntfs驱动没有正常工作吧。 ...


当时直接用菜单启动,选择之后直接跳回菜单。boot命令晚点试下。

ntfs驱动有可能有一定兼容性的问题,我试过了这台电脑上面,手工制作的单镜像可以启动,用批处理创建的单镜像又不行,WIN7单镜像出问题的概率似乎多点,WIN8 WIN10似乎没发现问题,镜像8GB左右。我手工用单镜像制作可以启动,用芈员外的一键制作单镜像模式,WIN8 WIN10似乎没发现问题,WIN7就不行,可能是一键制作程序有问题。现在的问题还没有准确地定位,我看到grub2抛出这个错误所以问问看。

ntfs驱动似乎不支持压缩模式,我看有网友反馈NTFS压缩的话,NTFS驱动似乎不能正常识别,akeo的驱动据说支持NTFS压缩,但是又不能适配grub2。我试了compact wimboot压缩双镜像模式似乎也是无法启动。还有较多的地方需要进行研究。

grub2获取卷标不能像g4e一个简单的vol那样遍历并显示出来吗?probe命令对于非linux-er来说,记不住啊。


哦,ls -l似乎可以遍历卷标,不然的话分不清哪个是哪个盘符。
        

点评

refind 的 NTFS 驱动不支持压缩。efifs (就是你说的 akeo) 驱动源码来自 grub2,按理说应该支持 NTFS 压缩。 这不存在什么适配不适配 grub2 的问题。grub2, grub4dos 加载驱动用的是同一套代码,都是我从 efi s  详情 回复 发表于 2020-12-28 11:15
回复

使用道具 举报

113#
发表于 2020-12-28 11:24:04 | 显示全部楼层
wintoflash 发表于 2020-12-28 11:15
refind 的 NTFS 驱动不支持压缩。efifs (就是你说的 akeo) 驱动源码来自 grub2,按理说应该支持 NTFS ...

        虽然NTFS驱动不靠谱,但是他简单啊,加载这个驱动之后,芈员外的部分代码可以复用,如果搞FAT32+NTFS方式,代码就要调整很多,这个改代码、测试工作量太大了,我比较懒散,小圈子的人能用就行了,不是很追求普遍通用,相比较svbus的简单来说,primo驱动相关的事情比较复杂,即使大改,也是作为未来的长期计划。

我所说的适配,指的是我试过了akeo上面的1.7版本的驱动,如果搭配g4e就可以启动RAMOS,如果搭配grub2就不能启动RAMOS,我也感到非常的奇怪,akeo驱动源码来自grub2,为啥反而不能跟grub2好好地搭配。
回复

使用道具 举报

114#
发表于 2020-12-28 11:51:50 | 显示全部楼层
本帖最后由 liuzhaoyzz 于 2020-12-30 16:15 编辑
wintoflash 发表于 2020-12-28 11:15
refind 的 NTFS 驱动不支持压缩。efifs (就是你说的 akeo) 驱动源码来自 grub2,按理说应该支持 NTFS ...

另外,我也不是没有想过抛弃这个ntfs驱动,这个帖子前面547楼我就有这样子的想法。大概这样子设想的:


menuentry "RICH-RAMOS-2020-1225-09141.vdf" "/vdf/SX7P2/RICH-RAMOS-2020-1225-09141.vdf" {
search --no-floppy --set=boot --file /vdf/SX7P2/boot.img
map -nb ($boot)/vdf/SX7P2/boot.img
search --no-floppy --set --file $2
map $2
}

这个boot.img里面用一个激活的FAT32分区,放个EFI引导文件bootx64.efi以及BCD,指向vdf里面的分区,但第一个map不启动,hook上;第二个map应该不需要ntfs驱动的支持了吧,我不知道这样子做从理论上是否可行。问题是第二个map可能会直接查找$2里面的/EFI/boot/bootx64.efi,找不到可能就会报错。好像类似于你移植的NTBOOT这样子的原理。







点评

稍微改了一下ntboot对磁盘的判定。 现在也可以用 ntboot 启动map出来的vhd里面的windows系统了。 在我的电脑上试是可以的,那就不用加载万恶的ntfs驱动了。 我又不能顺着网线看你的电脑,我也没办法知道。  详情 回复 发表于 2020-12-28 20:56
你说反了吧。 map的第一个磁盘应该是你的 vdf,map -n /xxx.vdf map的第二个磁盘才是 fat32 boot.img,从这上面启动,map /boot.img。 还有,不查找启动的参数是 '--nb',或者简写为 '-n',不是 '-nb'。  详情 回复 发表于 2020-12-28 12:02
回复

使用道具 举报

115#
发表于 2020-12-28 12:08:51 来自手机 | 显示全部楼层
本帖最后由 liuzhaoyzz 于 2020-12-28 12:23 编辑
wintoflash 发表于 2020-12-28 12:02
你说反了吧。
map的第一个磁盘应该是你的 vdf,map -n /xxx.vdf
map的第二个磁盘才是 fat32 boot.img, ...


        哦,对的,你说的是对的。


大佬牛逼啊!按照你给的那一串命令,boot之后,成功启动了,出现了怪异的画面,后台是grub2,前台是win7四色旗徽标!
这个不是NTFS驱动的问题。

那么,这到底是为什么出现failed to load image这样子的情况?为什么菜单不行?
回复

使用道具 举报

116#
发表于 2020-12-28 22:06:32 来自手机 | 显示全部楼层
本帖最后由 liuzhaoyzz 于 2020-12-28 22:23 编辑

如果能够抛弃ntfs驱动将会大大提高兼容性。
map -n --mem --rt (hd0,msdos2)/ramos.vhd
ntboot --win --efi=(vd0,msdos1)/EFI/boot/bootx64.efi (vd0,msdos1)
我这边试了不行啊,里面有svbus驱动,结果0xc000000f,或者7B蓝屏,我不知道错在哪里了?   是不是必须用bootmgfw.efi作为名字?我手机回复的,打字好难。今天没时间继续测试了。

另外有没有好办法只搜索定位虚拟盘上面的bootmgfw.efi,不搜索物理硬盘上的bootmgfw.efi?

另外grub2命名不都是(hd0,msdos1)这种吗?你发的菜单(hd1,4)仅仅是个示意的意思是吗?

failed to load image我上面有截图呀?

IMG_20201228_215213.jpg (26.85 KB, 下载次数: 179)

IMG_20201228_215213.jpg

IMG_20201228_215153.jpg (32.91 KB, 下载次数: 191)

IMG_20201228_215153.jpg

点评

分区表可以不写的。(hd0,1) 一样可以。 是不是你的vhd里面的winload.efi路径不是 \Windows\System32\boot\winload.efi?那需要指定 winload的路径。 比如 ntboot --win -e (vd0,1)/efi/boot/bootx64.efi --win  详情 回复 发表于 2020-12-28 22:27
回复

使用道具 举报

117#
发表于 2020-12-28 22:52:50 来自手机 | 显示全部楼层
今天没法试了。晚点再试试看windows路径的问题,如果是路径的问题,对于win7 8是不同的,有点麻烦,菜单不好通用?
        你不是说 "当时直接用菜单启动,选择之后直接跳回菜单。boot命令晚点试下",但是手动输命令可以吗?
是的
回复

使用道具 举报

118#
发表于 2020-12-29 08:15:42 | 显示全部楼层
本帖最后由 liuzhaoyzz 于 2020-12-29 10:30 编辑
wintoflash 发表于 2020-12-28 22:27
分区表可以不写的。(hd0,1) 一样可以。

是不是你的vhd里面的winload.efi路径不是 \Windows\System32 ...

map -n --mem --rt (hd0,msdos2)/ramos.vhd
ntboot --win -e (vd0,1)/efi/boot/bootx64.efi --winload=\\Windows\\System32\\winload.efi (vd0,1)

早上起来试了下,结果如下:
1、WIN7启动后一台台式电脑7B蓝屏了(晚点我再试试,看下是否有其他原因)

另外一台笔记本WIN7成功启动。
2、WIN8.1启动成功。
3、WIN10启动成功。


有以下疑问:

1、能否自动搜索虚拟盘,不要指明分区这种?
ntboot --win -e (vd0)/EFI/boot/bootx64.efi --winload=\\Windows\\System32\\winload.efi (vd0)
这样子的话,不需要搜索bootx64.efi在vd0的哪个分区,因为有时候里面是单分区,有时候是双分区(激活FAT32+NTFS,或者GPT分区最少两个),而如果用search --no-floppy --set --file /EFI/boot/bootx64.efi,直接全盘搜索bootx64.efi,可能hd0,vd0上面都有,搜索到不匹配的bootx64.efi/bootmgfw.efi会不会有兼容性问题?
如果直接指明vd0,就可以直接自动查找vd0里面的bootx64.efi,最好激活的分区优先。
就好比g4e里面可以直接chainloader (hd-1),我不用担心bootx64.efi是在(hd0,0)或者是(hd0,1),只要是某个(hd-1),自动搜索(hd-1)里面的bootx64.efi,激活分区优先.

最后的(vd0)参数指明的是windows所在的盘符,如果能够自动定位windows目录,不需要指明分区,那就更好了。就不需要担心windows倒底是在(vd0,1)还是在(vd0,2)这样的问题了。

或者,有没有办法让search有参数直接搜索虚拟磁盘?这样的话,直接在用户侧就可以解决文件定位的问题。
哦,似乎在vhd内部放两个唯一名字的标志文件,也可以达到目标。搜索bootx64.efi用一个标志文件,搜索windows目录用一个标志文件,因为vd0内部,bootx64.efi和windows不一定在同一个分区。

2、WIN8 10似乎默认搜索\Windows\system32\boot\winload.efi,WIN7好像默认是\Windows\system32\winload.efi吧(这个有待大家指正)
这个能否做到自适应,因为启动之前我不知道这个vhd里面倒底是WIN7 还是WIN8.1 WIN10,菜单不容易通用,如果ntboot内部能够查找\Windows\system32\boot\winload.efi或者\Windows\system32\winload.efi是否存在并自动指定就好了。

3、用ntboot启动之后,屏幕的分辨率好像被锁定了不能更改?这个我不确定,试了笔记本好像又没事,可能是驱动的问题。





点评

加上 --highest=no 参数试试。默认是 highest=yes,也就是强制最高分辨率。 这样做不符合 UNIX 的哲学:"程序应该只关注一个目标,并尽可能把它做好。让程序能够互相协同工作。" 目前 GRUB 已经有了判断文件  详情 回复 发表于 2020-12-29 10:56
vhd 不是可以修改的吗? 我的建议是修改vhd来符合一般的引导,而不是修改ntboot,当然,修改ntboot也可以,但前提是不影响启动效率。 所以我建议: ntboot使用了 --win 参数,就默认bootmgfw.efi为win分区的  详情 回复 发表于 2020-12-29 10:31
回复

使用道具 举报

119#
发表于 2020-12-29 09:28:51 | 显示全部楼层
wintoflash 发表于 2020-12-13 17:29
如果文件无碎片,可以加 -l 参数,先转成 blocklist 格式加速读取。
如果文件有碎片,可能可以,也 ...
如果文件无碎片,可以加 -l 参数,先转成 blocklist 格式加速读取。
如果文件有碎片,可能可以,也可能不行。

本人亲测了-l这个参数,7GB的vhd加载到内存,结果如下:
1、把SX70211.vhd放到sata ssd上面,没有碎片。不带-l参数从0→100%,用时1分23秒。
menuentry "SX70211.vhd-svbus" "/VHD/SX70211.vhd" {
        efiload /EFI/grub/ntfs_x64.efi
        search --no-floppy --set --file $2
        map --mem --rt $2
}


加上-l参数,用时23秒。
menuentry "SX70211.vhd-svbus-l" "/VHD/SX70211.vhd" {
        efiload /EFI/grub/ntfs_x64.efi
        search --no-floppy --set --file $2
        map --mem --rt -l $2
}



2、把SX70211.vhd放到机械硬盘上面,wincontig显示4个碎片,在g4e下用blocklist看了显示有3个碎片。
不带-l参数从0→100%,用时1分13秒。
加上-l参数从0→100%,用时1分03秒


g4e用时1分11秒。
title WIN7X64-SVBUS (/VHD/SX70211.vhd)
find --ignore-floppies --ignore-cd --set-root /EFI/grub/ntfs_x64.efi
load /EFI/grub/ntfs_x64.efi
find --ignore-floppies --ignore-cd --set-root /VHD/SX70211.vhd
map --mem --top /VHD/SX70211.vhd (hd)
chainloader (hd-1)



我的结论:
1、如果vhd没有碎片,加上-l参数会极大地提高读盘速度。
2、如果vhd有碎片,加上-l参数提高读盘速度不是太多,机械硬盘上面加快了10秒,加上-l参数之后与g4e读盘速度几乎没有差别(可能有卡表误差);有碎片的ssd上面未测试。
3、无论是否有碎片,加上-l参数,无论是直接map,还是map --mem都可行。
所以最终结论是:grub2的map最好加上-l参数。

回复

使用道具 举报

120#
发表于 2020-12-29 11:03:17 | 显示全部楼层
本帖最后由 liuzhaoyzz 于 2020-12-29 11:20 编辑
ntboot使用了 --win 参数,就默认bootmgfw.efi为win分区的 \Windows\Boot\EFI\bootmgfw.efi ,winload.efi 为win分区的 \Windows\System32\Boot\winload.efi

我的电脑,只有一个1GB的FAT32启动分区,其他全部都是vhd,就没有\Windows目录,只有\EFI\Microsoft\Boot\bootmgfw.efi,winload.efi也全部都在vhd里面。

这样,正常的win启动只需 ntboot --win (vd0,1)
前面说了vhd里面可能有多分区啊。

另外,标志文件的办法,感觉有点麻烦。

        

点评

你的电脑没有 \Windows 目录,那更简单了 你map了某个vhd后,就只有 (vd0) 的某个分区上有 \Windows 这样只要 search -n -s -f \Windows\Boot\EFI\bootmgfw.efi ntboot ($root) 就只会引导 (vd0)上有 \Window  详情 回复 发表于 2020-12-29 18:33
回复

使用道具 举报

您需要登录后才可以回帖 登录 | 注册

本版积分规则

小黑屋|手机版|Archiver|捐助支持|无忧启动 ( 闽ICP备05002490号-1 )

闽公网安备 35020302032614号

GMT+8, 2024-5-6 15:08

Powered by Discuz! X3.3

© 2001-2017 Comsenz Inc.

快速回复 返回顶部 返回列表