grub4dos出错提示inconsistent filesystem structure

不点

2011yaya2007777 发表于 2019-4-21 14:51
我知道了。是参数 --top 的问题。
2017-02-03开始，加参数 --top 从 4Gb 以上内存分配空间，否则从 4Gb 以 ...

inconsistent filesystem structure

是说 “文件系统结构不完整”。这与内存，应该是没有关系的。

读 ISO 或 IMG 到内存的时候，首先要访问该 ISO 或 IMG 所在的分区，比如 (hd0,0)。

如果该分区的结构有错误，就会出现这个错误信息。

如果这个 ISO 或 IMG 文件所在位置超出 BIOS 的访问能力，可能也会出错。

有很多 BIOS 都只支持 137G，超过的部分，访问了就会失败。

楼主的 256G，超过了 137G 的大小。

整理碎块，将文件放在盘的开头附近，可能就好了。

或者重新格式化这个 SSD，让它的第一分区很小（比如只有 8G），然后把 ISO 放进去，再试验，可能就好了。

如果还是不行，那就怀疑 2018-02-03 同时修改了文件系统的驱动程序，产生了 bug。

总之，在我看来，这与内存应该是毫无关系的。是读文件的过程就出错的，错误信息指明属于 “文件系统错乱” 的问题，而不是 “内存不够” 之类的问题。

不点

2011yaya2007777 发表于 2019-4-21 15:42
不是bug，是改进。
以前的内存大多小于 4Gb，没有差别。现在 4Gb 以上内存普遍了，所以要注意。
你加上 - ...

无论放在 4G 以上还是以下，都是放在 Usable RAM 的区域，而不可能放在 Reserved 区域，因此，是不会出错的。如果这出错的话，那就严重了，应该早就有人报告了，而不会等到现在才有人发现错误。

不点

我猜，不用 map，只用 blocklist 命令，应该也会出错。

blocklist   (...)/.../.../your_file.iso

就是说，只要去碰这个文件，它就会出错。

如果我的猜想被证实了，那就可以说与 map 命令无关了，而应该属于 grub4dos 里面的文件系统驱动程序的 bug，或者 BIOS 的 bug。

而楼主报告旧版本没问题，因此，这就排除了 BIOS 出错的可能性。

只剩下一个可能性：grub4dos 的文件系统驱动程序有修改，在修改时产生了 bug。

不点

楼主必须在这个 SSD 上测试，才是有效的测试。

放在机械硬盘上与放在 SSD 上，是完全不同的。千万不要以为 “文件名一样，结果也一样”。


用不同版本的 grldr 进行测试时，必须使用同一个 iso 文件，而且这个 iso 文件的位置不能移动，即，始终都不把它复制到别处，它是定死在原位置不动的。这样才能确定究竟哪个 grldr 是有问题的。


楼主在机械硬盘上可以正常使用这个 iso 文件，这就证明，map 的部分是没有错误的。也就是说，错误与 map 命令无关。这也得出了与上述猜测相一致的结论，即，错误出在 读的过程中。



除了 blocklist 以外，还可以试试 cat --hex


cat  --hex  (...)/.../your_file.iso


它也会触发那条错误信息。

不点

本次 --top 的改动，（印像中）是我干的。

但是，我的改动也是严格检查了的，“很难出错吧”，我只能这么说（因为我不能说 “完全不会出错”，太武断了）。

但是，yaya 居然让楼主试试 --top，竟然真的没问题了！

我来猜测并解释一下这究竟是怎么回事。

在 2017-02-03 以前的旧版本中，不加 --top 是从低向高搜索空闲空间。

楼主的内存碎块是这样的：

（1）Usable RAM  （一大块）正常
（2）Usable RAM  （一小块，忽略不计）
（3）Usable RAM  （一大块）<----作孽呀！
（4）Usable RAM  （一小块，忽略不计）
（5）Usable RAM  （最后这块是最大的那块，位于 4G 以上）正常

