grub4dos出错提示inconsistent filesystem structure

2011yaya2007777 · 发表于 2019-4-21 20:59:43

32楼

2011yaya2007777 · 发表于 2019-4-21 21:02:16

在32楼，你说了3种情况，前2种你说明了结果，那第3种情况结果如何？是不是一样grub4dos-0.4.6a-2019-03-25，map --mem失败，map--mem --top成功，直接map也成功。

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来创建的并加载到内存中，因此不存在高低位内存的问题。

不点 · 发表于 2019-4-22 08:12:34

本帖最后由不点于 2019-4-22 08:19 编辑

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 存在了。

不点 · 发表于 2019-4-22 08:38:58

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

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

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

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

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

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，要重启多少次啊~~~

不点 · 发表于 2019-4-22 17:31:12

liuzhaoyzz 版主

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

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

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

不点 · 发表于 2019-4-22 17:35:08

frg521 兄

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

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

2011yaya2007777 · 发表于 2019-4-22 19:37:11

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

在1楼，楼主在命令行执行：map --mem /Wepe_64_v2.0.iso (0xff)
就出现错误提示：Inconsistent filesystem structure
Wepe_64_v2.0.iso 放在 NTFS 分区。

fsys_ntfs.c 有 3 个函数返回此错误信息。
fsys_iso9660.c 有 1 个函数返回此错误信息。
builtins.c 有 1 个函数返回此错误信息。
我在这些函数里放置了痕迹显示。向内存复制文件之前，fsys_ntfs.c 的 3 个函数都有痕迹。复制完成 Wepe_64_v2.0.iso 文件后，直到命令执行完毕，不再有痕迹。

从楼主反馈的情况分析，视乎与内存块有关，也就是说读放到内存的 Wepe_64_v2.0.iso 文件，由于内存被破坏，读错误，才返回那样的错误信息 Inconsistent filesystem structure。
可是执行命令 map --mem /Wepe_64_v2.0.iso (0xff) 并没有读内存的 Wepe_64_v2.0.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也没问题。

不点 · 发表于 2019-4-22 21:09:33

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 文件的扇区数据了。所以，我们不用猜它具体是卡在哪里了。即使猜准了也没有意义。我们笼统地说它 “不正常了”就行。

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

2011yaya2007777 · 发表于 2019-4-22 21:34:41

好吧，不再费心思了。退出讨论。

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。

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

不点 · 发表于 2019-4-22 23:22:56

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

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

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

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

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

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

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

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

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

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

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

不点 · 发表于 2019-4-24 12:14:26

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 开头的若干个扇区，而虚拟盘的总扇区数也控制在某个已知的值。

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

江南一根葱 · 发表于 2019-4-24 19:51:30

楼主的问题应该和我刚来无忧的时候差不多情况
http://bbs.wuyou.net/forum.php?m ... d=388596&extra=

我用这种变态方法解决的
http://bbs.wuyou.net/forum.php?m ... d=388624&extra=

就是grldr启动后再chainloader grldr一次，再用菜单进入
可能就是让内存分配混乱，瞎打误撞然后就正常了，哈哈，我反正瞎折腾好的，不知道什么问题

楼主这个提示其实我平时也常遇到的（我电脑公司里年理万机)，
解决办法是：在g4d菜单加备胎，如grub2，或上面说的变态、不知道原理的方式，我遇到过grub2在内存混插的机上居然能启pe.
如果是g4d菜单，一个pe都启不了，不管是wimboot还是map，都提示类似于楼主发的那个错误信息
装机太多，平常单用g4d已经满足不了要求了

不点 · 发表于 2019-4-25 10:11:34

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

关于 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 屏蔽低端，就可以确保不使用低端内存块。

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

grub4dos有很多知识点啊！

不点 · 发表于 2019-4-25 11:12:58

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

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

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

分两种情况来讨论。

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

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

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

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

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

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

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

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

2011yaya2007777 · 发表于 2019-4-25 12:31:42

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

2011yaya2007777 · 发表于 2019-4-25 18:07:02

0new88.iso在哪里?

2011yaya2007777 · 发表于 2019-4-25 19:09:31

0new88.bin 应当预先建立吧

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，实际上是不行的，有暗桩，可能是这片内存区域已经被占领，所以有冲突。

2011yaya2007777 · 发表于 2019-4-25 20:07:51

只能向已经存在的文件写数据，并且不能超过原有文件的尺寸。

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

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

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

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

grub4dos出错提示inconsistent filesystem structure

点评

点评

点评

点评

点评