grub4dos出错提示inconsistent filesystem structure

liuzhaoyzz

华硕Z97-K R2.0主板，SM961 NVME-SSD 256GB，MBR用bootice写入了grub4dos.这个SSD用diskgenius分了两个MBR主分区。还有个1TB的机械硬盘分了4个MBR主分区。bios设置了从NVME-SSD启动。
grub4dos-0.4.6a-2019-03-25版本的grldr引导微PE2.0，提示出错，inconsistent filesystem structure,WePE_64_V2.0.iso就放在NVME-SSD的根目录下面。
用grub4dos-0.4.6a-2019-03-25版本的grldr引导机械硬盘的微PE2.0正常。

grub4dos-0.4.5c-2016-01-18版本的grldr引导微PE2.0正常。
引导菜单menu.lst 如下：
graphicsmode -1 640:800 480:600 24:32 || graphicsmode -1 -1 -1 24:32
font (bd)/boot/grub/UNIFONT.HEX
color white/blue blue/yellow light-red/blue 10
foreground FFFFFF
background 0000AD
timeout 2
default 0

title WINPE by uepon (WePE_64_V2.0.iso)
find --ignore-floppies --ignore-cd --set-root /WePE_64_V2.0.iso
map --mem /WePE_64_V2.0.iso (0xff)
map --e820cycles=-1
map --hook
chainloader (0xff)

在grub4dos菜单选择的时候，按c键进入grub4dos命令行，键入map --mem /WePE_64_V2.0.iso (0xff)的时候，grub4dos-0.4.6a-2019-03-25版本就提示出错了，inconsistent filesystem structure。
这是怎么回事？

liuzhaoyzz

frg521 发表于 2019-4-20 23:18
...

grub4dos-0.4.6a-2019-03-25版本的grldr，ls (hd0,0)/能够看到WePE_64_V2.0.iso
同一个WePE_64_V2.0.iso,用grub4dos-0.4.5c-2016-01-18版本的grldr就没问题，再换用其他的PE没有必要，PE就没有启动。
map --mem /WePE_64_V2.0.iso (0xff)只是加载到内存这一步就出错了，与不同的PE没有关系，有命令截图。

map --e820cycles=-1我用#键注释也没用，grub4dos的注释不是//吧，-1是默认值，这一句的作用是如果碰到了异常，可以按e键修改它的值，我记不住参数。

MBR及62扇区用diskgenius重置过了的，然后用bootice写入了grub4dos-0.4.6a-2019-03-25版本的grldr.mbr。

现在只是引导，引导盘是格式化了的，不涉及到ghost系统的问题，我也没有用ghost安装系统。

我也尝试过用diskgenius4.9重新对ssd分区了，结果一样，分区了MBR分区表也就更新了。

pqmagic感觉是很老很老的软件了，这个软件留给我的记忆是在DOS中，Windows环境下很不可靠。
fdisk /mbr和bootsect /nt52 c:不是我要的，我要的是从grub4dos的MBR启动，这样启动没有干扰，如果从bootmgr转向grldr启动，可能会有环境干扰，更加难以定位问题。

2011yaya2007777

这个SSD用diskgenius分了两个MBR主分区

是什么类型的分区?比如ntfs?

liuzhaoyzz

全部都是NTFS,我不知道还需要报告什么相关的信息。
刚才测试了grub4dos-0.4.6a-2018-02-27，也是一样的结果，版本太多了。

2011yaya2007777

既然grub4dos-0.4.5c-2016-01-18版本能启动，说明是有bug引入。如果可能的话，定位一下错误版本。
从grub4dos-0.4.6a-2016-01-nn开始，到grub4dos-0.4.6a-2018-02-27。
首先测试2016-01-nn，2017-01-nn及2018-01-nn。
然后使用折半法测试，可以减少测试次数。

liuzhaoyzz

原来只有这样定位问题。。。这电脑要惨遭蹂躏啊。我试下。

liuzhaoyzz