旧版本的 --mem 会找到第（1）块内存，并使用它。结果正常，没有出现问题。

yaya 给出新版的 --mem --top，会使用 4G 之上的那块，即第（5）块，也正常，没有问题。

出问题的是新版 --mem，由于 --top 不见了，新版会智能地在 4G 以下寻找可用空间。但是，新版永远是 “从高向低寻找可用空间”，因此，就找到了第（3）块。而作孽的，恰恰就是这一块。


BIOS 告诉我们，这是一个 Usable RAM（可用内存块）。但是，当我们真的来 “使用” 这一块（即，写入它）的时候，BIOS 却自杀了！——也或者说，戳到了它的伤疤，它立马就犯神经病了！换句话说，这不是一个可以随便使用的内存块。BIOS 骗了我们，引诱我们去使用它！因此，这是 BIOS 的 bug，依我看，八成是故意搞事吧，流氓 BIOS 本来就多如牛毛。


好的，我这就已经给 yaya 解释清楚了。下一步，就看 yaya 如何 “善后” 处理了。


注意，不可以将搜索顺序调整为从低到高。因为流氓 BIOS 也会在其它块上 “使坏”，跟搜索顺序无关。一个变通的解决办法是，尽量使用 --top，这样的话，总是选用 4G 以上的内存块，这样也就不会与低端 BIOS 区域相冲突了。也就是说，开发者什么也不用做，只是提醒用户 “尽量使用 4G 以上的内存块”，这就完事了。

不点

liuzhaoyzz 发表于 2019-4-21 17:16
cat  --hex  (...)/.../your_file.iso
是正确的，没有出错。

谢谢辛苦。同时也向你表示抱歉，让你辛苦做的那些测试都是无效的，白做了。yaya 让你测试 --top 成功，这才暴露出了症结在哪里。

不点

2011yaya2007777 发表于 2019-4-21 17:07
试一试
map --mem /WePE_64_V2.0.iso (0xff) || map --mem --top /WePE_64_V2.0.iso (0xff)

根据先前我的解释，这个操作注定要失败。

当前半部分 map --mem /WePE_64_V2.0.iso (0xff)  执行的时候，第（3）块内存就已经破坏掉了。而它恰恰是 BIOS 要使用的。此时，BIOS 已经犯病了，后续的任何操作，都可能会失败，甚至可能直接死机。

就是说，在这台机器上，根本不敢执行 map --mem /WePE_64_V2.0.iso (0xff) 这条命令！

如果某人想让菜单安全可靠，就不可以使用不带 --top 的 map 命令。

甚至，光是有 --top 还不够！内存必须超过 4G，否则，即使有 --top 参数也无济于事，因为这仍然会找到 4G 之下的某个内存块，从而造成失败或死机。

世界的发展步伐好快啊！竟然以这样的方式逼着大家都使用 8G 以上的内存了！祝贺世界加快前进的步伐！再次祝贺！

不点

liuzhaoyzz 发表于 2019-4-21 18:08
接续不点的帖子，内存布局是这样子的：
（1）Usable RAM  （一大块）正常 640KB
（2）Usable RAM  （一小 ...

你搞错了。你把常规内存的那一块也弄上来了。那块是无用的，要去掉。总共是 6 块，去掉第一块的常规内存，剩下的 5 块，才是与我们的 img 有关的。

不点

2011yaya2007777 发表于 2019-4-21 19:22
也没有可能是这样：硬件占用了内存，没有注册，或者注册不准确，比如小了，造成了内存冲突。

这个可能性当然是有的，而且可能性很大。

不过，也可以考虑改进一下我们的 int15，看看能否解决问题。

目前的 int15，是把现有的 usable ram 块的长度减少，而我们 img 所占领的实际空间（位于 usable ram 的尾部），成为了黑户，没有在 int15 的内存块列表中注册登记。不知是不是这种黑户的存在，影响了 bios 的运作？

