无忧启动论坛

标题: grub4dos出错提示inconsistent filesystem structure [打印本页]
作者: liuzhaoyzz    时间: 2019-4-20 22:34
标题: 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。
这是怎么回事？

IMG_20190420_224203.jpg (886.58 KB, 下载次数: 212)

IMG_20190420_224203.jpg

IMG_20190420_224345.jpg (762.42 KB, 下载次数: 219)

IMG_20190420_224345.jpg
作者: liuzhaoyzz    时间: 2019-4-21 07:58
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
这个SSD用diskgenius分了两个MBR主分区

是什么类型的分区?比如ntfs?
作者: liuzhaoyzz    时间: 2019-4-21 09:11
全部都是NTFS,我不知道还需要报告什么相关的信息。
刚才测试了grub4dos-0.4.6a-2018-02-27，也是一样的结果，版本太多了。
作者: 2011yaya2007777    时间: 2019-4-21 09:25
既然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
原来只有这样定位问题。。。这电脑要惨遭蹂躏啊。我试下。
作者: liuzhaoyzz    时间: 2019-4-21 12:30
下载了很多版本测试，用sinoxer的简易启动测试器与实体机似乎有区别，只能实体机测试，结果出来了：
2016年的最后一个版本grub4dos-0.4.6a-2016-12-24正常。
2017年的第一个版本grub4dos-0.4.6a-2017-02-03出错。
作者: liuzhaoyzz    时间: 2019-4-21 14:44
       http://wuyou.net/forum.php?mod=v ... &extra=page%3D3这个帖子也碰到类似的问题，才看到，不过他是linux.iso,我是pe.iso。不点说是扇区太大，可SSD只有256GB啊。        
作者: 2011yaya2007777    时间: 2019-4-21 14:51
我知道了。是参数 --top 的问题。
2017-02-03开始，加参数 --top 从 4Gb 以上内存分配空间，否则从 4Gb 以下内存分配空间。
作者: liuzhaoyzz    时间: 2019-4-21 15:22
本帖最后由 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
本帖最后由 2011yaya2007777 于 2019-4-21 15:57 编辑

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

BIOS 从机械硬盘启动，或者从 SSD 启动，可能占用的内存不同，因此内存剩余空间也不同。你有疑问的话，查看一下启动后不同的内存分布即可。
作者: 不点    时间: 2019-4-21 16:12
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
2011yaya2007777 发表于 2019-4-21 15:42
不是bug，是改进。
以前的内存大多小于 4Gb，没有差别。现在 4Gb 以上内存普遍了，所以要注意。
你加上 - ...

无论放在 4G 以上还是以下，都是放在 Usable RAM 的区域，而不可能放在 Reserved 区域，因此，是不会出错的。如果这出错的话，那就严重了，应该早就有人报告了，而不会等到现在才有人发现错误。
作者: 不点    时间: 2019-4-21 16:28
本帖最后由 不点 于 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
楼主定位版本grub4dos-0.4.6a-2017-02-03出错，视乎补丁与“inconsistent filesystem structure”毫无关系。
等待楼主进一步反馈。
作者: liuzhaoyzz    时间: 2019-4-21 16:51
本帖最后由 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能够改进下。

IMG_20190421_163842.jpg (1.07 MB, 下载次数: 182)

IMG_20190421_163842.jpg
作者: 不点    时间: 2019-4-21 16:51
楼主必须在这个 SSD 上测试，才是有效的测试。

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


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


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



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


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


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

作者: liuzhaoyzz    时间: 2019-4-21 16:58
本帖最后由 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
本帖最后由 不点 于 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
试一试
map --mem /WePE_64_V2.0.iso (0xff) || map --mem --top /WePE_64_V2.0.iso (0xff)
作者: liuzhaoyzz    时间: 2019-4-21 17:16
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
liuzhaoyzz 发表于 2019-4-21 17:16
cat  --hex  (...)/.../your_file.iso
是正确的，没有出错。

谢谢辛苦。同时也向你表示抱歉，让你辛苦做的那些测试都是无效的，白做了。yaya 让你测试 --top 成功，这才暴露出了症结在哪里。
作者: 不点    时间: 2019-4-21 18:03
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
本帖最后由 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
以后可能会碰到较多类似的案例。