下载了很多版本测试，用sinoxer的简易启动测试器与实体机似乎有区别，只能实体机测试，结果出来了：
2016年的最后一个版本grub4dos-0.4.6a-2016-12-24正常。
2017年的第一个版本grub4dos-0.4.6a-2017-02-03出错。

liuzhaoyzz

       http://wuyou.net/forum.php?mod=v ... &extra=page%3D3这个帖子也碰到类似的问题，才看到，不过他是linux.iso,我是pe.iso。不点说是扇区太大，可SSD只有256GB啊。        

2011yaya2007777

我知道了。是参数 --top 的问题。
2017-02-03开始，加参数 --top 从 4Gb 以上内存分配空间，否则从 4Gb 以下内存分配空间。

liuzhaoyzz

        如果说是--top参数的问题，那为什么同一个grldr20190325，可以启动机械硬盘的微PE.ISO，不能启动SSD上的同一个ISO，我没用--top参数，应该都是放在低位内存的，微PE只有200MB不到，不会跨越高低位内存分界线，难以理解。
    哦，机械硬盘的微PE.ISO我用的是sratlf版主的run模块启动的。  
    如果此bug成立，那么这个bug已经存在两年之久了，难道大家都用的旧版g4d？     

2011yaya2007777

不是bug，是改进。
以前的内存大多小于 4Gb，没有差别。现在 4Gb 以上内存普遍了，所以要注意。
你加上 --top 参数从 SSD 上启动试一试。

BIOS 从机械硬盘启动，或者从 SSD 启动，可能占用的内存不同，因此内存剩余空间也不同。你有疑问的话，查看一下启动后不同的内存分布即可。

不点

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。

2011yaya2007777

楼主定位版本grub4dos-0.4.6a-2017-02-03出错，视乎补丁与“inconsistent filesystem structure”毫无关系。
等待楼主进一步反馈。

liuzhaoyzz

yaya的说法是正确的。
在这个ssd上面，用map --mem --top /WePE_64_V2.0.iso (0xff)命令，原来无法启动的微PE.ISO，都可以启动了，尝试了grub4dos-0.4.6a-2017-02-03版本，grub4dos-0.4.6a-2018-02-27版本，grub4dos-0.4.6a-2019-03-25都可以。
内存分布displaymem直接上图。

我曾经怀疑内存条坏了，下了两根条子，结果不是条子的事情。
这个主板原生支持2TB的硬盘访问，256GB应该不是问题吧。
发现无法启动之后，我分区过，格式化过，SSD第一个分区分了40GB，grldr就放在这里面的，没放其他的什么文件，还是一样的结果。

事实证明不是PE.ISO的问题，前面已经很冷静地用置换法分析过啊。

blocklist命令没有出错，直接上图。

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

确实是这样的，不应该是BIOS的问题。

    然后问题来了，印象中关于这个map --top参数，我记得来回调整了几次，原来的map --mem挺智能的啊，现在内存大了，200MB的PE.ISO不能自动放到低位内存，还出错？低位内存连续的内存块有3GB啊。必须放到高位内存才行吗，必须加上--top？那么这个PE.ISO如果放到其他小于4GB内存的电脑怎么办？改菜单才行吗？改菜单就不通用了啊。期待yaya能够改进下。

不点

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

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


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


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



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


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


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

liuzhaoyzz

    SSD正确，机械硬盘出错，我估计差别是不同的菜单。SSD是用的手工写的菜单，机械硬盘用的sratlf的菜单，可能环境不同，起初我只是想当然认为同一个PE，同一个grldr，没想到手工菜单和sratlf的run模块还是有区别的，感觉run模块更加智能化。
run命令内部到底用了什么样子的菜单，没有深究。

title WINPE by uepon (WePE_64_V2.0.iso)
find --ignore-floppies --ignore-cd --set-root /WePE_64_V2.0.iso
map --mem /WePE_64_V2.0.iso (0xff)
map --e820cycles=-1
map --hook
chainloader (0xff)

