GRUB4DOS for UEFI

yjd

2011yaya2007777 发表于 2023-12-4 11:52
我下载了udm，查看文件没有grldr，但是设置里面有，不知怎么使用。

我看ldr目录还grldr文件，做了新版替换，
菜单里有个更新grldr功能{测试功能好像失效}，但是这些我也从来没用过。今天尝试更新替换，测试也没启作用。yaya 做参考即可，很大概率应该出在udm跟g4d无关

2010XwX

yjd 发表于 2023-12-5 17:21
根据 3121# 案例 ，做了测试：
1，替换 NTBOOT-2017-04-02.iso 里面的引导文件和根文件为同样最新grldr， ...

udm 我没有用过。NTBOOT 可以下载 5大的 2022-11-11 版。有两种形式，一个是 ISO 版，一个是单文件版。我使用的是单文件版。一个用来直接启动 Ventoy.vhd（Ventoy 虚拟硬盘），第二作为启动管理器来用，没出过什么问题。不知 5大的 NTBOOT 和你用的是否同一个。NTBOOT 我整合在 C大的 USBOS 启动移动盘里（ud）。
我看了一下，5大的 NTBOOT-2022-11-11.ISO 里面的 grldr 是 2022-10-26。
另外你还要注意一点，光更新 grldr 还不够，里面是否还有 grldr 运行环境版本要求的判断。

liuguangyan

恭喜楼主

2011yaya2007777

我看ldr目录还grldr文件，做了新版替换，

1. 直接替换“\MBROSTool6.26.12A-12x8664-20220630B26\ldr\grldr"文件为最新版本。
2. 运行MBROSTool.exe，选"高级->启动设置"，在选项卡"BIOS启动器->启动文件"选择”ldr\grldr",
    点击“导入并设定”。
3. 使用 QEMU 虚拟机启动U盘，进入命令行。（可能菜单设置有问题，没有搜索到 grldr）
    执行 find，判断文件在什么地方，配合 ls (hdx,y)。比如找到为 （hd0,0)/
4. 启动镜像
    root （hd0,0)
    map /NTBOOT-2017-04-02.iso (0xff)
    map --hook
    chainloader (0xff)
    boot
正常启动！

说明：
我的启动文件 NTBOOT-2017-04-02.iso 在可见区。
不知道有没有隐藏分区，怎么放在隐藏分区。

kevin2023

菜单目录更能不能自定义

2010XwX

2011yaya2007777 发表于 2023-12-6 10:03
1. 直接替换“\MBROSTool6.26.12A-12x8664-20220630B26\ldr\grldr"文件为最新版本。
2. 运行MBROSTool.e ...

我的启动U盘是 ud 三分区形式，ud 启动最新版 grub4dos-0.4.6a-2023-11-27，因没有 yid 的 NTBOOT-2017-04-02.iso，测试的是 5大的 NTBOOT-2022-11-11.iso ，iso 放在隐藏区，测试正常。

yjd

2011yaya2007777 发表于 2023-12-6 10:03
1. 直接替换“\MBROSTool6.26.12A-12x8664-20220630B26\ldr\grldr"文件为最新版本。
2. 运行MBROSTool.e ...

我没测试成功，到了chainloader就卡住，我看你操作好像都没把U盘格式化成udm分区格式。如图：
(hd0,0)是udm隐藏分区，存的就是3070# 模板文件(hd0,2)是可见数据分区

2011yaya2007777

我格式化成udm了。你的iso在看见分区还是隐藏分区？好像是可见分区。我是mbr分区模式，在g4d环境只有分区0。
使用mbrostool.exe的分区管理看，还有3个隐藏分区。

我把 efi 分区删除了。
咱俩的grldr版本不一样。

yjd

要拷数据到 udm隐藏分区，这样操作：


我的udm分区分布是这样（菜单--高级--分区管理|udm管理）：




刚才用grldr 2023-11-27 测试也都是到 root(0xff) 或 chainloader (0xff) 就卡住

2011yaya2007777

我的grldf在隐藏分区。但是目前我看不见。如何可见？

2011yaya2007777

我的iso在可见分区，你的在哪里？

2011yaya2007777

其他无论怎样都不会影响结果吧。

2011yaya2007777

我看见隐藏分区了。
其中有：grldr    menu.lst
但是这个  grldr  不是我安放进去的，是以前的。我启动到命令行不是这个版本，说明不是由这个 grldr 启动的。
我安放的那个--真正用作启动的 grldr 在哪里？

