A new branch of 0PE

pseudo

从程序逻辑上我没看出问题。
如果是chkpci卡死，那属于g4d及其外部命令的事。
这种情况得靠更换版本解决，pe方面无从改进。

可以试试统一PE（5月2日的1.2.6版加8月9日的补丁），没准那时的版本不卡。

另外，如果您能跟踪到哪一步，请设法提取.com文件，以便检查其内置的id文本是否合法。
如果不合法，卡死可以理解。那属于可以改进的地方。
不过，要提取文件得费点脑筋，我还没想到简单方法。
您可加49405566，报无忧id以便联系。

pseudo

我笔记本用无线鼠标没问题。无线鼠标是插usb接口吧，这个要先接上再进pe才认。

硬盘bootmgr -> BCD -> grldr.mbr-> grldr -> 0PE.ISO，XPPE卡在NATIVE.LZMA这个我没环境试。
看看其他网友有无类似情形。

话说你不要弄bcd吧。弄个boot.ini文件（没有就自己创建）类似xp那样，里面加一行调用grldr.mbr。
这个对xp、03、7都通用，也可顺便试试xp/03对于grldr.mbr是否卡。
另外可解开iso到某分区根目录并去掉iso，这种摆布方式对你的机器是新的尝试。

pseudo

想起来一些疑点你得排除。
1、你是否用Ultraiso修改或保存过0pe.iso
是则会有问题
2、你用的grldr是否来自0pe.iso里面的
否则其版本、内置菜单不能保证能启动0pe
3、你是否用wincontig工具检查过硬盘上的0pe.iso文件碎片
该文件不要有碎片

pseudo

您对文件碎片概念的理解不对。
可能您没用过wincontig工具，它跟一般整理磁盘碎片的工具（例如defrag）不同，它是用来整理文件而非磁盘碎片的。磁盘有碎片时，某个文件可以连续无碎片；某文件有碎片时，磁盘可以无碎片。
将一个连续的iso文件复制到其它地方，它很可能就变成不连续的了。

iso不连续时，不影响map --mem，而map按理会失败。
问题是，可能grub4dos有bug（不按理），导致map成功（过了初一），而后读取仿真光盘上的某些文件（遇到碎片）失败（过不了十五）。这种bug可能在iso体积非4k整数倍、硬盘文件系统是ntfs或某种格式时爆发。

所以，有必要学会使用wincontig工具。这个工具候选组件或大体积的0pe下载里经常带有，网上也不难搜到下载。

如果将iso拖入ud，那它一般就自然地是连续的了。放在u盘非ud区、放在硬盘则不能保证连续。
总之，就您遇到的问题来说，iso连续问题还是值得检查一下。

pseudo

原帖由 2010yg 于 2012-5-2 23:29 发表
pseudo兄,我在老机上测试,出现加载: 0PE\XP\NATIVE.LZMA, 0PE\2003\NATIVE.LZMA出错,XP,2003两个引导都失败!

于兄也遇到问题，看来真像有问题了。
我把读取native.lzma的过程出错时加点警告信息，可以进一步定位出错点。请用附件试试。

pseudo

那没用，连续的文件复制到别处，很可能变成不连续的。
一对夫妻携手出门，上公共汽车找位置坐下来，座位不一定紧挨着。

关键是对最终要用到的那个位置的那个文件进行整理。

pseudo

原帖由 2010XwX 于 2012-5-3 13:46 发表
测试机器是神州HP860D4笔记本电脑，测试0PE是ZHS509最新增强版0PE_NBv1.4.3(2012-04-25)2in1_290MB(zhs509_H):
1, 按P大建议，首先用wincontig工具检查硬盘上的0pe.iso文件碎片，分析结果无碎片，但为确保连续，又整理了一次。第一次测试，XPPE和2003PE均通过，再测，XPPE又卡在了NATIVE.LZMA，03PE通过，第三次测XPPE仍卡在NATIVE.LZMA，第四次测，XPPE又通过了。
2，把0PE.ISO全解开放在C盘根目录，二次测试XPPE均卡在NATIVE.LZMA，03PE通过。
3, 0PE1.2.6/1.4.1，批处理生成ISO后，我未整理过碎片，但在笔记本电脑上一直运行良好。

这么说，读取xppe的native.lzma有50%的成功率。
另外，2010yg (于山) 兄在#1280楼也曾遇到读取native.lzma报错问题，但后来他发了个帖子：
http://bbs.wuyou.net/forum.php?mod=viewthread&tid=209988&extra=page%3D1
看样子也有成功的时候。