楼主，可否在 SSD 盘再测试一下
map /WePE_64_V2.0.iso (0xff)
看看是否报错。
作者: 2011yaya2007777    时间: 2019-4-21 19:22
也没有可能是这样：硬件占用了内存，没有注册，或者注册不准确，比如小了，造成了内存冲突。
作者: 不点    时间: 2019-4-21 19:23
liuzhaoyzz 发表于 2019-4-21 18:08
接续不点的帖子，内存布局是这样子的：
（1）Usable RAM  （一大块）正常 640KB
（2）Usable RAM  （一小 ...

你搞错了。你把常规内存的那一块也弄上来了。那块是无用的，要去掉。总共是 6 块，去掉第一块的常规内存，剩下的 5 块，才是与我们的 img 有关的。
作者: liuzhaoyzz    时间: 2019-4-21 20:14
本帖最后由 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
本帖最后由 不点 于 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
本帖最后由 不点 于 2019-4-21 20:59 编辑

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

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

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

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

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

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

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


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

作者: 2011yaya2007777    时间: 2019-4-21 20:59
32楼
作者: 2011yaya2007777    时间: 2019-4-21 21:02
在32楼，你说了3种情况，前2种你说明了结果，那第3种情况结果如何？是不是一样grub4dos-0.4.6a-2019-03-25，map --mem失败，map--mem --top成功，直接map也成功。
作者: liuzhaoyzz    时间: 2019-4-21 21:29
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
本帖最后由 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
本帖最后由 不点 于 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
liuzhaoyzz 发表于 2019-4-21 21:29
第三种情况彻底让我迷惑了！彻底拿掉转接卡之后，机械硬盘写入grub4dos-0.4.6a-2019-03-25,机械硬盘上 ...

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

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

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

很容易猜到，很可能这个转接卡 “暗中”、“偷偷地” 使用了第（3）块内存，又不 “登记”，因此制造了麻烦。
作者: liuzhaoyzz    时间: 2019-4-22 11:55
本帖最后由 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 的结果全都一样，又怎么解释？

PCIE转M.2接口转接卡.jpg (80.11 KB, 下载次数: 148)

PCIE转M.2接口转接卡.jpg
作者: liuzhaoyzz    时间: 2019-4-22 16:32
本帖最后由 liuzhaoyzz 于 2019-4-22 16:37 编辑

要回复你，要有空、实机测试才行啊，那电脑没在身边。搞这么多ISO，要重启多少次啊~~~
作者: 不点    时间: 2019-4-22 17:31
liuzhaoyzz 版主

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

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

问题就是这么简单，没什么技术含量。不知这几句话能否帮到你。
作者: 不点    时间: 2019-4-22 17:35
frg521 兄

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

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

作者: 2011yaya2007777    时间: 2019-4-22 19:37
上传个这个问题的物证，就它们两个：

在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
本帖最后由 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也没问题。

IMG_20190422_194315.jpg (458.74 KB, 下载次数: 150)

IMG_20190422_194315.jpg

IMG_20190422_194614.jpg (435.08 KB, 下载次数: 145)

IMG_20190422_194614.jpg

看起来好整齐，代表死机次数X2.png (87.09 KB, 下载次数: 142)

o(∩_∩)o 哈哈

o(∩_∩)o 哈哈
作者: 不点    时间: 2019-4-22 21:09
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
好吧，不再费心思了。退出讨论。
作者: liuzhaoyzz    时间: 2019-4-22 22:40
本帖最后由 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
用户自己可以想办法排除有问题的内存块。

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

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

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

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

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

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

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


作者: liuzhaoyzz    时间: 2019-4-24 09:55
   
map 命令有两个参数，分别控制最低的内存地址和最高的内存地址。
这两个参数复杂吗？没看到哪里有介绍啊？
作者: 不点    时间: 2019-4-24 12:14
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
楼主的问题应该和我刚来无忧的时候差不多情况
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
我搜到了这个帖子，很重要，请留意：

关于 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
    grub4dos有很多知识点啊！   
作者: 不点    时间: 2019-4-25 11:12
深入讨论 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
本帖最后由 liuzhaoyzz 于 2019-4-25 11:25 编辑

    我觉得第二种情况的可能性更大，SSD在BIOS中能够被看到，肯定是实模式下分配了盘号及内存用于被访问，这个盘号只是临时的，进入windows之后，windows有保护模式的驱动，BIOS下实模式的内存占用不会冲突。windows是个黑盒子，使用者只能通过现象分析黑盒子里面是什么东西，并且通过一些巧妙的方法来规避这些暗桩。   
