无忧启动论坛

标题: grldr引导bootmgr后出现“Bootmgr image is corrupt. The system cannot boot” [打印本页]
作者: 2011131013    时间: 2012-5-3 14:43
标题: grldr引导bootmgr后出现“Bootmgr image is corrupt. The system cannot boot”
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    时间: 2012-5-3 14:49
个人理解：GRLDR的chainloader /bootmgr读取BOOTMGR文件方式存在BUG，造成读取出来的内容有错，因为出现这个错误提示。
如果理解有错，希望指教
尝试过多个GRUB版本，同样现象。
作者: sratlf    时间: 2012-5-3 14:56
bootmgr在哪个分区
作者: 2011131013    时间: 2012-5-3 15:02
标题: 回复 #4 sratlf 的帖子
呵呵，当然在活动分区上了(hd0,1)
作者: fujianabc    时间: 2012-5-3 15:13
有一定可能是grub4dos的ntfs读取存在bug。
作者: xiaoy    时间: 2012-5-3 15:16
我一直都用这个方法启动BOOTMGR 没有发现不妥
作者: 2011131013    时间: 2012-5-3 15:28
原帖由 xiaoy 于 2012-5-3 15:16 发表
我一直都用这个方法启动BOOTMGR 没有发现不妥


这个方法当然是正确的，并且一般都是正常使用的，现在说的是个例
一些小BUG当然只有极少部分电脑才会发生。
作者: sratlf    时间: 2012-5-3 15:31
标题: 回复 #4 2011131013 的帖子
试试将mbr改为grub4dos  然后chainloader /bootmgr
作者: 2011131013    时间: 2012-5-3 15:34
原帖由 sratlf 于 2012-5-3 15:31 发表
试试将mbr改为grub4dos  然后chainloader /bootmgr


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

当然，如果版主认为MBR方式和PBR方式有区别的话我当然试一下。
作者: 2011131013    时间: 2012-5-3 15:41
原帖由 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 编辑 ]
作者: 不点    时间: 2012-5-3 16:33
同意以上各位的分析。

建议做以下测试，或者也算是 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 19:30
原帖由 不点 于 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 19:31
原帖由 不点 于 2012-5-3 16:33 发表
同意以上各位的分析。

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

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

把 "md5 [file]" 搞出來試試吧(反正已經有MD5的代碼)
作者: 2011131013    时间: 2012-5-3 19:44
原帖由 不点 于 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 编辑 ]
作者: 不点    时间: 2012-5-3 19:51
问题很严重，连续的文件竟然读错。

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

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

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

请保护好你的 bootmgr 文件，不要删除它，也不要移动它，只等 chenall 或 bean 来解决。
作者: 2011131013    时间: 2012-5-3 19:54
原帖由 不点 于 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 编辑 ]
作者: 不点    时间: 2012-5-3 20:39
在 grub4dos 下用 blocklist /bootmgr 列出它的扇区序列，看看是不是正确显示为连续的。
作者: 2011131013    时间: 2012-5-3 20:43
原帖由 不点 于 2012-5-3 20:39 发表
在 grub4dos 下用 blocklist /bootmgr 列出它的扇区序列，看看是不是正确显示为连续的。


运行结果：16376424 +750

blocklist /bootmgr1的结果：22901416 +750
作者: 不点    时间: 2012-5-3 20:55
连续的扇区序列，读取应该很简单，怎会出错？

怀疑是 0.4.5 引入的 bug。

试试老的 0.4.4 系列的 grldr，看看有无问题。
作者: 2011131013    时间: 2012-5-3 21:05
原帖由 不点 于 2012-5-3 20:55 发表
连续的扇区序列，读取应该很简单，怎会出错？

怀疑是 0.4.5 引入的 bug。

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


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

[ 本帖最后由 2011131013 于 2012-5-3 21:10 编辑 ]
作者: 不点    时间: 2012-5-3 21:16
看来真的是旧代码中早已存在的 bug 了。等待解决。

