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

Plantsoot

我那个问题很奇怪，不知道你还记得不记得我和P大当时找原因的情况。

昨天晚上和今天早上我反复测试，同样的ISO，上次宣布已经损坏的U盘，竟然又“活”了。
无法再现找不到PE.WIM的情况，太奇怪了。

不点

@幸运的草

说的很含糊，没明白。什么叫做  “LBA 值是最大的”，能不能说的精确一些？文件本身没有 LBA 概念，文件可能占用很多扇区，每个扇区都有一个 LBA。所以，文件不只有一个 LBA。你说文件的 LBA 值最大，这就不能让人明白了。另外，什么叫 “ 最大 ”？这个也含糊。是最大的整数 0xFFFFFFFF 呢？还是最大达到整个 iso 的尾部？

map 有 “ 带 --mem ” 和 “ 不带 --mem ” 之分。如果带上 --mem 正常了，从 grub4dos 内部可以访问 iso 里的文件了，这说明，文件格式确实没问题。而如果此时不带 --mem 就无法用 grub4dos 来访问 iso 里面的文件，那就属于 grub4dos 的 bug。当然，需要事先排除 USB 出现故障的可能性。我们知道，USB 的 BIOS 有很多毛病。应该用普通的硬盘来试验。既然是格式问题，那与介质无关，普通的硬盘照样可以重现问题。所以应该用硬盘来试验，这样比较可靠。其实硬盘也不保证 100% 可靠。因为 BIOS 有 137G 极限，如果 iso 的位置处于超过 137G 的界限之外，那么即使在硬盘上，也照样会有问题。

希望各位逐一澄清这些问题。

[ 本帖最后由 不点 于 2012-2-22 09:08 编辑 ]

zhaohj

我们不要忘这一点：map --mem 这个ISO文件是正常的。
这就排除了ISO文件有bug的情况。也验证了firadisk或winvblk在map --mem情况下是正常的。

现在范围缩小了，map非mem下firadisk或winvblk有bug

不点

我终于有点明白了，你们都是在 U 盘上做。

USB BIOS 出现各类故障，太常见了。如果 iso 碰巧处于 BIOS 能够访问到的区域，那么访问你 iso 里面的文件不成问题。如果 iso 碰巧跨越极限，则有一部分 iso 的扇区是可以访问的（即处于极限之内的部分），另一部分 iso 的扇区是无法访问的（即处于极限之外的部分）。

题外话：

各位尽量都把错别字改正一下，毕竟这里有外国人通过 google 翻译来阅读帖子。

楼主或者版主最好把整个线索的标题改一下。“一个非常古怪的问题”不是一个好的标题，不利于大家将来搜索这个帖子。

[ 本帖最后由 不点 于 2012-2-22 09:25 编辑 ]

Plantsoot

我更糊涂了，因为同样的文件，同样的U盘，上次我直接拖入grldr和0PE.ISO到ud，启动过程中有无法找到PE.WIM的提示。
然后再拖入一个0PE.ISO到ud，原来的改名，就可以正常启动到PE桌面。

今天为了再现这个问题，我再次这样测试，发现两个ISO都可以正常启动，让我很不解。
难道真是BIOS的问题？上次是实机，这次是虚拟机。

我马上测试真机。

不点

你好糊涂啊！抱歉，这不是责怪你的意思。

虚拟机的 BIOS 怎能等价于真实机的 BIOS？

幸运的草

回复 #32 不点 的帖子

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

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

不点

你的意思是说，用某软件修改 ISO 之后，不行了。

怀疑这个软件有 bug。

另外，你没有确认，带 --mem 是否也是失败的。如果带 --mem 失败，那就是 iso 格式被破坏所导致的了。也或者是 grub4dos 的 bug：它不能认识修改后的正确的格式，但这种可能性很小。而软件修改 iso 造成错误，这种可能性较大。

这里说的问题，与楼主所遇到的问题，可能属于两个不同的问题，不是同一个问题。

幸运的草

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

幸运的草

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

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

mahuniu

这个iso文件，加进去几十k的东西，或许就能map了，而缩小体积，却还是不行，例如缩小2m，它还是不能被map，但是缩小保存后再加几十k，可能就可以map了

幸运的草

楼主的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共同作用的结果，导致的问题出现。
　　

Plantsoot

