无忧启动论坛

标题: grub4dos_0.4.6a_20170515 不能识别文件系统类型 [打印本页]
作者: jdcgzb    时间: 2017-5-20 15:28
标题: grub4dos_0.4.6a_20170515 不能识别文件系统类型
本帖最后由 jdcgzb 于 2017-5-31 19:46 编辑

如图所示


http://grub4dos.chenall.net/近几天打不开
作者: 2011yaya2007777    时间: 2017-5-20 16:30
本帖最后由 2011yaya2007777 于 2017-5-20 19:10 编辑

帮忙看看是哪一个版本开始出现的问题。屏幕显示是第三方软件产生的，是什么，也可能是它的问题，上传一下。
作者: jdcgzb    时间: 2017-5-21 11:50
2011yaya2007777 发表于 2017-5-20 16:30
帮忙看看是哪一个版本开始出现的问题。屏幕显示是第三方软件产生的，是什么，也可能是它的问题，上传一下。

请看图片
作者: jdcgzb    时间: 2017-5-21 11:51
本帖最后由 jdcgzb 于 2017-5-21 11:59 编辑
2011yaya2007777 发表于 2017-5-20 16:30
帮忙看看是哪一个版本开始出现的问题。屏幕显示是第三方软件产生的，是什么，也可能是它的问题，上传一下。

因为http://grub4dos.chenall.net/近几天打不开，不能更新grub4dos_0.4.6a，仅找到两个版本的试验结果。
请看图片




作者: tegl    时间: 2017-5-21 14:57
本帖最后由 tegl 于 2017-5-21 15:02 编辑

我也发现了5月份的版本都有此严重BUG，导致无法加载dos.img，进入不了DOS，最后一个没有问题的稳定版本是grub4dos-0.4.6a-2017-04-21

1、2017-04-21为稳定版
2、以下几个版本有严重BUG，无法识别分区文件系统类型，导致无法进DOS
2017-05-15
2017-05-12
2017-05-09
2017-05-06
2017-05-05
作者: 不点    时间: 2017-5-22 10:38
报告给出了产生问题的确切日期，很好。我猜是 5 月 5 日改动太大，引入了 bug。相信 yaya 会处理的。

我早都不参与开发了，不用私信通知我了。目前我的兴趣已经转向 ARM，已经脱离 x86 了。与 grub4dos 有关的问题，请与 chenall、yaya 联系。

作者: 2011yaya2007777    时间: 2017-5-22 16:36
问题已经定位。不日解决。
作者: 2011yaya2007777    时间: 2017-5-23 09:48
是因为 UUID 函数改动，影响了 RUN。
官网已经更新。
作者: jdcgzb    时间: 2017-5-23 13:30
2011yaya2007777 发表于 2017-5-23 09:48
是因为 UUID 函数改动，影响了 RUN。
官网已经更新。


文件系统类型识别正常了。

作者: akkakk    时间: 2017-5-25 09:01
本帖最后由 akkakk 于 2017-5-25 09:03 编辑

试了试最新版grub4dos-0.4.6a-2017-05-23，mem方式引导4g容量的2003系统vhd文件时，提示cannot fit into memory。用grub4dos-0.4.5c-2016-01-18的grldr正常。不知道是不是bug。 （grub4dos安装在启动硬盘的mbr）

title Win2003
  hide (hd0,0)
  map --mem (hd0,4)/WIN2003.vhd (hd0)
  map --hook
  rootnoverify (hd0)
  chainloader +1
作者: 不点    时间: 2017-5-25 09:23
akkakk 发表于 2017-5-25 09:01
试了试最新版grub4dos-0.4.6a-2017-05-23，mem方式引导4g容量的2003系统vhd文件时，提示cannot fit into me ...

新版要想使用 4G 之上的 “高位内存”，必须为 map 命令加上 --top 参数才行。

改成这样就可以了：

map   --top   --mem   (hd0,4)/WIN2003.vhd   (hd0)

