无忧启动论坛

标题: 请教各位grldr引导pe出现的现象？（已经解决） [打印本页]

作者: 天涯海角1216 时间: 2011-6-3 19:53
标题: 请教各位grldr引导pe出现的现象？（已经解决）
今天用GRLDR启动一个刚分区的 SETUPLDR.BIN ，结果如图提示，但是用XORLDR引导这个 SETUPLDR.BIN 能够正常启动 PE ，何故？
谢谢！

之前用 DISKGEN 建立的扩展分区引导PE出错，用 WINPM 7.0 重新建立该扩展分区，问题解决！

不点兄在17楼找出 DISKGEN 分区错误，引用如下，在此感谢！

原帖由不点于 2011-6-7 23:07 发表
没关系，根据你提供的两个分区表，终于发现 diskgen 的错误了。
你可以向 diskgen 的开发者报告 bug。
由于此处 H=255，S=63 是已知的，所以，无论是 LBA 到 CHS，还是 CHS 到 LBA，转换都很简单。
扩展分区表起始于 LBA=62942670       转换为 C/H/S=3918/0/1
分区 (hd0,4) 起始于 LBA=62942733       转换为 C/H/S=3918/1/1
分区 (hd0,4) 终止于 LBA=188771861       转换为 C/H/S=11750/128/48
由于 C 值超过 1023，所以，忽略 C 值，只考虑 H/S 的转换结果。
diskgen 计算出的 (hd0,4) 的起始 C/H/S=1023/211/1，它应该是 1023/1/1 才算是正确的。
diskgen 计算出的 (hd0,4) 的终止 C/H/S=1023/218/48，它应该是 1023/128/48 才算是正确的。
也就是说，diskgen 计算出的 H 是错误的。
所以，这证实了 bug 是属于 diskgen 的。完毕。

[ 本帖最后由天涯海角1216 于 2011-6-8 06:10 编辑 ]

作者: yjd 时间: 2011-6-3 22:34
扩展分区引导pe应该要用到如下第一种才行吧。。

title 5, Find and load WinPE \n 此方法适合启动主分区和逻辑分区的PE
find --set-root --ignore-floppies --ignore-cd /boot/H3PE/03g4d
map --in-place ()+1 (hd0)
map --hook
chainloader --force /boot/H3PE/03g4d

title 5, Find and load Windows \n 启动逻辑分区windows需修改boot.ini(rdisk(0))为1
find --set-root --ignore-floppies --ignore-cd /ntldr
map ()+1 (hd0)
map (hd0) (hd1)
map --harddrives=2
map --hook
chainloader (hd0,0)/ntldr

title 5, Find and load WinPE \n 此方法适合启动任意主分区上的PE
find --set-root --ignore-floppies --ignore-cd /boot/H3PE/03g4d
map ()+1 (hd0)
map --hook
chainloader --force /boot/H3PE/03g4d

作者: 天涯海角1216 时间: 2011-6-4 08:26
我采用这种方法在前一个硬盘上启动PE成功

title 【11】盛世雄风 WinPE 维护系统
find --set-root /boot/syslinux/IBM.ICO
map +1 (hd0)
chainloader /BOOT/SSXFLDR

作者: yjd 时间: 2011-6-4 09:06

我采用这种方法在前一个硬盘上启动PE成功

title 【11】盛世雄风 WinPE 维护系统
find --set-root /boot/syslinux/IBM.ICO
map +1 (hd0)
chainloader /BOOT/SSXFLDR

逻辑分区应该不行吧？

作者: 天涯海角1216 时间: 2011-6-4 17:15
标题: 回复 #4 yjd 的帖子
这个在前面的硬盘上是能正常启动PE的。

作者: 不点 时间: 2011-6-4 17:39
Error 41 已经说清楚了：扩展分区表有错误。

作者: 天涯海角1216 时间: 2011-6-5 20:53
谢谢，用新版DISKGEN 检测居然说没问题，很郁闷…

作者: 2010fengyun 时间: 2011-6-6 01:52
是否曾经对该硬盘改过分区结构。除了第一次分区和格式化之后。又进行过其他分区类操作。导致某些分区参数的差异。我试着调整过一个分区的大小。并格式化其中一个分区。结果整出来的参数WINHEX里的。和其他没调整的参数在几个核心参数的位置上误差很大。比如我改的是D盘，以前它的MFT位置也是762342，但是改过后的结果它变成了4，而其他清一色是762342，而且扇区号也对不上，我看不出其中的规律，其他的盘EFG都能对上号。这也许就是不同分区工具导致的不同效果。虽然也能正常使用。但是总感觉参数不一致。用一些分区表软件打开也不会报错。

[ 本帖最后由 2010fengyun 于 2011-6-6 01:53 编辑 ]

