无忧启动论坛

标题: MultiOS-USB 初步体验 [打印本页]

作者: 不点 时间: 2025-1-28 10:40
标题: MultiOS-USB 初步体验
前几天，看到了启动软件 MultiOS-USB 的介绍：

http://bbs.wuyou.net/forum.php?mod=viewthread&tid=444229

简单来说，它是和 Ventoy 类似的软件。我就把它安装到 U 盘，初步评估了一下，看看有
什么优缺点。

1、它采用 GPT 分区结构，这算是优点还是缺点？我觉得，对于不支持 GPT 的老电脑，这可能会造成一些麻烦。比如说，由于找不到 U 盘上的 MBR 分区（Volume 卷）信息，主板有可能不承认 U 盘为合法启动盘，从而拒绝从 U 盘启动。但也有可能歪打正着，使得启动成功率比 MBR 分区结构还要高。当然了，只有实践才能检验；空口说，都是瞎猜，都不算数。
2、我拷贝了 gmy 的那个 EFI.iso 到 ISOs 文件夹下，它不能显示相应的启动项。这方面的工作，它不如 Ventoy 做得细致。它只能支持它的官网列出的那些 iso 文件。这个缺点也是相当严重的，说明基础工作还很不完善。

但它也有优点。貌似它的布局比较自由，有可能把它改造成“第二启动”—— 就是说，让别的启动软件作为第一启动，然后再用链式加载的方法来启动它。

作者: yc2428 时间: 2025-1-28 11:09
多探索，多体验

作者: rgfwqx@163.com 时间: 2025-1-28 12:19
看看

作者: 小灰兔 时间: 2025-1-28 12:19
谢谢分享

作者: Anson4 时间: 2025-1-28 13:05
原帖的说明显示支持 - BIOS and UEFI support

作者: chairmansu 时间: 2025-1-28 13:16
有體驗過但不是很順手

作者: chen463 时间: 2025-1-28 13:26
本帖最后由 chen463 于 2025-1-28 14:58 编辑

安装步骤
1）使用上面提到的软件将「image.img」写入磁盘
2）使用 Windows+R 开启执行，输入 diskmgmt.msc 并按 Enter
3）右键单击 USB 上未分配的空间，然后选择新简单卷
  - 选择尺寸：如您所愿，最大？
  文件系统：fat32
  卷标：MultiOS-USB
4）将「files.zip」解压缩到新建立的磁盘
5）复制 ISO 文件，然后从 USB 启动计算器

玩得开心！

我的操作方式：
1.先U盘前面格式一个[MBR-FAT32]分区-MultiOS
2.将「image.img」解压到此FAT32分区- MultiOS\EFI，\GRUB
3.将「files.zip」解压缩到新建立的磁盘文件系统：fat32
  卷标：MultiOS-USB，\ ISOs，\ MultiOS-USB，完成启动UEFI。

可能是不会使用它？WIM无法启动，ISO没显示，使用失败…比E2B，AIO功能少

作者: wang1126 时间: 2025-1-28 16:15
谢谢楼主分享

作者: wintoflash 时间: 2025-1-28 21:31

我拷贝了 gmy 的那个 EFI.iso 到 ISOs 文件夹下，它不能显示相应的启动项。这方面的工作，它不如 Ventoy 做得细致。它只能支持它的官网列出的那些 iso 文件。这个缺点也是相当严重的，说明基础工作还很不完善。

1. MultiOS-USB 是根据 ISO 的文件名来判断是否位于支持列表中的。
2. MultiOS-USB 用的是官方版 GRUB 2 (打了一些安全启动方面的补丁)。
官方版 GRUB 2 不支持磁盘仿真 (map功能)，没有一个"托底"的方式来支持所有 ISO。

作者: 不点 时间: 2025-1-29 09:14

wintoflash 发表于 2025-1-28 21:31
1. MultiOS-USB 是根据 ISO 的文件名来判断是否位于支持列表中的。
2. MultiOS-USB 用的是官方版 GRUB 2 ...

感谢您的回复，非常好！

我也注意到了它是根据文件名来逐个处理。

官方 grub2 不支持磁盘仿真，它居然只用 loopback 就能支持这么多的 iso，我亲测了微软最新的 Win11 24H2，成功进入正常的 Windows 安装流程！

既然不需要 map，那也算是一个不错的思路。也许，将来的 iso 制作者，都会朝着这样一个方式靠拢，支持这种启动模式。

本质上是 “你支持他”或 “他支持你”的问题。你支持他，那就费劲。他支持你，那就省事了。

作者: 不点 时间: 2025-1-29 10:28
我按照它提供的方法，在 Windows 下制作了 gpt 格式的启动 U 盘。U 盘前端 25M 是 FAT 格式的分区，用来存放 grub 引导程序。剩余空间格式化为 NTFS 分区，这样就能够存放大于 4G 的 iso 文件了。

我试着把 FAT 分区的文件复制到我的另外一个安装了 grub4dos 的 U 盘上（MBR 结构），在 BIOS 下让 grub4dos 用 kernel 命令加载 core.img，来启动 grub2。结果是，能够进入 grub 命令行，但无法执行后续的步骤。发现 prefix 变量的值为 (hd0,gpt1)/grub，而我的环境下，这应该是 (hd0,msdos1)/grub。在命令行手动把 prefix 和 root 变量都调整好，用 configfile 再加载它的 grub.cfg，这样也还是不能成功启动 win11 的 iso。

我想，这个 core.img 是专门用于 (hd0,gpt1)/grub 的，如果 grub 的文件（即，各种 mod 文件）是在 (hd0,msdos1) 之下，core.img 就出问题了。这是这个 core.img 不够灵活的方面。奇怪的是，我在命令行下纠正 prefix 变量和 root 变量，也未能有效（后续启动 iso 失败了）。这说明 core.img 太过于限制它自己的位置了。不知有没有一种补救措施（workaround），能够让 grub4dos 在加载 core.img 之时，告知 core.img 的主程序： prefix 和 root 等变量应该改变成某个希望的值。

作者: 不点 时间: 2025-1-29 11:05
本帖最后由不点于 2025-1-29 13:20 编辑

既然 grub2 的 core.img 只能放在 (hd0,gpt1) 分区下，我就只好顺从它了。以下这个测试是成功的，证明了 grub4dos 的 kernel 加载 core.img 的方法是正确的。

当电脑进入 grub2 的菜单时，我按 c 进入命令行，然后执行 ntldr /grldr 来加载 grub4dos，执行 boot 命令后就进入 grub4dos 了。进入 grub4dos 后，我又用 kernel 加载 core.img，这次就能成功启动 win11 的 iso 了。也就是说，只要保证 core.img 所在的盘是 (hd0,gpt1)，它就能够成功。反之，如果不在 (hd0,gpt1)上，它就毛病百出。

这里要提到一个细节，免得朋友遇到时被吓坏了。

当我在 grub2 下执行 ntldr /grldr 进入 grub4dos 后，花屏了！但它不是死机，而是可以摸黑操作。我摸黑敲入几个 c 键进入命令行，再摸黑敲入几个回车，再摸黑敲入 graphicsmode 3 命令，进入文本模式，这是成功的，屏幕可以看见命令提示符了。

好吧，我猜，在执行 ntldr /grldr 的时候，处于 grub2 的图形模式。而继续执行 boot 命令的时候，grub2 未能自动切换到文本模式，导致图形模式处于 “未正常退出”的状态。因此，进入 grub4dos 后就花屏了。

上述 graphicsmode 3 虽然可以进入文本模式暂时解决难题，但假如再次尝试用 graphicsmode 命令进入图形模式，照样会花屏。也就是说，图形模式已经无法正常运转了。

我记得 grub4dos 的 boot 命令会自动执行切换到文本模式的步骤（也就是说，能够干净地退出图形环境）。所以，grub4dos 启动别的系统或者启动别的引导管理器，都不会出现问题。

我不知道 grub2 用什么命令可以退出图形模式。假如能够退出图形模式，我想，这就有希望解决花屏问题了。

以下是构思：

此刻处于 grub2 的图形模式 ----->
执行 ntldr /grldr ------>
执行某条命令退出 grub2 的图形模式 ----->
执行 boot 命令 ----->
这样，进入 grub4dos 后，看看图形模式是否正常。如果正常，说明问题的症结确实找到了。

作者: wintoflash 时间: 2025-1-29 12:15

不点发表于 2025-1-29 10:28
我按照它提供的方法，在 Windows 下制作了 gpt 格式的启动 U 盘。U 盘前端 25M 是 FAT 格式的分区，用来存 ...

这个是作者故意做的限制。在生成core.img时已经写死了gpt分区。https://gitlab.com/MultiOS-USB/g ... ref_type=heads#L118

作者: wintoflash 时间: 2025-1-29 12:16

不点发表于 2025-1-29 11:05
既然 grub2 的 core.img 只能放在 (hd0,gpt1) 分区下，我就只好顺从它了。以下这个测试是成功的，证明了 gr ...

terminal_output console

作者: 不点 时间: 2025-1-29 12:26

wintoflash 发表于 2025-1-29 12:16
terminal_output console

刚刚试验了，
terminal_output console
和
terminal_output vga_text
都可以解决问题。