作者: akkakk    时间: 2017-5-25 09:41
不点 发表于 2017-5-25 09:23
新版要想使用 4G 之上的 “高位内存”，必须为 map 命令加上 --top 参数才行。

改成这样就可以了：

刚才试了一下，加top参数后可以开始加载vhd，4096M大小的vhd加载到186M的时候电脑就重启了，试了好几遍，一直是这样。
作者: 2011yaya2007777    时间: 2017-5-25 10:01
本帖最后由 2011yaya2007777 于 2017-5-25 10:04 编辑

使用 displaymem 看看内存分布

map --mem (hd0,4)/WIN2003.vhd (hd0)
映射为 (hd0) 是否不妥？

作者: 不点    时间: 2017-5-25 10:23
yaya 注意，akkakk 在前面一帖的报告说，0.4.5c 是成功加载。因此，有可能是 0.4.5a 出现的 bug。

不要认为 map 到 (hd0) 有错，因为 0.4.5c 执行 map 到 (hd0) 是成功的呀。所以，判断错误的方向，就不要走弯路了。

我判断，八成还是 0.4.6a 的某个 bug。

可以让 akkakk 测试一下，究竟从哪天开始出现 bug 的。需要辛苦一下 akkakk 了，逐个测试 0.4.6a，看看最早从哪个版本开始有问题了。

作者: akkakk    时间: 2017-5-25 12:59
本帖最后由 akkakk 于 2017-5-25 13:12 编辑

做了一把小白鼠，测试结果如下：
grub4dos-0.4.6a-2012-01-01.7z
正常引导
grub4dos-0.4.6a-2012-12-31.7z
正常引导
grub4dos-0.4.6a-2014-01-17.7z
正常引导
grub4dos-0.4.6a-2015-01-09.7z
正常引导
grub4dos-0.4.6a-2016-01-14.7z
正常引导
grub4dos-0.4.6a-2017-02-03.7z
正常引导
grub4dos-0.4.6a-2017-03-30.7z
正常引导
grub4dos-0.4.6a-2017-04-21.7z
正常引导
grub4dos-0.4.6a-2017-05-05.7z
不能引导（VHD文件能够完整加载到内存）
grub4dos-0.4.6a-2017-05-06.7z
不能引导（测试三次分别在VHD加载到0M、24M、64M出现重启现象）
grub4dos-0.4.6a-2017-05-12.7z
不能引导（加载到100M以内就出现重启现象）

引导菜单
title Win2003
  hide (hd0,0)
  map --top --mem (hd0,4)/WIN2003.vhd (hd0)
  map --hook
  rootnoverify (hd0)
  chainloader +1

displaymem


所有版本VDF格式Win7x64均能够正常引导。
作者: 求道者    时间: 2017-5-25 13:59
现在map --top --mem是用pae还是mem64？
作者: 2011yaya2007777    时间: 2017-5-25 14:13
本帖最后由 2011yaya2007777 于 2017-5-25 15:07 编辑

mem64优先于pae.
win2003比win7大?

难道是开放 mem64 惹的祸？
试一试禁止 mem64 函数。


grldr.rar

162.7 KB, 下载次数: 2, 下载积分: 无忧币 -2

作者: akkakk    时间: 2017-5-25 15:19
2011yaya2007777 发表于 2017-5-25 14:13
mem64优先于pae.
win2003比win7大?

是直接用这个grldr替换测试，还是要加什么参数？
作者: akkakk    时间: 2017-5-25 15:26
2011yaya2007777 发表于 2017-5-25 14:13
mem64优先于pae.
win2003比win7大?

直接替换测试，结果还是不能引导，但是VHD文件能够完整加载到内存。
作者: 2011yaya2007777    时间: 2017-5-25 18:14
设置 debug=3，看看有什么不能引导的反馈信息。
作者: akkakk    时间: 2017-5-25 19:32
本帖最后由 akkakk 于 2017-5-25 19:36 编辑
2011yaya2007777 发表于 2017-5-25 18:14
设置 debug=3，看看有什么不能引导的反馈信息。


