非--mem形式 map iso镜像后读取文件失败的问题

幸运的草

回复楼上各位：
　　这个问题，确实是软碟通的问题。很久前我们在调试NATIVE版的PE时，就发现了这个问题。一个ISO，无引导记录，只是一个或两个WIM文件，你如果用软碟通修改ISO中WIM文件，哪怕是覆盖导入，这个被修改的文件的LBA值就是最大的。这个最大LBA值的WIM文件挂载时就出错。刚开始WIM文件挂载出错，误以为是方件不连续造成的，后来发现是这样，于是就向里面添加一个无关的小文件，使这个文件的LBA值最大。这时挂载WIM文件就正常了。
　　一句话，只要用软碟通修改的文件，其LBA值是最大的。在G4D中仿真，读取这个文件就失败。　
  　或者也是G4D的问题。至少是这两个共同作用的结果。

[ 本帖最后由 幸运的草 于 2012-2-22 08:57 编辑 ]

幸运的草

补充：实际这个文件没有损坏，你导出后，与原文件无异，就是map后G4D不能正确读取。

幸运的草

回复 #32 不点 的帖子

这里所说的LBA值最大，是指在ISO中所有文件中是最大的。也就是最靠后的文件。是指修改后，而非指原创文件。原创文件没有这个问题。一修改就出现了这个问题。
　LBA值，在ISO中，好像是一个文件一个值。

注：原来测试的是hotdll发布的tangope两个版本，一个是CAB版，一个是WIM版，都出现这个问题。而没有加载FIRADISK之类驱动。只是解压后的文件不全，WIM文件挂载失败。都是在UD区，通过GRLDR引导仿真ISO。VM及实机均测试如此。

幸运的草

同一个文件，导出再导入，LBA值就大了很多。

幸运的草

带--mem是可以的。我下载测试一下，楼主的情况。

[ 本帖最后由 幸运的草 于 2012-2-22 10:49 编辑 ]

幸运的草

楼主的ISO，用VM挂载ISO，测试可以加载驱动。用U盘测试，在VM上也能加载外置。

但实机不行。

经查看楼主的ISO，发现他加载外置工具的BASIC.WIM的LBA值是ISO文件中最大的。也就是说楼主用软碟通修改过这个文件。
　　这个问题实际和我说的是同一样问题。你可以向里面添加一个几十KB的无关的小文件，使这个小文件的LBA值大于BASIC.WIM。不用加载FIRADISK之类的驱动。完全可以加载外置工具。
　　在实机上测试通过。
　　map /mype.iso (0xff)
     map --hook
chainloader (0xff)
boot
      全测试没有加载这类驱动，因此完全排除是这类驱动的BUG。

　　至此，还是我的结论：是软碟通与G4D共同作用的结果，导致的问题出现。
　　

幸运的草

我测试：
　相同的文件，用软碟通导出再导入，就导致其LBA值在ISO所有文件中最大化。即表现最直接的就是WIM文件挂载失败，CAB文件不能完全解圧或失败。
0PE.WIM，中还有好几个WIM文件，这就是为什么不能用软碟通修改的原因。其实要破解也简单，向里面添加一个无用的小文件，使这个文件的LBA值在ISO中是最大的。就可以了。

还有一个办法也可，先用软碟通打开ISO，把引导记录保存为一个BIF文件，把ISO的文件及文件夹导出到硬盘；然后再重建一个新的ISO，不需要任何设置，采用默认的就行。要先添加所有的WIM文件，再添加其他的文件及文件夹。最后加载引导记录，保存。一切OK。

    目前的问题，在WIM文件表现较为突出，楼主出现的问题，就是WIM文件挂载失败引起的。

[ 本帖最后由 幸运的草 于 2012-2-22 12:40 编辑 ]

幸运的草

不是这样的，如果没有用软碟通修改过，不存在这个问题。也就是你用软碟通重新制作一个ISO，先添加WIM文件，后添加其他文件，再导入原ISO的引导记录。可在就不存在这个问题。
　　出现这个问题必须是用软碟通修改过且被修改的文件的LBA值最大。才导致这个问题。

　　楼主的ISO，本身就是用软碟通修改过，而且basic.wim文件的LBA值最大。
　
　　当然解决办法就是使原ISO文件增大4K体积。（不修改用软碟通新制作的不需增大4K）。

幸运的草

初步断定是软碟通的BUG。因为即使文件导出再导入，原文件的LBA值就发生了变化。按道理不应该。

　应该说加4K，只是解决办法的一种，其实，不加4K也可以。

大家可以做个测试：修改后只要保证WIM文件的LBA值不是最大，即可解决这个问题。
方法就是：修改保存前，把ISO的引导文件。即.BIN或COM。导出再导入，保存即可。该方法不增加ISO文件的体积。
　　这些文件是ISO的引导，不依靠G4D运行，所以说可“动”。
　　该方法实机测试通过。只是多了一个冗余的操作。

[ 本帖最后由 幸运的草 于 2012-2-22 14:10 编辑 ]

幸运的草

　这个问题，估计是和FBINS出现的问题一样。也就是计算文件连续空间文件有误。其根据就是同一文件导出再导入，lba值就变化，且是所有文件最大的。也就是没有在同一个空间存放，实际放在了最后部分。这一点和原来的FBINST是一样的。
　但为什么最后的WIM会挂载失败。这个问题有能力且有兴趣的可以探讨一下。

　或者，G4D可以改进一下，在map时，人为把ISO的体积增大4K空间。这个问题就可以永久的解决了。

[ 本帖最后由 幸运的草 于 2012-2-22 14:13 编辑 ]

