GRUB4DOS for UEFI

yjd

今天正想更新U盘的grldr去下了最新版，然后发现在z77主板上加载 chenall 的 NTBOOT-2017-04-02.iso 文件会直接卡住。
而没我没更新之前grldr版本是0.4.6a 2017-03-30 和 NTBOOT-2017-04-02.iso里面的版本相同。就不存在这个问题。
加载菜单

1. title  NTBoot Chenall Plus \n
   
2. map /boot/imgs/NTBOOT-2017-04-02.iso (0xff) || map --mem /boot/imgs/NTBOOT-2017-04-02.iso (0xff)
   
3. map --hook
   
4. root (0xff)
   
5. chainloader (0xff)

复制代码

2011yaya2007777

请上传这两个文件。
请问，不是在uefi环境下吧。

yjd

2011yaya2007777 发表于 2023-11-23 18:47
请上传这两个文件。
请问，不是在uefi环境下吧。

z77主板uefi环境开了兼容模式，bios引导。
test.7z (1.8 MB, 下载次数: 15)

2023-11-24 10:54 上传

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

2011yaya2007777

title  NTBoot Chenall Plus
map /boot/imgs/NTBOOT-2017-04-02.iso (0xff)
map --hook
chainloader (0xff)
使用新版本grldr正常。

title  NTBoot Chenall Plus
map /boot/imgs/NTBOOT-2017-04-02.iso (cd)
map --hook
chainloader (cd-1)
使用新版本grldr正常。

yjd

2011yaya2007777 发表于 2023-11-24 15:37
title  NTBoot Chenall Plus
map /boot/imgs/NTBOOT-2017-04-02.iso (0xff)
map --hook

用新U盘格式成相同udm结构，复现了同样问题，看起来像新版grldr和udm存在问题？
1，udm工具按图格式化，解压模板拖进去。
模板： test-udm.part1.rar (2.5 MB, 下载次数: 6)

2023-11-25 00:03 上传

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

test-udm.part2.rar (2 MB, 下载次数: 6)

2023-11-25 00:04 上传

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

2，开启debug on，启动就卡这里
Qemu启动测试器.part1.rar (2.5 MB, 下载次数: 6)

2023-11-25 00:04 上传

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

Qemu启动测试器.part2.rar (499.97 KB, 下载次数: 10)

2023-11-25 00:04 上传

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

2011yaya2007777

使用3069#的grldr也是同样问题？
看你提供的截图，是执行 int13/ax=4b01 出现了问题。应当是平台的问题。
换另外一台不同机型的电脑试一试。

yjd

2011yaya2007777 发表于 2023-11-25 07:10
使用3069#的grldr也是同样问题？
看你提供的截图，是执行 int13/ax=4b01 出现了问题。应当是平台的问题。
...

1，模板里的grldr用的 #3069 的文件，还附带2017旧版测试则正常
2，换了G41+酷睿E3110 问题一样，原机启动非虚拟机

2011yaya2007777

2，换了G41+酷睿E3110 问题一样，原机启动非虚拟机

两次测试错误，提示与#3070的截图一样吗？
从截图看，是卡在 int13/ax=4b01 ，没有从 int13 返回。

不点

2011yaya2007777 发表于 2023-11-25 10:58
两次测试错误，提示与#3070的截图一样吗？
从截图看，是卡在 int13/ax=4b01 ，没有从 int13 返回。

在我主持开发期间，udm 并非我所支持的运行环境。换句话说，我并不接受由 udm 所产生的问题报告。报告者必须脱离 udm 环境，然后再复现出问题，这才承认是一个 “可以接受” 的报告。如果脱离 udm  之后，一切正常，那就不再视为是 “有问题” 的了。我有义务向现在的开发维护者汇报这个历史。仅仅是汇报而已，不希望有任何干扰，以及可能带来的其它负面影响。

2011yaya2007777

谢谢不点大师评论。

yjd

2011yaya2007777 发表于 2023-11-25 12:42
谢谢不点大师评论。

刚才U盘单独格式化成FAT32做了测试，新版也正常。确定问题出在udm分区引起了。

yaya可以忽略我这次报告。谢谢！

本来计划要淘汰udm。看来要提前了。

不点

淘汰 udm，小事一桩。就连 grub4dos for legacy BIOS 都该消失了。

不点

再多说几句废话，虽然没什么太大的用处（因为 BIOS 正在淘汰）。