在执行 grub2 的 boot 命令之前，执行以上两条命令之一，即可解决花屏问题。

作者: 不点 时间: 2025-1-29 12:46

wintoflash 发表于 2025-1-29 12:15
这个是作者故意做的限制。在生成core.img时已经写死了gpt分区。https://gitlab.com/MultiOS-USB/grub/-/b ...

这应该不是他故意限制。grub-mkimage 这条命令必须有参数 --prefix，否则报错。由于他使用 gpt 分区，所以他填的是 gpt1，这是正确的，所以有错也不是他的错，而是 grub2 本身的限制造成的。

作者: 不点 时间: 2025-1-29 14:01
要想让 grub2 的 core.img 支持“自由拼装”，那是不容易的。这些天绞尽脑汁，也未能有什么突破。

在 EFI 架构下，根本不存在这种问题；都是 efi 文件，互相调用即可。

从这个角度看，还是 BIOS 尽快消失比较好，各种混乱都会减少。

另外，既然基于 loopback 都能做 ISO 的安装工作，那也太 NB 了吧？这比基于磁盘虚拟的软件，难度更高吧？所以，这个项目要是真能做好的话，那它给人的震撼力，还是蛮大的。总之，这个软件值得关注。

作者: wintoflash 时间: 2025-1-29 14:13

不点发表于 2025-1-29 12:46
这应该不是他故意限制。grub-mkimage 这条命令必须有参数 --prefix，否则报错。由于他使用 gpt 分区，所 ...

(,gpt1)改成(,1)就可以了

作者: 不点 时间: 2025-1-29 14:41

wintoflash 发表于 2025-1-29 14:13
(,gpt1)改成(,1)就可以了

确实，1 的适应性就比较大。我这也是惯性思维，所以未能意识到 gpt1 是有问题的。

我这里没有编译环境。您能给个编译好的 core.img 吗？

作者: liuzhaoyzz 时间: 2025-1-29 18:02
本帖最后由 liuzhaoyzz 于 2025-1-29 18:09 编辑

不点发表于 2025-1-29 14:41
确实，1 的适应性就比较大。我这也是惯性思维，所以未能意识到 gpt1 是有问题的。

我这里没有编译环境 ...

core.img根本就不需要编译，不需要搭建编译环境，用grub-mkimage命令定制就可以实现目标，那个不叫做编译，叫做定制。定制的core.img可以全盘搜索任何一个盘符的/boot/grub/grub.cfg菜单，实现跟grub4dos一样的全盘找菜单的目的，论坛里有帖子，我的那个SX_linux_pe安装器中，有个定制grub2的core.img的批处理，搜索定制，看一眼就知道了，照葫芦画瓢即可，我回老家了，手机回帖不方便搞这个。

作者: 不点 时间: 2025-1-29 18:44

liuzhaoyzz 发表于 2025-1-29 18:02
core.img根本就不需要编译，不需要搭建编译环境，用grub-mkimage命令定制就可以实现目标，那个不叫做编 ...

http://wuyou.net/forum.php?mod=viewthread&tid=417233&extra=page%3D1&page=3

搜到这了，这个是用于 EFI 的，不是用于 core.img 的，而 core.img 才是用于 BIOS 的版本。

前面 wintoflash 说过，MultiOS-USB 修改了 grub2，如果不用 MultiOS-USB 自己的 grub2 版本，而用其他的版本，可能会因缺少某些功能而无法工作。

作者: liuzhaoyzz 时间: 2025-1-29 19:35

不点发表于 2025-1-29 18:44
http://wuyou.net/forum.php?mod=viewthread&tid=417233&extra=page%3D1&page=3

搜到这了，这个是用于 ...

core.img确实是用于BIOS的。如果他修改了GNU grub2，那就要把grub-mkimage命令定制用于他修改的版本了，他应该有分享他编译之后的grub2了吧，但是就查找菜单这一项功能是不需要重新编译他修改的grub2的，只需要用grub-mkimage命令重新定制下查找菜单的命令即可。

作者: wintoflash 时间: 2025-1-29 19:45

不点发表于 2025-1-29 14:41
确实，1 的适应性就比较大。我这也是惯性思维，所以未能意识到 gpt1 是有问题的。

我这里没有编译环境 ...

core.zip (101.37 KB, 下载次数: 31)
具体能不能用我没试过。

作者: wintoflash 时间: 2025-1-29 20:04
本帖最后由 wintoflash 于 2025-1-29 20:26 编辑

不点发表于 2025-1-29 09:14
感谢您的回复，非常好！

我也注意到了它是根据文件名来逐个处理。

既然基于 loopback 都能做 ISO 的安装工作，那也太 NB 了吧？这比基于磁盘虚拟的软件，难度更高吧？

在实现难度上 loopback 更简单。
loopback 只要保证在 grub 内部有效就行了，退出 grub 之后就不存在了。

也许，将来的 iso 制作者，都会朝着这样一个方式靠拢，支持这种启动模式。

事实上，Linux 的 ISO 有相关的启动规范 (非强制性)：https://www.supergrubdisk.org/wiki/Loopback.cfg
几乎所有基于 Ubuntu 的发行版、少部分基于 Debian 的发行版、Manjaro、grml、SystemRescue 等支持这个规范。
另外，大多数 Linux 发行版也支持 bootloader 通过传递某个内核参数来方便系统在启动过程中挂载 ISO。
https://github.com/a1ive/a1ive.g ... r/grub2_loopback.md
对我来说，如果某个 Linux 发行版连这种参数都不支持，那就是故意不想让用户使用它的 ISO。

这是这个 core.img 不够灵活的方面。奇怪的是，我在命令行下纠正 prefix 变量和 root 变量，也未能有效（后续启动 iso 失败了）。这说明 core.img 太过于限制它自己的位置了。不知有没有一种补救措施（workaround），能够让 grub4dos 在加载 core.img 之时，告知 core.img 的主程序： prefix 和 root 等变量应该改变成某个希望的值。

用户可以自由地用grub-mkimage程序生成自己定制的core.img。用户当然可以考虑各种情况，生成一个在各种情况下都能正常启动的core.img，也能生成一个只能在特定环境下才正常的core.img。
这有点像grldr的内置菜单，你只能建议用户不要修改它，而不能完全阻止用户修改它。

作者: 不点 时间: 2025-1-29 22:47

wintoflash 发表于 2025-1-29 19:45
具体能不能用我没试过。

先来报告成功，是牛的一劈，太绝了！

作者: nianyueriPE 时间: 2025-1-29 23:04
GPT不是什么大缺点吧，至少我遇到的电脑，往gpt中安装UD做成混合分区表还没遇到不能启动的

作者: nianyueriPE 时间: 2025-1-29 23:11
其实只要系统能在启动后挂载iso就行，管他是map还是loopback。之前用过的grub2文件管理器挂载Windows安装盘安装Windows的原理就是利用wimboot把挂载软件、winpeshl.ini和文件路径cfg传入boot.wim加载后的pe镜像，让挂载软件先挂载iso再启动setup.exe安装Windows。

作者: 不点 时间: 2025-1-29 23:28
用原版 core.img 是不成功的，用 wintoflash 的改造版是成功的。

说说我的操作。

我基于以前制作的“一盘走天下”自由拼装修改版，添加了 multios-usb 的支持。到今天为止，算是彻底获得了成功。

一盘走天下【自由拼装修改版】，是在 U 盘建立两个分区，第一个分区是 FAT32，负责启动，分区大小任意，我的是 30G左右。第二分区是 NTFS，负责存放大文件，分区大小任意，我的是分配了剩余空间，应该大约有 400G 以上吧。EFI 文件夹就在 FAT32 上，grldr 以及 menu.lst 也在 FAT32 上。MBR 上安装 grldr.mbr，或者 wee 也行。EFI 里面存放的是 g4e 的启动文件。

把 multios-usb 的 FAT 里面的内容，都拷贝到 FAT32 这个分区。当然，EFI 会有冲突，因为大家都要占据 BOOTx64.efi 这个文件名。我肯定要保留原先的 g4e，而把来自 multios-usb 的同名文件进行更名。然后，在 menu.lst 中增加一项，链式加载 multios-usb 的那个 efi 文件。因此，EFI 的操作非常简单，根本不是个事。

multios-usb 另外一个存放 ISOs 的分区（包括 ISOs 和 multios-usb 两个文件夹），全部拷贝到 NTFS 分区上。

当我用 BIOS 启动时，我尝试用 grub4dos 加载 multios-usb 的 core.img，结果就是，只能进入命令行，无法进入 multios-usb 的菜单界面。前面帖子已经说了，无论如何折腾，都是失败，即使设法勉强进入了菜单，也不能成功启动 Win11 的 iso。

现在，用 grub4dos 加载 wintoflash 给的这个 core.img，就完美解决了。这个新的 core.img 可以放在任何地方，不需要删除原来的 core.img。当然了，旧的 core.img 也没有用处了，确实可以删除。

将来我会把这个过程，在“一盘走天下【自由拼装修改版】”那个帖子中，加以详细解释。

作者: 不点 时间: 2025-1-29 23:53

nianyueriPE 发表于 2025-1-29 23:04
GPT不是什么大缺点吧，至少我遇到的电脑，往gpt中安装UD做成混合分区表还没遇到不能启动的