既然有成功不卡的，表明pe本身逻辑没问题。

至于为什么有卡的，那不是pe稳定性问题。有可能是grldr有bug，在特殊环境条件下发作。
这里有个帖子也遇到费解的问题：
http://bbs.wuyou.net/forum.php?mod=viewthread&tid=209983&page=2#pid2433958

原帖由 不点 于 2012-5-3 19:51 发表
问题很严重，连续的文件竟然读错 ...

在那里，cmp比较两个副本竟然不同。

当然现在只是怀疑grldr有bug，尚无足够证据。
但你们的成功经历和grldr存在bug的可能性，已让我比较肯定pe在这方面本身没问题。

您可以把iso移到其它分区根目录（无需动grldr和菜单），最好是移到不同类型分区（例如原来在ntfs分区的，现在移到fat32分区），看看表现是否不同。


这种问题不是普遍性的发作，应该影响有限。估计以后换新版grldr会自然解决。

pseudo

回复 #1297 zjzaog 的帖子、回复 #1296 2010XwX 的帖子

是的，1.4.3有cpynat。但我看了相关代码，无论对错，都没有卡住的道理，除非grub4dos有bug。
前面几楼我还给出一个执行cpynat遇到错误（不该有的错误）会报提示信息的0penb.lzma，可以定位具体在哪里出现意外，可惜没有具体反馈。

前面提到那个帖：
http://bbs.wuyou.net/forum.php?m ... p;page=5#pid2434204
最后原因归结为硬盘有坏道，还不好说g4d有bug。

提示：
启动开始出菜单前有3秒读秒，这时按空格键，估计（绝对）不会出现卡在0penb.lzma的现象。可以验证一下。

pseudo

未收到有无忧id的qq消息

pseudo

卡在native.lzma的网友，请替换附件grldr作简化测试。

如果能重现卡住的现象，就好了。
不卡住就多试几次，争取卡住，并请记录屏幕信息。

不卡的话应该是类似这样的效果：

pseudo

您弄错了。

盘上0pe相关文件应该是两个：
一个grldr，一个0pe.iso，
由grldr引导0pe.iso。
如果不是这样布局，请介绍你的目录文件结构。

确保这个grldr是来自楼上附件。从图看您用的grldr仍是之前的。

[ 本帖最后由 pseudo 于 2012-5-9 22:28 编辑 ]

pseudo

您这个iso有问题，或者有碎片不连续。
请用附件工具对最终要使用的那个位置上的iso进行整理，消除碎片。

pseudo

你的ud最好用附件版本的fbinsttool重新强制格式化一下，再拖入iso。

藏入ud的情形，fbinstool有菜单项整理碎片。

pseudo

确信不会卡住之后，替换ud里的grldr，换回以前的原版grldr看看还卡么。

iso不再动，因为其内grldr此情形下没被用到。

原帖由 chenmaochun 于 2012-5-9 23:21 发表
经过把优盘重新格式化ud区以后，测试了10几次，不会出现卡住，很奇怪，如果是碎片导致的卡住，按了空格键应该不会卡住才对啊，这点我想不明白了！

我预期现在换回原版grldr也不会卡了。

即各种问题现在都消失了，那些都是本来就不该有的问题。

[ 本帖最后由 pseudo 于 2012-5-10 00:07 编辑 ]

pseudo

晕，这么诡异啊。
这里有个52MB的fba，里面有图片，按图直接制作U盘看看。
http://bbs.wuyou.net/forum.php?mod=viewthread&tid=210105

如果出现卡住现象，那么启动时按回车让它出主菜单，然后按C键进入grub命令行手动依次执行
map --mem (bd)/0PE/XP/NATIVE.LZMA (11)
map --hook
ls (11)/
看是否卡住在这几个命令上。我预期不卡，须反复验证数次。

然后再做这个测试：
启动时按回车让它出主菜单，然后按C键进入grub命令行手动执行
(hd-1,0)/BIN/CPYNAT.BAT
预期很有卡住的机会。

如果卡住，应该就是g4d的bug；
如果不卡，仍属诡异。不过可以修改菜单，提前在这个不卡的时候执行读NATIVE.LZMA的操作，绕过这个诡异。


现在想起来这种诡异可能缘于我把map等操作放在批处理里进行，而批处理执行这种操作可能是靠不住的(必须g4d很完美才靠得住)。
只有这样能解释这种诡异。