如果修改 int15，添加这些黑户，那么，代码将会增大不少。yaya 你可以斟酌一下，要不要做这样一个工作，进行试验。做这个工作的话，有可能解决问题，也有可能无效。

我当然倾向于懒惰了，就是说，什么也不做，正如前面曾经说过的那样，让用户自己想办法，比如增加内存，达到 8G 以上。

补充：修改 int15 肯定不会有效。这事与 int15 无关。分析如下：

map --mem 这条命令还没执行完，就出错了。这证明 int15 的内存表格还没更新，就出错了。换句话说，仅仅是把 iso 从硬盘复制到内存块上，就出错了。此时还没有执行 map --hook，因此，此时还没有更新 BIOS 的 int15，甚至连 hook 都没有，仅仅是原始 ROM 的 int15 在起作用。因此可以肯定，与 grub4dos 的 int15 代码无关，而完全是内存块的 “写入” 操作本身所造成的问题。

不点

liuzhaoyzz 版主，你可能有点没反应过来。

你能肯定最大的那块一定是好的吗？

不一定啊。你无法预知作孽的方式。

甚至有这样的可能性：所有的低位内存块都作孽。这你就只能投降了。

我给诸位玩家们量身定做的这身衣服，非常合适，保准诸位可以支撑相当长的一个时期，幸运时，说不定能够支撑到 BIOS 彻底消失的一天。这身衣服，就是增加内存，越大越好。

其实，真正把玩这些内存盘的，也就是你们这少数玩家而已。普通用户根本没这耐力去折腾。

所以，只要你们知道如果应对 BIOS 的 bug，那就万事大吉了，没有任何问题需要解决了。


补充：8G 内存才不到 300元，谁要是舍不得花钱，就打屁股，判定为酒驾，罚款 1000 元，并且扣 12分，取消他玩 ramos 的资格。（既然打屁股了，就不关监狱了）

不点

liuzhaoyzz 发表于 2019-4-21 21:33
弱弱地说下，潜意识里面，ISO放在内存块大点的估计是要比内存小点的成功率更高吧。

关于RAMOS，主流 ...

我的想法，与你恰恰相反。我认为应该使用较小的内存块，留着较大的内存块供别的 IMG 使用。

无论如何，我们这种美好的愿望，都是一厢情愿而已。假如 BIOS 存心搞破坏，那无论我们怎么样努力，最后都是白搭。不过，好在我已经远离了 x86 下的开发了，这锅就由 chenall 和 yaya 来背了，chenall 其实多年来也很少露面了，主要是 yaya 的事了。当初我由于身体原因找了 bean 当下家，bean 找到 chenall 做下家，chenall 让 yaya 做下家，时运到此，yaya 能找到哪个来 “背锅”，就要看天了。反正我脱身了，与我无关了，我只有发表自己的看法的份，我不再插手任何实质性的事宜。

假如你们这些玩家都不使用 grub4dos 来做 RAMOS，我想，根本就不会出现这么奇葩的事情。我猜，可能是你们都爱用 grub4dos，所以，人家就要想方设法干掉 grub4dos 吧？假如你们都不用 grub4dos 的话，那就没这事了。所以，你们的存在才是祸根（很抱歉，这话有点难听）。不要再找 bug 了，这就是个最大的 bug。先解决这个 bug，那么，其它一切就都迎刃而解了。前面我给 yaya 提出的建议是，不要做任何工作，这应该让用户自己去处理。这也仅仅是我的建议而已，我只是想让 yaya 偷点懒、省点事而已。

很抱歉，我完全不懂什么叫 RAMOS，所以，我有关 ramos 的概念，可能都是错的。但我的意思是明确的，只要能够摆脱 grub4dos，任何 RAMOS 的方案，都是可行的。只要你们远离 grub4dos，就永远不会再有 grub4dos 的 bug 存在了。

不点