不再烧脑了，放弃。
这个问题就此打住！不再议论。

yjd

2011yaya2007777 发表于 2023-12-6 17:50
我看见隐藏分区了。
其中有：grldr    menu.lst
但是这个  grldr  不是我安放进去的，是以前的。我启动到 ...

辛苦了，不用继续讨论。是udm问题。我也要改成ud。

最后回复下
隐藏的udm分区的grldr和menu.lst是我模板里的自定义文件。而你从udm工具导入的grldr实际是看不见的，udm工具也没地方可以显示出来。这个隐藏位置约等于MBR

1，U盘引导优先加载你导入的grldr
2，如果不手工导入grldr，U盘引导优先按规则搜索到udm隐藏udm分区的grldr并加载

不点

不想影响各位讨论。我插入一段文字。

BIOS 还要不要用？不用的话，那就不提了。如果还要用，哪怕是暂时的，也得遵循 BIOS 下的 “规律”、“法则”、“方式”、“方法”。逻辑要清楚，而不是一团乱麻。

首要的一个问题：谁来做为第一启动？这个是非常非常重要的。

在此之前，你还得做个选择题：你是想要 “功能”，还是想要 “启动成功率”？

假如你想要 “功能”，把 “启动成功率” 作为次要的，那么，你不要往下看了。

好的，按照约定，你要的不是 “功能”，而是 “启动成功率”。

因此，你八成会使用 fbinst + grub4dos 作为主要启动手段，用微软的各种引导方法，作为辅助启动手段。甚至你偷懒，只用 “grub4dos、 微软引导” 这两个，也不是不行，只是成功率会有所降低。

我想说啥呢？我要说的是，不要 “周折”，不要 “拐弯”。只要 “周折、拐弯”，就会增加路程，增加出问题的概率。这么说比较抽象，那就具体说说吧。

比如，你要使用 grub4dos，那就让 grub4dos 接管 BIOS 控制，而不是 “让别的软件接管 BIOS 控制，然后再把控制交给 grub4dos。” 你可以用另一个 U 盘来做个微软启动，此时，微软的 BOOTMGR 来接管 BIOS 控制。

写到这里，我发现我举的这个例子不太合适。因为，碰巧 grub4dos 和微软的引导能够共存在同一个 U 盘上（微软的引导扇区能够引导更了名的 grldr）。不过没关系，大家理解成 “无法共存、必须使用两个 U 盘” 即可。如果能够用两个 U 盘做到近乎 100% 的启动成功率，那也是相当令人满意的。

有人问了：从 grub4dos 启动 bootmgr，这算不算 “拐弯”？这要看你自己的判断了。严格来说，也算是 “周折” 了，但实际上，基本上不算是 “周折”。因为 grub4dos 的操作是 “纯绿色” 的，对内存关键数据结构没有任何伤害，不会对 bootmgr 的启动产生不良影响。换句话说，bootmgr 被 grub4dos 加载，完全等同于被微软自己的引导扇区加载。

bootmgr 加载 grldr 的情况怎么样？也差不多算是 “纯绿色”，不算是 “拐弯”。换句话说，grldr 被 bootmgr 加载，也基本认为是等同于被 grub4dos 自己的引导扇区加载。

好的，这是个铺垫。关键的问题来了。还有哪些属于 “不拐弯” 的？而有哪些属于 “拐弯” 的呢？

ud 是 grub4dos 内建支持的，肯定属于 “不拐弯”、“纯绿色” 的。

但是，从其他的软件、环境进入 grub4dos，都应该算是 “拐弯” 的。比如，从 grub2 进入 grldr （或用 grub2 的 linux 命令加载 grub.exe）, 都是经过了 grub2 的主体程序的运行，都有可能触碰某些 BIOS 陷阱（魔鬼），因此，都算是 “拐弯”。如果是从闭源的软件进入 grub4dos，那更属于 “拐弯”。

为什么从 bootmgr 进入 grub4dos 就不算是 “拐弯” 呢？因为，既然 bootmgr 接管了控制，我们就认为 BIOS 没有受到伤害，也即，没有碰上魔鬼。bootmgr 是微软的，因此 bootmgr 的 “面子” 大，主板制造商们都会考虑支持和兼容 bootmgr。

