mygamexxx 发表于 2024-12-27 18:05
感谢不点与yaya两位大大的指点！

使用下列菜单，G4D与G4E均启动成功RAMOS。G4E下不需要加载ntfs_x64.efi ...

G4E自己无需ntfs驱动，但是bootmgfw.ef【读取BCD的时候】他不认识NTFS，所以得上ntfs_x64.efi驱动或者主板UEFI固件比较高级，自带ntfs驱动，否则这个时候【bootmgfw.efi】会报错。当然如果你的BCD文件在FAT分区那就没有这个问题，因为bootmgfw.efi读取BCD的时候假设自己在标准UEFI规范的ESP分区走的是UEFI的读文件API而不是自己内部的驱动程序，而ESP一定是FAT的。

是你的UEFI固件支持NTFS。

感谢不点与yaya两位大大的指点！

使用下列菜单，G4D与G4E均启动成功RAMOS。G4E下不需要加载ntfs_x64.efi，是否意味着我的UEFI自带ntfs驱动？还是G4E本身不需要加载ntfs驱动？我的认知偏向于G4E不需要加载ntfs驱动。yaya大大确认是我的UEFI支持NTFS。

title 启动RAMOS-WIN10系统\n启动SSIC-WIN10-20241225-8504
# %@uefi%==64 find --ignore-floppies --ignore-cd --set-root /EFI/grub/ntfs_x64.efi
#我的UEFI固件支持ntfs，所以不需要加载ntfs驱动
# %@uefi%==64 load /EFI/grub/ntfs_x64.efi
find --ignore-floppies --ignore-cd --set-root /VHD/SSIC-WIN10-20241225-1509.vhd
#BIOS下需要--top的map参数加载至高端内存。
if %@uefi%#==# && map --mem --top /VHD/SSIC-WIN10-20241225-1509.vhd (hd)
#UEFI下不需要--top的map参数。
if %@uefi%==64 && map --mem /VHD/SSIC-WIN10-20241225-1509.vhd (hd)
#G4D下必须要map --hook，G4E下不需要会自动执行map --hook。
if %@uefi%#==# && map --hook
root (hd-1,0)
if %@uefi%#==# && chainloader /bootmgr ! chainloader /efi/boot/bootx64.efi
boot

进来学习的

我在QEMU虚拟机及实机测试，没有问题。不清楚你哪里是什么情况。可能与UEFI固件有关，没有条件排查。
既然不加 --top 正常，就不要加了。

有不少人问 grub4dos for legacy BIOS 下的 map --hook 的问题。

下面通过一个菜单实例，来理解 map --hook 的必要性。

    title find and load NTLDR of Windows NT/2K/XP\n find and load NTLDR of Windows NT/2K/XP
    find --set-root --ignore-floppies --ignore-cd /ntldr
    map () (hd0)
    map (hd0) ()
    map --hook
    find --set-root --ignore-floppies --ignore-cd /ntldr
    rootnoverify (hd0) —— 这句添乱了，不该有这句。请看后文解释。
    chainloader /ntldr
    boot

下面详细解释每一句的作用。


    find --set-root --ignore-floppies --ignore-cd /ntldr ——————这一句是确定当前默认的工作设备（也就是 root 设备）。找到含有 /ntldr 文件的那个设备，就把它设定为当前工作设备。假定这条 find 命令找到了 (hd2,3)，并把当前 root 设定为 (hd2,3) 了。


    map () (hd0) —————— 将当前默认设备所在的 BIOS 盘号映射为 “第一硬盘”。相当于执行 map (hd2) (hd0)


    map (hd0) () —————— 将“第一硬盘”映射为当前默认设备所在的 BIOS 盘号。相当于执行 map (hd0) (hd2)


    map --hook —————— 让前面的 map 生效。如果没有 map --hook，前面的 map 都只是一个 “暗示”，并未真正起效。如果没有 map --hook，此时你在 grub4dos 低下就会发现，hd0 的内容还是原先的 hd0 的内容；同样，hd2 的内容，也依旧是原先 hd2 的内容，也就是说，hd0 与 hd2 没有进行互换。 执行了 map --hook 以后，你会发现，两者确实互换了：hd0 的内容是原先 hd2 的内容，而 hd2 的内容是原先 hd0 的内容。

    find --set-root --ignore-floppies --ignore-cd /ntldr —————— 两个盘号互换以后，需要再次查找 /ntldr 文件，并确定新的当前默认设备是哪个设备。既然已经互换了，那么，此时它找到的，就应该是 (hd0,3) 了，于是，(hd0,3) 就被设定为当前 root 设备了。

    rootnoverify (hd0) —————— 这一句放在这里是错误的，此时不该有这句。如果没有这一句，此时当前root设备就是 (hd0,3)。而有了这一句，当前 root 设备变成 (hd0)——代表整个硬盘，而不是代表分区 (hd0,3)——那么，接下来的 chainloader /ntldr 就会因 “找不到 /ntldr 文件” 而失败。

    chainloader /ntldr —————— 这一句是加载当前 root 设备的 /ntldr 文件，把它当作引导扇区代码。
    boot —————— 这一句，首先是根据 “当前 root 为 (hd0,3)” 来设定 CPU 的 DL 寄存器的值为 0x80，然后把控制权交给前面已经加载的引导扇区代码。

【补充】第二条 find 命令的作用，就是在交换两个盘号之后，把 root 设备也进行相应的“更新”。比如，原来的 ntldr 是在 (hd2,3) 上，交换盘号之后，它就是在 (hd0,3) 上了。