[ 本帖最后由 pseudo 于 2012-5-10 09:26 编辑 ]

pseudo

回复 #1315 不点 的帖子
谢谢大人指点。
0pe向来拿g4d乱踹。那个用的是批处理里调用批处理，后者有map、rehook等操作。
那么复杂的关系去折腾grldr，要处理好难度可以想见，出点问题也能理解。
暂时绕过它吧。

回复 #1316 chenmaochun 的帖子
这下完全符合我的预期了。
原因是map等操作放在批处理里面执行不可靠，这是g4d的不足。
或者说我透支了g4d的能力，导致g4d不稳定。

现在好办了，稍后我给出一个补丁，绕过此问题。

pseudo

那样也可以。

建议这样：
ud放来自0PE_NBv1.4.3(2012-04-25)2in1_150MB.7z
的grldr和0pe.iso两个文件。再把候选组件解开放入ud。

即候选组件不必加入0pe.iso，放在ud内iso外即可。在开始菜单点petools即可见候选外置工具。

候选组件的增减很随意。其体积不影响启动速度，不占启动内存。

pseudo

这种键盘失灵现象是特定硬件环境所致，罕见。
从pe角度无法改进。打bios关于键盘、usb设置的主意，或许能有所改变。

您可以把grldr内置菜单里头一行的
set showmenu=1
改为
set showmenu=0
或者找fba打包的下载（那种已经改过了）。
改过之后就是直入pe不出菜单的（回车才出菜单），那么键盘无效也不影响进pe。

pseudo

换附件0PENB.LZMA、dos.gz预期读native.lzma不卡了，请验证。

这个把map等操作从批处理里面移出到菜单脚本里，绕过批处理的bug。


此外，文件位置有以下调整（请自行调整）：
1、删除文件
SRS\WVBLK64.SY_
SRS\CHKPCIDB.GZ
它们已内置于dos.gz，这样外观更清爽。
2、ntboot.iso位置移动
由
boot\imgs\ntboot.iso
移到
boot\grub\ntboot.iso
这样，boot\imgs目录完全与0pe无关，放哪个分区，iso内还是外都随便，删掉也没事。

ntboot.iso现在跟run放在一起，删掉也不影响pe启动。
但留着有好处，有的非pe菜单项用得着它们。

pseudo

原帖由 chenmaochun 于 2012-5-10 16:53 发表
还是会卡住，崩溃了！

看来RP有问题。不过越来越接近真相，快要解开谜底了。

还需继续定位。
附件有3个文件，分别换来试一下。
这3个文件对操作进行不同程度的简化，读native.lzma卡的可能性逐步提高。

pseudo

辛苦了。
这三个测试主要看Loading /0PE/XP/NATIVE.LZMA...这步能否通过。如果有任何后续显示，无论成败，都表示不卡。测试1已经去掉菜单，不卡的话预期有ok字样提示。

令人惊讶的是三个测试中最简单的测试1也卡在Loading /0PE/XP/NATIVE.LZMA...这步无后续显示。
对此我有点不敢相信，因为这个情形跟上回您进菜单后按c进命令行直接发几个命令访问native.lzma相似。您说那样不会卡，而执行功能相当的.bat批处理则卡。
我曾据此认为批处理方式会带来bug，现在看来不用批处理也有卡的。
请确认一下测试1是卡在Loading /0PE/XP/NATIVE.LZMA...这步，真的无后续ok显示吗？

果真如此的话，我们得进一步简化，提炼出能重现卡住现象的更简单的一组语句。
附件grldr内置了一个更简单的菜单脚本，请用它替换ud里iso外的grldr，ud里的0pe.iso不要动，这个grldr启动时按不按回车效果都应一样。

一个细节：怎样替换ud里的grldr呢？当拖grldr进ud时，如果ud原有grldr，会提问是否覆盖，当然要覆盖，然后提问是否保留原有菜单，请选不保留。
如果选保留，则只更换了（升级了）grldr的程序版本，没有改变内置菜单。
grldr文件包含两部分内容，前面的内容为程序（不同版本程序部分不同），尾部内容为内置菜单。
0pe的grldr内置菜单比较复杂。

迄今的测试结果，没有证明0pe的处理方面有问题，也没有定位出g4d哪里有bug。
有的都是无法解释、足以让人崩溃的诡异。
我现在很担心这个简化的grldr不卡，即问题不好简化，那才难办。