我们每个人面前都有很多条路可走，都有很多选择。开发者如此，用户也一样。开发者选择的开发方向是由开发者决定的。用户选择的使用方式、习惯，是由用户自己来决定的。如果开发者只有一个，那么，用户别无选择，只有用这个开发者的产品。如果开发者有多个，产品细分为很多种，那么，用户也就有很多了。有的用户偏爱这个产品，有的用户偏爱另一个产品。

两个产品，有可能产生不协调，或者叫做冲突。这时候，用户也是很无奈的，或者说是很懵逼。如果这个情况是无法避免的，那也就算了，不提了。但如果这是可以避免的，那就很值得思考了。也就是说，人为造成的冲突，一开始就埋下祸根，终有一天会爆发出来。我理解不动，为何放着光明大道不走，偏要去走那条本来就必然会产生冲突的那条路呢？一部分用户跟着你走，是对你的信任。而你能对得起这些用户的信任吗？虽然 BIOS 就要死了，但这个道理还在，未来照样会发生类似的事情。

不点

刚才这段话，说得太隐晦，可能不容易让人理解。现在试试说直白一点。

一个开发者用了我的产品作为基础进行二次开发。但在技术上，他的使用方式是错误的，是我无法接受的。此时他的产品出了问题，还让用户跑到我这里寻求解决，大家说说，我该咋办？肯定是拒绝，对不对？人之常情，谁都会这么做。关键是，不可能解决。根源在于此开发者没有按照我这个软件的使用要求去使用，这是必然会出问题的，而且究竟会出多少个问题，无法预料。我这里也没有办法去解决。就算想要去解决，也毫无边际，没有尽头，是无穷无尽，永远陷进去，无底洞。这就相当于，我被别人牵着鼻子走，大家说，这事我能乐意去干吗？好吧，这样写应该容易理解了。

yyz2191958

谢谢分享

AndrewCharlotte

感谢分享

yjd

不点 发表于 2023-11-26 07:44
再多说几句废话，虽然没什么太大的用处（因为 BIOS 正在淘汰）。

我们每个人面前都有很多条路可走，都有 ...

bios我现在还在用。暂时还没到淘汰的时候，有不少软件还是bios引导操作方便。
距我上次更新启动U盘是2017年。也就我这U盘6年没动过。好多都快忘光了。
所以这次遇到问题。卡住，第一时间就到这里反馈，没去测试udm。我的问题。

我淘汰udm主要还是因为做好的bios+uefi引导，经常在不同电脑启动后，就会被破坏。导致可能uefi不能启动，也可能bios有问题，经常要修复。后期得试试三分区或U+哪个好用。ud bios很稳但是现在得双启动的支持更好。

2011yaya2007777

启动后就破坏，一定是向U盘写入了什么。U盘有个读写开关就好。

不点

udm 里面的功能很丰富。那些超出 grub4dos 的部分，我也不能进行评论。最后还是要看综合效果，即，用户的欢迎程度。

我可以从另一个侧面去评论。功能集成了很多，然而这驾驭起来，难度就增大了，需要更长的时间、花费更多的精力才能磨合妥当。

legacy bios 的启动软件是很难开发的。需要处理的方面太多了。而 EFI 能够在文件系统底下操作，这方面的负担大大减轻了。我在开发 wee63.mbr 的时候，发现了某个工具软件（貌似 ghost 之类的）会写入第 63 扇区，直接破坏了 wee 的代码。这是高手们在使用过程中发现的，不是我发现的。所以后来就把代码压缩为 62 个扇区，这样才躲过与那个工具软件的冲突。udm 在原则上也可能碰到类似的问题。代码可能以某种方式被破坏了，所以出现了莫名其妙的的问题。

开发难度高，所以，更需要小心翼翼，而不是放松警惕、随心所欲。要尽量减少出问题的可能性。

比如，要调用 grub4dos，那就应该使用正规的方式来调用，而不是用 hack 的方式直接调用 grldr 里面的 stage2。正规的调用方式是这样的：

把 grldr 完整地加载在内存中，就像加载 ntldr 那样，然后递交控制权。

或者

在 grub2 里面，用加载 linux 内核的方式来加载 grub.exe，这也是正规的调用方式。

开发启动软件的另一方面的困难在于，用户报告出来的问题，需要尽快解决。要抢时间。不可以让问题堆积起来。问题堆积得多了，用户就失去信心了，会流失的。解决问题的速度，应该快于用户报告问题的速度才对。比如用户每个月报告 3 个问题，那就应该每个月解决 3 个问题才行。如果每个月只能解决 2 个问题，那就太慢了，问题会堆积起来，最终的结果是：一堆问题都得不到解决。