存在皆合理。各种方式，都是偏爱，没有好坏优劣。根据场景的不同，会存在细微差异。

譬如说，假如要启动一台老旧电脑，它不支持 GPT，你想查看 U 盘的内容，就不方便，因为 U 盘弄成了 GPT 格式。虽然你能顺利启动，但不等于说，启动以后，你都很顺利。你可能会磕磕绊绊的，出现一些小毛病，不太舒服。

我在老的 XP 电脑上插上 exFAT 格式的 U 盘，都遇到障碍呢。还得为 XP 添加一个 exFAT 的驱动，才能使用那个 U 盘。而更常见的一个问题是，Win10 之前的系统，不支持 U 盘多分区，只能看见一个分区。

作者: liuzhaoyzz 时间: 2025-1-30 15:12

不点发表于 2025-1-29 23:53
存在皆合理。各种方式，都是偏爱，没有好坏优劣。根据场景的不同，会存在细微差异。

譬如说，假如要启 ...

MultiOS-USB用MBR分区也行吧？

作者: 不点 时间: 2025-1-30 19:58

liuzhaoyzz 发表于 2025-1-30 15:12
MultiOS-USB用MBR分区也行吧？

用了 wintoflash 改造后的 core.img 之后，这就没问题了，可以适应 MBR 和 GPT。否则，原版的 core.img 只认 GPT 格式。请看我前面的描述，尤其留意，我的一盘走天下【自由拼装修改版】，就是 MBR 分区结构。

作者: AcidBurn 时间: 2025-1-31 06:44
谢谢楼主的分享!

作者: liuzhaoyzz 时间: 2025-1-31 09:55

不点发表于 2025-1-30 19:58
用了 wintoflash 改造后的 core.img 之后，这就没问题了，可以适应 MBR 和 GPT。否则，原版的 core.img ...

懂了。

作者: 不点 时间: 2025-1-31 10:40
试着深入思考一下 ISO 的启动问题。

ISO 是古老的启动盘格式——光盘格式。古老的启动盘格式有好几种，比如软盘格式、硬盘格式。其中，软盘格式正处于被淘汰、被消灭的状态。光盘格式能够坚持多久？这无法断言。我只能说，UEFI 时代的主板，现在还在支持光盘格式。

ISO 格式，除了它是一种主板支持的“启动”格式以外，它还表现为一种“打包”格式。像 cpio 和 tar 这样的格式，就属于“打包”格式。能“打包”，也就能“解包”。

ISO 作为“启动”格式，它有 BIOS 的“引导头”（即，bootsector），或者，UEFI 的引导文件。它，作为光盘 cdrom，能够被真实机和虚拟机直接启动。

敲完了边鼓，现在归入正题。

ISO 作为“打包”格式，不“理睬”引导头，也不“理睬”引导文件，而是直接进入下一个环节，找到所谓“目标”载体，直接引导“目标”文件或“目标”系统。只要遵守某些“补充规范”，这是可以做到的。

loopback 并未建立虚拟机，也未建立虚拟（磁、光）盘。它本质上是一个“解包”过程，只不过不需要解开到一个文件夹下，而是能够动态读取 ISO 内的每一个文件。这种读取能力的存在，就是 loopback 的实质。

好了，既然可以通过 loopback 来访问 ISO 内的每一个文件了，那就设法启动这个 ISO 内的“目标”文件。也就是说，加载“目标”文件到内存（有时候还需要对运行环境进行某些动态调整，即“补充或修正”），然后递交控制权。

这就是说，multios-usb 从原则上说，能够启动大量的 ISO，只要针对每个具体的 iso 作具体的动态调整即可。

相比之下，grub4dos 启动 ISO 时，建立了虚拟盘。然而仅仅建立这种虚拟盘，是不能完全虚拟所有的 iso 的（只能虚拟一部分 iso，比如实模式的 DOS 光盘）。还需要有后续的 svbus 之类的配合，才能真正完成 iso 的启动和正确运行。也就是说，即使建立了虚拟盘，也不能彻底解决问题，而是照样需要用 svbus 之类的手段进行“补充或修正”。

原则上讲，带有“虚拟盘”功能的 iso 启动方法（Ventoy 是一个典型代表），能够启动更多的 iso，包括启动 BIOS 时代的那些 ISO。

而不带“虚拟盘”功能的 iso 启动方法（就像 multios-usb 那样的情况），则主要用于启动新近出现的 iso。它的服务重点，不是古老的 iso，而是未来的 iso。

随着时间的推移，随着 BIOS 和老电脑逐步退出历史舞台，可以想见，Ventoy 与 multios-usb 在 iso 启动方面的差异，会逐渐缩小，直至消失。两个软件都会不断进步、不断完善，其结果大概会是：殊途同归。

作者: liuzhaoyzz 时间: 2025-1-31 16:26
本帖最后由 liuzhaoyzz 于 2025-1-31 16:48 编辑

启动linux.iso，MultiOS-USB用的是loopback方案；不知道启动PE.ISO它用的是什么方案？理论上单独的loopback是不行的，因为只在grub2环境下有效，是不是也是用的和ventoy类似的方案呢？wintoflash可能解答下？
https://gitlab.com/MultiOS-USB/mountiso/-/releases/v0.1.0

感觉上来说，ventoy对于grub2和ipxe进行了深度二次开发，魔改，MultiOS-USB感觉没有那么深入，他跟ventoy相比差的很远，ventoy成熟度、开发进度遥遥领先于MultiOS-USB，ventoy1.1版本是最新版，MultiOS-USB的版本只相当于ventoy的0.1版本，支持的linux/PE发行版太少了，只有ventoy的十分之一。
https://github.com/Mexit/MultiOS ... ocs/Supported_OS.md

MultiOS-USB优点是便于无损部署，部署条件不高，没有ventoy那么苛刻。

作者: fjun67 时间: 2025-1-31 16:42
谢谢分享！

作者: 不点 时间: 2025-1-31 19:28

liuzhaoyzz 发表于 2025-1-31 16:26
启动linux.iso，MultiOS-USB用的是loopback方案；不知道启动PE.ISO它用的是什么方案？理论上单独的loopback ...

每个软件，给出的都是一种可能性。你选择使用它，或者你不选择使用它，你是自由的。

每个软件，它本身有优点，也有缺点。你的选择，就是对这些优缺点加以对比，进行综合判断后得出的结果。

关于 iso 的启动【此处是指用 bootloader 加载启动 iso 文件，而不是刻录光盘，也不是用虚拟机把 iso 当作光盘来启动】，我个人目前的应用范围比较狭窄。因此，我的结论、我的选择，可能只适合我自己，或者再加上那些跟我的想法和使用场景一致的人。

到目前为止，我还未使用 iso 来安装 Linux。都是使用 iso 来启动 PE，或者启动以前的 DOS 之类的 iso 文件。

grub4dos（此处包含了 g4e 在内）能够启动 PE.iso。我接触到的 PE，貌似都能支持 grub4dos 的 map 仿真启动【那些不能成功启动的，也许早已经被我忽略了、放弃了，所以也就想不起来了】。这个启动方式，工作得很完美，没出啥大毛病，因此，我也没有动力，换成别的启动方式。

看到 multios-usb 这个启动软件以后，我觉得它带给了我新的可能性，可以拓展我的应用场景。首先，我看重的是，它能够挂在 grub4dos 底下，不丢失 grub4dos 原有的启动功能，而扩展出新的功能。这种“自由拼装”，给我的吸引力是很大的。新功能本身给我的吸引力也是有的——就是说——现在能够通过 multios-usb 来启动微软的 Win11.iso 安装光盘了。以前的 grub4dos map 命令只能启动 PE.iso，不能启动 Win11.iso。我现在是“拿来主义”，我不需要做任何工作，因为 multios-usb 都已经做了那些工作。我只需要安心使用它的功能即可。当然这里应该特别感谢 wintoflash，否则我还不能成功地把 multios-usb 挂在 grub4dos 底下。我完全没有费劲做任何工作，我只是进行了“挂接”，就同时拥有了 grub4dos 和 multios-usb 的功能。非常“便宜”，非常“划算”。

作者: wintoflash 时间: 2025-1-31 20:36

liuzhaoyzz 发表于 2025-1-31 16:26
启动linux.iso，MultiOS-USB用的是loopback方案；不知道启动PE.ISO它用的是什么方案？理论上单独的loopback ...

源码很清楚啊，就是wimboot。
https://github.com/Mexit/MultiOS ... ows/windows_iso.cfg

作者: wintoflash 时间: 2025-1-31 20:48

不点发表于 2025-1-31 10:40
试着深入思考一下 ISO 的启动问题。

ISO 是古老的启动盘格式——光盘格式。古老的启动盘格式有好几种， ...

带有“虚拟盘”功能的 iso 启动方法（Ventoy 是一个典型代表）