liuzhaoyzz 发表于 2019-4-21 21:29
第三种情况彻底让我迷惑了！彻底拿掉转接卡之后，机械硬盘写入grub4dos-0.4.6a-2019-03-25,机械硬盘上 ...

这还有啥迷糊的？不清清楚楚吗？

你已经说了，displaymem 的结果全都一样。因此，你这次放在第（3）块内存上，原本“作孽”，现在不 “作孽” 了。

这说明，之所以作孽，是因为存在转接卡。拿掉转接卡，它就好了。

很容易猜到，很可能这个转接卡 “暗中”、“偷偷地” 使用了第（3）块内存，又不 “登记”，因此制造了麻烦。

不点

liuzhaoyzz 版主

前面我们已经把问题都弄得很清楚了，我认为没啥疑问了。接下来，就得靠你自己分析了，都很容易分析的。

主板没有改动内存布局，这属于主板的 bug。它应该根据 SSD 使用内存的情况，相应地更改内存布局才行。否则，就造成内存冲突了。

问题就是这么简单，没什么技术含量。不知这几句话能否帮到你。

不点

frg521 兄

你给的测试方案，测试起来有点累人。

问题的性质已经弄清楚了，我认为不需要再做什么测试了。

不点

2011yaya2007777 发表于 2019-4-22 19:37
在1楼，楼主在命令行执行：map --mem /Wepe_64_v2.0.iso (0xff)
就出现错误提示：Inconsistent filesyst ...

你可能还在用 “常规思维” 来分析“特殊情况”——场景不对，分析是无效的。
在脑子里面不要总想着 "Inconsistent ...." 这条信息。把这条信息理解为 “不正常了” 就 OK，不要想着它具体是啥含义。

当你让 liuzhaoyzz 用 --top 成功之后，我就立即意识到了这个问题，知道了它的症结不在于文件系统读写方面。可以肯定地说，文件系统的读写，不可能出现问题。为什么呢？因为既然 --top 加载成功，那本身就证明了，文件系统的访问是顺利的，事实上在 --top 的情况也确实没有 Inconsistent 之类的问题存在。

不用 --top 而加载在低端时，出问题了。这说明，加载在低端时，破坏了 BIOS 的运行环境，属于内存冲突的范畴了。我们不是 BIOS 的设计者，我们无法猜测 BIOS 在那个位置放置了什么数据、参数，而当这些数据、参数被覆盖之后，我们也无法估计 BIOS 将会发生什么样的不正常行为。理论上什么行为都可能发生，包括死机。

而 Inconsistent ... 的信息，就是这种不正常的一种表现。我们无需猜测为何会这样，以及为何偏偏导致这样的错误，以及为何显示这样的信息。使劲猜，也没有太大意义。

当 map 开始复制扇区时，一部分扇区复制完成，此时已经覆盖掉了内存块中的 BIOS 参数，导致了 BIOS 失常。那么，继续读取 SSD 时，由于 BIOS 已经失常了，所以，读 SSD 就会失败。很可能连 SSD 上的分区表、BPB 信息都找不到了，更不用说去读剩下的 ISO 文件的扇区数据了。所以，我们不用猜它具体是卡在哪里了。即使猜准了也没有意义。我们笼统地说它 “不正常了”就行。

不知我这么解释，是否清楚。

不点

用户自己可以想办法排除有问题的内存块。

map 命令有两个参数，分别控制最低的内存地址和最高的内存地址。

只要你使用这两个参数，你就能控制哪个内存块是要使用的。

就是说，假如你已经知道了某个内存块是有冲突的（就是说，是你应该躲过它的），你就可以设定 map 参数，让 map 命令使用另外一个没有内存冲突的内存块。

就是说，你想用哪个内存块，你就能用 map 参数来达到你的目的。不需要像 liuzhaoyzz 说的那样，保留新旧两个版本的 GRLDR。

对于有高位内存的情况，建议总是使用高位内存。它节约了低位内存，同时还能避免与 buggy BIOS 发生内存冲突。

