改了标题：新版grldr已经完美修复了在某些主板上复制第一分区的bpb到mbr会出现的问题

zjzaog

令人钦佩的修复速度，grub4dos维护人员真是可靠！已经完美解决了这个小问题，

以下问题已成过去。。

【一个重要的问题：我用ud方式启动，使用FbinstTool制作，
在设置U盘的mbr参数：复制第一分区的bpb到mbr之后，在我的电脑上顺利启动到下面的界面，但是只能使用前面大概2MB的东西，2MB之后的所有img都提示错误，我仔细地毯式的试用不同的版本，发现所有在2012年3月26日之前的0.4.5c或b或a都是完全没有问题的，只有26日的0.4.5c版的grldr出现上述问题，还有3月29日不点大师提供的grldr也是一样出现这个问题，在时空那帖zw2312914在114#的这个grldr也是一样出问题，请研究3月26日前后grldr的改变】
附上本人的菜单
timeout 20
default 0
title [0] >>>>> LWS <<<<< \n 搜索并加载本地电脑上的Windows系统
find --set-root --ignore-floppies --ignore-cd /ntldr || find --set-root --ignore-floppies --ignore-cd /bootmgr
map () (hd0)
map (hd0) ()
map --rehook
find --set-root --ignore-floppies --ignore-cd /ntldr || find --set-root --ignore-floppies --ignore-cd /bootmgr
chainloader /ntldr || chainloader /bootmgr
title [1] >>>>> 0PE <<<<< \n 启动“Pseudo”制作的0PE精简维护系统
find --set-root /0PE.ISO
map /0PE.ISO (0xff)
map --hook
chainloader (0xff)
title [2] >>>>> 3PE <<<<< \n 加载“我心如水”修正的2003PE维护系统
find --set-root /T/OP.ISO
map /T/OP.ISO (0xff)
map --hook
chainloader (0xff)
title [3] >>>>> GHO <<<<< \n 经典的备份还原工具，同时也适用于安装系统
map --mem (ud)/TOOLS/GHOST.lzma (fd0)
map --hook
chainloader (fd0)+1
rootnoverify (fd0)
title [4] >>>>> TBI <<<<< \n 优秀的增量备份工具，对MBR进行自动备份和还原
map --mem (ud)/TOOLS/IMAGE.lzma (fd0)
map --hook
chainloader (fd0)+1
rootnoverify (fd0)
title [5] >>>>> DGS <<<<< \n 非常实用的磁盘分区维护与数据还原工具
map --mem (ud)/TOOLS/DGDOS.lzma (fd0)
map --hook
chainloader (fd0)+1
rootnoverify (fd0)
title [6] >>>>> PWD <<<<< \n 万能的清除掉系统密码的工具
map --mem (ud)/TOOLS/PASSWORD.lzma (fd0)
map --hook
chainloader (fd0)+1
rootnoverify (fd0)
title [7] >>>>> KON <<<<< \n 传奇的绕过系统密码进入电脑的工具
map --mem (ud)/TOOLS/KON.lzma (fd0)
map --hook
chainloader (fd0)+1
find --set-root --ignore-floppies --ignore-cd /ntldr || find --set-root --ignore-floppies --ignore-cd /bootmgr
map () (hd0)
map (hd0) ()
map --rehook
rootnoverify (fd0)

[ 本帖最后由 zjzaog 于 2012-4-12 20:49 编辑 ]

不点

很遗憾，你未能提供更多测试结果。

根据提供的这点信息，未能发现代码的任何错误。我也研究了 3 月 26 日的改动，没能发现错误。

怀疑：lzma 的解压代码存在 bug，它不能适应代码的最新变动。

代码的改动本身，并未对 lzma 的解压部分造成任何影响（可以说是完全无关的）。怀疑是由于 lzma 解压部分存在 bug，所以才出问题的。

请进一步测试和定位 bug。最近身体不好，因此不一定能够经常上网答复，见谅。

zjzaog