作者: 不点    时间: 2017-5-25 20:49
本帖最后由 不点 于 2017-5-25 21:12 编辑

是不是又碰上 NTFS 的 bug 了？

试试把 VHD 放在 exFAT 或 Linux 的 ext2 分区下，看看能正常启动吗？


还有一点，提醒一下。

有些 cpu 是 32 位的，不支持 64 位，但却支持 PAE。

所以，逻辑上可以优先采用 mem64，但前提条件是首先确定了 cpu 支持 64 位才行。否则，就应该使用 PAE。

作者: 不点    时间: 2017-5-25 21:24
既然 用 yaya 给出的 PAE 版本测试，照样不能正确引导，那么就怀疑，磁盘访问 disk_io.c 出了问题。

yaya 5 月 5 日的改动太大。有可能是 disk_io 或者相关的改动引入了 bug。

作者: 2011yaya2007777    时间: 2017-5-27 08:33
请 akkakk 帮忙再测试一下，直接替换即可。

grldr.rar

162.68 KB, 下载次数: 7, 下载积分: 无忧币 -2

作者: akkakk    时间: 2017-5-27 14:26
2011yaya2007777 发表于 2017-5-27 08:33
请 akkakk 帮忙再测试一下，直接替换即可。

这个可以了，正常引导启动。
作者: 2011yaya2007777    时间: 2017-5-27 15:46
本帖最后由 2011yaya2007777 于 2017-5-28 07:53 编辑

请 akkakk 帮忙再测试一下， 看看开放 mem64 函数，是否会重启。直接替换即可。
作者: akkakk    时间: 2017-5-27 20:21
2011yaya2007777 发表于 2017-5-27 15:46
请 akkakk 帮忙再测试一下， 看看开放 mem64 函数，是否会重启。直接替换即可。

这个不能用，试了几次，分别加载vhd到96M、208M、200M的时候出现重启现象。
作者: 2011yaya2007777    时间: 2017-5-27 20:34
看来这个函数有些问题，需要排查。也请不点留意一下。
作者: 不点    时间: 2017-5-27 22:13
yaya 能否做这样一个试验：给 0.4.5c 的 mem64 打补丁，试试看怎么样？

加载 img 的过程中重启——看来我们得猜猜这是啥问题了。

另外，需要确定，有没有人能够成功使用 mem64 加载 img 到 4G 以上的内存？只要有一个成功案例就行。

我们获得的信息越多，就越容易猜到症结。目前获得的信息太少，因此判断起来就没有头绪。

作者: 不点    时间: 2017-5-28 01:31
本帖最后由 不点 于 2017-5-28 02:20 编辑

报告一个好消息，我似乎猜到了。

从“加载过程不稳定”这一现象，我努力地想，感觉这可能是“中断响应”之类的问题。比如说，数据传输过程中破坏了中断向量表，或者破坏了内存的代码或堆栈。

终于，突然意识到，mem64 没有执行 cli 指令。

在早期，32 位保护模式的代码只运行在 cli 的情况下，只有切换到实模式之后才执行 sti，一旦准备进入保护模式，就又要先执行一条 cli 了。

mem64 就是早期写成的，所以，无需执行 cli 指令（根据刚才的解释，保护模式代码的运行，就意味着 cli 早执行过了）。

然而后来，我们给保护模式开放了中断响应。进入保护模式之后，执行了 sti。就是说，保护模式的代码运行在 sti（允许响应硬件中断）的状态。

这下子，mem64 就“躺枪”了。

假如说 mem64 依旧只是使用 32 位保护模式，那就不用管 cli 和 sti 的问题，因为 32 位代码可以响应硬件中断，我们已经有了 32 位的硬件中断响应处理程序。

然而 mem64 要切换 cpu 模式，就是切换到 64 位模式，这就不能响应硬件中断了，因为我们没有编写 64 位的硬件中断处理程序。只要在 64 位代码执行期间发生硬件中断（比如时钟中断），程序必然要崩溃。因此，在进入 64 位模式之前，必须执行一条 cli 指令（禁止响应硬件中断）。