你无法预知 BIOS 会污染哪个内存块。如果你能确定 BIOS 会固定污染某个内存块，你也可以用适当的 map 参数来躲过那个块而使用其它块。

可以查看 map 的源代码，来了解那些控制参数。

不点

liuzhaoyzz 发表于 2019-4-24 09:55
这两个参数复杂吗？没看到哪里有介绍啊？

确实没有见到有介绍的。不过，看源代码可以知道有哪些参数：

  for (;;)
  {
        if (grub_memcmp (arg, "--status", 8) == 0)
    else if (grub_memcmp (arg, "--hook", 6) == 0)
    else if (grub_memcmp (arg, "--unhook", 8) == 0)
    else if (grub_memcmp (arg, "--unmap=", 8) == 0)
    else if (grub_memcmp (arg, "--rehook", 8) == 0)
    else if (grub_memcmp (arg, "--floppies=", 11) == 0)
    else if (grub_memcmp (arg, "--harddrives=", 13) == 0)
    else if (grub_memcmp (arg, "--ram-drive=", 12) == 0)
    else if (grub_memcmp (arg, "--rd-base=", 10) == 0)
    else if (grub_memcmp (arg, "--rd-size=", 10) == 0)
    else if (grub_memcmp (arg, "--e820cycles=", 13) == 0)
    else if (grub_memcmp (arg, "--int15nolow=", 13) == 0)
    else if (grub_memcmp (arg, "--memdisk-raw=", 14) == 0)
    else if (grub_memcmp (arg, "--a20-keep-on=", 14) == 0)
    else if (grub_memcmp (arg, "--safe-mbr-hook=", 16) == 0)
    else if (grub_memcmp (arg, "--int13-scheme=", 15) == 0)
    else if (grub_memcmp (arg, "--mem-max=", 10) == 0)
    else if (grub_memcmp (arg, "--mem-min=", 10) == 0)
    else if (grub_memcmp (arg, "--mem=", 6) == 0)
    else if (grub_memcmp (arg, "--mem", 5) == 0)
    else if (grub_memcmp (arg, "--top", 5) == 0)
    else if (grub_memcmp (arg, "--read-only", 11) == 0)
    else if (grub_memcmp (arg, "--fake-write", 12) == 0)
    else if (grub_memcmp (arg, "--unsafe-boot", 13) == 0)
    else if (grub_memcmp (arg, "--disable-chs-mode", 18) == 0)
    else if (grub_memcmp (arg, "--disable-lba-mode", 18) == 0)
    else if (grub_memcmp (arg, "--in-place=", 11) == 0)
    else if (grub_memcmp (arg, "--in-situ=", 10) == 0)
    else if (grub_memcmp (arg, "--in-place", 10) == 0)
    else if (grub_memcmp (arg, "--in-situ", 9) == 0)
    else if (grub_memcmp (arg, "--heads=", 8) == 0)
    else if (grub_memcmp (arg, "--sectors-per-track=", 20) == 0)
    else if (grub_memcmp (arg, "--add-mbt=", 10) == 0)
    else if (grub_memcmp (arg, "--skip-sectors=", 15) == 0)
    else if (grub_memcmp (arg, "--max-sectors=", 14) == 0)
    else
        break;
    arg = skip_to (0, arg);
}

--mem-min 和 --mem-max 就是用来控制 IMG 所使用的最小内存地址和最大内存地址的，不过，单位不是字节，而是扇区（即 512 字节）。

这两个参数不是我加的，似乎是 karyonix 加的，记不太清了。

而 --skip-sectors 和 --max-sectors 这两个，好像是我加的（也记不清了，抱歉，记忆力减退）。 这两个参数的意思是，虚拟盘的起始扇区要跳过 IMG 开头的若干个扇区，而虚拟盘的总扇区数也控制在某个已知的值。

