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？

sunsea

将菜单变成这样试试：
chainloader (hd0,1)/bootmgr
root (hd0,1)
#上面这句是让BOOTMGR认为(hd0,1)是启动分区
boot

xiaoy

我也遇到了同楼上一样的情况，卡在此处不动，没耐心等，换成4.25正常

xianglang

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

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

在我的上网本上实机测试，停在 Starting cmain()... 处就没有了下文（等了一分钟多），而2012-04-24的版本正常。上网本是N270的CPU，西数160GB硬盘，分了三个都是主分区的分区，将WEE装到MBR来调用G4D进行启动。

[ 本帖最后由 xianglang 于 2012-5-5 13:47 编辑 ]

pseudo

5.4grldr遇到问题，4.25正常。
另外，感觉慢多了。

[ 本帖最后由 pseudo 于 2012-5-4 20:56 编辑 ]

2011131013

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

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

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

不点

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

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

2011131013

已经确定坏道引起

grub4dos 也是使用类似的做法

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

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

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

zjzaog

“问题很严重，连续的文件竟然读错。”看见不点大师的这句话时，直觉是：有坏道！看到最后竟然真的很有可能是这个！！

楼主很友善，开发者很积极

[ 本帖最后由 zjzaog 于 2012-5-4 08:21 编辑 ]

不点

谢谢 2011131013，你干得太好了。

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

我同意你的猜测和分析。

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

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

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

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

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

不点

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

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

不点

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

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

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错误？

不点

你还真得试试 31 楼所说。

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

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

2011131013

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

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

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

fujianabc

原帖由 2011131013 于 2012-5-4 00:01 发表
谢两位解释，22901416 +750之前好象的确还有显示(hd0,1)，那就是应该是相对于(hd0,1)的偏移了。

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

fujianabc

windows下可以用winhex精确按扇区备份整个分区或者硬盘的

2011131013

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

fujianabc

原帖由 2011131013 于 2012-5-3 22:33 发表
自己编译就真的搞不了了，对我来说真的很难。

问一个问题：blocklist /bootmgr后得到的数据22901416 +750前面部分是指什么？相对本分区的扇区偏移还是相对硬盘0扇区的偏移还是其它？后面的750理解是bootmgr文 ...

举个例子:
(hd0)100+200是相对于硬盘第0扇区后100个扇区开始读取200个扇区，如果是(hd0,1)100+200就是相对于(hd0,1)分区的第零扇区后100个扇区开始读取200个扇区

不点

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

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

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

2011131013

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

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

不点

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

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

最安全的是备份。

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

2011131013

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

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

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

2011131013

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

fujianabc

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


备份整个分区的所有扇区至另一硬盘不难。不过感觉备份单一分区也许不满足条件。因为该分区并非位于硬盘首，备份的分区在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 编辑 ]

2011131013

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

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

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

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