Ventoy支持两种方式启动 ISO。一是你所说的虚拟盘。二是类似loopback的方式。
两者都会在操作系统启动中进行hook，再次挂载磁盘上的ISO。
方式二是为了解决部分电脑上方式一死机的问题。
因为有各种各样奇葩的BIOS固件，这个虚拟盘驱动不可能保证在所有的电脑上都能不出问题。
以我熟悉的UEFI举例，比如很多苹果电脑，Ventoy的虚拟盘会造成死机。
grub4efi以及我开发的grub2分支，（dido0379，我以及yaya实现的）虚拟盘驱动的健壮性是比Ventoy强一些的 (自卖自夸)，但是也遇到过死机的情况。

作者: dawensger 时间: 2025-1-31 20:49
路过看看

作者: 不点 时间: 2025-1-31 21:09

wintoflash 发表于 2025-1-31 20:48
Ventoy支持两种方式启动 ISO。一是你所说的虚拟盘。二是类似loopback的方式。
两者都会在操作系统启动 ...

了解了，非常感谢。

诚实地说，我用过 Ventoy，却还未用过您的 grub2 修改版。我觉得，开辟 grub2 的分支是对的，这增大了用户的“可选择空间”。

有可能的话，我也想把您的 grub2 挂在“一盘走天下【自由拼装修改版】”中。也或者，（如果可能的话），把“一盘走天下【自由拼装修改版】”中的 multios-usb 的 grub2 版本，替换成您的 grub2 版本。不知难度大不大。

作者: wintoflash 时间: 2025-1-31 21:44
本帖最后由 wintoflash 于 2025-1-31 21:47 编辑

不点发表于 2025-1-31 21:09
了解了，非常感谢。

诚实地说，我用过 Ventoy，却还未用过您的 grub2 修改版。我觉得，开辟 grub2 的 ...

我修改的分支已经不再维护了。
multios-usb中的grub2，不可以直接替换为我修改的分支。
如果只是为自己的启动盘多一个选择，可以用我的grubfm，便携式单efi文件。
https://github.com/a1ive/grub2-filemanager

作者: 不点 时间: 2025-1-31 21:57

wintoflash 发表于 2025-1-31 21:44
我修改的分支已经不再维护了。
multios-usb中的grub2，不可以直接替换为我修改的分支。

不维护了？那么能否把补丁提交给 grub2 维护者，看看能否被采用？

第二个思路是，能否把补丁打在 multios-usb 上？就算 multios-usb 的维护者不采用，我们也可以自己用。比如说，用于“一盘走天下【自由拼装修改版】”的 U 盘上。

作者: 834772509 时间: 2025-1-31 22:49

wintoflash 发表于 2025-1-31 21:44
我修改的分支已经不再维护了。
multios-usb中的grub2，不可以直接替换为我修改的分支。
如果只是为自己 ...

我看grubfm也不维护了，后期还有维护的打算嘛？

作者: liuzhaoyzz 时间: 2025-1-31 23:17

wintoflash 发表于 2025-1-31 20:48
Ventoy支持两种方式启动 ISO。一是你所说的虚拟盘。二是类似loopback的方式。
两者都会在操作系统启动 ...

你魔改的grub2和yaya的g4e，对于MAC电脑确实经过了很多实战检验，当时在svbus,primo驱动RAMOS测试的时候经过了很多实战检验，论坛里面也有网友反馈grub2,grubfm和g4e都可以，ventoy无法启动MAC的情况。

作者: wintoflash 时间: 7 天前

834772509 发表于 2025-1-31 22:49
我看grubfm也不维护了，后期还有维护的打算嘛？

没有。

作者: 不点 时间: 7 天前
本帖最后由不点于 2025-2-1 07:36 编辑

wintoflash 发表于 2025-1-31 21:44
我修改的分支已经不再维护了。
multios-usb中的grub2，不可以直接替换为我修改的分支。
如果只是为自己 ...

我有个疑问，针对 i386-pc：

GRUB4DOS

map --mem /grubfm.iso (0xff)
map --hook
chainloader (0xff)

GRUB 2

linux /loadfm
initrd /grubfm.iso

这里的 g4d、grub2 加载方式，为何不同？

在 g4d 中，能否使用 grub2 的加载方式？g4d 中有 kernel 命令，可以与 grub2 的 linux 命令相对应。

因为我看到，grub2 的加载方式，没有使用 map 命令，因此，不需要建立虚拟光盘。而 grub4dos 的加载方式，却建立了虚拟光盘。

我的意思是，如果能够避免建立虚拟盘，还是设法避免比较好，除非根本无法避免。

作者: 不点 时间: 7 天前

wintoflash 发表于 2025-2-1 06:40
没有。

能否透露一下，不维护的主要原因是啥？

抱歉，由于身体原因，我错过了关注这个话题的时机，不知道开发历史，以及在此期间发生的事件。

1、是因为软件成熟了，无需继续开发了吗？
2、是因为工作成果已经转移、附加到别处了，比如转移、附加到 grub2 或 grub4dos 中了吗？
3、是因为时间、精力、身体状况等原因吗？
4、是别的我想不到的原因？

作者: chen463 时间: 7 天前
本帖最后由 chen463 于 2025-2-1 09:23 编辑

再一次详细看说明操作
可能是我U盘或系统缺少软件开启WIMBOOT-WIM的条件，失败…这我就不明白其中道理了，为何WIMBOOT不执行，难道还需安装动作，如果是，那太被动了。或许它分区限制的条件我不吻合，我是刻意测试的，看它随机应变的能力。
ISO无法显示出来...看说明：支持的ISO文件是独特的限制。非广泛的PE-ISO，这我明白了

这不是随便安装就能使用它功能的，我分区MBR格式测试，把GRUBX64.EFI更名BOOTX64.EFI来启动，跟VENTOY相同的路径\GRUB\grub.cfg启动没问题，只不过它修正了，菜单能整合自己的设定变成一个新菜单。
IOSs放入PE-ISO结果不支持显示，不符合它的条件。这我明白了
放入WIM文件，结果支持显示，WIMBOOT执行失败了，可能我分区格式或分区位置不符合它启动的条件。如果分区一定坚持是GPT格式或IOSs放第二分区，那就局限它使用的范围。

2025-02-01_3.png (13.34 KB, 下载次数: 2)

2025-02-01_2.png (3.33 KB, 下载次数: 1)

2025-02-01_1.png (2.96 KB, 下载次数: 2)

作者: 不点 时间: 7 天前
本帖最后由不点于 2025-2-1 09:14 编辑

chen463 发表于 2025-2-1 07:58
可能是我U盘或系统缺少软件开启WIMBOOT-WIM的条件，失败…
ISO无法显示出来...

对这个软件，首先要有“理解”。如果“理解”不到位，就会产生“误解”。

首先，这个软件的开发历史，比 Ventoy 还要久。确切地说，比 Ventoy 早 2 个月。

但是，遗憾的是，它的精细程度、完善程度，与 Ventoy 相比，还有很大差距。
Ventoy 的 fork 数量、star 数量以及开发者、贡献者的数量，都远远超过 multios-usb。

它启动 iso 的时候，或者启动 wim 的时候，都是根据文件名来弄的。

比如说，启动 Windows 的 iso，那么，文件名就必须是 Win1*_*_x64*.iso 这样的形式，否则，不会呈现出这个启动项目。参见 /multios-usb/config/windows/windows_iso.cfg

而启动 wim，就必须是 *.wim，也就是，必须以 wim 为后缀的文件名，否则不会呈现出这个启动项目。参见 /multios-usb/config/windows/wim_file.cfg

这方面，它的工作很不完善。我觉得，它需要有开发者尽快完善才好。

再者，我们作为用户，就不要对这个软件期望太多。期望越多，失望也越多。

你看重了它哪方面的优点，就应该接纳它在其他方面的缺点。

如果你像我一样，觉得是“白剽”的，能够完全无损地挂在 grub4dos 底下，不伤害 grub4dos 原有的任何东西，而能纯粹增加微软 Win11 的 iso 文件的启动能力，这就满意了。如果对此功能不满意，那就干脆当成垃圾软件，彻底删除就 OK 了。

作者: chen463 时间: 7 天前
本帖最后由 chen463 于 2025-2-1 10:13 编辑

不点发表于 2025-2-1 09:12
对这个软件，首先要有“理解”。如果“理解”不到位，就会产生“误解”。

首先，这个软件的开发历史， ...

我是看到大大在测试，所以好奇玩玩，

刚查询一下，创作时间2020年刚好是VENTOY发布哪一年，其实这版本我几年前就测试过了，只是时间久了还有点印象，

另外还有一个AIO-BOOT更类似VENTOY，也是2020五年前作品，现在也不更新了，这个安装条件更宽松，使用更方便，被我收纳入U盘。

W大的grubfm功能，我个人使用后给于很高的评价，不输VENTOY，甚至还更高，因限制条件少使用更广泛，推荐您试试。

如果能有自动辨别功能，直接使用何种方案开启ISO或WIM或VHD，不须再选择，那更无敌啰！

首先，这个软件的开发历史，比 Ventoy 还要久。确切地说，比 Ventoy 早 2 个月。-？？？？？
这是我上网查询开发版本时间，也许有误，但不在讨论范围内。
AIO-BOOT-2016/06
VENTOY-2020/04
MultiOS--2020/05

作者: 834772509 时间: 7 天前

不点发表于 2025-2-1 09:12
对这个软件，首先要有“理解”。如果“理解”不到位，就会产生“误解”。