我上次遇到的情况无法再现，先不管了。今天我做了另外一个测试。

1、win7系统、2G的U盘（fb盘，ud区的数据全部填00后再导入文件。
2、vmware7.1虚拟机，因为我实机测试了一下，效果和虚拟机一样。
3、grldr、0PE.ISO原版、0PE.ISO修改版（用ultraiso修改，把PE.WIM删除后保存，再加入PE.WIM）
4、全部测试均按map不加--mem和加--mem参数两种方式进行。
5、测试0PE.ISO修改版的时候，分几次手工修改ud文件列表中该文件的大小后进行测试。

不知道这次的测试有没点意义。

文件大小	map	map后占扇区数（512）	map后占扇区数（2048）	map后占扇区数（4096）	启动	备注
122748928		239744	59936	29968	成功	mkisofs
	--mem	239744	59936	29968	成功
122677248		239604	59901	29950.5	失败	用ultraiso修改，把PE.WIM删除后保存，再加入PE.WIM
	--mem	239608	59902	29951	失败
122679296		239608	59902	29951	成功
	--mem	239608	59902	29951	失败
122681344		239612	59903	29951.5	成功
	--mem	239616	59904	29952	成功
122682368		239614	59903.5	29951.75	成功
	--mem	239616	59904	29952	成功
122683904		239617	59904.25	29952.125	成功
	--mem	239624	59906	29953	成功
122685952		239621	59905.25	29952.625	成功
	--mem	239624	59906	29953	成功
122748928		239744	59936	29968	成功
	--mem	239744	59936	29968	成功

我拿楼主的有问题的MYPE.ISO做了个简单的测试。

按zhaohj说加一个4K大小的文件也行，那我就强行手工在ud内修改MYPE.ISO的大小，
增加4K大的空间，结果真的可以了。

结合我上面的测试，是不是说不管有没有用软碟通修改过，
只要map的时候，强行增大镜像体积4K以上，就可以正常启动？

MYPE.ISO文件大小	map	map后占扇区数（512）	map后占扇区数（2048）	map后占扇区数（4096）	加载外置
57698304	不加--mem	112692	28173	14086.5	失败
57702400	不加--mem	112700	28175	14087.5	成功

[ 本帖最后由 Plantsoot 于 2012-2-22 13:19 编辑 ]

幸运的草

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

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

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

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

zhaohj

通过多次测试，发现这样一个规律（map非mem)：
1：当文件大小是4k的整数倍时，肯定成功;
2：当文件大小不是4k的整数倍时，往ISO中加入大于等于4KB的一个文件，肯定成功。

Plantsoot

看看我上面的测试，是不是有点意思，我现在拿楼主的MYPE.ISO测试下。

一会给结果。

Plantsoot

我拿楼主的有问题的MYPE.ISO做了个简单的测试。

按zhaohj说加一个4K大小的文件也行，那我就强行手工在ud内修改MYPE.ISO的大小，
增加4K大的空间，结果真的可以了。

结合我上面的测试，是不是说不管有没有用软碟通修改过，
只要map的时候，强行增大镜像体积4K以上，就可以正常启动？
或者换个方式，软碟通修改后的ISO用winhex再尾部补上8个512扇区的00是不是也可以解决？

title  MYPE.ISO
map --mem (ud)/WINVBLK.IMG (fd1)
map --mem (md)0x6000+800 (fd0)
map (ud)/MYPE.ISO (0xff)
map --hook
dd if=(fd1) of=(fd0) count=1
chainloader (0xff)

MYPE.ISO文件大小	map	map后占扇区数（512）	map后占扇区数（2048）	map后占扇区数（4096）	加载外置
57698304	不加--mem	112692	28173	14086.5	失败
57702400	不加--mem	112700	28175	14087.5	成功

[ 本帖最后由 Plantsoot 于 2012-2-22 13:14 编辑 ]

幸运的草

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

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

Plantsoot

我明白你的意思，我是说不管ISO有没用软碟通修改过，
只要map的时候都把ISO的体积扩大4K，是不能就代表着ISO都可以兼容了，
管他有没用软碟通修改过，或者采取我上面说的另外一个方法，
用软碟通修改的时候末尾加上4K的00.

幸运的草

初步断定是软碟通的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 编辑 ]

zhaohj

