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版本，同样现象。

2011131013

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

2011131013

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

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

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

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

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

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

2011131013

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

运行结果：16376424 +750

blocklist /bootmgr1的结果：22901416 +750

2011131013

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

怀疑是 0.4.5 引入的 bug。

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

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

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

2011131013

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

你记住这事，通知 chenall。

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

2011131013

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

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

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

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

2011131013

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

2011131013

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

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

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

2011131013

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

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

2011131013

谢两位解释，22901416 +750之前好象的确还有显示(hd0,1)，那就是应该是相对于(hd0,1)的偏移了。

2011131013

原帖由 fujianabc 于 2012-5-4 00:03 发表

那(hd0,1)之前的(hd0,0)多大？怀疑或许bios的int 13也有可能有问题。

也就几百M吧，HP的原引导分区，给我暂时17隐藏了而已，应该不关int13的事，扇区位置更加靠后的bootmgr1都能引导

bootmgr：16376424 +750

bootmgr1：22901416 +750

2011131013

原帖由 fujianabc 于 2012-5-4 00:01 发表
windows下可以用winhex精确按扇区备份整个分区或者硬盘的

备份暂时不予考虑：笔记本，不想拆其硬盘，容量500G（整盘备份的话数据量有些大），手头暂时也无可以腾出来备份的作为USB外设的硬盘。

2011131013

原帖由 不点 于 2012-5-4 00:34 发表
你还真得试试 31 楼所说。

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

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

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

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

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

cat --hex /bootmgr已经做过，的确是不同，cat --hex (hd0,1)16376424 +750等下就试，不过应该也是不同，因为就是这个不同引发的故障，相同了就没故障了。

疑问：
但为什么如果不同的话是bios问题而不是cat问题？
如果是bios问题为什么更靠硬盘后部的bootmgr1可以正常cat而靠前的bootmgr反而cat错误？

2011131013

原帖由 不点 于 2012-5-4 01:13 发表
bios 通常发生极限错误，即，超过某个极限时出错。

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

也许，条件即将丢失，之前的blocklist /bootmgr的结果16376424 +750，现在的结果变成814272+750了，自认为没任何误操作，唯一的可能就是windows7的后台磁盘整理，刚才开着机器没关机，记得windows7会开启自动磁盘整理功能，但没想到本已连续存放bootmgr文件也会移动？

新位置：cat --hex 814272+750后正确，当然cmp /bootmgr /bootmgr1也没有差别了。
仍尝试读取旧位置：cat --hex 16376424+750，还是和以前同一结果，后部分读取出错（不和事实的bootmgr内容相同）。虽文件被移动了，但旧空间内容还在，和我之前用相机照下来的结果相同

查看了下分区表，(hd0,1)的起始扇区位于20498940，旧bootmgr（即未变动位置的出问题的bootmgr）存放位置偏移量16376424，即硬盘20498940+16376424=36875364扇区=17G左右位置，远离可能产生问题的int13的8.4G临界位置，并且bootmgr1也处于17G附近且更靠后位置而不产生问题。所以对于由int13引起的仍存疑问。且当时不由grldr引导而直接由微软的PBR直接引导BOOTMGR可以正常读取并进入系统。

之前对fujianabc说的(hd0,0)才几百M的说法有误，原来之前的空间有10G，即是原本所有的读写操作都在远离8.4G位置

条件即将丢失，有些遗憾，不过对开发者的态度表示很欣慰。

[ 本帖最后由 2011131013 于 2012-5-4 01:42 编辑 ]

2011131013

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

不会用dd命令，不过不点提示的我换了种办法确认，应该用cat --hex一样相同确认才对。

之前的数据计算得到读取错误的扇区位于(hd0,1)偏移16377165扇区处，cat --hex 16377164+2，和我想的一样，首扇区16377164读取正确，正是bootmgr的文件内容，次扇区16377165读取的内容和bootmgr文件不符（该扇区读取的和之前发生错误时相机照下的内容相同）

进U盘XP，用Disk Probe读取该分区的16377164和16377165扇区，两个扇区的内容正确，都属于BOOTMGR的实际内容。用Disk Probe之前先用Winhex，也许在读数据区扇区时winhex以簇为单位读取，在输入扇区号16377165读取时出错，提示16377180扇区I/O错误

个人理解，winhex出现I/O错误提示，GRLDR的读取就有可能不是扇区换算引起的bug了，而是坏道临界现象引起？GRLDR未加以检验而直接读取造成读取出来的内容出错？还有一个现象，cat --hex时，在读及16377165扇区时也的确会有一下较明显的卡顿，如果是坏道临界引起，个人也不再把这种现象归入grub4dos的bug了。至于为什么用ms的pbr可以正确读取（Disk Probe也是ms自家的工具）而grldr无法正确读取这个问题也许更难找出原因了。

再尝试在纯dos下用int13读取扇区36876105（grldr读取的错误扇区的LBA扇区），确认直接int13读取的一样正确，这也就排除了bios的int13问题。

如果是坏道临界引起的问题，我想这个bug不能再称之为bug了，应该可以结贴了。反馈了一个不算bug的bug，抱歉了，承蒙各位关注。

[ 本帖最后由 2011131013 于 2012-5-4 03:24 编辑 ]

2011131013

已经确定坏道引起

grub4dos 也是使用类似的做法

这就清楚为什么ms的pbr可以正确读取而grub4dos会出错了。ms的pbr是以扇区为单位读取引导文件的。

直接在纯dos下读取winhex的提示的I/O错误的扇区36876120，的确是C标志位=Y而无法读取了。

bootmgr存放扇区无坏道，但恰刚好在其最后部分扇区同道的位置存在坏扇区而造成这种现象，呵呵，几率堪比彩票头彩啊

2011131013

原帖由 不点 于 2012-5-4 17:38 发表
修复了，请在时空论坛下载。

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

完美解决：cat --hex 16377164+20后，第二扇区（16377165）不再出现卡顿现象且读取出来的内容正确，在读至事实上的坏扇区（16377180）时，出现ERROR 25: Disk read error后退出。辛苦了！