幸运的草

下载测试了百草的PE，发现这是个0PE。
先说测试结果。实机测试确如百草所说，加--mem中间停止到命令行下，是由于PE.WIM挂载失败引起的。而不加--mem反而没问题。
　查看ISO内部，发现PE.WIM的LBA值最高。
然后用软碟通把引导GRLDR导出，再导入，使这个文件LBA值为最高，这时实机测试，反过来了。--mem测试成功，而非--mem则引导失败。

  个人意见。0PE本身有说明，只兼容makiso制作的ISO，不建议用软碟通修改制作。PE.WIM，里面有几个WIM文件。而其他PE的WIM文件只是一个。这是不同之处。
　挂载失败也要在0PE内部查起，由于--mem方式加载后，启动0PE的速度飞快。而以前有反映。0PE为了求快，造成启动失败的情况，所以，会不会是高速启动造成了挂载WIM文件失败呢。
　　因为他要选挂第一层，然后映射后再挂第二层。速度过快，WIM管理程序能否反映过来呢？

幸运的草

我要说的就是这样道理。问题基本明了，在G4D外的解决办法，几种方法我前面已经说了。
　　现在需要新版G4D的测试，即MAP　ISO时，把ISO体积空间增大＞4K，这样再进行测试，看是否问题消失。
　如果消失，那就彻底解决了这个问题。

＞＞CHIANNET
　在G4D外的解决办法有三，向ISO里添加无用文件是一种方法。第二种，就是把ISO的引导文件即.BIN或.com文件，导出再导入，即可，因为这两个文件是ISO的引导，不依赖于windows。不会出现上面的问题。
　第三个办法，就是将原ISO的引导记录保存，重新制作新的ISO，再导入原引导记录。制作时最好保证WIM文件最先导入。
　
　

幸运的草

提点建议：
还应注意另一个问题，一直不明白，但无能力证明。
　　同一个文件，为什么导出再导入，LBA值就变为最大？是不是说，它是把这个文件放到了ISO的最后位置？
这个情况和发现的FBINST的情况是一样的。
　　因此有理由怀疑，是这个工具在计算文件存放空间方面有错误呢。

[ 本帖最后由 幸运的草 于 2012-2-24 17:41 编辑 ]

幸运的草

我再次建议不要用0PE进行测试，用普通的ISO就是有SETUPLDR.BIN的那种进行测试。
p大再三声明，0PE不承认其他ISO制作工具，理由就是兼容性问题。

[ 本帖最后由 幸运的草 于 2012-2-25 09:32 编辑 ]

幸运的草

因为0pe与其他普通的ISO不同，他是由GRLDR引导的，里面的很多菜单程序语句及变量，还有很多内存使用，测试环境很复杂，你不可能知道到底是由于GRLDR使用引起的内存变动还是由于WINDOWS对内存的破坏。
  而普通的ISO，却是由于WINDOWS的引导模块引导，测试环境简单。
  这就是我建议用普通的ISO做测试的原因。可以排除其他情况的干扰。



还有一个有意思的现象：
　　我把楼主的ISO，用软碟通导出，将引导记录保存，然后新建一个ISO，导入原引导记录，制作时，我故意把BASIC.WIM最后导入，保存后，再打开，却发现，最后导入的BASIC.WIM的LBA值却不是最大的。相反，先前导入的背景文件的LBA值却是最大的。
　　再观察，发现新制作的ISO，其LBA值是有规律的，他是按目录层数放置的。目录层次越深，LBA值越大。但无论是否最大。却不会被破坏。奇怪？

　这个ISO和楼主的ISO字节数是一样的。
稍后，我上传到115，供各位测试研究。 对比同一个工具制作与修改后有什么变化。看新制作的ISO，是否也有4K问题。

[ 本帖最后由 幸运的草 于 2012-2-25 11:36 编辑 ]

幸运的草

我的意思是说，新制作的ISO，所楼主的字节数是一样的，如果是4K的问题，那这个也应该存在，你们查查看，如果不存在问题，那这个WINDOWS破坏4K的问题就值得怀疑。至少可以证明是否制作工具本身存在问题。

经测试，这个新制作的ISO，启动没有问题。（但不代表无4K的问题）

http://115.com/file/e7lwv5pa#
pe.rar

[ 本帖最后由 幸运的草 于 2012-2-25 12:09 编辑 ]

幸运的草

回复 #108 网虫2008 的帖子
很多问题不是修改引导出现问题，而是修改WIM即二级内核出现挂载失败的问题。

回复 #107 2011bigbarry 的帖子
我在前面就指出是软碟通的问题，被不点否定了。　

　在＃103、＃105就是要证明这个问题。但我没能力测试。
　我一直不认为是WINDOWS及FIRADISK等驱动造成的。

经测试，另存为也不行，必须是新制作做的才行。还有一个问题。同一个文件导出再导入，就不在原位置放置了。放到最后面。是否说明它这个判断中间连续空间的方法有问题？我也一再强调这个问题，这和FBINST出现的是一样的问题。

[ 本帖最后由 幸运的草 于 2012-2-29 11:17 编辑 ]

幸运的草

这个，可以理解，解决办法也不是一种，前面的帖子我就提出了几种解决方案，经测试都通过。
　　我主要有一个纠结的疑问：为什么同一个文件，导出再导入，LBA的值就是最大的。（文件被放到最后了）。按道理不应该。这个问题同原来的FBINST的BUG是一样的。我怀疑软碟通在这方面也可能有问题。
　　谁能证明软碟通这个工具在计算空间容量方面有BUG？