作者: 2011yaya2007777    时间: 2019-4-25 12:31
实模式启动时，未使用的内存，应当都是0吧？如果是，那么安装内存块时，先测试一下。如果有数据，则移动安装位置。
作者: 2011yaya2007777    时间: 2019-4-25 18:07
0new88.iso在哪里?
作者: 2011yaya2007777    时间: 2019-4-25 19:09
0new88.bin 应当预先建立吧
作者: liuzhaoyzz    时间: 2019-4-25 19:30
    低位内存可以map --mem最大不到200MB。管他是放在哪一区域，反正是不行啊。   
作者: liuzhaoyzz    时间: 2019-4-25 20:05
    可能是我表达的 不准确让你产生了误解。我所说的最大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，实际上是不行的，有暗桩，可能是这片内存区域已经被占领，所以有冲突。
   

IMG_20190425_195453.jpg (290.02 KB, 下载次数: 140)

IMG_20190425_195453.jpg

IMG_20190425_195556.jpg (404.69 KB, 下载次数: 137)

IMG_20190425_195556.jpg
作者: 2011yaya2007777    时间: 2019-4-25 20:07
只能向已经存在的文件写数据，并且不能超过原有文件的尺寸。
作者: liuzhaoyzz    时间: 2019-4-26 09:25
   
实模式启动时，未使用的内存，应当都是0吧？如果是，那么安装内存块时，先测试一下。如果有数据，则移动安装位置。

    请问下您所说的这个，是试图在代码层面解决问题是吗？还是在用户层面加个什么参数实现问题？我没听懂这个意思。如果能在代码层面解决，判断内存块上面有东西，如果可行，那就最好了。
   
作者: 2011yaya2007777    时间: 2019-4-26 09:47
是想在代码中解决。但是我在虚拟机里测试，可以内存块里有数据，不是全空白。实体机还没有测试，不知情况如何。
作者: liuzhaoyzz    时间: 2019-4-26 10:15
2011yaya2007777 发表于 2019-4-26 09:47
是想在代码中解决。但是我在虚拟机里测试，可以内存块里有数据，不是全空白。实体机还没有测试，不知情况如 ...

    感觉虚拟机和实体机测试结果是有区别的，如果能在代码层面解决就好了。这样子一个菜单通用。不用根据不同电脑不同内存大小来区别对待是否加--top.   
作者: 2011yaya2007777    时间: 2019-4-26 10:37
实体机测试，行不通。放弃方案。
作者: 2011yaya2007777    时间: 2019-4-26 12:42
‘‘’不用根据不同电脑不同内存大小来区别对待是否加--top‘  不用管内存是否大于4Bb，增加参数 --top 后，内存不足4Gb，就会在4Gb以下内存分配空间。
作者: liuzhaoyzz    时间: 2019-4-26 14:33
本帖最后由 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

   
作者: 不点    时间: 2019-4-27 02:34
frg521 发表于 2019-4-26 11:13
...

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

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

dd 可以写文件，write 命令也可以写文件，重定向符号也是可以用来写文件的。要不，你先学习一下 grub4dos 的教程？置顶的教程，应该会涉及到这方面的知识吧？
作者: 江南一根葱    时间: 2019-4-27 10:35
说句帖外话，看看楼上的语法，以前还怀疑楼上是歪国人，翻译的中文，
现在看看语法像美式中文。。。。。。。。。
作者: liuzhaoyzz    时间: 2019-5-11 18:47
本帖最后由 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
     sratlf的run模块可以直接用记事本编辑，没有加密，不懂grub4dos批处理，期待有高手能够更新下这个run模块，挺好用的，不然就只能用老版本的grub4dos0.4.6a20161224版本了。      
作者: 不点    时间: 2019-5-18 14:22
Refuse to hook int13 由于 map 表格为空。这条信息似乎是老版本的 grub4dos 才会显示吧？很老很老的。

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

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

作者: liuzhaoyzz    时间: 2019-5-18 16:45
本帖最后由 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挺好用啊。
作者: 不点    时间: 2019-5-18 22:04
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 入手来解决问题，那是方向性的错误。



欢迎光临 无忧启动论坛 (http://wuyou.net/) Powered by Discuz! X3.3