然而，我们已经在第一次执行 find 命令时，找到了这个分区，（比如说）它就是 (hd2,3)。此时我们可以考虑“偷懒”，不再执行 find 命令，而是仅仅把当前 root 设备的设定，从 (hd2,3) 变更到 (hd0,3) 即可。


好的，我们就是想要让这第二条 find 命令不再执行了。


此时，我们心里明白，当前 root 设备依旧是 (hd2,3)。我们同时也知道，此时 ntldr 已经位于新的 (hd0,3) 上了。那么，我们就需要让 (hd0,3) 成为当前 root 设备。因此，执行 root (hd0,3) 就可以了。然而，如果我们直接执行 root (hd0,3)，这就不具有通用性了（因为分区号 3 是写死的，不能适应别的情况）。好在我们有个巧招，就是，执行 root (hd0,) 即可。此处，我们省略了分区号 3（然而要注意，逗号不可以省略——如果没有逗号，那就代表整个硬盘 hd0 了，而不是代表一个分区）。一般来说，grub4dos 发现了省略的分区号，就会用当前 root 设备的分区号来（自动）填补。所以，(hd0,) 就等价于 (hd0,3)。而我们执行 root (hd0,) 就具有通用性了。也就是说，这第二条 find 命令，可以用一条 root (hd0,) 命令来完美取代。这种“偷懒”能够减少一次 find 命令的执行，应该算是合理的吧？

【再补充】上述菜单示例中的 map --hook 调整为 map --rehook 更好一些。当 map 项目不存在时，map --hook 命令会报错，无法执行。换用 map --rehook 命令，就会忽略错误，继续执行。


总的来说，菜单改成下面这样，更完美一些：

    title find and load NTLDR of Windows NT/2K/XP\n find and load NTLDR of Windows NT/2K/XP
    find --set-root --ignore-floppies --ignore-cd /ntldr
    map () (hd0)
    map (hd0) ()
    map --rehook
    root (hd0,)
    chainloader /ntldr
    boot

这样更改以后，也能够适应当 find 找到的是 (hd0,x) 的情况。详细解释一下。


    find --set-root --ignore-floppies --ignore-cd /ntldr —— 假定找到了 (hd0,3) 上的 ntldr，设定 root 为 (hd0,3)
    map () (hd0) —— 相当于执行 map (hd0) (hd0)，把 hd0 映射成自己，也就是撤销对 hd0 的映射项目。
    map (hd0) () —— 也相当于执行 map (hd0) (hd0)，把 hd0 映射成自己，也就是撤销对 hd0 的映射项目。
    map --rehook —— 此时由于磁盘映射项目不存在，map --rehook 将不执行任何动作。但如果是 map --hook，则会报错。

    root (hd0,) —— 这句也没问题。执行这条命令之前 root 是 (hd0,3)，执行后，root 仍然是 (hd0,3)。
    chainloader /ntldr —— 加载当前 root 设备根目录下的 ntldr （“引导代码”）到内存。

    boot —— 启动前面已经加载的引导代码（递交控制权）。

G4E下没有必要使用 --top。纯粹是为了满足有些人的喜好。因为你不能随便使用内存，必须由固件分配，不存在内存冲突。

G4D一定要有 map --hook

报告问题，先得让人明白到底是 BIOS 还是 UEFI。

好吧，既然 BIOS 没问题，我就不参与讨论了。

你提的问题：BIOS 下需要 map --hook 吗？是的，必须。

UEFI 下，貌似 map 之后就自动 hook 了。具体情况，你可以阅读一下文档（如果有的话）。

另外，你在某个帖子中，致力于将 BIOS 和 UEFI 的 menu.lst 进行 “统一处理”，个人感觉，可能有点难度。

g4e 的开发历史还比较短，还在不断完善的过程中。再过一些时日，成熟以后，或许两者的 menu.lst 就比较容易进行融合了。

来了解下

if %@uefi%#==# && set bt=BIOS && set ph=/boot ! set bt=EFI_x%@uefi% && set ph=/efi
title 启动RAMOS-WIN10系统\n启动SSIC-WIN10-20241225-8504
#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/SSIC-WIN10-20241225-1509.vhd
map --mem --top /VHD/SSIC-WIN10-20241225-1509.vhd (hd)
#map --mem /VHD/SSIC-WIN10-20241225-1509.vhd (hd)
map --hook
root (hd-1,0)
if %bt%==BIOS && chainloader /bootmgr ! chainloader /efi/boot/bootx64.efi
boot

G4D下启动成功！G4E不成功。

你这是使用的G4E。似乎有些问题，等抽空看看。

学习学习，感谢分享。

问别人，恐怕更蒙吧？你自己已经是很熟练的了。

能操控你的电脑的人，也就是你本人了。别人看不到发生了什么，只有你自己能看到。

虽然我看不到，不过，我可以 “瞎出主意”，不一定管用。

以下这些思路可供参考。

你可以换用别的 img 或 iso 来试验（大的、小的，以及各种系统的），看看情况如何。

如果你怀疑是 grub4dos 的 bug，那就试试不同版本的 grub4dos，看看究竟是哪天引入的 bug。

用 grub4dos 的 displaymem 命令显示一下内存布局，看看 4G 以上的内存布局是啥样的？

“map --mem --top 不成功”，你是怎么知道 “不成功” 的？有出错信息吗？