yaya 可以在 mem64 的开头放置一条 cli，然后在尾部的 ret 之前再放置一条 sti。

更好一点的做法是，在开头放置一条 pushfl（保存原有的中断标志），然后执行 cli（目的是让 64 位指令能够不受干扰地顺利执行），再在结尾的 ret 之前放置一条 popfl 指令，恢复原有的中断标志。

这样的话，程序的适应性就要好一些了：既能适用于早期的情况（32 位保护模式不具有中断响应的功能），也能适用于现在的情况（32 位保护模式能够响应硬件中断，比如键盘中断、时钟中断）。



作者: 2011yaya2007777    时间: 2017-5-28 07:51
按不点的提示修改了。请 akkakk 帮忙再测试一下，直接替换即可。

grldr.rar

162.75 KB, 下载次数: 5, 下载积分: 无忧币 -2

作者: 不点    时间: 2017-5-28 15:16
本帖最后由 不点 于 2017-5-28 15:34 编辑

几个小时过去了，没人测试。其实，任何人都可以测试，并非只有 akkakk 才可以测试。

先前的测试版是未增加 cli 指令的，应该很容易碰上“重启”的问题。就是说，只要试图加载几百 MB 的文件，总会碰上问题。因为加载过程中只要发生时钟中断，或者敲击键盘，或者移动鼠标，这就触发了硬件中断，于是就很容易“重启”。

最新的测试版增加了 cli 指令，应该没问题了。大家都可以测试的，没有什么危险，不会造成损失（最坏的情况，无非就是 “重启”、“死机”）。

只要你有条件加载比较大的 img，你都可以测试。

前一个版本是容易发生重启的，后一个版本正常。如果测试结果证实了这样的情况，那就是“测试成功”。



再补充，并非只有超过 4G 内存的电脑才可以测试。低于 4G 的电脑也可以测试。只要测试 img 足够大（大约几百 M 即可），必能重现问题。

而且，测试时，你没必要去启动 IMG，你只需要把它完整加载到内存，只要不发生重启的毛病，这就是成功了。前一版本肯定会发生重启，后一版本应该不会发生重启。如果测试结果确实如此，那我们就可以说，确实是找到了问题的症结。



再补充，低于 4G 内存的电脑，恐怕测试不出来。因为低于 4G 会自动采用 32 位的 memmove 函数，而不是采用 mem64。

但 yaya 自己可以测试。yaya 自己可以强制采用 mem64，这样就可以用低于 4G 内存的电脑来测试了。


作者: jdcgzb    时间: 2017-5-28 16:18
本帖最后由 jdcgzb 于 2017-5-28 16:19 编辑
不点 发表于 2017-5-28 15:16
几个小时过去了，没人测试。其实，任何人都可以测试，并非只有 akkakk 才可以测试。

先前的测试版是未增 ...


8G内存电脑测试成功加载到内存启动。



作者: 不点    时间: 2017-5-28 16:34
jdcgzb 发表于 2017-5-28 16:18
8G内存电脑测试成功加载到内存启动。

很抱歉，测试无效，哈哈。

要用真实机来测试，而不是虚拟机。

可以从 U 盘启动来测试，以免还得修改硬盘上的 grldr 文件。

你虚拟机测试，虚拟机的内存只有 256 M，内存没有超过 4G，测试无效啊。

作者: jdcgzb    时间: 2017-5-28 16:42
本帖最后由 jdcgzb 于 2017-5-28 16:45 编辑
不点 发表于 2017-5-28 16:34
很抱歉，测试无效，哈哈。

要用真实机来测试，而不是虚拟机。


我是用真机测试启动成功，然后在虚拟机里截图，主要是为了方便。




作者: 不点    时间: 2017-5-28 16:59
jdcgzb 发表于 2017-5-28 16:42
我是用真机测试启动成功，然后在虚拟机里截图，主要是为了方便。