pseudo

楼上简化的grldr是对测试1的进一步简化。前者都卡，后者就更卡了。

到目前为止，g4d有bug的可能性越来越大。

附件grldr的简化索性一步到位，现在这个内置菜单最简单了，按情理是不该卡的。注意做这个最简测试不用动、不用换iso，只换ud内iso外的grldr。

若它能重现卡的现象就好了。那样从我们的角度，就已经确认找到g4d的bug了。我们的测试结束了。
接下来就得不点、chenall大他们去解决了。请保留ud里的0pe.iso不动，留待他们研究。

如果这个最简单的菜单不卡，反而有点郁闷，要在这两个grldr之间的差异中继续寻找卡的原因。

[ 本帖最后由 pseudo 于 2012-5-11 10:25 编辑 ]

pseudo

难得2010XwX兄弟也有能重现此现象的机器。如果方便，也请测试一下：

iso不动，iso外grldr换#1336楼的看看读native.lzma这步卡不卡，即看
Loading /0PE/XP/NATIVE.LZMA...
这步有无后续显示。

如果卡，因为它的菜单最简，就定论g4d有bug了。
如果不卡（须数次证实），再换#1330楼的试试。
前面chenmaochun兄弟发现#1330楼的会卡。#1330楼的也算比较简单菜单。

pseudo

待反馈的#1336楼的grldr内置菜单最简最纯。
其实#1330楼已经比较简单差不多能说明问题，它没有e820cycles字样。

直感（猜想）可能是这样的问题：
native.lzma体积3465109字节非4kb/2kb/1kb/512字节整数倍，读尾部时若以扇区或块为单位，可能越界（例如超出iso范围），因访问了不适当的地方或找不到预期结尾标志等而卡死。


刚得到#1339楼chenmaochun 网友反馈。总结一下现在情况：
1、部署方式：
用mkisofs生成0pe.iso（体积50mb以上），ud里放入两个文件0pe.iso和grldr，整理ud碎片。
2、在chenmaochun 网友机器上，当ud里iso外的grldr的内置菜单为：

1. 
   
2. echo mapping /0PE.ISO...
   
3. map /0PE.ISO (0xff) || pause Error: Fail to map /0PE.ISO (0xff). && reboot
   
4. map --hook
   
5. rootnoverify (0xff)
   
6. echo Loading /0PE/0PENB.LZMA from %@root%...
   
7. map --mem ()/0PE/0PENB.LZMA (hd)
   
8. map --hook
   
9. echo Loading /0PE/XP/NATIVE.LZMA...
   
10. map --mem /0PE/XP/NATIVE.LZMA (11) || pause Error occurred while loading /0PE/XP/NATIVE.LZMA. && reboot
    
11. map --hook || pause warning:map --hook
    
12. ls (11)/
    
13. pause NATIVE.LZMA is okokokokokokokokok,game over.
    

复制代码

可以看到game over字样。
而当grldr的内置菜单为：

1. 
   
2. terminal console
   
3. debug off
   
4. font
   
5. echo -e \n\nPress a key within 3 seconds:
   
6. echo -e \n\t<Enter>--Show/Hide Menu\n\t<Esc>--Grub4Dos Commandline\n\t<Space>--Load 0PE.ISO into memory entirely\n
   
7. set keyt=
   
8. pause --wait=3 && set /A keyt=*0x4CB00
   
9. if not exist keyt commandline
   
10. checkrange 524:-1 calc *0x413 & 0xffff || map --int15nolow=1 && pause Warnning: less memory
    
11. default 0
    
12. timeout 0
    
13. #0
    
14. title
    
15. echo mapping /0PE.ISO...
    
16. map /0PE.ISO (0xff) || pause Error: Fail to map /0PE.ISO (0xff). && reboot
    
17. map --hook
    
18. rootnoverify (0xff)
    
19. dd if=(md) of=(md) bs=1 count=8 skip=0x829c seek=0x60130
    
20. echo
    
21. echo Loading /0PE/0PENB.LZMA from %@root%...
    
22. map --mem ()/0PE/0PENB.LZMA (hd)
    
23. map --hook
    
24. goto 1
    
25. #1
    
26. title
    
27. dd if=(md) of=(md) bs=1 count=4 skip=0x60130 seek=0x8208
    
28. dd if=(md) of=(md) bs=1 count=4 skip=0x60134 seek=0x8280
    
29. root (bd) || echo -n
    
30. set *
    