作者: 天涯海角1216 时间: 2011-6-6 09:09
总觉得这个 diskgen 3.4.5 有问题，其他软件检测这个分区表也有问题，偏偏 diskgen 3.4.5 说没问题！
以前就发现 diskgen 技术不过关，所以一般结合 WINPM 7.0 使用。。。

作者: fujianabc 时间: 2011-6-6 09:42
这就是所谓的"分区不良"。前两年一直用winpm 7.0，不会出分区不良。
不过最近手上有4K的硬盘以及SSD，不能再用winpm 7.0了，那个会对不齐的，现在一直用win7自己的diskpart和磁盘管理器

作者: sgw888 时间: 2011-6-6 09:43
DISKGEN 3。4。5 已经不再检测CHS 错误，可能是CHS参数错误的问题吧。

作者: 天涯海角1216 时间: 2011-6-7 09:45
今天用 PTDD 3.5 和WINPM 7.0重新分区，启动 PE 正常！
这个 DiskGenius 3.4.5.1 还是不行的，呵呵

作者: 不点 时间: 2011-6-7 10:41
你可以把diskgen的扩展分区表以及分区引导扇区上传（总共两个扇区，通常这两个扇区相距 63 扇区），研究一下，看看能否支持 diskgen。

作为对比，你也可以上传 PTDD 和 WinPM 的。

grub4dos 开发之初，是以微软的分区格式为蓝本（把它作为标准），diskgen 有可能创建出更“合理”的分区表和引导扇区，但却与微软的不同。如果确实是这样，那么，diskgen 也应该被支持。

作者: 天涯海角1216 时间: 2011-6-7 13:36
标题: 回复 #13 不点的帖子
不点兄看看，那个分区的PBR没了，被我清零，我看PBR没问题的！
下面是主分区表和扩展分区表。

主分区表.rar

563 Bytes, 下载次数: 28, 下载积分: 无忧币 -2

扩展分区表.rar

140 Bytes, 下载次数: 26, 下载积分: 无忧币 -2

作者: 不点 时间: 2011-6-7 17:37
不行，grub4dos 的仿真代码，需要检测 pbr 的代码（BPB）。你不可以把它清零。

请你上载 PBR。

而且，我主要怀疑的，正是 PBR 中的某些 BPB 域有差异，才导致 diskgen 与 PTDD / WinPM 的不同表现。

你自己也可以比较一下两者有何差异。

作为对比，还需要你上载 PTDD 或者 WinPM 的结果，包括主分区表和扩展分区表以及PBR。

[ 本帖最后由不点于 2011-6-7 17:51 编辑 ]

作者: 天涯海角1216 时间: 2011-6-7 19:21
标题: 回复 #15 不点的帖子
我仔细搜索了，实在对不起，连备份的 PBR 都被我清零了！
没办法出现了，见谅！

作者: 不点 时间: 2011-6-7 23:07
没关系，根据你提供的两个分区表，终于发现 diskgen 的错误了。

你可以向 diskgen 的开发者报告 bug。

由于此处 H=255，S=63 是已知的，所以，无论是 LBA 到 CHS，还是 CHS 到 LBA，转换都很简单。

扩展分区表起始于 LBA=62942670 转换为 C/H/S=3918/0/1
分区 (hd0,4) 起始于 LBA=62942733 转换为 C/H/S=3918/1/1
分区 (hd0,4) 终止于 LBA=188771861 转换为 C/H/S=11750/128/48

由于 C 值超过 1023，所以，忽略 C 值，只考虑 H/S 的转换结果。

diskgen 计算出的 (hd0,4) 的起始 C/H/S=1023/211/1，它应该是 1023/1/1 才算是正确的。
diskgen 计算出的 (hd0,4) 的终止 C/H/S=1023/218/48，它应该是 1023/128/48 才算是正确的。

也就是说，diskgen 计算出的 H 是错误的。

所以，这证实了 bug 是属于 diskgen 的。完毕。

作者: 天涯海角1216 时间: 2011-6-8 06:05
标题: 回复 #17 不点的帖子
非常感谢不点兄，高手就是高手。
以前的硬盘是用XP自带的磁盘管理分区的，就这个新硬盘才用 DISKGEN 分区，果真是它的错误，看样子以后用 PTDD 和 WINPM 结合分区才安全啊

作者: freesoft00 时间: 2011-6-8 12:41
我在diskgen论坛发了这个问题，作者的回复：

请问你能重现这个问题吗？
使用的DiskGenius是DOS版还是Windows版？
DiskGenius检测到的硬盘参数是否正确？

作者: 天涯海角1216 时间: 2011-6-8 14:02
这个不想再做了，以后遇到再说吧，呵呵