不错，值得庆祝。

不过测试过程只完成了一半。还需要测试上一个版本确实是要导致 “死机” 或 “重启”，才算完成了测试。

注意，在加载 img 的过程中就应该碰上死机或重启。如果没有碰上死机或重启，那你得换个大一点的 img 才能让它有充足的时间去 “死机” 或 “重启”。

如果加载过程没有死机、重启，那它进入 Windows 也正常，没什么可测试的。问题就出在加载 img 到 4G 之上内存的过程中。加载的 map 命令行必须带有 --top 参数，才可能加载在 4G 以上。

作者: jdcgzb    时间: 2017-5-28 17:02
不点 发表于 2017-5-28 16:59
不错，值得庆祝。

不过测试过程只完成了一半。还需要测试上一个版本确实是要导致 “死机” 或 “重启 ...

请说明一下“上一个版本”具体指哪一个版本？
作者: 不点    时间: 2017-5-28 17:08
本帖最后由 不点 于 2017-5-28 17:14 编辑

就是 27 楼那个版本，不过，yaya 已经把它删除了，没法测试了。

本帖最后由 2011yaya2007777 于 2017-5-28 07:53 编辑

请 akkakk 帮忙再测试一下， 看看开放 mem64 函数，是否会重启。直接替换即可。
点评
akkakk
这个不能用，试了几次，分别加载vhd到96M、208M、200M的时候出现重启现象。  详情 回复 发表于 昨天 20:21


算了，那就不测试了。

那你最好再测试一个 4G 的大文件，让它加载，看看会不会成功。不用启动它，只要 map 命令能够完成加载，就算成功。

随便一个 4G 的文件都可以的，不一定非得是 img 文件。可以进入命令行，用 map --top --mem 加载它。
作者: 2011yaya2007777    时间: 2017-5-28 17:49
重启的grldr

grldr.rar

162.14 KB, 下载次数: 1, 下载积分: 无忧币 -2

作者: 不点    时间: 2017-5-28 18:27
2011yaya2007777 发表于 2017-5-28 17:49
重启的grldr

好的，这个是有问题的 grldr，大家可以证实一下，是不是有重启的问题。虽然已经知道症结了，但确认一下没坏处，以防万一还有别的蹊跷。
作者: 2011yaya2007777    时间: 2017-5-28 18:57
经过测试，mem64 重启的问题已经解决。

grub_memmove64 函数是分段执行的：
4GB以下采用常规方法；4GB及以上，优先 AMD64/IA32-e 分页模式，其次 PAE 分页模式。

如果全部采用 PAE 分页模式，没有感觉到速度变化。

如果全部采用 AMD64/IA32-e 分页模式，在真实计算机速度奇慢，卡在调用预置菜单及设置视频模式。但是加载内存似乎速度还可以。在虚拟机，则在[0M/325M]停止不前。不过也可能会变，没有耐心等待。
作者: jdcgzb    时间: 2017-5-28 19:04
2011yaya2007777 发表于 2017-5-28 17:49
重启的grldr

用此版本的GRLDR加载0PE会黑屏重启。
作者: 不点    时间: 2017-5-28 19:10
jdcgzb 发表于 2017-5-28 19:04
用此版本的GRLDR加载0PE会黑屏重启。

非常好，辛苦了。

猜测得到了实践的证实。问题应该算是搞清楚了。

当我们有可能把问题搞清楚时，就应该钉死它、彻底搞清，尽量不留下疑问点。我们有幸能搞清的问题并不多。对于一个问题，如果我们有可能搞清，就尽量搞清。

作者: 不点    时间: 2017-5-28 19:27
2011yaya2007777 发表于 2017-5-28 18:57
经过测试，mem64 重启的问题已经解决。

grub_memmove64 函数是分段执行的：

我没弄明白你说的情况。难道说在 mem64 的代码还没开始执行的时候，电脑已经很慢了？不可能吧？