#sratlf的run菜单
title run mem automenu by sratlf-2014.04.21
find --ignore-floppies --ignore-cd --set-root /boot/imgs/firadisk.img
command --set-path=/boot/grub
command run --loadfont --mem --e820cycles=-1 --set-showsize=0 --automenu --show.iso /boot/imgs/

不点

本次 --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 以上的内存块”，这就完事了。

2011yaya2007777

试一试
map --mem /WePE_64_V2.0.iso (0xff) || map --mem --top /WePE_64_V2.0.iso (0xff)

liuzhaoyzz

cat  --hex  (...)/.../your_file.iso
是正确的，没有出错。

map --mem /WePE_64_V2.0.iso (0xff) || map --mem --top /WePE_64_V2.0.iso (0xff)
这个菜单不行，前面半句一旦出错，就报错inconsistent filesystem structure，根本不会执行后面的语句。实体机亲测。

不点

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

接续不点的帖子，内存布局是这样子的：
（1）Usable RAM  （一大块）正常 3083MB
（2）Usable RAM  （一小块，忽略不计） 4.6MB
（3）Usable RAM  （一大块）<----作孽呀！472MB
（4）Usable RAM  （一小块，忽略不计）4KB
（5）Usable RAM  （最后这块是最大的那块，位于 4G 以上）正常 29GB

我记得以前不点有个回帖，非常详细地说明了map --mem对于高低位内存的仿真，我找不到了。我记得以前是很智能的啊，逻辑似乎是map --mem也会尝试放在高位内存。

    顺便说下，内存被切块，不一定是BIOS搞的，而是我搞的，三星SM961 NVME SSD是PCIE3.0*4的才能全速，为了让它全速，我用了一个PCIE转M.2的转接卡，这个转接卡直接插在主板黑色的PCIE插槽里面，可能这个转接卡需要占用内存区段，造成了内存切块的现象，以后可能会碰到较多类似的案例。

2011yaya2007777

以后可能会碰到较多类似的案例。

楼主，可否在 SSD 盘再测试一下
map /WePE_64_V2.0.iso (0xff)
看看是否报错。

2011yaya2007777

也没有可能是这样：硬件占用了内存，没有注册，或者注册不准确，比如小了，造成了内存冲突。

不点

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

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

liuzhaoyzz

内存布局是这样子的：
（1）Usable RAM  （一大块）正常 3083MB
（2）Usable RAM  （一小块，忽略不计） 4.6MB
（3）Usable RAM  （一大块）<----作孽呀！472MB
（4）Usable RAM  （一小块，忽略不计）4KB
（5）Usable RAM  （最后这块是最大的那块，位于 4G 以上）正常 29GB

1、拿掉PCIE-M.2转接卡，把SSD直接插到主板M.2接口，grub4dos-0.4.6a-2019-03-25，map --mem失败，map --mem --top成功，直接map也成功。
2、插上PCIE-M.2转接卡，把SSD插到转接卡上面，grub4dos-0.4.6a-2019-03-25，map --mem失败，map --mem --top成功，直接map也成功。
3、彻底拿掉转接卡，或者把SSD插到转接卡上面，或者把SSD直接插到主板M.2接口，这三种情况下，displaymem的结果居然一摸一样，意思就是M.2接口或者PCIE转接卡不影响内存布局。难道影响内存布局的是显卡？

27楼的内存布局我已修正，错误的数据会导向错误的结论，不好意思。这个内存布局，从grldr代码层面来看，是没有问题的，200MB的WePE_64_V2.0.iso放到了（3）Usable RAM  （一大块）<----作孽呀！472MB，能放下去。
能不能这样子实现map --mem的智能化，从高位到低位遍历可用内存块Usable RAM，然后尝试把PE.ISO放到这个最大的可用内存块，是否可行？如果这个最大的内存块还出错，那就抛出个错误。

不点在22楼分析的推论是完全正确的。

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

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

不点

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 的资格。（既然打屁股了，就不关监狱了）