首先，这个软件的开发历史， ...

如果是这样的话，那岂不是很多PE多不支持启动？

作者: 不点 时间: 7 天前
刚刚在我的“一盘走天下【自由拼装修改版】”U 盘上，挂接了 grubfm。我在 BIOS 启动环境测试了微软 Win11 的 iso 文件。成功启动，进入安装流程。

而我从 grub4dos for BIOS 启动 grubfm 的命令是：

kernel /grubfm-zh_CN/loadfm
initrd /grubfm-zh_CN/grubfm.iso

grubfm 确实很强大，很成熟。

而我对 multios-usb，也继续保持跟踪支持，尽管其开发进展比较缓慢。

作者: wintoflash 时间: 7 天前
本帖最后由 wintoflash 于 2025-2-1 14:20 编辑

不点发表于 2025-2-1 07:35
我有个疑问，针对 i386-pc：

GRUB4DOS

在 g4d 中，能否使用 grub2 的加载方式？g4d 中有 kernel 命令，可以与 grub2 的 linux 命令相对应。

loadfm实际上是有特殊菜单的grub.exe。因此在grub4dos再用一次没什么意义。

作者: 不点 时间: 7 天前
本帖最后由不点于 2025-2-1 14:39 编辑

wintoflash 发表于 2025-2-1 14:07
loadfm实际上是有特殊菜单的grub.exe。

就是说，最终还是需要 map 建立虚拟光盘。

grubfm 能否做成不需要建立虚拟盘的形式呢？

比如说，就像 Linux 的 vmlinuz 那样，直接在内存中运行。

---------------

又仔细想了想，建立虚拟盘也行，只要在启动 iso 的时候，能够销毁虚拟盘即可。iso 本身启动运行的时候，如果有虚拟盘存在，那对 iso 里面的操作系统的运行，会带来某些副作用。

--------------

上面这段话，写得含糊。重新写。

grubfm 在启动某个 iso，比如 win11.iso，的时候，应该尽量撤销虚拟盘，让操作系统在没有虚拟盘存在的环境下，干净地运行。grubfm.iso 本身占据的那个虚拟盘，对于要启动的操作系统来说，是没有用的。虚拟盘的存在，会干扰操作系统的运行，甚至，在最坏的情况下，可能会导致死机。

作者: wintoflash 时间: 7 天前

不点发表于 2025-2-1 14:27
就是说，最终还是需要 map 建立虚拟光盘。

grubfm 能否做成不需要建立虚拟盘的形式呢？

如果只考虑grub2来加载的情况，可以不用虚拟盘。
loopback挂载ISO后，用multiboot启动里面的grubfm.elf就可以了
但是用grub4dos的话，不用虚拟盘比较困难。

作者: 不点 时间: 7 天前

wintoflash 发表于 2025-2-1 14:40
如果只考虑grub2来加载的情况，可以不用虚拟盘。
loopback挂载ISO后，用multiboot启动里面的grubfm.elf ...

我的意思是，用虚拟盘也可。但是，在把控制交给 win11.iso 的那一刻，赶紧卸载虚拟盘。这样不是可以让虚拟盘消失吗？

虚拟盘的存在，有可能干扰操作系统的运行。没有虚拟盘的存在，就没有这种担忧了、就放心了。

作者: wintoflash 时间: 7 天前

不点发表于 2025-2-1 15:01
我的意思是，用虚拟盘也可。但是，在把控制交给 win11.iso 的那一刻，赶紧卸载虚拟盘。这样不是可以让虚 ...

确实卸载虚拟盘对Windows可能造成的影响更小。
但是启动Windows安装镜像时用的是loopback，因此不会出现两个光驱的情况。
我当时是不确定对不同版本grub4dos的虚拟盘执行unmap会不会出现问题，因此没有做这个操作。

这个项目因为不再维护了，所以不会再纠正这个问题。

作者: liuzhaoyzz 时间: 7 天前
本帖最后由 liuzhaoyzz 于 2025-2-1 15:23 编辑

不点发表于 2025-1-31 19:28
每个软件，给出的都是一种可能性。你选择使用它，或者你不选择使用它，你是自由的。

每个软件，它本身 ...

到目前为止，我还未使用 iso 来安装 Linux。都是使用 iso 来启动 PE，或者启动以前的 DOS 之类的 iso 文件。

如果说只用来启动PE的话，甚至都不需要grubfm了，yaya修改的g4d/g4e的run模块就足够使用了，只有几百KB，用于启动PE.WIM/PE.ISO，搭配g4d/g4e通杀BIOS/UEFI。
用grubfm和ventoy可是说是大材小用，grubfm/ventoy的长处是可以启动众多linux的liveCD用于启动或者进一步安装到硬盘，linux的启动远比PE要复杂。

作者: 不点 时间: 7 天前
本帖最后由不点于 2025-2-1 15:53 编辑

wintoflash 发表于 2025-2-1 15:14
确实卸载虚拟盘对Windows可能造成的影响更小。
但是启动Windows安装镜像时用的是loopback，因此不会出现 ...

不同版本的 grub4dos 虚拟盘，是可以“互操作”的。但与 memdisk 建立的虚拟盘，不能互操作。

换句话说，前面的 grub4dos 创建的虚拟盘，后面的 grub4dos 也能识别出来，并承认。

可以卸载前一个 grub4dos 建立的虚拟盘，也可以继续增加别的虚拟盘。

grubfm 不维护了也罢，知道这个状况就行。如果发现死机之类的，就可以朝这个方面去怀疑了。

比如，您前面曾经提到的苹果电脑的死机问题，就可以朝这个方向怀疑。

【补充】很难说，虚拟盘号 (0xFF) 是否被苹果电脑用于它自己的内部操作的某种目的。即使换成别的某个盘号，比如 (0xFE) 或 (0xA5) 等等，都存在同样问题，即，碰巧占用了某个制造商的内部盘号。所以，虚拟盘用完之后，要尽早卸载虚拟盘。卸载虚拟盘，这个动作，对于操作系统的启动、运行来说，是最安全的，只有好处，没有坏处。

作者: 不点 时间: 7 天前

liuzhaoyzz 发表于 2025-2-1 15:17
如果说只用来启动PE的话，甚至都不需要grubfm了，yaya修改的g4d/g4e的run模块就足够使用了，只有几百 ...

我最近两年一直在用 g4d/g4e 来运行 PE .iso。我对这个情况比较熟悉。

然而，grub4dos 不能支持微软原版 Windows iso 的运行。因此，我看重的，就是 Ventoy、multios-usb、grubfm 的这种启动能力。

我是初次接触，所以，不太了解行情。我不知道 multios-usb 这方面的功能很弱。我也不知道谁最强。

下一步，我确实有可能用这种方式来启动 Linux 的 iso。

特别是，我并不放弃 multios-usb。我仍然会关注和支持。也许我的要求不高。我觉得 multios-usb，也还不赖吧。瑕不掩瑜。

作者: liuzhaoyzz 时间: 7 天前
本帖最后由 liuzhaoyzz 于 2025-2-1 16:33 编辑

微软原版 Windows iso，其实就是打包了一个没有GUI的PE，也就是boot.wim，外加一个install.wim安装镜像，然而微软官方的PE.WIM，实在是不好用，特别是系统分区，分区调整，激活等等，我都是启动PE之后再用winntsetup/dism++之类的软件安装系统，没有这样的第三方软件加持，有时候不符合win11安装条件会出错还要加载那个注册表跳过，比较麻烦。
而且原版windows，实在是不好用，那个windows defender太烦人了，乱杀一气，会影响工作，还有一堆没用的组件。

作者: 不点 时间: 7 天前

liuzhaoyzz 发表于 2025-2-1 16:29
微软原版 Windows iso，其实就是打包了一个没有GUI的PE，也就是boot.wim，外加一个install.wim安装镜像，然 ...

defender 确实没用。但我还能忍。不能忍受的，是要注册账户。而且，不连接网络，就不能继续安装。等于说，强制连网才能安装。我实在难以承受，到了崩溃的边缘，说不定某一天，咬咬牙，就转到别的某个系统底下了。

作者: 不点 时间: 7 天前
再谈虚拟盘。

在 WinXP 的时候，NTLDR 需要在 (hd0) 上，或者在软盘 (fd0) 上，才能工作。这是沿用了 DOS 时代的规范。

大家都在争抢 fd0 或 hd0 的地位。只有它俩能启动操作系统，别的就不能启动操作系统。

这个状况就跟 MBR 也是争抢一样，每个启动软件都想抢占这个位置，即硬盘的首扇区。

到了 bootmgr，这个限制解除了。可以从 (hd1) 等其他盘号启动操作系统了。就是说，从 bootmgr 开始，不再需要交换盘号了。

“交换盘号”——虽然这个动作不算大，但它本质上也是需要接管 int13 磁盘中断服务。这一般是安全的，不会与厂家的主板设计造成冲突。盘号也通常都在 0x80，0x81，0x82 等少数几个数值之间变动。