如果你是说，“首先用 mem64 加载 img，然后又进入 img 里面的 grldr，此时出现问题”，这倒有可能是 mem64 带来的某个“副作用”。

这个问题出现在什么架构？intel 还是 AMD？有多少人会出现这样的情况？

难道说 mem64 里面的 cpu 模式切换过程，不太彻底？进入了一个“有问题” 的模式？或者说在函数返回时未能彻底恢复到正常的 32 位保护模式？

作者: 2011yaya2007777    时间: 2017-5-28 19:37
我是在grub_memmove64全部采用mem64，即屏蔽了4G以下的常规模式。电脑一启动就慢。不一定是执行map --mem时才调用grub_memmove64，有可能是其他什么地方调用了grub_memmove64。我猜测可能是频繁地切换cpu模式引起的吧。
作者: akkakk    时间: 2017-5-28 19:58
2011yaya2007777 发表于 2017-5-28 07:51
按不点的提示修改了。请 akkakk 帮忙再测试一下，直接替换即可。

抱歉，今天干了一天活，现在才有时间，赶紧测了一下，发现还是有点问题。
计算机8G内存，VHD镜像4G。4.20版本VHD文件加载到内存在20秒以内。
这个grldr速度变得很慢，前2G差不多30秒左右能加载，后2G第一次用了6分钟（总共6分半），第二次2分钟（总共2分半）。加载启动后系统运行正常。
测过的其他版本加载速度均正常，应该在20秒左右。
作者: 求道者    时间: 2017-5-28 20:07
akkakk 发表于 2017-5-28 19:58
抱歉，今天干了一天活，现在才有时间，赶紧测了一下，发现还是有点问题。
计算机8G内存，VHD镜像4G。4.2 ...


这是好消息吧……
mem64的问题果然没有那么容易修好啊……
然后yaya 首页有个usb --init的兼容问题
PLOP没能开源真是可惜
作者: 不点    时间: 2017-5-28 20:52
本帖最后由 不点 于 2017-5-28 21:08 编辑
2011yaya2007777 发表于 2017-5-28 19:37
我是在grub_memmove64全部采用mem64，即屏蔽了4G以下的常规模式。电脑一启动就慢。不一定是执行map --mem时 ...


至于说哪些地方调用了 memmove64，你搜索一下就知道了。好像文件系统驱动都使用了 memmove64。正如你所猜想的那样，mem64 切换 cpu 模式，是个很慢的操作。因此，在 4G 以内不该使用 mem64。



哦，看 mem64 函数当中的这条注释：

/* XXX: page maps can initialise only once for efficiency. */

2M 的页映射表，只需要执行一次即可。目前是每调用一次 mem64 就执行一次页表初始化，当然会浪费大量时间了。

你酌情处理吧。

作者: 2011yaya2007777    时间: 2017-5-28 21:08
我是为了测试。我的内存只有2GB。看来代码还需优化。只有我的测试是全域使用mem64。上传的测试用grldr，只有超过4GB，才使用mem64。网友报告6分半加载到内存，就是大于4GB的情况。
作者: 不点    时间: 2017-5-28 21:11
akkakk 发表于 2017-5-28 19:58
抱歉，今天干了一天活，现在才有时间，赶紧测了一下，发现还是有点问题。
计算机8G内存，VHD镜像4G。4.2 ...

可能与“页映射表”的反复初始化有关，浪费了时间。等待 yaya 给出优化后的测试版吧。

作者: 2011yaya2007777    时间: 2017-5-29 08:04
“页映射表”只初始化一次，速度正常了！

grldr.rar

162.75 KB, 下载次数: 4, 下载积分: 无忧币 -2

作者: akkakk    时间: 2017-5-29 18:42
2011yaya2007777 发表于 2017-5-29 08:04
“页映射表”只初始化一次，速度正常了！

正常了！！！！！
作者: 2011yaya2007777    时间: 2017-5-29 19:05
已经上传官网。



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