是这样的，ULTRAISO修改过的最后放进去的文件,map后都会被windows api 丢弃。
可以这样做试验：在mype.iso中先导出minipe\winpe.ini，导出后删除minipe\winpe.ini，保存ISO；再把winpe.ini拖进原位置，保存ISO。
你会发现出现蓝屏。
这个试验证明lba最大的文件，无法被windows api 识别。
而grub4dos实模式下我查看是正常的。下面的图是按上面方法修改的最后导进去的bliss.jpg文件，LBA最大。

Plantsoot

为什么人为在文件尾部增加4k的空间后，又不抛弃了？

zhaohj

原帖由 Plantsoot 于 2012-2-22 14:45 发表
为什么人为在文件尾部增加4k的空间后，又不抛弃了？

感觉是windows api丢弃了4k余数部分，人为在ISO文件尾部增加4k后，所有的文件都不在这4k中，即所有文件完整的。
map --mem为何成功，因为map --mem是4k的整数倍。

Plantsoot

map --mem 不一定成功，你看我做的测试。

文件大小

map

map后占扇区数（512）

map后占扇区数（2048）

map后占扇区数（4096）

启动

122679296		239608	59902	29951	成功
	--mem	239608	59902	29951	失败

不加 --mem成功，加了失败，让我十分不理解！

zhaohj

奇怪，上面的正好是4k的整数倍，难道map --mem后丢弃了4k?
能否测试一下加个4k的文件后，map --mem能否成功？

Plantsoot

全部的测试：
http://bbs.wuyou.net/forum.php?m ... p;page=5#pid2388985

结果是，增加大于4K的体积后随便加不加--mem都正常了。

不点

诸位的探索，让我有这样一种印象：

grub4dos 没有问题。那个修改 ISO 的软件也没有问题。有问题的是 Windows 的 ISO 驱动程序（可能是 winvblock 之类的），它不能处理这种情况。

这还不能证明是 Windows 的 API 出了问题。要证明 Windows API 出问题，必须刻录光盘（或者把 ISO 挂在 qemu 之类的虚拟机的光驱上也是一样的）来验证 Windows 可否读出相关的文件。


当 ISO 文件长度不是 4K 的倍数的时候，可能出现这种问题。到目前为止的讨论表明，这是驱动程序的 bug。我认为 Windows API 很难出现这类问题。因此，我还是觉得这是 winvblock 的 bug。

由于 map --mem 自动把映像文件按 4K 对齐，因此，在带 --mem 的情形，bug 未表现出来。

这下子快要彻底弄清楚了。修改后的文件，可能破坏了原来的 “ 4K 对齐 ” 的文件长度，导致一系列问题的发生。

这 bug 是属于驱动程序的 bug（即，winvblock/firadisk 的 bug） 或者 Windows API 的 bug（这个可能性不大），这一点再次得到验证。诱因是当某个软件修改 ISO 之后，没有把 ISO 的长度按照 4K 对齐。因此，这也就有了 workaround：制作 iso 之后，保证 iso 的长度是 4K 的倍数，这个问题也就不复存在了。

不点

刚才没看到 55 楼以后的讨论。55 楼，确认没弄错吗？你把 ISO 提供给大家，让大家都测试，看看结果是否一样。

只要 grub4dos 在实模式能够访问文件，那就表明 grub4dos 没问题，同时也说明修改 ISO 的工具也没问题。

至于说其他问题，那就只能猜测了。

Plantsoot

以上测试是 fbinst + grldr 测试的。
我现在改用burg来map有问题的ISO，看看。

结果：

1、软碟通修改过的0PE.ISO（122677248字节，不是4K的整数倍），用burg来map，不管是否加--mem、都会有缺文件的提示。

2、人为在0PE.ISO尾部增加数据（00），变为122679296字节，4K的整数倍，
      用burg来map，不管是否加--mem、都会正常启动。
      这个情况用grldr来map，加--mem不正常，不加反而正常，非常蹊跷（特例）。

3、人为在0PE.ISO尾部增加4K的数据（00），变为122681344字节，不是4K的整数倍，
     用burg来map，不管是否加--mem、都会正常启动。
     这个情况用grldr来map，不管是否加--mem、都会正常启动。

如果不考虑那个蹊跷的特例，不知道是不是说明grub4dos应该是没问题的。应该是驱动的问题。

[ 本帖最后由 Plantsoot 于 2012-2-22 16:30 编辑 ]