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

mahuniu

我自己修改的PE的iso，大小是55M，通过grub4dos加载，用map --mem则一切正常，但是不加mem就不能加载外置，不过古怪的是，在iso里面随便加些东西，该iso文件到了一定体积，又会正常。
这是配置内容：
title MYPE.iso(map)
map --mem /boot/winvblock.img.gz (fd1)
map --mem (md)0x6000+800 (fd0)
find --set-root /boot/MYPE.iso
map /boot/MYPE.iso (0xff)
map --hook
dd if=(fd1) of=(fd0) count=1
chainloader (0xff)

title MYPE1.iso(map)
map --mem /boot/winvblock.img.gz (fd1)
map --mem (md)0x6000+800 (fd0)
find --set-root /boot/MYPE1.iso
map /boot/MYPE1.iso (0xff)
map --hook
dd if=(fd1) of=(fd0) count=1
chainloader (0xff)

MYPE.iso和MYPE1.iso内容是一样的，就是容量不一样，后者随便加了个与PE没有任何关系的二十多m的文件，前者模拟出来的光驱，不是不能读ini文件就是不能读外置的wim，后者就正常加载了。如果用map --mem则是正常的。
为什么会加文件呢，那是因为我起先觉得是自己没把pe修改好，一直折腾，到最后觉得和修改前的原版pe只剩容良不一样了。

[ 本帖最后由 sratlf 于 2012-2-22 10:01 编辑 ]

pseudo

呵呵，不怪。
是不是iso大于64mb才行？

某个旧版grldr估计无此问题。

楼主最好提供一个能在虚拟机重现的测试例。或者定位grldr从何时起出问题，我想大约是在冬季。

[ 本帖最后由 pseudo 于 2012-2-20 23:40 编辑 ]

不点

感觉 grub4dos 不太可能出现此类问题。只要你在 grub4dos 之下能够访问虚拟的光盘 (0xff) 中的所有扇区，那 grub4dos 的任务就圆满完成了。这很容易验证: 只需 把 (0xff) 的最后一个扇区 cat 出来:

cat --hex (0xff)xxxxx+1

如果内容正确，就表示没问题。注意，光盘的扇区大小是 2048 字节，不要把扇区号弄错。如果按 512 字节的小扇区，计算得到的最后一个扇区号肯定比较大。而应该按照 2048 字节的大扇区计算，最后一个扇区的扇区号应该比较小。

从描述的故障现象来看，好像是 winvblock 的某个限制造成的，请进一步确认。

mahuniu

用firadisk效果更差，有时候在pe里看不到它模拟出来的光驱，而winvblock 怎么也看到光驱吧，不过如果加上mem，都正常的。反正加载pe内核后，访问模拟光驱上的文件是不正常的，如果用mem挂iso到内存，会有两个模拟光驱，而且好象都能正常读取

[ 本帖最后由 mahuniu 于 2012-2-21 01:10 编辑 ]

mahuniu

这个事情太诡异了，今天早上把那PE 的img重新做了一下并打包，竟然正常了，那iso 文件大小没有变化一个字节，邪了。
不知道什么原因，把我那个在3台电脑上不能map而只能map --mem的iso 文件上传了，如果有兴趣自己去测试一下：
http://115.com/file/c2ref4li#

zhaohj

“在3台电脑上不能map而只能map --mem”，想问一下，你的菜单是怎么写的？
在保证ISO文件连续存放的前提下，那就是菜单的写法有问题了。

mahuniu

文件是连续存放的，不然不可能加载iso吧（加载前有错误提示），菜单文件内容，顶楼已经写了呀，至于格式，ansi和其他的，好象也一样结果

sratlf

有一点是错误的  对winvblock驱动可以这么写  进入pe后也能挂载上

对firadisk驱动  还需要写入配置信息  只有这几行代码进入pe后是没办法挂载的

mahuniu

我刚刚在Virtual PC试了，也是一样的结果，反正我这个55m的iso就是不能被map，但是map --mem或者在iso随便加二、三十m的文件进去，却又正常。55m的东西，下载也快的，如果有测试出原因的，希望能告诉我具体原因，因为这个实在太邪门了

zhaohj

我测试了一下很正常，你的问题属于对firadisk驱动不真正了解所致。
不多讲了，写出菜单：
title  Boot MYPE.ISO With map (no mem)
map --mem /boot/FIRADISK.IMG  (fd1)
map --mem (md)0x200+800 (fd0)
map --hook
dd if=(fd1) of=(fd0) count=1
set iso=/MYPE.ISO
find --set-root %iso%
map %iso% (0xff)
map --mem (md)0x200+4 (99)
map --hook
echo [FiraDisk] > (99)+1
echo StartOptions=cdrom,vmem=find:%iso%; >> (99)+1
chainloader (0xff)

