grldr引导bootmgr后出现“Bootmgr image is corrupt. The system cannot boot”

不点

同意以上各位的分析。

建议做以下测试，或者也算是 workaround 吧（因为 NTFS 部分的代码不容易理解，估计只有等 bean 来解决了）：

1. 建立多个 bootmgr，叫做 bootmgr1、bootmgr2、等等，用 chainloader 加载它们，看看能否有一个成功。

2. 在 FAT32 分区上放一个 bootmgr（或者在虚拟软盘上放一个 bootmgr），然后用 chainloader 加载它。加载时注意使用 --edx 参数，或者 chainloader 加载之后，立即用一条 root (hdX,Y) 命令指定正确的 bootmgr 所在的分区为当前分区。然后才可以执行 boot 命令。

3. 用 blocklist 命令列出 bootmgr 的扇区序列，看它是不是连续的。如果不是连续的，可以尝试用 contig 工具整理为连续的。这样可能减少读取失败的几率。

4. grub4dos 有一个叫做 cmp 的命令，可以用来比较两个文件是否相同。你可以比较 bootmgr 与 bootmgr1 、bootmgr2 是否相同。如果发现不同，则证明 grub4dos 有 bug。

[ 本帖最后由 不点 于 2012-5-3 16:45 编辑 ]

不点

问题很严重，连续的文件竟然读错。

等待 chenall 或者 bean 来解决。本人身体差，而且不擅长解决 NTFS 的问题。

你可以用 cat --hex /bootmgr 来读扇区，与 Windows 下的 Winhex 读取的扇区进行对照，看看第一个出错的扇区是哪个。

我觉得这个问题最终能够解决。

请保护好你的 bootmgr 文件，不要删除它，也不要移动它，只等 chenall 或 bean 来解决。

不点

在 grub4dos 下用 blocklist /bootmgr 列出它的扇区序列，看看是不是正确显示为连续的。

不点

连续的扇区序列，读取应该很简单，怎会出错？

怀疑是 0.4.5 引入的 bug。

试试老的 0.4.4 系列的 grldr，看看有无问题。

不点

看来真的是旧代码中早已存在的 bug 了。等待解决。

你记住这事，通知 chenall。

不点

你可以把这个盘留下，给客户换个新盘。或者你精确备份这个盘，按扇区备份它。只需精确备份这个 ntfs 分区便可。

如果不方便，那就放弃也罢。

不点

你用 dd 命令，比如使用 dd for windows，就很精确了。

试着把整个分区（ntfs分区）备份到（并覆盖）另一个分区（分区2）。

分区2 的大小只要不小于要备份的 ntfs 分区便可，因此，分区2更大一些是没关系的。

当 dd 完成之后，分区2 也就成为 ntfs 格式了。

此时你可以立即验证 grldr 可否正常启动分区2上的 bootmgr，至少可以验证 cmp 命令比较 bootmgr 和 bootmgr1 是否不同。

如果不同，则达到目的，说明备份的分区2 是可以用来调试除错的。

使用 dd 时，一定要注意安全，不要毁掉有用的数据。

[ 本帖最后由 不点 于 2012-5-3 22:09 编辑 ]

不点

bean 很久都没露面了，估计是没时间来。bean 的 burg 也有很长时间没更新了。

chenall 有事，也可能要耽搁一个月。

最安全的是备份。

当然，你也可以自己编译，加入调试输出，自己定位 bug。这应该也不是很难。

不点

好像是相对于分区开头的扇区偏移。

你试着 cat --hex (hd0,Y)22901416+750 就应该得到 bootmgr 的扇区内容。此处 Y 是分区号码。

chainloader (hd0,Y)22901416+750 也应该可以启动它。

不点

你还真得试试 31 楼所说。

确认读扇区序列是正确的。可以用 cat --hex 显示这个扇区序列，看看它到底与 bootmgr 的真实内容一样还是不一样。

如果不一样，则问题确实出在 int13 上，即，BIOS 的错。

不点

bios 通常发生极限错误，即，超过某个极限时出错。

但也有可能在临近某个特殊的位置时发生错误，比如，靠近 8.4G 附近。一切皆有可能。比如，有可能是 grub4dos 自己在 8.4G 附近出错。这都需要有证据，有验证。而你，正好可以验证这些猜想。

不点

你可以用 grub4dos 的 dd 命令把 16376424+750 复制到某个文件中。再进入 Windows 比较这个文件与 Winhex 显示的绝对磁盘扇区 16376424+750 是否一致。如果不相同，就证明 grub4dos 的读操作含有 bug。

不点

谢谢 2011131013，你干得太好了。

你所发现的，终究还得归结为 grub4dos 的 bug。你研究得很细致，在此也表示佩服。

我同意你的猜测和分析。

Winhex 在读扇区 16377165 时，却提示稍后的 16377180扇区I/O错误，这个信息十分要紧。

这说明，Winhex 是一次读取多个扇区（通常是一个磁道，即 63 个扇区）。当所读取的扇区之中有一个失败的时候，就宣告失败。所以，Winhex 也在读 16377165 时报错。

grub4dos 也是使用类似的做法。这里有一个隐蔽的 bug，待我抽时间看看。

你的任务完成了。再次谢谢。

不点

修复了，请在时空论坛下载。

由于变化很大，因此请其他人也广泛测试，看看有无问题。