不点

今天又有一点新的想法，与大家共同探讨。

BIOS 要遭到淘汰，这个趋势是不可改变的。我新买的电脑，就只支持 EFI，没有办法使用 BIOS 了。

我在想：既然 BIOS 已经处于死亡的边缘了，那么，硬件厂家对 BIOS 的恶意封杀，是不是会减小一些呢？就是说，一个将死之人，你还有必要用枪去打他吗？我的意思是说，那些现在还在支持 BIOS 的硬件，很可能已经撤销了原先针对 gnu grub、grub2、grub4dos （都是 for legacy bios）等而进行的各种封杀。当然，它们最终是会彻底取缔 BIOS 的，那样也就很自然地、很彻底地消灭了 BIOS 下的所有启动软件。

好的，既然它们不会封杀了，那么，那些 fbinst、multimbr 之类的技术，是不是都可以不必使用了呢？这是我的猜测，不一定符合真实情况，只是一个想法罢了。

所以，大家如果还在用 BIOS，可以尝试普通的启动方式，而不是 fbinst 之类的方式。就是说，直接把 U 盘格式化成 FAT32、NTFS 等格式，在 U 盘的 MBR 上安装 grub4dos 或 wee63.mbr，试试这样能否启动成功。

yjd

2011yaya2007777 发表于 2023-11-26 12:54
启动后就破坏，一定是向U盘写入了什么。U盘有个读写开关就好。

我U盘有保护开关，但是不想用不方便，一次也没用过。所以选了隐藏分区+可见分区畸形目录。

yjd

不点 发表于 2023-11-27 06:40
今天又有一点新的想法，与大家共同探讨。

BIOS 要遭到淘汰，这个趋势是不可改变的。我新买的电脑，就只 ...

我的需求是要个隐藏分区。看了下Ventoy使用是挺方便，不过都是可见分区，如果没保护的U盘。理论上文件容易被感染。特别是到处给别人弄电脑的时候。

2011yaya2007777

可能是病毒，也可能不是。可能有程序向磁盘写了些什么，这与分区隐藏不隐藏无关。

不点

出问题，有很多可能性，至少有两种。一种是病毒、或者别人的软件，写入了扇区，导致你的扇区数据被覆盖。另一种可能性是，自己所用的软件本身有 bug，导致各种失败。用不合适的方式调用 grub4dos，那就不属于 grub4dos 的 bug，而属于调用者的 bug。

如果调用者是正常、正规的调用 grub4dos，而问题依然出现，那就怀疑，大概是扇区数据被别的软件（或病毒）覆盖了。

所以，启动结构应该尽量设计得简单，不要绕很多弯。弯越多，出问题的概率就越大。

不点

再说一点想法。关于开源。

启动软件，你是很难拿来卖钱的。没必要闭源。就算你要卖钱，你也不一定能有很好的收入。而且，假如你好不容易有了很好的收入了，此时却被某巨头盯上了，一通骚操作，你的软件灰飞烟灭。

开源有什么好处？当开发者（你）没精力维护的时候，就会有别人（替你）继续维护。

如果不开源，当你撒手不管的时候，而且有很多问题在等待解决的时候，你这个软件是不是就处于死亡状态？难道你开发软件的初衷就是这样的吗？

2011yaya2007777

不点大师说的到位。

不点

2011yaya2007777 发表于 2023-11-27 12:39
不点大师说的到位。

您才是大师，我只是岁数大而已。岁数大，碰壁多，吃亏多，经验教训多，仅此而已。身体是第一位的，一定在保护好身体的前提下，再来做自己喜欢的事情。

不点

关于 “在执行 int13/4B01 时发生死机” 的问题，今天有一些想法。

有以下可能性：

1、grub4dos 本身出现的 bug。这又分两种：（A）是 grub4dos 的代码、数据结构等出现了 bug。（B）是编译器 gcc 出现的 bug【而 grub4dos 的代码、结构都没有问题】。以上这两种，笼统都算是 grub4dos 本身出现的 bug。这是因为，用户拿到的是二进制编译结果，而不是 grub4dos 的文本程序代码。既然二进制编译结果是有问题的（尽管有可能是 gcc 造成的问题），那就算是 grub4dos 本身的问题。

2、调用 grub4dos 的那个调用者，出现的问题。可以通过举例来说明这方面的问题。

