grub4dos出错提示inconsistent filesystem structure

liuzhaoyzz · 发表于 2019-4-20 22:34:51

本帖最后由 liuzhaoyzz 于 2019-4-20 23:05 编辑

华硕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 · 发表于 2019-4-21 07:58:48

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启动，可能会有环境干扰，更加难以定位问题。

liuzhaoyzz · 发表于 2019-4-21 09:11:55

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

liuzhaoyzz · 发表于 2019-4-21 10:36:49

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

liuzhaoyzz · 发表于 2019-4-21 12:30:20

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

liuzhaoyzz · 发表于 2019-4-21 14:44:40

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

liuzhaoyzz · 发表于 2019-4-21 15:22:44

本帖最后由 liuzhaoyzz 于 2019-4-21 15:31 编辑

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

liuzhaoyzz · 发表于 2019-4-21 16:51:44

本帖最后由 liuzhaoyzz 于 2019-4-21 17:04 编辑

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能够改进下。

liuzhaoyzz · 发表于 2019-4-21 16:58:25

本帖最后由 liuzhaoyzz 于 2019-4-21 16:59 编辑

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/

liuzhaoyzz · 发表于 2019-4-21 17:16:29

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 18:08:06

本帖最后由 liuzhaoyzz 于 2019-4-21 19:33 编辑

接续不点的帖子，内存布局是这样子的：
（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插槽里面，可能这个转接卡需要占用内存区段，造成了内存切块的现象，以后可能会碰到较多类似的案例。

liuzhaoyzz · 发表于 2019-4-21 20:14:51

本帖最后由 liuzhaoyzz 于 2019-5-3 09:16 编辑

内存布局是这样子的：
（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 以上的内存块”，这就完事了。

liuzhaoyzz · 发表于 2019-4-21 21:29:02

2011yaya2007777 发表于 2019-4-21 21:02
在32楼，你说了3种情况，前2种你说明了结果，那第3种情况结果如何？是不是一样grub4dos-0.4.6a-2019-03-25 ...

第三种情况彻底让我迷惑了！彻底拿掉转接卡之后，机械硬盘写入grub4dos-0.4.6a-2019-03-25,机械硬盘上的微PE正常启动，包括直接map，map --mem,map --mem --top，都没问题。
难道PE.ISO存放的位置不同（这个是保存在机械硬盘上面），加载到内存里面的区段还不同吗？

liuzhaoyzz · 发表于 2019-4-21 21:33:12

本帖最后由 liuzhaoyzz 于 2019-4-22 06:47 编辑

不点发表于 2019-4-21 20:46
liuzhaoyzz 版主，你可能有点没反应过来。

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

弱弱地说下，潜意识里面，ISO放在内存块大点的估计是要比内存小点的成功率更高吧。

关于RAMOS，主流是使用primo驱动，这个驱动用直接map的方式启动的，内存盘是primo提前创建好的，由primo驱动把vdf镜像仿真拷进入到内存中，这个vdf可以直接跨越高低位内存的分界线仿真到内存中，内存盘不是由grub4dos来创建的并加载到内存中，因此不存在高低位内存的问题。

liuzhaoyzz · 发表于 2019-4-22 11:55:02

本帖最后由 liuzhaoyzz 于 2019-5-3 09:32 编辑

上传个这个问题的物证，就它们两个：

拿掉PCIE-M.2转接卡，把SSD直接插到主板M.2接口，grub4dos-0.4.6a-2019-03-25启动SSD上面的PE.ISO，map --mem失败，map --mem --top成功，直接map也成功。
所以也不一定全是转接卡的事情。难道是M.2接口的SSD只要插在主板上面，就会有影响，是不是有可能NVME SSD的芯片占用了内存区段，属于“黑户”，导致潜在的冲突发生？可是displaymem 的结果全都一样，又怎么解释？

liuzhaoyzz · 发表于 2019-4-22 16:32:32

本帖最后由 liuzhaoyzz 于 2019-4-22 16:37 编辑

要回复你，要有空、实机测试才行啊，那电脑没在身边。搞这么多ISO，要重启多少次啊~~~

liuzhaoyzz · 发表于 2019-4-22 19:53:42

本帖最后由 liuzhaoyzz 于 2019-4-22 20:04 编辑

frg521 发表于 2019-4-22 18:12
...

实体机，试了你发的iso，11个，其中1-10大小最大32MB，11.iso大小为256MB。
grub4dos-0.4.6a-2019-03-25 map --mem 1-10.iso都没问题， map --mem 11.iso出现inconsistent filesystem structure。出错之后，BIOS就疯了！后面读盘就出错。
直接上图。
map --mem --top 1-11.iso都没问题。
直接map 11.iso也没问题。

liuzhaoyzz · 发表于 2019-4-22 22:40:16

本帖最后由 liuzhaoyzz 于 2019-4-22 22:47 编辑

