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 发表于 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 入手来解决问题，那是方向性的错误。

liuzhaoyzz

我在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挺好用啊。

不点

Refuse to hook int13 由于 map 表格为空。这条信息似乎是老版本的 grub4dos 才会显示吧？很老很老的。

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

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

liuzhaoyzz

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

liuzhaoyzz

    再来反馈个问题，不知道是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 下正常运行了。

   

江南一根葱

说句帖外话，看看楼上的语法，以前还怀疑楼上是歪国人，翻译的中文，
现在看看语法像美式中文。。。。。。。。。

不点

frg521 发表于 2019-4-26 11:13
...

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

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

dd 可以写文件，write 命令也可以写文件，重定向符号也是可以用来写文件的。要不，你先学习一下 grub4dos 的教程？置顶的教程，应该会涉及到这方面的知识吧？

liuzhaoyzz

    谢谢提醒。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

   

2011yaya2007777

‘‘’不用根据不同电脑不同内存大小来区别对待是否加--top‘  不用管内存是否大于4Bb，增加参数 --top 后，内存不足4Gb，就会在4Gb以下内存分配空间。

2011yaya2007777

实体机测试，行不通。放弃方案。

liuzhaoyzz

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

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

2011yaya2007777

是想在代码中解决。但是我在虚拟机里测试，可以内存块里有数据，不是全空白。实体机还没有测试，不知情况如何。

liuzhaoyzz

   

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

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

2011yaya2007777

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

liuzhaoyzz

    可能是我表达的 不准确让你产生了误解。我所说的最大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

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

2011yaya2007777

0new88.bin 应当预先建立吧

2011yaya2007777

0new88.iso在哪里?

2011yaya2007777

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

liuzhaoyzz

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

不点

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

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

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

分两种情况来讨论。

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

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

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

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

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

liuzhaoyzz

    grub4dos有很多知识点啊！   

不点

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

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

江南一根葱

楼主的问题应该和我刚来无忧的时候差不多情况
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已经满足不了要求了

不点

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

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

liuzhaoyzz

   

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

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

不点

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

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

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

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

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

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

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

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

liuzhaoyzz

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。

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

2011yaya2007777

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

不点

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

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