然而，如果是光盘盘号，这里缺乏规范。不同厂家对于 cdrom 所采用的盘号，也是千差万别。主板本来是不需要占用光盘盘号的。但假如某个厂家确实使用了内部光盘，那就可能会出问题。厂家可能用这个光盘盘号做某些事情。我们创建的虚拟光盘，可能正好覆盖了厂家的光盘盘号，厂家的 ROM 程序有可能出现异常、死机。

因此，虚拟盘用完之后，如果不再需要了，就应该卸载它。尤其是虚拟光盘，更应该在不需要时卸载掉。

---------------------------

loopback 启动 iso，这个方式不产生虚拟盘。因此，这个方式是安全的。出乎意料的是，Windows 的 iso 居然也能使用这种方式。

既然这样，那么，multios-usb 的启动方案，隐隐约约地，可能代表着未来 iso 启动的发展方向。这节省了“磁盘虚拟”的步骤。

作者: wintoflash 时间: 7 天前

不点发表于 2025-2-1 15:43
不同版本的 grub4dos 虚拟盘，是可以“互操作”的。但与 memdisk 建立的虚拟盘，不能互操作。

换句话 ...

能否透露一下，不维护的主要原因是啥？
1、是因为软件成熟了，无需继续开发了吗？
2、是因为工作成果已经转移、附加到别处了，比如转移、附加到 grub2 或 grub4dos 中了吗？
3、是因为时间、精力、身体状况等原因吗？
4、是别的我想不到的原因？

2,3皆有。

比如，您前面曾经提到的苹果电脑的死机问题，就可以朝这个方向怀疑。

这倒不是。苹果电脑都是EFI固件。而且grub2/grub4dos都没有问题，是Ventoy有问题。

loopback 启动 iso，这个方式不产生虚拟盘。因此，这个方式是安全的。出乎意料的是，Windows 的 iso 居然也能使用这种方式。

启动 Windows 安装镜像没这么简单。这个过程会产生一个让bootmgr/bootmgfw.efi认可的虚拟硬盘。
BIOS下，这个虚拟硬盘只是局限在让bootmgr认可的范围内，不会修改BIOS提供的int13中断本身。
UEFI下，这个虚拟硬盘是固件层面的。在以前的开发过程中，我们已经发现了微软的bootmgfw.efi对光驱的识别是有问题的，它只认可第一个光盘。但是在启动过程中生成的是硬盘，所以没有影响。

作者: 不点 时间: 6 天前

wintoflash 发表于 2025-2-1 20:36
2,3皆有。

这倒不是。苹果电脑都是EFI固件。而且grub2/grub4dos都没有问题，是Ventoy有问题。

有点明白了。我隐约记得，以前的 Windows （甚至 DOS），都有 RAMdrive。这是操作系统自己的虚拟盘。我想，Linux 下的内存盘，以及 loop 设备，原理上也是这样，都是操作系统内建的虚拟设备。

利用操作系统内建的虚拟设备，就可以在没有“主板虚拟设备”（比如 int13 设备）参与的情况下，实现操作系统的安装、启动、运行。这可能就是 grub2 的 loopback 启动的内涵。

------------------------------

下一个问题，g4d 的作用。

Legacy BIOS 处于正在被消灭的路上。之所以还需要 g4d，是因为还存在 Legacy 电脑。

g4d 的长处是，启动方式多样、灵活，很适合作为一个“跳板”。

从 g4d 跳到 grub2，能够获得 grub2 的功能。

到了 BIOS 彻底消失的一天，g4d 的历史使命也就完成了，就连“跳板”也不能当了。

-----------------------------

下一个问题，g4e 的作用。

开发者们创建了 g4e，实现了 UEFI 下的 map 虚拟盘功能。

然而，时代变了。虚拟盘在 BIOS 时代可以说是个宝贝，可玩性很高。但现在，许多新技术被发明，让虚拟盘的用处变小、地位降低。grub2 不使用虚拟盘，照样可以通过新的技术手段来实现 Win.iso 的启动。往后的发展，我看不清楚。如果虚拟盘的作用和地位持续降低的话，那么，我觉得 g4e 与 grub2 相比，就很难有优势了。目前来看，虚拟盘还是有一些使用场景的。但长远来看，逐步发展的新技术，有可能一点一点挤占或取代虚拟盘（的地位）。

---------------------------------------

下一个问题，PE.iso 的 loopback 启动。

微软原版的 win11.iso，能够在不使用“虚拟盘”的情况下启动。下一个目标，就是让众多的 PE.iso 也能够以这种方式启动。既然微软原版能够实现，那么我想，那些 PE.iso 应该也能实现，只不过需要有人去调整具体的命令和参数而已。相信有人去做这个工作，让 multios-usb 也能启动 PE.iso。

作者: 不点 时间: 6 天前
本帖最后由不点于 2025-2-2 15:42 编辑

PE.iso “无虚拟盘”启动尝试：gmy 的 EFI.iso 失败报错：

wimboot v2.8.0

FATAL: no bootmgr.exe

Press a key to reboot...

把 gmy 的 EFI.iso 更名为 Win11_gmy_EFI_x64.iso，放在 ISOs 文件夹下，就可以测试了。我在 BIOS 环境进行测试，结果是，失败报错。在 UEFI 下测试，也是失败，但看不见报错信息。

那么我猜，之所以失败，是因为缺少 bootmgr.exe 等文件。换句话说，精简得太狠了。

很自然地，接下来的思路就是：找一个精简得不那么厉害的 PE.iso 试试。

搜到这个网页，讲到关于 wimboot 和 WinPE 的知识：

https://easy2boot.xyz/troubleshooting-e2b/wimboot-and-the-winpe-boot-process/

下面这个 PE 是 Wim 格式的，不知有谁可以试试，放在 ISOs 文件夹，看看能否成功启动（有个手工制作成品 PE，Wim 格式）：

http://bbs.wuyou.net/forum.php?mod=viewthread&tid=444396

作者: chen463 时间: 5 天前
经过几天折腾瞎搞，终于明白MultiOS作者的用心，悟出其中的奥妙之处，安装WIN.ISO系统，此方案更胜一筹，测试后方便性高低立判，或许是我个人高估了他的创作，那就说说使用后心得分享吧！好的方案大家共同学习。

1.比Rufus写入WIN.ISO更方便，不须每次新版本重新再写入，只要U盘第一次制作好以后，把任一**WIN.ISO的版本COPY进入\IOSs，他即刻菜单显示该ISO选项。
2.进入安装Windows画面后，即使放弃安装动作，立刻退出，不拖泥带水有S机现象或迟疑。我没继续操作安装，因为是实机操作没此需求。
3.进入PE利用安装Windows的软件来安装，偶有不支持驱动程式的现象。MultiOS没有此现象。
4.重点所在，把**WIN.ISO的版本放在U盘\IOSs里面，即使是新盘制作安装，也不影响Windows的安装。它会自动搜寻U盘启动安装。
5.我把此U盘测试制作成VHD，发现GPT或MBR格式都可，即使后面放ISO的分区格式化为NTFS、exFAT也行。不过BIOS有分区格式的辨别要求，不符合一样不通用。
6.不支持一般PE.ISO启动，不支持一般PE-BOOT.WIM启动，支持的范围极少。可能是他启动的方案不支持造成。
7.ISO的辨别支持的能力极强，不符合的尽力排除不显示，但WIM却不行。

作者: 不点 时间: 5 天前
也谈一点认识。

把“不可能”，变成“可能”。

BIOS 下的虚拟盘，本来是只为“实模式”操作系统（DOS）服务的。要想让这种虚拟盘能够在 Windows 下使用，（本来）是不可能的。然而，有人就是很“钻”（钻研的钻），就是要把“不可能”变成“可能”。这就是 firadisk、winvblock、svbus 带来的新思想。

有了 svbus 这样的工作，虚拟盘的性质发生了变化。其实，svbus 变成了主角，而（实模式）虚拟盘本身，退居次要的地位。当进入 Windows 的保护模式以后，实模式的代码完全不再调用了。svbus 只需要知道扇区序列的内存地址或者在硬盘上的位置即可。获得扇区序列的地址或位置之后，由 svbus 来处理虚拟盘的读写事务。

这个想法继续发酵，就进入到下一个阶段：虚拟盘也可以省略掉，不再需要虚拟盘了。

针对某个特殊的 ISO（比如 Windows 的安装光盘），不需要把 ISO 虚拟为“光盘”。直接把 ISO 内的某个主程序读出来，并启动它，这就能够模拟出这个 ISO 原先期望的效果。

既然 Windows 的 iso 能够这么启动，那么，PE 也能这样启动。不存在实质性障碍，只存在“何时有人去完成这个工作”的问题。

把“不可能”变成“可能”，还需要各方面的协调与配合。大家互相协同，互相支持。你支持我，我支持你。否则，互相拆台，你不支持我，我也不支持你，那就是泡影，啥事也干不成。假定我的软件（好不容易）支持了一个 iso，这本来就是一个创举，令人欣喜。第二个 iso 的制作者也仿照那个被支持的 iso 来制作，那么，这个 iso 也被支持了。这就是良性循环。其他 iso 都这么模仿，复制成功的模式，无限循环，那么也都会成功。

同理，假定我的软件（好不容易）支持了一个 wim，令人欣喜。第二个 wim 的制作者也仿照那个被支持的 wim 来制作，那么，这个新的 wim 也就被支持了。其他 wim 都这么模仿，复制成功的模式，无限循环，那么也都会成功。