谢谢不点大师的回复，
我在把lzma放进ud的过程中，最先放进去的lzma（小于2MB）能够正常的启动，后面拖放进去的lzma就不行。我测试过，比如我先放进去password.lzma,后放进去diskgen.lzma，则password能正常启动而diskgen则不能；而顺序反过来放进去，则diskgen能启动，password不能启动！！很奇怪，而且先放进去kon.lzma，再放进去password，最后放进去diskgen.lzma，则kon和password能正常启动，而diskgen则不能。放很多lzma进去也一样。
另外：可能复制第一分区的bpb到mbr在不同的主板上会结果不一样，我在另一台电脑上启动则一切正常，所以也有可能是我电脑的主板问题，不过我电脑的主板在用3-26之前的所有grldr又是正常启动的，，，，，

我再去试试把lzma改成img看看

================================
测试结果，使用img文件的加载的结果与上面一样有问题，

[ 本帖最后由 zjzaog 于 2012-4-11 22:11 编辑 ]

不点

待更多失败报告以后才能确定问题的根源。目前暂时不知道原因。

暂时搁置起来。

EDIT：

找到了一个毛病，新版上载到时空论坛。应该解决了。

EDIT 2：

时空已经被攻击，无法访问。因此上载在这里，作为备份。

EDIT 3：

今天（ 12 日）上载的版本，与 11 日的版本完全相同，只是添加了 ChangeLog 的记录，方便 Roy 或 chenall 提交到 SVN。

由于解决了 26 日引入的 bug，因此有必要尽快提交到 SVN。请 chenall 和 Roy 留意。别忘了同时也要修补 0.4.6a。

[ 本帖最后由 不点 于 2012-4-12 19:57 编辑 ]

zjzaog

感谢不点大师的完美修复，测试了后一切都搞定，谢谢您的辛苦付出

不点

无论如何，这个问题解决了，这是一件好事。

产生问题的原因是，我在3月26日的补丁含有一个极其隐蔽的漏洞。这个漏洞导致从 ud 得到的可靠 CHS 被替换为不可靠的 BPB 表里面的 CHS（位于内存 0x7C00 处），因而导致访问设备失败。

我体会到，像这样隐蔽的漏洞，是很难避免的。写程序的人，不容易照顾得太周全，所以很难避免发生错漏。

如果没有 zjzaog 的报告，这个问题可能会潜藏很久很久。

所以，zjzaog 的报告是十分珍贵的。尤其是，在错误出现之后不久就被发现并报告，这也是难得的。

报告者采用 “地毯式” 轰炸，逐一排除，找到产生错误的确切日期，这一点也是值得称道的。

你做得很棒。

如果像你这样的用户多了起来，那么我相信 grub4dos 将会获得更加迅猛的发展。

如果光有开发人员，那是不行的。软件需要用户。

世界是普遍联系的。开发人员需要用户的参与，需要用户的热情支持。如果没有用户的热情支持，那么开发者开发出来的产品就可能与用户的使用产生某种程度的 “脱节”。这种脱节反过来也影响开发的进度：用户少，报告问题者少，这当然影响开发的速度和质量。

万幸 grub4dos 目前似乎处于良性循环的状态。我想，不仅开发人员要珍惜它，而且用户也要珍惜它。珍惜这来之不易的美好时光。

开发人员要付出您的爱，用户也要付出您的爱。用爱来共同缔造的东西，用爱来共同维护的东西，那应该有着强大的生命力，那应该是难以被摧毁的，那也应该是不可战胜的、无坚不摧的。

zjzaog

cheers,为了坚不可摧的爱

rroo

原帖由 不点 于 2012-4-13 23:49 发表
无论如何，这个问题解决了，这是一件好事。

产生问题的原因是，我在3月26日的补丁含有一个极其隐蔽的漏洞。这个漏洞导致从 ud 得到的可靠 CHS 被替换为不可靠的 BPB 表里面的 CHS（位于内存 0x7C00 处），因 ...

呵呵！！！关健是有不点大师的兢兢业业的精神，才会发现问题，解决问题呀！！