以上列出的全部参数当中，有一些参数已经过时了，是无用的。刚才提到的这几个参数，还是有用的，只是使用频率不高罢了。

不点

我搜到了这个帖子，很重要，请留意：

关于 GRUB4DOS 用户使用内存管理
http://bbs.wuyou.net/forum.php?mod=viewthread&tid=385531


在上述那个帖子的讨论中，我当时可能研究了 --mem-max 参数的相关代码，现在就摘录其中比较重要的内容：

map --mem-max=0x800000 能够控制使用不超过 4G 的内存地址。这条命令应该单独执行，执行一次即可，后续的 map --mem 命令都将使用这一控制参数。

当用户需要使用 4G 以上内存块时，还得再执行一条  map --mem-max=0，这是恢复为 64 位的内存访问，可以访问 4G 以上内存块。

首先解释一下，这里提到的 0x800000 个扇区，就是指 4G 这个界限了。这条命令单独执行，不要与 map 的其它命令行参数混用。这条命令执行后，会影响后续的所有 map --mem 命令，也就是说，后续所有的 map --mem 命令，都不会去使用超过 4G 的内存块。要想恢复原先那种默认 “不限制内存”的情况，需要再执行一条 map --mem-max=0 之后才行。


--mem-min 的用法也是类似的，就不重复了。比如说，设定 map --mem-min=0 之后，也会执行 “恢复 --mem-min 默认值”的操作。


如果我们设定 map --mem-min=0x800000，则最低使用的内存就是 4G 了。换句话说，就是不使用低位内存。注意这条命令也是需要单独执行的，就是说，不要与其它 map 参数混合使用。使用这条命令之后，在后续的 map --mem 命令行中，都必须使用 --top，否则，没有一个内存块会被找到。进一步解释，如果不使用 --top，那么，只能找到低位内存。但低位内存又被 map --mem-min=0x800000 命令屏蔽掉了，因此，没有任何内存块会满足搜索条件，也就是说，找不到一个内存块。


如果设定 map --mem-min 而不设定 map --mem-max，则 --mem-max 会保持其默认值（其默认值可以想象为无穷大，其实不是无穷大，而是一个比较大的值，比如 0xFFFFFFFFFFFFF000 之类的）。


如果设定 map --mem-max 而不设定 map --mem-min，则 --mem-min 会保持其默认值（其默认值可以想象为 0，其实不是 0，而是一个比较小的值，比如 1M 之类的）。


如果你想让你的程序在别人的机器上也不至于出现死机之类的情况，你只能屏蔽掉低位内存，就像刚才说的那样：先执行一条 map --mem-min=0x800000，然后再执行 map --mem --top 把映像文件加载在高端。如果没有执行 map --mem-min=0x800000，而只有 map --mem --top
，则映像有可能被加载在低端。当高端内存块不存在的时候，或者高端内存块太小的时候，就有可能加载在低端了。如果用 map --mem-min=0x800000 屏蔽低端，就可以确保不使用低端内存块。

不点

深入讨论 SSD 之类的设备对 BIOS 的影响。

BIOS 允许这类设备的存在，并为这类设备提供访问支持。

但在实模式 BIOS 阶段，主板 BIOS 却 “偷偷地” 使用了某一块内存，来支持对 SSD 的访问。主板在使用这些内存块时，并不 “登记”，因此，其它实模式程序都不知道这块内存已经被 SSD 使用。于是就容易产生内存冲突。

分两种情况来讨论。

情况一、SSD 的敏感硬件信息记录在未登记的内存块上，这样，到了 Windows 的保护模式，Windows 一旦也使用了这块内存，破坏敏感的 SSD 硬件参数，那么，Windows 在访问 SSD 时也会不正常。

情况二、SSD 只是在实模式使用未登记的内存。使用这块内存是 “临时性”的、“过渡式”的，只是为了支持实模式下的 SSD 的访问。只要实模式不出现内存冲突，那么到了保护模式，SSD 的驱动程序就不再使用这些内存了，于是这些内存交给操作系统，由操作系统任意使用，这样也就不会有问题了。

