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

2011131013

grldr版本：grub4dos-0.4.6a-2012-04-25
GRUB引导安装在PBR，已经正常进入GRUB命令行
root (hd0,1)后ls显示正确无误：我的活动分区在第二主分区，NTFS格式。第1主分区为17隐藏，非活动
chainloader /bootmgr
boot
出错：Bootmgr image is corrupt. The system cannot boot

bootmgr确认是正常的，因为bootsect /nt60 sys后可以正常进入Windows7

或需要提供什么资料才能查到是什么原因导致grldr不能这样引导BOOTMGR？

2011131013

个人理解：GRLDR的chainloader /bootmgr读取BOOTMGR文件方式存在BUG，造成读取出来的内容有错，因为出现这个错误提示。
如果理解有错，希望指教
尝试过多个GRUB版本，同样现象。

sratlf

bootmgr在哪个分区

2011131013

呵呵，当然在活动分区上了(hd0,1)

fujianabc

有一定可能是grub4dos的ntfs读取存在bug。

xiaoy

我一直都用这个方法启动BOOTMGR 没有发现不妥

2011131013

原帖由 xiaoy 于 2012-5-3 15:16 发表
我一直都用这个方法启动BOOTMGR 没有发现不妥

这个方法当然是正确的，并且一般都是正常使用的，现在说的是个例
一些小BUG当然只有极少部分电脑才会发生。

sratlf

试试将mbr改为grub4dos  然后chainloader /bootmgr

2011131013

原帖由 sratlf 于 2012-5-3 15:31 发表
试试将mbr改为grub4dos  然后chainloader /bootmgr

不认为MBR方式和PBR方式引导GRUB4DOS有何其别，因为现在PBR方式已经成功加载GRLDR至GRUB>提示符
出问题的是GRUB4DOS加载BOOTMGR后出问题

当然，如果版主认为MBR方式和PBR方式有区别的话我当然试一下。

2011131013

原帖由 fujianabc 于 2012-5-3 15:13 发表
有一定可能是grub4dos的ntfs读取存在bug。

我也觉得是这个可能

其实这个功能我用不用都没所谓，只是测试其它修改版的GRUB4DOS软件时发现了，觉得应该是GRUB4DOS的BUG，修改版的加载方式（内置菜单自动加载）：
find --set-root --ignore-floppies --ignore-cd /bootmgr
chainloader /bootmgr

原版GRUB4DOS再测试，手工加载：
root (hd0,1)
ls
分区确定正确
chainloader /bootmgr
boot

结果一样发生故障，借此反馈一下，但不知道GRUB4DOS如何提供资料以排除BUG，过几天机器还给客户的话就没机会找BUG了。

如果可以无视这个BUG，也可以，因为大多数电脑上chainloader /bootmgr还是正常使用的。

[ 本帖最后由 2011131013 于 2012-5-3 15:58 编辑 ]

不点

同意以上各位的分析。

建议做以下测试，或者也算是 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 编辑 ]

2011131013

原帖由 不点 于 2012-5-3 16:33 发表
同意以上各位的分析。

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

1. 建立多个 bootmgr，叫做 bootmgr1、bootmgr2、等等，用 chainloade ...

Windows环境中复制两份bootmgr，命名bootmgr1和bootmgr2

chainloader bootmgr1成功，所以2不用试。

扇区排列也都连续：

1. D:\TDDOWNLOAD>contig -a c:\bootmgr1
   
2. Contig v1.6 - Makes files contiguous
   
3. Copyright (C) 1998-2010 Mark Russinovich
   
4. Sysinternals - www.sysinternals.com
   
5. c:\bootmgr1 is defragmented
   
6. Summary:
   
7.      Number of files processed   : 1
   
8.      Average fragmentation       : 1 frags/file
   
9. D:\TDDOWNLOAD>contig -a c:\bootmgr
   
10. Contig v1.6 - Makes files contiguous
    
11. Copyright (C) 1998-2010 Mark Russinovich
    
12. Sysinternals - www.sysinternals.com
    
13. c:\bootmgr is defragmented
    
14. Summary:
    
15.      Number of files processed   : 1
    
16.      Average fragmentation       : 1 frags/file

复制代码

CMP的结果好象是不同，重启再看看结果。

[ 本帖最后由 2011131013 于 2012-5-3 19:47 编辑 ]

roytam1

原帖由 不点 于 2012-5-3 16:33 发表
同意以上各位的分析。

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

1. 建立多个 bootmgr，叫做 bootmgr1、bootmgr2、等等，用 chainloade ...

把 "md5 [file]" 搞出來試試吧(反正已經有MD5的代碼)

2011131013

原帖由 不点 于 2012-5-3 16:33 发表
同意以上各位的分析。

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