mahuniu

楼上老兄，你这个是不正常的，没加载外挂。你把光驱里的文件复制一下试试

zhaohj

测试了一下，确实有点奇怪，往MYPE.ISO中复制一些文件后，加载了外挂。

zhaohj

下面是5#的mype.iso两种方式加载的情况，不点大与C大看一下，这个ISO已连续存放，为何总扇区数不一样？
(0xff)是map方式的，(hd32)是map --mem加载的。
map --mem按照8的倍数，很正常！
map不是8的倍数，难道问题在这里？

[ 本帖最后由 zhaohj 于 2012-2-21 13:17 编辑 ]

zhaohj

文件大小=0x3706800，按每扇区512字节计算=0x1b834扇区数；按每扇区2048字节=0x6e0d扇区数
cat --hex (0xff)0x6e0c+1
显示结果正常。

pseudo

楼主的iso是用ultraiso弄过的吧。

我曾经遇到过用ultraiso更换chenall的dpms.iso里的dpms.bat后，出现

直接map成功，但不能找到dpms.bat的现象。

所以在0pe里有这段代码：
map  %~1DPMS.ISO (0xdf) && map --hook ! echo
if not exist (0xdf)/DPMS.BAT && map --unmap=0xdf && map --rehook && map --mem  %~1DPMS.ISO (0xdf) && map --hook ! echo

就是说，直接map成功并不能保证iso内文件可读。

所以0pe还是用基于mkisofs的批处理生成iso靠得住。只是dpms.iso是chenall提供的，怕批处理重新生成走样，我才用ultraiso处理一下。

Plantsoot

原帖由 zhaohj 于 2012-2-21 14:40 发表
文件大小=0x3706800，按每扇区512字节计算=0x1b834扇区数；按每扇区2048字节=0x6e0d扇区数
cat --hex (0xff)0x6e0c+1
显示结果正常。

我这测试的结果和你的一样。
有点奇怪了，不加--mem的cat --hex (0xff)0x6e0c+1是正确的。
加了--mem的，cat最后一个扇区应该是cat --hex (0xff)0x6e0d+1，反而不正常了。

不正常的启动后反而可以加载外置?

Plantsoot

回复 #15 pseudo 的帖子

特意拿一个体积大小和楼主差不多的mkisofs制作的ISO再测试一下。
得到下面的结果，两种方式得到的文件大小一样了。

zhaohj

加了--mem的，cat最后一个扇区应该是cat --hex (0xff)0x6e0d+1，我这里正常！

mahuniu

早上把那内核的img文件重新做，打包后用ultraiso修改那iso文件后，却是正常map了，所以应该不是和容量有关，但怪异的是它加进去二十多m文件进去之后却是变正常map 了，按理说，如果iso有问题，那加文件也不会改变什么呀

Plantsoot

原帖由 zhaohj 于 2012-2-21 15:43 发表
加了--mem的，cat最后一个扇区应该是cat --hex (0xff)0x6e0d+1，我这里正常！

看看我这个是怎么回事，我这cat --hex (0xff)0x6e0d+1得到的全是00，实际最后1个扇区不全是00。

不点

我来试着分析一下。

zhaohj 说：

文件大小=0x3706800，按每扇区512字节计算=0x1b834扇区数；按每扇区2048字节=0x6e0d扇区数
cat --hex (0xff)0x6e0c+1
显示结果正常。

文件大小不是 4K 的整数倍。注意，4K = 0x1000。因此，拷贝到内存之后，可能向上浮动，补全到 4K 对齐。因此，在内存中，大小按 0x1b838 个 512 小扇区计算，即 0x3707000 字节。

实际上最后多出了 4 个 512 字节小扇区，也就等于多出一个 2048 字节的大扇区。多出的这个扇区，当然是无效的扇区，即，不使用的扇区。它的内容全是 00 ，那是正常的，没问题。

以上各位的测试，没有发现 grub4dos 有任何错误（或者说没有发现 bug）。

那么，错误就在别的软件上了。例如，winvblock 有 bug。