31. command --set-path=(hd-1,0)/BIN/
    
32. set XPor03=XP
    
33. echo Loading /0PE/%XPor03%/NATIVE.LZMA...
    
34. map --mem (bd)/0PE/%XPor03%/NATIVE.LZMA (11) || map --mem (0xff)/0PE/%XPor03%/NATIVE.LZMA (11) || pause Error occurred while loading /0PE/%XPor03%/NATIVE.LZMA. && reboot
    
35. map --hook || pause warning:map --hook
    
36. (hd-1,0)/BIN/CPYFILES.BAT (11)/WXPE/SYSTEM32/ (hd-1,0)/WXPE/SYSTEM32/ || pause warning:system32
    
37. (hd-1,0)/BIN/CPYFILES.BAT (11)/WXPE/SYSTEM32/DRIVERS/ (hd-1,0)/WXPE/SYSTEM32/DRIVERS/ || pause warning:drivers
    
38. map --unmap=11 && map --rehook
    
39. pause NATIVE.LZMA is okokokokokokokokok,game over.
    

复制代码

则在出现
Loading /0PE/0PENB.LZMA from (hd127)...
后卡住，无后续显示。

[ 本帖最后由 pseudo 于 2012-5-11 11:18 编辑 ]

pseudo

请chenmaochun再试这个

pseudo

回复 #1341 不点 的帖子、回复 #1342 不点 的帖子
我理解#1339楼的反馈是对#1336楼的反馈；
#1332楼是对#1330楼的反馈。

map --mem /.... (11) || pause Error occured while loading
不在乎失败、失败代码，在于陷进去卡死无反馈。

不过我有个疏忽，就是没有去掉之后的
CPYFILES.BAT行，如果前面过了但卡在这行就冤枉g4d了。
去掉CPYFILES.BAT行的最简菜单并不卡。

#1343楼去掉CPYFILES.BAT 行，看看结果。

pseudo

不好意思，弄了半天，问题看来出在CPYFILES.BAT这行。
先前的现象都可以解释了。

pseudo

CPYFILES.BAT代码：

1. !BAT
   
2. setlocal
   
3. set src=%1
   
4. set dst=%2
   
5. ls %src% | call :loop
   
6. endlocal
   
7. exit
   
8. :loop
   
9. shift
   
10. if "%0"=="" exit
    
11. if /i not "%0"=="FAT" (hd-1,0)/BIN/FAT copy /o %src%%%0 %dst%%%0 > nul || echo -n
    
12. goto :loop

复制代码

看不出会卡死的地方。

疑点是ls %src%结果包含目录名drivers，后面fat copy复制时，执行的是
(hd-1,0)/BIN/FAT copy /o (11)/wxpe/system32/drivers (hd-1,0)/wxpe/system32/drivers
这个本来无论成败逻辑上都无问题，都不会卡。

但是，有的机器在复制对象不是文件而是目录时，就有一定的概率卡死。
印象中，以前不点、chenall遇到过访问pxe服务器端文件menu.lst，当menu.lst不是文件而是目录时，有可能会死掉。
这个相似性似乎可以解释得通。

等会我传个测试文件，把复制目录名情形避过，看看是不是好了。

pseudo

@chenmaochun 、2010XwX
换附件两个文件，但愿不再卡了。

主要变动是避开fat复制目录名。

@不点
fat是有出问题的时候，包括复制文件有时实际已复制成功，却返回失败。
但fat在内存方面的问题，经验上感觉还不到卡住的地步。
看这回测试结果了。

pseudo

谢谢你们做了大量测试，辛苦了。

总结一下：

原因：
开始弄错方向，以为是对native.lzma进行map时卡死，其实是卡在后来的复制操作。
当外部命令fat复制的不是文件而是目录时，按说无论成败都应返回才合理。
但事实上，在少数机器上（不是每台机器），多次启动中有随机地出现（同一台机不是总出现）卡死的现象。
g4d曾经在试图读pxe服务器端menu.lst文件，恰好menu.lst不是文件而是目录名时遇到过类似卡死现象。

对策：
避开复制目录情形，确保复制对象都是文件。

这个问题藏得较深，一般机器上不会出现，出现的机器也不是总出现，显得诡异。

--------------------------------------------------------------------------------------
补充：
尤其03pe也是完全相同操作，却不见报告有卡的现象，更显诡异。

[ 本帖最后由 pseudo 于 2012-5-11 19:32 编辑 ]