情况一仅仅是一种可能性而已。我猜，实际上，生产者不敢让情况一出现。

那么，情况二可能会是未来新设备的一种 “常态”了。请大家留意。

就是说，假如你还能有幸继续 “暂时”使用 BIOS，你应该适应那种新 “常态”，即，在实模式 BIOS 阶段，低位内存常常被污染。你为了确保安全，你就不得不躲过低位内存，而被迫使用高位内存。况且，BIOS 终究会有消失的一天。你对 BIOS 的使用，也仅仅是 “暂时” 而已。对这种 “暂时” 的使用，你本来也不应该抱有过高的期望。如果你能 “凑合着”用一段时间，你也该满意了。不能要求太高；要求太高了，达不到。

不点

frg521 发表于 2019-4-26 11:13
...

看不懂你想干啥。只写 4 个字节到文件，就有点故意为难自己的嫌疑了。何必写到文件呢？你用笔和纸，记录下来，不是更快吗？

无论如何，写文件的方法有很多。你得找到一个适合你的具体场景的一个最方便的方法。

dd 可以写文件，write 命令也可以写文件，重定向符号也是可以用来写文件的。要不，你先学习一下 grub4dos 的教程？置顶的教程，应该会涉及到这方面的知识吧？

不点

Refuse to hook int13 由于 map 表格为空。这条信息似乎是老版本的 grub4dos 才会显示吧？很老很老的。

建议彻底更新到最新版。如果你是用新版调用老版，那么结果还是老版在起作用。

就是说，应该把 img 或 iso 里面的 grldr、grub.exe 统统更新为最新版，这才行。而且，注意要把硬盘或 U 盘上所有分区（包括隐藏分区）里面的 grldr、grub.exe（或改名后的文件）全部更新为最新版。否则，一旦它们（由于某种差错而抢先）接管了控制，那结果就是老版本在运行。

不点

liuzhaoyzz 发表于 2019-5-18 16:45
我在68楼说的情况，是用的sratlf的2014年1206的run模块搭配最新版grub4dos-0.4.6a-2019-03-25,在nvme ssd上 ...

本来就不可能解决这些问题。前面的讨论，就明确了这一点。

根源是 BIOS 的问题，也属于故意制造的问题，有意淘汰 BIOS 以及基于 BIOS 的软件。

所以根本上是不可能解决的。具体到某个情况，或许能找到变通的解决办法，也或许找不到办法。就算是能找到办法，但如果开发者感到麻烦，或者由于其它原因不愿意做，那也就等于没办法。

至于说用户采取什么方法，那都是各人自己的选择。根据自己的实际情况，选择自己认为最省事的处理方式。

我既不是开发者，也不是用户（在我的应用范围，我遇不上这些问题，而且我在逐步迁移到 ARM Linux 系统，因此最多我只算半个用户）。我是曾经的开发者。如果我发现问题正好与我的开发有关，而且我又力所能及，我就来提供帮助。而且，我确实是应该来讲明情况的，因为我不希望目前的开发者由于不了解情况而被绕进去，浪费大量宝贵时间。

从开发者的角度来看，这个问题算是已经处理完了，没有遗留问题。我写这句话，目的是提醒我自己，这个问题不需要继续处理了，免得以后一看到有人回帖，就以为没处理完，又来从头到尾看一遍。

剩下的问题，都是用户自己的权衡和决断了，开发者不太容易下手，就是说，没什么特别有效的手段。前面已经全面讨论了相关的技术细节，这可以作为用户的参考。尤其是，这问题被判定为 BIOS 的问题，我相信，这一点对用户是很有帮助的。用户起码知道了，原来这不是 grub4dos 的 bug。这当然很有用了，否则，用户不明真相，还想从 grub4dos 入手来解决问题，那是方向性的错误。