猜测，当 ISO 处于硬盘不同位置时，winvblock 或者 firadisk 有 bug，导致不能正确访问 ISO 里的文件。bug 很可能随着起始扇区的数值的不同而有不同的表现。比如说，如果在硬盘上 ISO 的起始扇区号是 4 的整数倍，也就是 2048 字节对齐，则计算大扇区很容易。如果 ISO 在硬盘上的起始扇区号不是 4 的整数倍，那么软件在访问大扇区的时候，以某种方式发生了错误，即 bug。这只是一种猜测，究竟什么地方搞错了，那很难说。但我们总归可以确定，那是 winvblock 这类驱动程序的 bug。这种 bug 究竟是怎么表现的，具体的技术原因是什么，现在并不十分清楚。但 bug 属于它，却是比较清楚的，因为 grub4dos 没有问题，已经证明过了。如果从 grub4dos 内部访问 ISO 中的任何文件，都没问题，那就证明了 grub4dos 没问题。而且这是严格的证明。既然是证明，那就可以排除 grub4dos 的问题了。那么，就一定是别的问题了，例如 Windows 本身的 API 的问题，或者是 winvblock 的驱动程序的问题。如果我们相信 Windows API 不会有问题，那么就可以确定是 winvblock 的问题了。

[ 本帖最后由 不点 于 2012-2-21 18:49 编辑 ]

Plantsoot

原帖由 不点 于 2012-2-21 18:43 发表
如果在硬盘上 ISO 的起始扇区号是 4 的整数倍，也就是 2048 字节对齐，则计算大扇区很容易。如果 ISO 在硬盘上的起始扇区号不是 4 的整数倍，那么软件在访问大扇区的时候，以某种方式发生了错误，即 bug。...

不点这个解释很好，明天我做个这样的测试，用ud比较容易控制ISO的起始位置，之前我也遇到0PE.ISO无法正常启动的问题，再拖入一个0PE.ISO后，后拖入的文件可以正常启动。

当时我们以为可能是我的U盘有问题了，刚好第一个ISO占用了坏的部分，但是奇怪的是，我把第一个ISO导出来，和第二个ISO对比，md5是完全一致的。当时没引起重视，也许，和这个是同一个问题，我明天上午做个测试。

不点

别忘了，winvblock 是开源的，原则上讲，你甚至可以把代码中的 bug 找出来。

chiannet

看了楼上各位老大的实验及不点老师的分析，总算大体知道了此类问题产生的原委了。这个是真实存在的问题。我补充两例：

     在native Pe启动时，即便二级内核所在ISO的确已经确保无碎片且保存在UD扩展数据区内，在我们map它启动，仍有一定的概率发生native shell找不到二级内核的时候。一直找不到原因，便武断地认为是足迹老大native shell不完善，可笑！

    也碰到过楼主在一楼阐述的问题，ISO被map 了，同样是winvblock 驱动，在PE资源浏览器里能看到仿真光驱内的文件及目录，但就是不能访问它们，当时也不知原委，便随意添加一个空的WIM文件后，其他的那些原本不能正确挂载的WIM便挂载成功了，对此百思不得其解，误认为是wim驱动程序的问题。

     按照不点老师的阐述，此两类现象都是同一个问题所致。

[ 本帖最后由 chiannet 于 2012-2-21 22:17 编辑 ]

Plantsoot

嗯，呵呵，看来我们都遇到了同样的问题，只不过没引起重视，也没去追究真正的原因，用其他的方法“解决”了就没再去找原因了。

pseudo

我说的与winvblk关系不大。
grldr成功直接map了iso镜像，但无法找到其上文件。
是g4d找不到。

问题可能跟ultraiso有关，所以也不好说是g4d的bug。

chiannet 的iso可能也是ultraiso弄的吧。

Plantsoot

P大还记得我的U盘吗？我拖入grldr + 0PE.ISO，会卡住加载WIM的阶段，然后我再拖入一个同样的ISO，后者可以顺利启动。

当时我们考虑是U盘的寿命问题，但是我导出第一个ISO，md5和第二个是一样的。

还记得是哪个版本的0PE吗？反正是1.4的，我想再现一次这个问题，可惜我忘记是哪个版本了，U盘已经格式化了。

不点

@pseudo

如果你能确认是 grub4dos 找不到 iso 里面的文件，那么确实如你所说，可能是 grub4dos 的 bug。这很容易证明，以上几位为何不证明一下呢？

当然，也可能是 ultraiso 的 bug。这是有可能的，我记得 ultraiso 曾经有过别的 bug，它并未锤炼得很完善。

总之，究竟是谁的 bug，这太容易确定了。如果是 ultraiso 的 bug，那么，它制作的 iso 刻录到 cdrom 上，也无法被 windows、dos、linux 识别。或者挂在 qemu 之类的虚拟机上，无法被 windows、dos、linux 识别。

幸运的草

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

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

幸运的草

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