1. 建立多个 bootmgr，叫做 bootmgr1、bootmgr2、等等，用 chainloade ...

果然是读取的bug引起，cmp /bootmgr /bootmgr1后的结果：
Differ at the offset 379392: 0x47 [/bootmgr], 0x22 [/bootmgr1]

而这两个文件在windows中的比较是相同的。



BUG已经存在，但能否除去这个BUG就看大湿们的了。

[ 本帖最后由 2011131013 于 2012-5-3 19:50 编辑 ]

不点

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

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

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

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

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

2011131013

原帖由 不点 于 2012-5-3 19:51 发表
问题很严重，连续的文件竟然读错。

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

你可以用 cat --hex /bootmgr 来读扇区，与 Windows 下的 Winhex 读取的扇区进行对照，看看 ...

呵呵，知道，这个BOOTMGR已经是重点保护对象。不过只怕万一操作失误

不过从offset 379392（0x5ca00）上看，出错的扇区应该在文件尾部。0x1--0x2e4扇区读取正确，0x2e5扇区开始错误？（379392=0x5ca00  /0x200=0x2E5）

cat -hex查看后的确从0x5ca00开始读取出错，截了图，但附件大小限制，压缩成不成形都达不到附件要求，所以不上传了。

[ 本帖最后由 2011131013 于 2012-5-3 20:28 编辑 ]

不点

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

2011131013

原帖由 不点 于 2012-5-3 20:39 发表
在 grub4dos 下用 blocklist /bootmgr 列出它的扇区序列，看看是不是正确显示为连续的。

运行结果：16376424 +750

blocklist /bootmgr1的结果：22901416 +750

不点

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

怀疑是 0.4.5 引入的 bug。

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

2011131013

原帖由 不点 于 2012-5-3 20:55 发表
连续的扇区序列，读取应该很简单，怎会出错？

怀疑是 0.4.5 引入的 bug。

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

2楼已经说过，试了很多个版本的grub4dos，包括一个几年前的，都有此问题。所以应该是一个很潜在的bug，用了这么久的chainloader，也是第一次遇到这个错误。

[ 本帖最后由 2011131013 于 2012-5-3 21:10 编辑 ]

不点

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

你记住这事，通知 chenall。

2011131013

原帖由 不点 于 2012-5-3 21:16 发表
看来真的是旧代码中早已存在的 bug 了。等待解决。

你记住这事，通知 chenall。

也只有这两天稍有时间，两天后可能就要绝网一星期了。客户的机器，也未定几时过来拿
如果不能及时排除BUG，可以当成极少的个例，不当BUG看待；也可能留下一个存在BUG的阴影。

不点

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

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

2011131013

原帖由 不点 于 2012-5-3 21:37 发表
你可以把这个盘留下，给客户换个新盘。或者你精确备份这个盘，按扇区备份它。只需精确备份这个 ntfs 分区便可。

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

备份整个分区的所有扇区至另一硬盘不难。不过感觉备份单一分区也许不满足条件。因为该分区并非位于硬盘首，备份的分区在LBA换算后的扇区应该并不相同而造成未必同一故障。

呵呵，看情况吧，有可能的话尽量排除，到时丢失排除条件也没办法了。

不点

你用 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 编辑 ]

fujianabc

原帖由 2011131013 于 2012-5-3 21:54 发表


备份整个分区的所有扇区至另一硬盘不难。不过感觉备份单一分区也许不满足条件。因为该分区并非位于硬盘首，备份的分区在LBA换算后的扇区应该并不相同而造成未必同一故障。

呵呵，看情况吧，有可能的话尽 ...

你可以现在先备份一个分区看看，如果能够重复出问题，就无需备份整个硬盘了。

2011131013

对DD命令用不惯啊，还是希望客户不那么快过来拿的好，呵，希望chenall和bean有时间处理并尽早给出排bug方案。

2011131013

原帖由 fujianabc 于 2012-5-3 22:06 发表

你可以现在先备份一个分区看看，如果能够重复出问题，就无需备份整个硬盘了。

个人理解，chainloader后读取bootmgr也许最终的读取方式还是int13h的ah42h方式读取lba扇区（不知道理解有没有错误），而在转算过程中碰到独有的LBA扇区时才出错，如果这样的话用分区备份的功能我觉得应该不发生同一错误，因为简单的复制bootmgr就已经可以解决问题了。

不点

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

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

最安全的是备份。

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

2011131013

自己编译就真的搞不了了，对我来说真的很难。

问一个问题：blocklist /bootmgr后得到的数据22901416 +750前面部分是指什么？相对本分区的扇区偏移还是相对硬盘0扇区的偏移还是其它？后面的750理解是bootmgr文件占用750扇区，我用gurb4dos一般只用几个常用的命令，很多其它命令都并不熟悉