我写得乱，有可能把人绕晕了。我想说的关键问题是：哪个软件是可靠的？哪个软件是值得信任的？每个人都有着自己的答案。你最信任谁，就把谁作为主要启动手段。你不要把你 “第二” 信任的那个软件作为 “第一” 启动（然后才把控制递交给你最信任的那个软件上）。也就是说，对于你最信任的软件，你不要让它的启动路径发生 “拐弯”，而要让它直接从 BIOS 那里接管控制。这么说，就是公平的了。你不一定最信任谁；有可能是 grub4dos，也有可能是别的某个启动软件或工具。补充这段话，是防止前面写的乱，把你绕晕了。希望这次写清楚了。前面虽然写得长、写得乱，但更详细、更具体，应该也更具有参考价值吧，我这么认为。


【确实需要补充】本主题是 EFI 专场，不应讨论 BIOS。但有人在本话题底下报告 BIOS 的问题，其实是一种绑架。我在本话题里面回帖，也是助长了绑架。我谈及这一点的目的，不是责怪谁，而只是想表明，我的回帖，都是关于 legacy bios 的，而与 EFI 完全无关。比如，我说从 grub2 进入 grub4dos，就算是 “拐弯”，此处的 grub2，仅仅是指 grub2 for legacy bios，不是指 grub2 for EFI。澄清这一点，防止发生误解。


也许有人偏要从 grub2（for bios） 进入 grub4dos。我认为，这要看他的理由是啥。如果理由是 “grub4dos for bios（作为第一启动）遇到启动失败，可靠性降低，不得不试试用 grub2 作为第一启动”，这个理由是合适的，逻辑也是成立的。如果理由是 “grub2 具有某个强大的（或者方便的）功能，而 grub4dos 不具备，所以要用 grub2 来作为第一启动”，我觉得这个理由就不合适。


而且，如果你觉得 grub2 的启动成功率比 bootmgr 还要高，那是可以用 grub2 来作为第一启动的。否则，不应让 grub2 作为第一启动，而应该让 bootmgr 作为第一启动。


由于我个人接触到的场景不多，因此，我无法获得 “grub2 比 bootmgr 成功率高” 的证据。我贸然揣测一下，你也很难得到这样的证据。


如果你的启动工具只是在你周围的小范围使用，或者只在硬盘上（而不在 U 盘上）使用，你就发现不了问题。此时你很可能觉得，任何启动软件都能工作，毫无差别。但如果你的工具发布出来，让世界上所有的人在各种环境下使用，你就会发现 “不同的启动方式具有不同的启动成功率” 的问题了。

willishe

没测试过。

不点

我再补充一段。

grub4dos 的开发者很重视 “互操作性”。在可能的情况下，grub4dos 尽力支持别的启动软件，除非那个启动软件的开发者千方百计设卡，不让用户能够经由 grub4dos 来启动他的软件。反过来也一样，grub4dos 的开发者为别的软件能够方便地启动 grub4dos 架设了桥梁。让用户能够直接用加载 ntldr 的方式来加载 grldr，这就是一个桥梁。别的软件的开发者（或用户）只要懂得如何加载 ntldr，那就懂得如何加载 grldr 了，完全不存在 “需要重新学习新知识” 的问题。另一座桥梁是 grub.exe，这是 linux 的 kernel 格式。任何能够加载 linux kernel 的启动软件，都可以加载 grub.exe，同样也是 “完全不需要学习新知识”。

就是说，grub4dos 作为第一启动，能够加载别的启动软件（那么被加载者也就是作为第二启动了）。这种情况是很安全的，因为 grub4dos 是 “纯绿色” 的软件，整个运行过程，不会对内存数据结构造成任何影响。别的软件在被 grub4dos 加载时，其内存和 CPU 的状态就跟主板通电自检之后的状态是一样的。只要这个软件自己没有 bug，那么 grub4dos 就不会给它增添一个 bug。例外情况有没有呢？当然有啊！否则，grub4dos 不就称王称霸了吗？例外情况，就是 grub4dos 被主板封杀了。这种封杀非常多！但大多数封杀，都已经被开发者巧妙躲过。新的封杀，如果有的话，是无法躲过了，因为开发者已经不把 BIOS 作为重点了。那就是说，随便封杀吧，反正你不封杀，也是个死，封杀，也是个死，都一样。BIOS 整体来说，总归是个死，总要被 EFI 取代。grub4dos 的被封杀，从用户的角度来看，可以认为 grub4dos “不可靠”。被封杀，当然属于 “不可靠” 的一个重要方面。也就是说，用户当然可以 “不信任” grub4dos。用户有这种自由。当 grub4dos “失效” 时，在另外一个 U 盘上，用户可以选择别的启动软件啊，对不对？