frg521 发表于 2019-4-22 20:06
...

  确实是我的笔误，应该是map --mem /PE.iso (0xff)这样子，但是我没有map --hook，也就是没有生效，只是测试，能够说明问题。

  不点大的分析，听起来确实合情合理，对于BIOS下各种杂乱的问题，确实很难以处理。对于各种内存冲突导致的问题，您确实是最清楚了，大概是从2003年至今，16年的时间，一直在坚守。按照您所说的，大家都希望趁着您对于grub4dos还有残存的记忆的时候，多向您讨论些问题，少走些弯路。

  出现inconsistent filesystem structure这个问题，对于这台电脑SSD硬盘，目前已经算是有解决办法了，一是用2016年以前的版本grub4dos-0.4.6a-2016-12-24 map --mem，这些版本会从低位向高位内存寻找空余的可用内存空间；要么对于内存较大的电脑用任何一个版本用map --mem --top把PE.ISO放到高位内存即可，前提是高位内存足够大存放这个PE.ISO。

对于机械硬盘，想怎么玩就怎么玩，都可以。

liuzhaoyzz · 发表于 2019-4-24 09:55:30

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

这两个参数复杂吗？没看到哪里有介绍啊？

liuzhaoyzz · 发表于 2019-4-25 10:38:52

grub4dos有很多知识点啊！

liuzhaoyzz · 发表于 2019-4-25 11:22:51

本帖最后由 liuzhaoyzz 于 2019-4-25 11:25 编辑

我觉得第二种情况的可能性更大，SSD在BIOS中能够被看到，肯定是实模式下分配了盘号及内存用于被访问，这个盘号只是临时的，进入windows之后，windows有保护模式的驱动，BIOS下实模式的内存占用不会冲突。windows是个黑盒子，使用者只能通过现象分析黑盒子里面是什么东西，并且通过一些巧妙的方法来规避这些暗桩。

liuzhaoyzz · 发表于 2019-4-25 19:30:27

低位内存可以map --mem最大不到200MB。管他是放在哪一区域，反正是不行啊。

liuzhaoyzz · 发表于 2019-4-25 20:05:14

可能是我表达的不准确让你产生了误解。我所说的最大200MB左右，指的是32楼http://wuyou.net/forum.php?mod=r ... &fromuid=298214的内存分布图中，只能放到第（3）个内存块472MB那个，如果把镜像扩大到472MB以上map --mem自动会放到大一点的内存块。直接上图吧，grub4dos-0.4.6a-2019-03-25,顶部显示了版本，显示低位内存最大支持3083MB，我随便找了个en_win7x64.iso来测试map --mem,3035MB,没问题。这证明不点的推断是非常正确的，g4d把200MB的微PE.ISO放到了472MB的内存区域，看上去这片区域可以放得下微PE.ISO，实际上是不行的，有暗桩，可能是这片内存区域已经被占领，所以有冲突。

liuzhaoyzz · 发表于 2019-4-26 09:25:22

实模式启动时，未使用的内存，应当都是0吧？如果是，那么安装内存块时，先测试一下。如果有数据，则移动安装位置。

请问下您所说的这个，是试图在代码层面解决问题是吗？还是在用户层面加个什么参数实现问题？我没听懂这个意思。如果能在代码层面解决，判断内存块上面有东西，如果可行，那就最好了。

liuzhaoyzz · 发表于 2019-4-26 10:15:49

2011yaya2007777 发表于 2019-4-26 09:47
是想在代码中解决。但是我在虚拟机里测试，可以内存块里有数据，不是全空白。实体机还没有测试，不知情况如 ...

感觉虚拟机和实体机测试结果是有区别的，如果能在代码层面解决就好了。这样子一个菜单通用。不用根据不同电脑不同内存大小来区别对待是否加--top.

liuzhaoyzz · 发表于 2019-4-26 14:33:26

本帖最后由 liuzhaoyzz 于 2019-4-26 15:21 编辑

谢谢提醒。2017年的第一个版本grub4dos-0.4.6a-2017-02-03，这是map --top改版的时间。
我找到了一篇不点在2017-12-19回复的帖子，详细说明了关于--top参数：
http://bbs.wuyou.net/forum.php?m ... &fromuid=298214

新版中 map 的 --top 参数是用来控制是否启用 4G 界线以上的内存块的。如果没有 --top 参数，则不会使用高位内存块。如果带有 --top 参数，则会优先使用高位内存块。另外，新版搜索可用内存块总是从高向低搜索，而不再从低向高搜索。

就是说，如果带有 --top 参数，则新版在大多数情况下可能总是使用高位内存块，除非高位内存块已经被很多 img 占满了（或者高位内存块太小），才会搜索到 4G 界线以内的内存块。新版的搜索方式更合理

不点发表于 2017-1-23，来回调整很多，看得我都晕了。
http://bbs.wuyou.net/forum.php?m ... &fromuid=298214

不点发表于 2017-1-3
http://bbs.wuyou.net/forum.php?m ... &fromuid=298214

liuzhaoyzz · 发表于 2019-5-11 18:47:59