你记住这事，通知 chenall。
作者: 2011131013    时间: 2012-5-3 21:21
原帖由 不点 于 2012-5-3 21:16 发表
看来真的是旧代码中早已存在的 bug 了。等待解决。

你记住这事，通知 chenall。


也只有这两天稍有时间，两天后可能就要绝网一星期了。客户的机器，也未定几时过来拿
如果不能及时排除BUG，可以当成极少的个例，不当BUG看待；也可能留下一个存在BUG的阴影。
作者: 不点    时间: 2012-5-3 21:37
你可以把这个盘留下，给客户换个新盘。或者你精确备份这个盘，按扇区备份它。只需精确备份这个 ntfs 分区便可。

如果不方便，那就放弃也罢。
作者: 2011131013    时间: 2012-5-3 21:54
原帖由 不点 于 2012-5-3 21:37 发表
你可以把这个盘留下，给客户换个新盘。或者你精确备份这个盘，按扇区备份它。只需精确备份这个 ntfs 分区便可。

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


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

呵呵，看情况吧，有可能的话尽量排除，到时丢失排除条件也没办法了。
作者: 不点    时间: 2012-5-3 22:04
你用 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    时间: 2012-5-3 22:06
原帖由 2011131013 于 2012-5-3 21:54 发表


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

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

你可以现在先备份一个分区看看，如果能够重复出问题，就无需备份整个硬盘了。
作者: 2011131013    时间: 2012-5-3 22:12
标题: 回复 #25 不点 的帖子
对DD命令用不惯啊，还是希望客户不那么快过来拿的好，呵，希望chenall和bean有时间处理并尽早给出排bug方案。
作者: 2011131013    时间: 2012-5-3 22:21
原帖由 fujianabc 于 2012-5-3 22:06 发表

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


个人理解，chainloader后读取bootmgr也许最终的读取方式还是int13h的ah42h方式读取lba扇区（不知道理解有没有错误），而在转算过程中碰到独有的LBA扇区时才出错，如果这样的话用分区备份的功能我觉得应该不发生同一错误，因为简单的复制bootmgr就已经可以解决问题了。
作者: 不点    时间: 2012-5-3 22:22
bean 很久都没露面了，估计是没时间来。bean 的 burg 也有很长时间没更新了。

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

最安全的是备份。

当然，你也可以自己编译，加入调试输出，自己定位 bug。这应该也不是很难。
作者: 2011131013    时间: 2012-5-3 22:33
标题: 回复 #29 不点 的帖子
自己编译就真的搞不了了，对我来说真的很难。

问一个问题：blocklist /bootmgr后得到的数据22901416 +750前面部分是指什么？相对本分区的扇区偏移还是相对硬盘0扇区的偏移还是其它？后面的750理解是bootmgr文件占用750扇区，我用gurb4dos一般只用几个常用的命令，很多其它命令都并不熟悉
作者: 不点    时间: 2012-5-3 23:31
好像是相对于分区开头的扇区偏移。

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

chainloader (hd0,Y)22901416+750 也应该可以启动它。
作者: fujianabc    时间: 2012-5-3 23:56
原帖由 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个扇区
作者: 2011131013    时间: 2012-5-4 00:01
谢两位解释，22901416 +750之前好象的确还有显示(hd0,1)，那就是应该是相对于(hd0,1)的偏移了。
作者: fujianabc    时间: 2012-5-4 00:01
windows下可以用winhex精确按扇区备份整个分区或者硬盘的
作者: fujianabc    时间: 2012-5-4 00:03
原帖由 2011131013 于 2012-5-4 00:01 发表
谢两位解释，22901416 +750之前好象的确还有显示(hd0,1)，那就是应该是相对于(hd0,1)的偏移了。

那(hd0,1)之前的(hd0,0)多大？怀疑或许bios的int 13也有可能有问题。
作者: 2011131013    时间: 2012-5-4 00:07
原帖由 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    时间: 2012-5-4 00:11
原帖由 fujianabc 于 2012-5-4 00:01 发表
windows下可以用winhex精确按扇区备份整个分区或者硬盘的