刚才说的是 grub4dos 作为第一启动。现在说说，grub4dos 作为第二启动。

grub4dos 确实可以作为第二启动。但是，你得保证，你的第一启动确实优秀。你的第一启动的责任就大了。相信你不会选择一个很烂的软件来作为第一启动，因为你不是傻子。但是，你有可能选择了一个不那么优秀的软件作为第一启动。“不那么优秀” 是不行的。你都把它放在 “第一启动” 的位置上了，它还敢 “不那么优秀” 吗？根本不敢！你的第一启动，就得为后续的任何启动过程 “负责”，包括为后续的 grub4dos 的启动负责，不可以给 grub4dos 带来莫名其妙的新的 bug。这正如 grub4dos 作为第一启动时，也必须为后续的整个启动过程负责一样：grub4dos 不可以给后续的 “第二启动” 软件带来任何一个新的 bug。【我们的想法要符合逻辑，要懂得换位思考，尽量做到公平。】

如果 “第一启动” 不小心，污染了 CPU 状态以及内存关键数据结构，那就会给 “第二启动” 带来麻烦。开发者 “自负” 是不行的，“自信” 也不要太过分。因为，假如没有封杀，你完全可以自负、自信。在有封杀的情况下，你哪来的自信？嗯？？封杀者没有针对你？封杀只针对 grub4dos？你的想法太过于简单了。马路上有人挖了个深坑，任何车辆都有可能陷进去。grub4dos 早都吃亏了，已经知道必须绕道走了。而你，完全不了解这些情况，你不中枪谁中枪？你以为那还是一条可以正常通行的马路啊？这跟你的程序代码 “正确与否” 没有关系。你越是 “自信”、越是 “自负”，你出问题的可能性就越是大。如果我要狂妄一点，我可以这么说：“我用贞操担保，你开发启动软件是不行的，尤其是不要开发 BIOS 下的启动软件。”但是，做人要低调，不可以如此狂妄，如此教训别人。提出自己的看法，让别人参考，让别人自己决定取舍，这是合适的。

2011yaya2007777

赞同

2010XwX

不点 发表于 2023-12-8 05:30
我再补充一段。

grub4dos 的开发者很重视 “互操作性”。在可能的情况下，grub4dos 尽力支持别的启动软 ...

互包容性，共赢模式！

137731

支持

137731

学习中

w332276

测试下。

evilDegg

2233333333

cantsong

围观中

evilDegg

牛逼

sanmu82

感谢分享

hhh333

新版，CD的标志改了？0x9f也是光盘

以前不是0xA0:0xFF才是光盘吗？

不支持诸如：
if %?_BOOT%==(cd)
if %?_BOOT%==(pd)
if %?_BOOT%==(ud)

这类用法了吗？

2011yaya2007777

新版，CD的标志改了？0x9f也是光盘

一般概念，0xA0:0xFF是光盘，这是map一个光盘时，grub内部分配的驱动器号。
但是VM虚拟机原生启动光盘，虚拟机的BIOS固件自己会分配驱动器号0x9f（QEMU会分配0xe0）。因此grub_0.4.6a初期就修改为0x9F:0xFF是光盘，不是最近的事情。

不支持诸如：
if %?_BOOT%==(cd)
if %?_BOOT%==(pd)
if %?_BOOT%==(ud)
这类用法了吗？

最初(cd)是特指原生启动光盘，不包含映射光盘。为了与G4E的菜单兼容，现在(cd)与(hd)概念相同，即包含原生启动光盘，也包含映射光盘。
使用上，可以这样：
map /xx.iso (cd)
chainloader (cd-1)

因此现在：if %?_BOOT%==(cd) 无效。
可以这样：if %?_BOOT% >= 0x9f

由于pd=0x21,  ud=0x23是固定的，因此：
if %?_BOOT%==(pd)
if %?_BOOT%==(ud)
可以继续使用。

mhk018

很给力!

hhh333

2011yaya2007777 发表于 2024-1-29 09:44
一般概念，0xA0:0xFF是光盘，这是map一个光盘时，grub内部分配的驱动器号。
但是VM虚拟机原生启动光盘， ...

谢谢解答，终于搞清了