作者: 不点 时间: 2011-6-8 17:03
标题: 回复 #19 freesoft00 的帖子
重现问题？根本不用重现。天涯海角1216 活生生地截取了 diskgen 创建的分区表，有此一例，即可证明。只要研究14楼的两个分区表以及核实17楼的计算无误，就能证明 diskgen 有问题了。一旦核实了，解决它则是很容易的一个问题了。

作者: 不才 时间: 2011-6-9 20:40

原帖由 天涯海角1216 于 2011-6-8 14:02 发表
这个不想再做了，以后遇到再说吧，呵呵

嘿嘿，请就图中圈定问题作答。谢谢！

36.png (5.98 KB, 下载次数: 123)

作者: 不点 时间: 2011-6-10 06:07
如果磁头数确实是 240，那么 diskgen 的计算是准确的。

DOS 下的软件，使用 int13 所获得的 CHS 是准确的。这与 U 盘的情况一样，CHS 的值随主板的不同而变化。所以，你在这块主板上使用这个硬盘，与在另外一块主板上使用同一个硬盘，其CHS参数有可能不同。

初步怀疑，天涯海角的主板是故意捣乱的。磁头数不该是 240，而应该是 255。如果磁头数搞成 240，那么 DOS 下用 CHS 模式可访问的磁盘容量就要少了，某些 DOS 软件不使用 LBA，而只使用 CHS。

天涯海角可以做一个测试，在同一个机器上，用 Win98 的 Fdisk 在实模式的 DOS 下分区，看看分区表是否为 H＝240。如果确实是 240，就证明 diskgen 没错。如果不是 240，就证明 diskgen 有错（因为微软的是标准，即使微软错了，也得与微软的一致，不一致的，都算是错的）。

＝＝＝＝＝＝＝＝＝

还有一个疑问：天涯海角是如何格式化 (hd0,4) 的？因为 (hd0,4) 的 BPB 中显示 H＝255，因此，怀疑执行 (hd0,4) 格式化的，是另外一个软件，而不是 diskgen。或者虽然也是 diskgen，但可能是在保护模式的 Windows 下操作，无法获得实模式的 H＝240 的信息。

＝＝＝＝＝＝＝＝＝

再补充：grub4dos 下用 geometry --tune 可以获得真实的 CHS 参数。

安装 fbinst 到这个硬盘，并用 fbinst 启动，也能获得准确的 CHS 参数。

[ 本帖最后由不点于 2011-6-10 06:13 编辑 ]

作者: 天涯海角1216 时间: 2011-6-10 10:12
标题: 回复 #23 不点的帖子
我的主板是 IBM X32，是 intel i855PM 主板，我是在PE 下用 DISKGEN 分区后，用PE的磁盘管理格式化的。

因为硬盘装了很多文件，所以就不想再重新分区格式化测试了。。。
以后遇到问题，再反馈吧。。。

作者: freesoft00 时间: 2011-6-10 15:12
diskgenius更新了
http://bbs.wuyou.net/forum.php?m ... &extra=page%3D1

作者: 不点 时间: 2011-6-10 17:10

原帖由 天涯海角1216 于 2011-6-10 10:12 发表
我的主板是 IBM X32，是 intel i855PM 主板，我是在PE 下用 DISKGEN 分区后，用PE的磁盘管理格式化的。

因为硬盘装了很多文件，所以就不想再重新分区格式化测试了。。。
以后遇到问题，再反馈吧。。。

你在 Windows （PE 也是保护模式，相当于 Windows）下使用 diskgen，此时，通常 diskgen 不容易找到 BIOS 所使用的几何参数。

那就不知道 diskgen 是如何把 240 作为 H 的了。

PE 自己的格式化程序，如果贸然用 H=255 去格式化硬盘分区，这也是不对的，你就是遇到了这种情况。就是说，240 和 255，必然有一个是错的。究竟谁错，这还不能确定。但是，你只要在 grub4dos 下使用 geometry --tune 来显示磁盘几何参数，谜底就可揭晓了。不需要你进行重新分区和格式化的动作。

作者: 不点 时间: 2011-6-10 17:17

原帖由 freesoft00 于 2011-6-10 15:12 发表
diskgenius更新了
http://bbs.wuyou.net/forum.php?mod=viewthread&tid=195142&extra=page%3D1

更新的内容好像与这里所讨论的话题无关。

作者: 天涯海角1216 时间: 2011-6-10 21:13
标题: 回复 #27 不点的帖子
我用这个怎么没反应呢？谢谢
title 【D】 geometry --tune
geometry --tune (hd0)

作者: 不点 时间: 2011-6-10 21:16
命令行执行吧。放在菜单里，显示的信息一闪而过，你能看清吗？要是你用 debug off 的话，还可能根本就不显示信息了呢。

[ 本帖最后由不点于 2011-6-10 21:18 编辑 ]