作者: wintoflash 时间: 5 天前

chen463 发表于 2025-2-3 11:34
经过几天折腾瞎搞，终于明白MultiOS作者的用心，悟出其中的奥妙之处，安装WIN.ISO系统，此方案更胜一筹，测 ...

国内的WinPE作者喜欢精简，导致wim不能直接被wimboot启动。
https://github.com/a1ive/wimboot ... 9/src/efifile.c#L44
例如uefi下，wim里面至少要有如下文件：
\Windows\Boot\EFI\bootmgfw.efi
\Windows\Boot\DVD\EFI\boot.sdi
\Windows\Boot\DVD\EFI\BCD
没有这些文件的话，只能自己补充。

作者: fjun67 时间: 5 天前
学习了。

作者: chen463 时间: 4 天前
感谢W大的解说，原来是这样呀！无解了。

我们不能去要求别人照着规范来制作PE，这是创作自由，

WIMBOOT是条铁路，偏偏人们喜走道路，原因是人们没电火车，所以不同道。

作者: 不点 时间: 4 天前

chen463 发表于 2025-2-4 10:03
感谢W大的解说，原来是这样呀！无解了。

我们不能去要求别人照着规范来制作PE，这是创作自由，

我的理解和猜测：并非无解。

您可以试试 grubfm，看看能否启动那样的 PE。

如果能启动，您再研究一下，grubfm 究竟是否针对 PE.iso 、PE.wim 使用了“虚拟盘（ map ）功能”。如果不使用虚拟盘就能做到，那说明，这在原则上是可以做到的，只不过 multios-usb 太“嫩”，因而未能做到。

作者: 834772509 时间: 4 天前
如果PE不怎么精简，如果和ventoy那样可以PE去适配multios-usb我觉得也是可行的

作者: chen463 时间: 4 天前
我的知识水平低，无法辨别这些，只在W大的GRUB2修正版测试过WIMBOOT能够直接启动PE.WIM成功，其他未尝试过。看内容指令是透过efi来启动，合乎引导原理，想要直接WIMBOOT来启动应该有难度，前段的引导工作必须具足。

Multios作者既然敢放上显示WIMs来引导选项，肯定是测试过，是否我们不懂操作此功能的设定，造成无法启动PE. WIM。看指令并未先引导EFI的迹象。假设是需透过WIN系统来引导启动WIMBOOT再启动PE. WIM，如果是如此，那就有争议。如果把引导启动PE. WIM的一些文件复制到U盘来让其引导，那合乎引导原理逻辑，成功启动机率就变高。

作者: wintoflash 时间: 4 天前

不点发表于 2025-2-4 10:16
我的理解和猜测：并非无解。

您可以试试 grubfm，看看能否启动那样的 PE。

原则上是可以做到的。wim里面没有那些文件，自己准备一套就行了。
grubfm就是自己准备了一套，所以wim里面没有那些文件也可以启动。
但是bootmgr/bootmgfw.efi是微软的东西，有版权的，所以MultiOS-USB开发者可能不愿意放有版权的二进制文件。

作者: 不点 时间: 4 天前

wintoflash 发表于 2025-2-4 11:29
原则上是可以做到的。wim里面没有那些文件，自己准备一套就行了。
grubfm就是自己准备了一套，所以wim里 ...

那好吧，既然 grubfm 就已经实现了，也没必要去管 multios-usb 能否实现了。

现在用 grubfm 来处理，那就 OK 了。

作者: wintoflash 时间: 4 天前
可以用自定义菜单来解决启动winpe iso的问题。

winpe.zip (1.53 MB, 下载次数: 15)
解压这个文件，将其中的winpe文件夹放入U盘MultiOS-USB\config_priv文件夹下。
解压后目录结构如下

?:\MultiOS-USB\config_priv
│ README.md
├─lmde
│ lmde.cfg-example
└─winpe
Winpeshl.ini
winpe.cfg
boot.sdi
bootmgr.exe
bootx64.efi
wgl4_boot.ttf
BCD

复制代码

注意事项：
(0)
脚本会检测iso上是否有/boot/boot.wim或/sources/boot.wim文件，有的话会创建菜单。
如果你的iso里面，wim在其他的路径下，那请照葫芦画瓢修改菜单。
如果iso有/sources/install.wim，则视为Windows安装镜像，不会生成菜单。
(1)
如果启动过程中红橙黄绿蓝靛紫屏了，说明 bootmgr.exe/bootx64.efi 的版本和iso里面系统的版本差别有点大，请自行更换。
(2)
如果遇到UEFI下winpe分辨率过低的问题，请编辑BCD添加highestmode属性。

作者: wintoflash 时间: 4 天前

834772509 发表于 2025-2-4 10:55
如果PE不怎么精简，如果和ventoy那样可以PE去适配multios-usb我觉得也是可行的

其实按照loopback标准，在iso里面放/boot/grub/loopback.cfg自己写菜单就可以了。

作者: 不点 时间: 4 天前

wintoflash 发表于 2025-2-4 14:52
可以用自定义菜单来解决启动winpe iso的问题。

解压这个文件，将其中的winpe文件夹放入U盘MultiOS-USB\c ...

前面您曾提到这个文件：

\Windows\Boot\EFI\bootmgfw.efi

那么，压缩包里的 bootx64.efi 是否就是它呢？

另外，关于 grubfm。在 BIOS 下总是用 grubfm.iso 虚拟出一个光盘，而在 UEFI 下，我猜是没有 map 的动作吧？

作者: wintoflash 时间: 4 天前

不点发表于 2025-2-4 18:30
前面您曾提到这个文件：

\Windows\Boot\EFI\bootmgfw.efi

前面您曾提到这个文件：
\Windows\Boot\EFI\bootmgfw.efi
那么，压缩包里的 bootx64.efi 是否就是它呢？

是同一个文件。

另外，关于 grubfm。在 BIOS 下总是用 grubfm.iso 虚拟出一个光盘，而在 UEFI 下，我猜是没有 map 的动作吧？

下载页面中我也提供了一个同时适用于BIOS/UEFI的ISO，如果启动的是这个ISO，那当然是有的。如果启动的是EFI文件，那就是没有的。
UEFI下虽然命令也是"map"，但原理是完全不同的。

作者: chen463 时间: 4 天前
本帖最后由 chen463 于 2025-2-5 10:22 编辑

终于知道为何WIM启动失败原因了，因为找不到BCD路径，
MultiOS从\ISOs文件夹显示去启动PE.WIM，那肯定不行的，除非修正路径\sources，如果是以\sources来启动PE，或许就能成功。

把配置文件菜单修正了显示路径ISOs→sources，启动BOOT.WIM，WIMBOOT引导启动PE还是失败。

除非要把相关PE文件COPY进入，在菜单上另加选项引导PE.EFI才能成功，那这样跟GRUB2菜单没两样，无特别性。

作者: 不点 时间: 4 天前
本帖最后由不点于 2025-2-4 21:33 编辑

chen463 发表于 2025-2-4 19:11
终于知道为何WIM启动失败原因了，因为找不到BCD路径，
MultiOS从\IOSs文件夹显示去启动PE.WIM，那肯定不行 ...

我启动 gmy 的 EFI.iso 成功了（保持这个文件名即可，不要改名为 Win11*x64*.iso，否则，它会列出两个看起来相同的项目，把你弄糊涂）。

以前是用 map 把 EFI.iso 虚拟为光盘来启动。现在是不需要 map 就能启动了。既然不用 map 了，也就不用整理 EFI.iso 的碎片了。

但是，把 EFI.iso 里面的 boot.wim 解包出来，放在 ISOs 文件夹下, 却不能列出它的菜单项。不知那里不对劲。也许是文件名不该叫做 boot.wim？

作者: youxia1220 时间: 4 天前
谢谢分享

作者: 不点 时间: 4 天前

chen463 发表于 2025-2-4 19:11
终于知道为何WIM启动失败原因了，因为找不到BCD路径，
MultiOS从\IOSs文件夹显示去启动PE.WIM，那肯定不行 ...

我看不懂。是不是您（手误）把 ISOs 弄成 IOSs 了？

作者: wintoflash 时间: 4 天前
本帖最后由 wintoflash 于 2025-2-4 22:11 编辑

不点发表于 2025-2-4 20:30
我启动 gmy 的 EFI.iso 成功了（保持这个文件名即可，不要改名为 Win11*x64*.iso，否则，它会列出两个看 ...

但是，把 EFI.iso 里面的 boot.wim 解包出来，放在 ISOs 文件夹下, 却不能列出它的菜单项。不知那里不对劲。也许是文件名不该叫做 boot.wim？

我这边可以列出菜单项啊 (版本：v0.9.6)。当然就算列出来了也不能启动的，因为wim里面缺文件。

作者: 不点 时间: 4 天前

wintoflash 发表于 2025-2-4 22:09
我这边可以列出菜单项啊 (版本：v0.9.6)。当然就算列出来了也不能启动的，因为wim里面缺文件。

暂时不追究了。我怀疑这个 boot.wim 文件缺少 index 1 2，所以，列不出项目来。我纯粹是瞎怀疑，因为我不懂这些语法。版本是 0.9.6。我以前也没安装过，只安装了这个最新版本。