开发者在开发 grub.exe 的时候，已经知道，DOS 环境修改了中断向量表，而 grub.exe 无法完整恢复被 DOS 修改了的中断向量表，所以，有可能出问题。也正因如此，开发者建议尽量使用 grldr 而不是 grub.exe，也就是说，尽量躲过 DOS 环境，这样就降低了出问题的概率。强调一下，从 DOS 调用 grub.exe，这个调用者是 DOS，增加了复杂性。刚才说了，DOS 对于中断向量表的修改，就是造成问题的一个因素。grub4dos 的开发者，无法把控 DOS，换句话说，无法完全摸清 DOS 的内幕、底细，所以，不敢保证 grub.exe 能够适应各种 BIOS 环境（尤其是那些专门故意攻击 grub4dos 的主板）。因为没能完全恢复出原始的中断向量表，它们就可能在那些没有恢复的中断向量上添加一些 “能够让 grub4dos 死机” 的代码。比如说，这个主板（时不时地）专门去调用那个没有恢复的中断向量，这就必然要死机了。

上述例子说明了，grub4dos 的运行环境是很脆弱的，经不起一点周折。用户（以及第三方开发者）在使用 grub4dos 时，要尽量减少复杂性，减少周转步骤。要尽量直接使用 grub4dos，而不是经由另外一条路径间接进入 grub4dos。为什么呢？因为，既然你是间接进入 grub4dos，那么，你在进入 grub4dos 之前，做了哪些事情呢？你做的那些事情，就有可能埋下隐患了。你自己都不一定意识到。你可能觉得你的代码是 “正确” 的，不会有问题。然而，你不明白的是，“正确” 的代码，照样可以出问题，因为某个主板的底层程序做了微调，专门让某些的 “正确” 代码产生死机。你可能正好 “躺枪” 了。grub4dos 当然也会 “躺枪”，不过呢，grub4dos “躺枪” 的概率，肯定比你躺枪的概率低。为什么呢？因为 grub4dos 的开发者早都意识到了，并且也躲过了无数的 “枪”，或者说，已经中过那个枪了，不敢再去那个地方了，也就不会再去 “中枪” 了。你都没有这个意识，怎么可能会躲过呢？比如说，某些不该执行的 int13 调用， 你却执行了。此时你来调用 grub4dos，死机了。你大概不会知道，正是你先前执行的这个 int13 调用，触发了 “魔鬼”，让 BIOS 开始不稳定，或者 “颠簸”，导致 grub4dos 死机。根源是 BIOS 已经 “有病” 了，而不是 grub4dos 的锅。而 BIOS 之所以 “失常” 了、“神经” 了，则是因为你在不经意间触碰了 “魔鬼”。

刚才说的是某些主板故意制造的一个陷阱，在别的主板下，不存在同样陷阱（但可能会出现另外一个陷阱；陷阱是很多的，五花八门，各具特色）。

其实，还有一种可能性，就是，你在调用 grub4dos 之前，已经以某种方式对内存中的关键代码或数据造成了破坏。这是你自己的程序代码的锅，不是主板 BIOS 的锅。比如，你的代码在运行时，破坏了某些中断向量，或者破坏了 BIOS 数据区。这样，不仅 grub4dos 无法正常运行，其它任何启动软件，也都无法正常运行。

好的，最后一种可能。你没有躺 “主板 BIOS” 的枪，也没有破坏内存关键代码、数据。但是，你建立了一个 int13 磁盘映射。这个磁盘仿真代码是你自己编写的，也可能是来自 memdisk 等。grub4dos 运行在你建立的这个磁盘映射之下，这可超出了 grub4dos 的使用范围（前面提到过，这是增加了复杂性）。那么，这个先于 grub4dos 而存在着的、额外的磁盘仿真环境，就得 “准备好” 为 grub4dos 的启动失败而 “背锅”。因为，你接管了 int13，而正当 grub4dos 要去调用 int13 时，你的代码不工作了、死机了！ 公平地说，grub4dos 要背 50% 的锅，你的 int13 环境也应该背 50% 的锅。究竟是谁的锅，通过调试、排查，就会弄清楚。设计几个简单的试验，用户自己通常就能判断出来。

本帖的探索性思考，希望能够对开发者有所帮助【让开发者不至于被用户的失败报告弄得疲惫不堪】，当然也希望能够对用户如何正确使用 grub4dos 有些许参考价值。

huchiren

感谢分享

2011yaya2007777

不点分析的对，两种可能皆有。问题是常规启动正常，而udf启动失败，我怀疑他在不同启动模式切换，很可能使用了grub.exe。