请教各位grldr引导pe出现的现象？（已经解决）

天涯海角1216

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

jzyjjp

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

2011ytf4425

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

1. title WinPE
   
2. find --set-root /MTLDR
   
3. chainloader /MTLDR

复制代码

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

zhaohj

我记得IBM笔记本都是drive 0x80(LBA): C/H/S=1024/240/63，H=240是IBM专利，在其他机器上没看到过。

不点

好了，已经证明 diskgen 没问题。接下来是要修复 grub4dos 了。慢慢来，不着急。

天涯海角1216

我用了 2011.05.23版本，且用了 --tune ，还是一样的显示：

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

下面是这个版本的 grldr

天涯海角1216

好的！
我再用新版的 grub4dos 试试，我确认用了 --tune ！
谢谢

不点

你确信使用了 --tune 参数了吗？如果是的，那么这证明 diskgen 是正确的，而 WinPE 的 H＝255 是错误的。

谢谢。

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

－－－－－－－－－－－

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

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

天涯海角1216

实在对不起，我不是故意的，不点兄见谅。
手头没相机，我抄下给你看看：
drive 0x80(LBA): C/H/S=1024/240/63 , Sector Count/Size=188848800/512

谢谢！

不点

按照 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

不点兄看看：

不点

命令行执行吧。放在菜单里，显示的信息一闪而过，你能看清吗？要是你用 debug off 的话，还可能根本就不显示信息了呢。

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

天涯海角1216

我用这个怎么没反应呢？谢谢
title 【D】  geometry --tune
geometry --tune (hd0)

不点

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

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

不点

原帖由 天涯海角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 来显示磁盘几何参数，谜底就可揭晓了。不需要你进行重新分区和格式化的动作。

freesoft00

diskgenius更新了
http://bbs.wuyou.net/forum.php?m ... &extra=page%3D1

天涯海角1216

我的主板是 IBM X32， 是 intel i855PM 主板，我是在PE 下用 DISKGEN 分区后，用PE的磁盘管理格式化的。

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

不点

如果磁头数确实是 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-8 14:02 发表
这个不想再做了，以后遇到再说吧，呵呵

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

不点

重现问题？根本不用重现。天涯海角1216 活生生地截取了 diskgen 创建的分区表，有此一例，即可证明。只要研究14楼的两个分区表以及核实17楼的计算无误，就能证明 diskgen 有问题了。一旦核实了，解决它则是很容易的一个问题了。

天涯海角1216

这个不想再做了，以后遇到再说吧，呵呵

freesoft00

我在diskgen论坛发了这个问题，作者的回复：

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

天涯海角1216

非常感谢不点兄，高手就是高手。
以前的硬盘是用XP自带的磁盘管理分区的，就这个新硬盘才用 DISKGEN 分区，果真是它的错误，看样子以后用 PTDD 和 WINPM 结合分区才安全啊

不点

没关系，根据你提供的两个分区表，终于发现 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

我仔细搜索了，实在对不起，连备份的 PBR 都被我清零了！
没办法出现了，见谅！

不点

不行，grub4dos 的仿真代码，需要检测 pbr 的代码（BPB）。你不可以把它清零。

请你上载 PBR。

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

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

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

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

天涯海角1216

不点 兄看看，那个分区的PBR没了，被我清零，我看PBR没问题的！
下面是主分区表和扩展分区表。

不点

你可以把diskgen的扩展分区表以及分区引导扇区上传（总共两个扇区，通常这两个扇区相距 63 扇区），研究一下，看看能否支持 diskgen。

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

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

天涯海角1216

今天用 PTDD 3.5 和WINPM 7.0重新分区，启动 PE 正常！
这个 DiskGenius 3.4.5.1 还是不行的，呵呵

sgw888

DISKGEN 3。4。5 已经不再检测CHS 错误，可能是CHS参数错误的问题吧。