备份暂时不予考虑：笔记本，不想拆其硬盘，容量500G（整盘备份的话数据量有些大），手头暂时也无可以腾出来备份的作为USB外设的硬盘。
作者: 不点    时间: 2012-5-4 00:34
你还真得试试 31 楼所说。

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

如果不一样，则问题确实出在 int13 上，即，BIOS 的错。
作者: 2011131013    时间: 2012-5-4 00:58
原帖由 不点 于 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错误？
作者: 不点    时间: 2012-5-4 01:13
bios 通常发生极限错误，即，超过某个极限时出错。

但也有可能在临近某个特殊的位置时发生错误，比如，靠近 8.4G 附近。一切皆有可能。比如，有可能是 grub4dos 自己在 8.4G 附近出错。这都需要有证据，有验证。而你，正好可以验证这些猜想。
作者: 2011131013    时间: 2012-5-4 01:34
原帖由 不点 于 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 编辑 ]
作者: 不点    时间: 2012-5-4 01:45
你可以用 grub4dos 的 dd 命令把 16376424+750 复制到某个文件中。再进入 Windows 比较这个文件与 Winhex 显示的绝对磁盘扇区 16376424+750 是否一致。如果不相同，就证明 grub4dos 的读操作含有 bug。
作者: 2011131013    时间: 2012-5-4 02:29
原帖由 不点 于 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 编辑 ]
作者: 不点    时间: 2012-5-4 07:27
谢谢 2011131013，你干得太好了。

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

我同意你的猜测和分析。

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

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

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

你的任务完成了。再次谢谢。
作者: zjzaog    时间: 2012-5-4 08:17
“问题很严重，连续的文件竟然读错。”看见不点大师的这句话时，直觉是：有坏道！看到最后竟然真的很有可能是这个！！

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

[ 本帖最后由 zjzaog 于 2012-5-4 08:21 编辑 ]
作者: 2011131013    时间: 2012-5-4 13:36
标题: 回复 #44 不点 的帖子
已经确定坏道引起
grub4dos 也是使用类似的做法

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

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

bootmgr存放扇区无坏道，但恰刚好在其最后部分扇区同道的位置存在坏扇区而造成这种现象，呵呵，几率堪比彩票头彩啊
作者: 不点    时间: 2012-5-4 17:38
修复了，请在时空论坛下载。

由于变化很大，因此请其他人也广泛测试，看看有无问题。
作者: 2011131013    时间: 2012-5-4 20:02
原帖由 不点 于 2012-5-4 17:38 发表
修复了，请在时空论坛下载。

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


完美解决：cat --hex 16377164+20后，第二扇区（16377165）不再出现卡顿现象且读取出来的内容正确，在读至事实上的坏扇区（16377180）时，出现ERROR 25: Disk read error后退出。辛苦了！
作者: pseudo    时间: 2012-5-4 20:54
5.4grldr遇到问题，4.25正常。
另外，感觉慢多了。

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

54.png (9.52 KB, 下载次数: 139)

54.png
作者: xianglang    时间: 2012-5-5 09:13
原帖由 不点 于 2012-5-4 17:38 发表
修复了，请在时空论坛下载。

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


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

[ 本帖最后由 xianglang 于 2012-5-5 13:47 编辑 ]
作者: xiaoy    时间: 2012-5-5 11:40
我也遇到了同楼上一样的情况，卡在此处不动，没耐心等，换成4.25正常
作者: sunsea    时间: 2012-5-12 18:28
将菜单变成这样试试：
chainloader (hd0,1)/bootmgr
root (hd0,1)
#上面这句是让BOOTMGR认为(hd0,1)是启动分区
boot



欢迎光临 无忧启动论坛 (http://bbs.wuyou.net/) Powered by Discuz! X3.3