作者: 天涯海角1216 时间: 2011-6-10 21:30
标题: 回复 #29 不点的帖子
不点兄看看：

作者: 不点 时间: 2011-6-10 22:14
按照 grub4dos 的 tune 的逻辑来解释，这似乎表明，从分区表以及其他途径（int13／ah＝8）所获得的 H 为 240。但这是错误的，被 geometry_tune 功能修正为正确的 255。

这就证明了 PE 的判断是没错的。diskgen 采用 240 是错误的。

但是，diskgen 之所以采用一个错误的 H 值，也可能是有原因的。假如 diskgen 能够获得实模式下 int13／ah＝8 的返回值，则 diskgen 有可能被 int13／ah＝8 误导。也就是说，int13／ah＝8 有可能返回 H＝240 这个错误的值，从而让 diskgen 犯错。这原因不是diskgen 造成的，而是由 BIOS 造成的。具体情况究竟是怎样的，还需要你动用 debug 之类的简单汇编来确定 int13／ah＝8 的返回值。请你自己学习 debug 来做这件事。（你也可以让 chenall 为你写一个 grub4dos 的命令来自动替你做这事，如果 chenall 能够做并且愿意做的话）。

如果不是这样，而是由于 diskgen 用别的手段得到了 H＝240 这个错误的值，那么 diskgen 应该负有主要责任。

一般可以认为，硬盘不可能具有不同于 H＝255，S＝63 的其他几何参数，因为那很明显没有任何好处，只能算是故意添乱的一个行为。

grub4dos 能够把 240 纠正为 255，我相信这个纠正的动作是工作正常的。如果纠正为别的值，那倒是不太可信，而纠正为 255，则大大增加了可信度。

－－－－－－－－－－－－

不对！我被你骗了。你用的是 qemu 来做这个硬盘的“主板BIOS”，得到的结果不是真实的。请你用真实机器来做，不要用虚拟机。

[ 本帖最后由不点于 2011-6-10 22:29 编辑 ]

作者: 天涯海角1216 时间: 2011-6-11 06:54
标题: 回复 #31 不点的帖子
实在对不起，我不是故意的，不点兄见谅。
手头没相机，我抄下给你看看：
drive 0x80(LBA): C/H/S=1024/240/63 , Sector Count/Size=188848800/512

谢谢！

作者: 不点 时间: 2011-6-11 07:20
你确信使用了 --tune 参数了吗？如果是的，那么这证明 diskgen 是正确的，而 WinPE 的 H＝255 是错误的。

谢谢。

接下来，就要针对这种情况，修正 grub4dos 了，让 grub4dos 的 probe_mbr 能够适应这个 H＝240 的情况。

－－－－－－－－－－－

顺便说，你上次贴图使用的 grub4dos 是 2010 年的版本，距今有一年了。那是不行的。karyonix 曾经为 geometry_tune 打过补丁，而你那个 2010 年的版本，有可能还没有打上 karyonix 的补丁。

[ 本帖最后由不点于 2011-6-11 07:28 编辑 ]

作者: 天涯海角1216 时间: 2011-6-11 07:45
标题: 回复 #33 不点的帖子
好的！
我再用新版的 grub4dos 试试，我确认用了 --tune ！
谢谢

作者: 天涯海角1216 时间: 2011-6-11 07:51
我用了 2011.05.23版本，且用了 --tune ，还是一样的显示：

drive 0x80(LBA): C/H/S=1024/240/63 , Sector Count/Size=188848800/512

下面是这个版本的 grldr

grldr.rar

136.38 KB, 下载次数: 30, 下载积分: 无忧币 -2

作者: 不点 时间: 2011-6-11 10:10
好了，已经证明 diskgen 没问题。接下来是要修复 grub4dos 了。慢慢来，不着急。

作者: zhaohj 时间: 2011-6-11 11:02
我记得IBM笔记本都是drive 0x80(LBA): C/H/S=1024/240/63，H=240是IBM专利，在其他机器上没看到过。

作者: 2011ytf4425 时间: 2011-7-7 10:16
我也遇到过这样的问题，你的PE是老毛桃的吧，把iso全部解压拷贝到优盘根目录（setup可以不要），进入wxpe，把里面所有文件剪切到优盘根目录，再把setupldr.bin改名为MTLDR（注意没有扩展名），再在menu.lst中加上

title WinPE
find --set-root /MTLDR
chainloader /MTLDR

复制代码

保存。
以后就可以选择winpe启动了

作者: jzyjjp 时间: 2011-7-26 08:37
我在winxp系统下用DiskGenius v3.5.0软件来恢复已被删除的文件，在搜索进度到95%时该程序没反应了。再试还是如此。不知道是不是我人品有问题

欢迎光临无忧启动论坛 (http://bbs.wuyou.net./)