wim_file.cfg

for wimindex in 1 2 do
...............................
done

补充：看了我的文件名，它是大写的 BOOT.WIM，难道说 grub2 不认大写的？嗯？？NTFS 格式。

作者: 不点 时间: 4 天前
果然是后缀名大写的问题！改成 BOOT.wim 就能列出了！

不过，列出了也不能成功启动。缺少文件。

不追究了，我的 PE 都是 ISO 格式，所以 wim 的问题，也没有太大影响。

作者: chen463 时间: 3 天前

不点发表于 2025-2-4 21:25
我看不懂。是不是您（手误）把 ISOs 弄成 IOSs 了？

对不起，输入ISOs错误了…

需要小写wim，我也是遇有这问题，修正了才显示出来。

作者: 不点 时间: 3 天前
到目前为止，算是很好了。

iso 没问题了。微软原版 iso 以及很多 PE.iso，都可以启动了。

至于说 wim 文件，这就要看 wim 的制作者了。制作者愿意兼容 multios-usb 的话，那就精心制作，在 multios-usb 下测试启动。如果不愿意支持 multios-usb 的话，那就没办法，只能用 grubfm 来“兜底”去启动它们。

作者: wintoflash 时间: 3 天前
GRUB2下FAT/NTFS/EXFAT文件名不区分大小写。但是通配符模块是区分大小写的。
我已经提issue了。
https://github.com/Mexit/MultiOS-USB/issues/28

作者: chen463 时间: 3 天前
MULTIOS功能其强，不可多得的方案引导，只是程度差，无法自定义更多的功能，如有搜寻各磁盘分区ISO功能更好，收下与VENTOY和GRUBFM互补使用，各有特色优点。

作者: 不点 时间: 3 天前

chen463 发表于 2025-2-5 17:26
MULTIOS功能其强，不可多得的方案引导，只是程度差，无法自定义更多的功能，如有搜寻各磁盘分区ISO功能更好 ...

谈谈我的理解。

multios-usb 属于“不使用虚拟盘”的方案。

Ventoy 和 grubfm 属于兼具“可使用虚拟盘”与“不使用虚拟盘”两套并存的方案。

“使用虚拟盘”，可以应对旧的 BIOS 时代遗留下来的那些 ISO，主要与 int13 有某种联系。

“不使用虚拟盘”，则适用于“远离 BIOS”的那些 ISO。比如，虽然在 BIOS 时代也有 Linux，但 Linux 的 iso 光盘，却不支持 int13 的虚拟方式。必须让 Linux 能够以其它方式识别 ISO，比如 loopback 规范。显然，int13 在这个过程中是没有用的。Windows 下需要 firadisk、winvblock、svbus 驱动来弥补虚拟盘的不足。

也就是说，即便在 BIOS 时代，“使用虚拟盘”的方案，也已经暴露出“无法满足需求”的问题了。

而“不使用虚拟盘”的方案，则是“彻底摆脱虚拟盘”的一种尝试了。这种方案，面向的是未来；因而可能无法应对旧的 BIOS 时代的那些 ISO（比如 WinXP 或更早的 iso）。

作者: 不点 时间: 3 天前
看自己的需求了。

如果自己的应用范围不再需要考虑旧的 BIOS 支持，那就可以选择上述任意一个方案。我认为差别不大，仅仅存在“成熟度”的差别，不存在本质差别。

如果自己的应用范围还需要支持旧的 BIOS，那只能选择 Ventoy、grubfm 这类软件了。而假如还想很方便地挂在 grub4dos 底下，那么可选择的软件就不多了，个人感觉，首选的应该是 grubfm。

作者: kukuyu 时间: 3 天前
谢谢分享

作者: chen463 时间: 3 天前
把他们整合全部放入U盘
1.MultiOS-EFI
2.VTOYEFI
3.GRUB4DOSG4E
4.GRUBFM.ISO

2025-02-05_195828.png (5.1 KB, 下载次数: 0)

作者: longpanda 时间: 3 天前
本帖最后由 longpanda 于 2025-2-5 22:50 编辑

不点发表于 2025-1-31 10:40
试着深入思考一下 ISO 的启动问题。

ISO 是古老的启动盘格式——光盘格式。古老的启动盘格式有好几种， ...

其实对于Linux类系统，是通过“虚拟盘” map的方式启动还是通过 loopback 的方式启动并不是最关键的问题。
最关键的问题是启动后，控制权交给原系统之后，它如何找到并能正常读取ISO文件内容，从而使得启动过程继续进行下去（一般是安装系统的流程）。

loopback的方式简单来说就是在前面启动的时候给系统传了个参数，比如 iso-file=xxx.iso。
也就是告诉系统：“等会你去所有的分区（硬盘的、U盘的等）里面扫描一遍，找到这个xxx.iso文件，挂载起来，然后继续后面的启动流程吧。”
这里其实隐含了一个前提条件，就是这个Linux系统要能支持ISO文件所在的那个分区的文件系统，否则它连这个U盘分区中的文件系统都无法识别，自然也就无法从里面找出这个ISO文件。

确实有很多Linux发行版支持loopback参数，但是这当中有很多发行版的 initramfs 中不带 exfat驱动或者fuse驱动+ntfs3g。
也就是说使用loopback参数的方式，如果ISO文件放在 FAT32分区或者是 ext/xfs 等这种Linux中常使用的分区中时，启动时可以正常找到ISO文件，
但是如果ISO文件放在 NTFS/exFAT 分区中时则会报错找不到ISO文件，就无法继续启动。
而NTFS/exFAT这两种文件系统是大部分人最常用的两种文件系统（除非是不需要考虑Windows环境的情况）。

至于为什么很多Linux发行版默认initramfs中不支持 exfat/NTFS系统？
这就比较复杂了，可能有版本、历史、阵营、信仰等等各种原因，总之现状就是这样，而且我觉得很长一段时间内都会维持这个现状。

因此，如果U盘使用 NTFS/exFAT文件系统的话，那所有基于loopback的方式启动Linux系统的方案，目前来说都无法支持很多发行版。
（除非U盘使用 ext/xfs 等Linux原生的文件系统，但这样又无法用来启动标准的Windows ISO文件了）

作者: pls 时间: 前天 00:10

chen463 发表于 2025-2-5 20:10
把他们整合全部放入U盘
1.MultiOS-EFI
2.VTOYEFI

你这是结合四大方子，药下的有点猛了，看你的了！

作者: 不点 时间: 前天 06:42

longpanda 发表于 2025-2-5 22:37
其实对于Linux类系统，是通过“虚拟盘” map的方式启动还是通过 loopback 的方式启动并不是最关键的问题 ...

欢迎 longpanda 光临指导！您创建的 Ventoy 项目，在启动领域震动很大。这么多年，您精心打造，不断完善，付出了您的智慧、精力、辛劳。我作为一个受益者，内心很感激，也佩服您技术精湛、细致入微。Ventoy 的功能十分强大，但我的使用范围比较狭窄，我只体验了 PE.iso 的启动，未能体验 Ventoy 在 Linux 启动方面的表现。既然您能提出 Linux 启动之初不支持 exFAT、NTFS 的问题，我猜，Ventoy 也有可能已经采取了措施，解决这个棘手问题，把不可能变成可能；那样的话，就太好了。

关于 Linux，我也顺便谈点粗浅认识。以下 Linux 不是指内核，而是指操作系统（或者通俗来说就是发行版）。从非技术层面（空洞的哲学层面）考虑，Linux 的问题很复杂。Linux 有长处，有优点，也有着无可替代的东西，很珍贵。但遗憾的是，Linux 也有某些不该有的缺点。那些缺点，并非技术难点、并非“做不到”、并非“无法完成的任务”，而是“不去做”或“拒绝去做”。这是 Linux 发行版开发商、制作者“事先设定”的框架，而 Linux 的现状，也正是开发商希望的现状。年轻的时候，我不是这么认为的。年轻的时候，我认为 Linux 发行商肯定希望 Linux 能够扩展到世界的每一个角落。但我现在不这样认为了。我认为开发商由于某种深层的、隐藏的原因而不想让 Linux 太过于“蔓延”。Linux 这种“不温不火”或者说“半死不活”的现状，正是这些开发商所希望的。Linux 开发商有很多，但他们整体上是一致的，都不约而同地愿意看到 Linux 的现状，而不是去努力改变这个现状。我希望将来会有 Linux 发行商去致力于改变 Linux 的现状。我以前曾经说过，神雕这个人制作的 Linux，就已经非常好了。我认为，他是在“全力打造”。换句话说，我认为他就是“努力让 Linux 蔓延”的那个人。但遗憾的是，他后来也停止开发了。“一个人”就能做好，而“一个团队”却做不好。为什么？因为缺少的，就是“神”，缺少的是“心”。他们心里就没想让 Linux 怎样怎样地“好”，所以，他们做出来的 Linux 也就不会怎样怎样地“好”。这是我的视角所见；对别人有没有用，我不知道；分享一下。

作者: fjun67 时间: 前天 06:50
值得尝试。

欢迎光临无忧启动论坛 (http://bbs.wuyou.net/)