grub4dos_0.4.6a_20170515 不能识别文件系统类型

jdcgzb · 发表于 2017-5-20 15:28:29

本帖最后由 jdcgzb 于 2017-5-31 19:46 编辑

如图所示

http://grub4dos.chenall.net/近几天打不开

2011yaya2007777 · 发表于 2017-5-20 16:30:11

本帖最后由 2011yaya2007777 于 2017-5-20 19:10 编辑

帮忙看看是哪一个版本开始出现的问题。屏幕显示是第三方软件产生的，是什么，也可能是它的问题，上传一下。

jdcgzb · 发表于 2017-5-21 11:50:06

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

请看图片

jdcgzb · 发表于 2017-5-21 11:51:31

本帖最后由 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:16

本帖最后由 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:32

报告给出了产生问题的确切日期，很好。我猜是 5 月 5 日改动太大，引入了 bug。相信 yaya 会处理的。

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

2011yaya2007777 · 发表于 2017-5-22 16:36:15

问题已经定位。不日解决。

2011yaya2007777 · 发表于 2017-5-23 09:48:32

是因为 UUID 函数改动，影响了 RUN。
官网已经更新。

jdcgzb · 发表于 2017-5-23 13:30:08

2011yaya2007777 发表于 2017-5-23 09:48
是因为 UUID 函数改动，影响了 RUN。
官网已经更新。

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

akkakk · 发表于 2017-5-25 09:01:06

本帖最后由 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:19

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:40

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

改成这样就可以了：

刚才试了一下，加top参数后可以开始加载vhd，4096M大小的vhd加载到186M的时候电脑就重启了，试了好几遍，一直是这样。

2011yaya2007777 · 发表于 2017-5-25 10:01:06

本帖最后由 2011yaya2007777 于 2017-5-25 10:04 编辑

使用 displaymem 看看内存分布

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

不点 · 发表于 2017-5-25 10:23:17

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:16

本帖最后由 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:54

现在map --top --mem是用pae还是mem64？

2011yaya2007777 · 发表于 2017-5-25 14:13:58

本帖最后由 2011yaya2007777 于 2017-5-25 15:07 编辑

mem64优先于pae.
win2003比win7大?

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

akkakk · 发表于 2017-5-25 15:19:37

2011yaya2007777 发表于 2017-5-25 14:13
mem64优先于pae.
win2003比win7大?

是直接用这个grldr替换测试，还是要加什么参数？

akkakk · 发表于 2017-5-25 15:26:24

2011yaya2007777 发表于 2017-5-25 14:13
mem64优先于pae.
win2003比win7大?

直接替换测试，结果还是不能引导，但是VHD文件能够完整加载到内存。

2011yaya2007777 · 发表于 2017-5-25 18:14:06

设置 debug=3，看看有什么不能引导的反馈信息。

akkakk · 发表于 2017-5-25 19:32:46

本帖最后由 akkakk 于 2017-5-25 19:36 编辑

2011yaya2007777 发表于 2017-5-25 18:14
设置 debug=3，看看有什么不能引导的反馈信息。

不点 · 发表于 2017-5-25 20:49:56

本帖最后由不点于 2017-5-25 21:12 编辑

是不是又碰上 NTFS 的 bug 了？

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

还有一点，提醒一下。

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

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

不点 · 发表于 2017-5-25 21:24:44

既然用 yaya 给出的 PAE 版本测试，照样不能正确引导，那么就怀疑，磁盘访问 disk_io.c 出了问题。

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

2011yaya2007777 · 发表于 2017-5-27 08:33:07

请 akkakk 帮忙再测试一下，直接替换即可。

akkakk · 发表于 2017-5-27 14:26:55

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

这个可以了，正常引导启动。

2011yaya2007777 · 发表于 2017-5-27 15:46:03

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

请 akkakk 帮忙再测试一下，看看开放 mem64 函数，是否会重启。直接替换即可。

akkakk · 发表于 2017-5-27 20:21:55

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

这个不能用，试了几次，分别加载vhd到96M、208M、200M的时候出现重启现象。

2011yaya2007777 · 发表于 2017-5-27 20:34:08

看来这个函数有些问题，需要排查。也请不点留意一下。

不点 · 发表于 2017-5-27 22:13:27

yaya 能否做这样一个试验：给 0.4.5c 的 mem64 打补丁，试试看怎么样？

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

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

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

不点 · 发表于 2017-5-28 01:31:37

本帖最后由不点于 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 位保护模式能够响应硬件中断，比如键盘中断、时钟中断）。

		自动登录	找回密码
密码			注册

[已解决] grub4dos_0.4.6a_20170515 不能识别文件系统类型

点评

点评

点评

点评

点评

点评

点评