grub4dos出错提示inconsistent filesystem structure

2011yaya2007777

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

liuzhaoyzz

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

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

2011yaya2007777

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

2011yaya2007777

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

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

   

不点

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

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

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

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

江南一根葱

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

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 下正常运行了。

   

liuzhaoyzz

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

不点

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

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

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

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

不点

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