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

grub4dos出错提示inconsistent filesystem structure

本帖最后由 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启动,可能会有环境干扰,更加难以定位问题。

2011yaya2007777 发表于 2019-4-21 09:09:50

这个SSD用diskgenius分了两个MBR主分区
是什么类型的分区?比如ntfs?

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

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

2011yaya2007777 发表于 2019-4-21 09:25:46

既然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 发表于 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=viewthread&tid=413341&extra=page%3D3这个帖子也碰到类似的问题,才看到,不过他是linux.iso,我是pe.iso。不点说是扇区太大,可SSD只有256GB啊。      

2011yaya2007777 发表于 2019-4-21 14:51:00

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

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?   

2011yaya2007777 发表于 2019-4-21 15:42:39

本帖最后由 2011yaya2007777 于 2019-4-21 15:57 编辑

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

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

不点 发表于 2019-4-21 16:12:43

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。

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

不点 发表于 2019-4-21 16:20:43

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

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

不点 发表于 2019-4-21 16:28:06

本帖最后由 不点 于 2019-4-21 16:37 编辑

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

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

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

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

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

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

2011yaya2007777 发表于 2019-4-21 16:36:18

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

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

不点 发表于 2019-4-21 16:51:46

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

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


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


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



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


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


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

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/

不点 发表于 2019-4-21 17:04:25

本帖最后由 不点 于 2019-4-21 17:46 编辑

本次 --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 发表于 2019-4-21 17:07:16

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

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,根本不会执行后面的语句。实体机亲测。

不点 发表于 2019-4-21 17:51:46

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



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

不点 发表于 2019-4-21 18:03:26

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: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插槽里面,可能这个转接卡需要占用内存区段,造成了内存切块的现象,以后可能会碰到较多类似的案例。

2011yaya2007777 发表于 2019-4-21 19:04:47

以后可能会碰到较多类似的案例。
楼主,可否在 SSD 盘再测试一下
map /WePE_64_V2.0.iso (0xff)
看看是否报错。

2011yaya2007777 发表于 2019-4-21 19:22:05

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

不点 发表于 2019-4-21 19:23:00

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

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

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

不点 发表于 2019-4-21 20:28:53

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

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 代码无关,而完全是内存块的 “写入” 操作本身所造成的问题。

不点 发表于 2019-4-21 20:46:07

本帖最后由 不点 于 2019-4-21 20:59 编辑

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

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

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

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

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

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

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


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

页: [1] 2 3
查看完整版本: grub4dos出错提示inconsistent filesystem structure