本帖最后由 liuzhaoyzz 于 2019-5-11 20:07 编辑

再来反馈个问题，不知道是sratlf的run模块的问题，还是grub4dos的问题，硬件条件跟一楼一样。C:\Boot\imgs\WePE_64_V2.0.iso放在NVME SSD上面。
menu.lst
title run mem automenu by sratlf-20141206
find --ignore-floppies --ignore-cd --set-root /boot/grub/RUN
command --set-path=/boot/grub
command run --loadfont --mem --top --e820cycles=-1 --set-showsize=0 --automenu show.iso /boot/imgs/

上面的这个菜单的功能基本和下面的相同：
title WINPE by uepon (WePE_64_V2.0.iso)
find --ignore-floppies --ignore-cd --set-root /boot/imgs/WePE_64_V2.0.iso
map --mem --top /boot/imgs/WePE_64_V2.0.iso (0xff)
map --e820cycles=-1
map --hook
chainloader (0xff)

用的RUN 1206 更新支持磁盘交换,文件检索,自动菜单,自动列表,全自动安装nt5x系统 - GRUB4DOS - 无忧启动论坛 - Powered by Discuz! http://wuyou.net/forum.php?mod=viewthread&tid=191301
run模块是20141206，如果搭配grub4dos-0.4.6a-2016-12-24则能够正常启动PE。
run模块是20141206，如果搭配grub4dos-0.4.6a-2018-03-26或者grub4dos-0.4.6a-2019-03-25，则启动PE失败。
前面的楼层都说到是map --mem --top的问题，现在run模块加了map --mem --top，把PE放到高位内存了，可是启动还是失败，这是怎么回事？
用上面的菜单，启动出错提示截图如下。
error 62:Refuse to hook int13 because of empty drive map table

用“Refuse to hook int13 ”作为关键字百度了下，没有任何有用的线索。

如果说sratlf版主的run模块是2014年的，没有更新，可为什么又可以搭配grub4dos-0.4.6a-2016-12-24,并且能够正常启动？
不知道他的run模块是不是开源的，有高手能否看下源代码是不是有问题。

如果不用run模块，采用下面的手工写的菜单，启动PE没问题。

另外想问下grub4dos-0.4.6a-2016-12-24是不是最大也是支持含有32个碎片的磁盘仿真？
支持含有碎片的文件仿真 - GRUB4DOS - 无忧启动论坛 - Powered by Discuz! http://wuyou.net/forum.php?mod=viewthread&tid=327458
本帖最后由 2011yaya2007777 于 2015-5-17 11:26 编辑，从日期上来看，grub4dos-0.4.6a-2016-12-24是支持32个碎片的。
111楼：2011yaya2007777发表于 2014-5-1 16:10:29 支持最多 32 段碎片。可以在 0PE 下正常运行了。

liuzhaoyzz · 发表于 2019-5-18 13:51:53

sratlf的run模块可以直接用记事本编辑，没有加密，不懂grub4dos批处理，期待有高手能够更新下这个run模块，挺好用的，不然就只能用老版本的grub4dos0.4.6a20161224版本了。

liuzhaoyzz · 发表于 2019-5-18 16:45:12

本帖最后由 liuzhaoyzz 于 2020-5-9 14:04 编辑

我在68楼说的情况，是用的sratlf的2014年1206的run模块搭配最新版grub4dos-0.4.6a-2019-03-25,在nvme ssd上面map --mem --top启动PE失败之后,才更换的grub4dos-0.4.6a-2016-12-24版本的。也就是说新版本不行，旧版本可以，可能是sratlf的run模块批处理没有同步更新的原因。

不想更新到最新版的原因是，在我的使用场景下，旧版本也运行的好好的，我还不想抛弃sratlf的run模块。

前面已经讨论了最新版的grub4dos-0.4.6a-2019-03-25版本，如果用手工写菜单map --mem --top也没问题，所以68楼不是来反馈grub4dos的bug（其实也没有bug，是搜索顺序就是那样子设计的），我估计是run模块没有更新的原因，我抛出这个问题来，一方面是期望有高手能解决问题，因为我不懂grub4dos的批处理；另一方面还有个目的是告诉用run模块的人，用于nvme ssd通过使用旧版的grub4dos可能会规避我这样子的问题。

另外，应该不是不同版本的grub4dos接管了控制权的问题，我不是从优盘启动的，是从NVME SSD硬盘启动的grub4dos，从grub4dos启动后的顶端标题行能够清楚地看到grub4dos的版本号，grub4dos-0.4.6a-2019-03-25版本不行，grub4dos-0.4.6a-2016-12-24版本+run1206可以。

发现grldr采用2016-12-23版本，可以更好地匹配sratlf的run模块启动pe.wim，如果遇到问题，可自行更换最新版本grldr。

没办法，sratlf的run模块6年不更新了，run pe.iso/wim挺好用啊。

		自动登录	找回密码
密码			注册

grub4dos出错提示inconsistent filesystem structure

点评

点评