12 replies to this topic

[Antonjo]

I downloaded the latest ArchLinux ISO and converted to a VDI, with:

 

 

VBoxManage  convertfromraw .\archlinux-xxx-dual.iso archiso.vdi

I am able to boot a VM from "archiso.vdi". 

 

Now, I would like to mount and possibly modify  "archiso.vdi":

imdisk -a -f .\archiso.vdi -m r: -b XXX

Do you know what is the proper offset?

 

 

[erwan.l]

check this.

[Antonjo]

 

After:

 

devio --dll=proxy.dll;dllopen shm:test_proxy archiso.vdi
imdisk -a -t proxy -o shm -o ro -f test_proxy -m x:

The disk is mounted, but its filesystem is not recognised and Windows wants to format it.

 

Using Arsenal Image Mounter and AOMEI Partition Assistant I see that the VDI disk (737 MB) has 2 partitions:

 

- the first partition (FAT16) starts at sector 172 and is 40 MB large.

- the rest of the space is appears unallocated.

 

If in AOMEI I assign a letter to the first partition, I can use it in Explorer.

 

Instead in devio the last lines read:

 

Image size used: 778043392 bytes.

Read request - size:512 offset:0

vdi_read_buffer_at_offset - size:512 offset:2097152

Detected a master boot record at sector 0.

Using partition 1.

Total size: 778043392 bytes. Using 778043392 bytes from offset 0.

 

To me, this means that devio is assuming a single partition as large as the whole 732 MB disk, which is wrong.

 

 

The full devio output follows:

 

u32Signature:BEDA107F
u32Version:65537
cbHeader:400
u32Type:1
fFlags:0
szComment:Converted image from .\archlinux-2016.08.01-dual.iso
offBlocks:1048576
offData:2097152
cCylinders:0
cHeads:0
cSectors:0
cbSector:512
cbSector:0
cbDisk:778043392
cbBlock:1048576
cbBlockExtra:0
cBlocks:742
cBlocksAllocated:735
vdi_open OK
size: 778043392
Successfully opened 'c:\archiso.vdi'.
Read request - size:1536 offset:0
vdi_read_buffer_at_offset - size:1536 offset:2097152
Image size used: 778043392 bytes.
Read request - size:512 offset:0
vdi_read_buffer_at_offset - size:512 offset:2097152
Detected a master boot record at sector 0.
Using partition 1.
Total size: 778043392 bytes. Using 778043392 bytes from offset 0.
Required alignment: 1 bytes.
Buffer size: 67108864 bytes.
Shared memory operation.
Waiting for connection on object test_proxy. Press Ctrl+C to cancel.

[Wonko the Sane]

It seems to me (without having seen the actual .iso involved) that there is anyway a base issue.

Very likely the .iso is a "hybrid" .iso. i.e. a .iso that has been modified to behave - besides as an image of a CD or DVD - also as a hard disk image.

Typically (not necessarily in this case) this is obtained by adding a MBR and a small partition before the actual iso, which is re-addressed as a partition in the added MBR, this is normally (almost, with some caveats) OK in Linux, but not on Windows. 

 

Such an image is simply not suitable to be used under Windows without modifications and/or some specific aded mounting steps and anyway, if there is a .iso partition, it will likely be a CDFS filesystem and as such "read only".

 

While writing this post, I am downloading the latest archlinux-2017.02.01-dual.iso, I'll have a look at it and then report what I can find about it.

 

 

Wonko 

[Wonko the Sane]

Did a quick check, as expected it is a isohybridized thingy, using each and every trick in the trade +1 (and potentially breaking a number of specifications/conventions) in order to use the same .iso to:

1) boot as CD/DVD in BIOS

2) boot as CD/DVD in UEFI

3) boot as hard disk if dd-ed to USB stick in BIOS

4) boot as hard disk if dd-ed to USB stick in UEFI

 

The setup is extremely complex, just like it is re-mastering it, see:
https://wiki.archlin...the_Install_ISO

 

The added MBR is a "mixed mode" MBR/EFI with the EFI protective partition (ID EF) NOT spanning the whole disk size and with a partition with ID 00 (which Linux accepts but that is a no-no in windows) covering the whole extents.

 

More or less if you analyze the image (before converting it to .vdi) with 10 tools, you will see 10 different things as each tool will favour the one or the other or yet another possible interpretation of the data.

 

I am attaching a view of the MBR, as seen in a "normal" hex editor with MBR data parser.

 

Wonko

 

 

 

Attached Thumbnails

• 

[erwan.l]

In that VDI image, the actual disk starts at offset 2097152.

 

Devio should therefore display something like this 

Detected a master boot record at sector 0.
Using partition 1.
Total size: 778043392 bytes. Using 778011136 bytes from offset 32256.

But as explained by Wonko, because this raw disk has a tweaked MBR, Devio cannot find the partition offset and therefore uses the whole disk starting at offset 0 by displaying

Detected a master boot record at sector 0.
Using partition 1.
Total size: 778043392 bytes. Using 778043392 bytes from offset 0.

You could either force devio (on the command line) to use a specific offset or force ImDisk (still on the command line) to use that same specific offset.

 

Wonko may be able to give you that offset (I am not able to retrieve that information looking at the screenshot provided by Wonko).

[erwan.l]

Wild guess, to me the offset should be 172 sectors or 172*512=88064 bytes ?

("start LBA" in Wonko screenshot, "sectors before" in my screenshot).

So in ImDisk command line, you could add -b 88064

 

And the partition is actually 131072 sectors i.e 65536 KB.

("num lba" in Wonko screenshot, "sectors" in my screenshot).

 

Another solution could consist in telling devio which partition to use (it uses partition 1 by default).

That might be an easier/clean solution as you dont have to bother then with the offset (which may vary from one image to the other).

 

 

[Wonko the Sane]

Yep, there is a "valid" FAT partition at offset 172 sectors (if mounted with 512 bytes/sector), 64 Mb in size, but it is not like this would be of any particular use.

It contains - among other things - a file "archlinux.img" containing a heavily compressed "archlinux" file shrinked from 155 Mb to 38 Mb which is an actual filesystem with a minimal Linux System.

As often happens it is a sort of "matrioshka", I accessed it by mounting the .iso with 172 sectors offset in Imdisk, then opening the archlinux.img in 7-zip and then opening (still with 7-zip) the archlinux file.

 

The MBR/GPT part, as said before, is a "mess", I am attaching (just for the fun of it) how gdisk sees it and a quick dir of both the FAT volume (when mounted in Imdisk as hard disk volume with 172 sectors offset) and of the CDFS volume when mounted in IMDISK as CD/DVD (whole file).

 

And I suggest also having a look at it in Isobuster, which can highlight some more trickery.

 

Wonko

 

 

Attached Files

•  someviews.txt   13.18KB   565 downloads

[Olof Lagerkvist]

Would it work to specify a partition number explicitly at devio command line?

devio --dll=proxy.dll;dllopen shm:test_proxy archiso.vdi 2

or

devio --dll=proxy.dll;dllopen shm:test_proxy archiso.vdi 3

etc

 

Even though devio defauls to first partition found in the partition table, you could specify other partitions as well.

[erwan.l]

Would it work to specify a partition number explicitly at devio command line?

devio --dll=proxy.dll;dllopen shm:test_proxy archiso.vdi 2

or

devio --dll=proxy.dll;dllopen shm:test_proxy archiso.vdi 3

etc

 

Even though devio defauls to first partition found in the partition table, you could specify other partitions as well.

 

I believe that would be the cleanest setup (rather that passing the offset parameter to imdisk).

[erwan.l]

Yep, there is a "valid" FAT partition at offset 172 sectors (if mounted with 512 bytes/sector), 64 Mb in size, but it is not like this would be of any particular use.

It contains - among other things - a file "archlinux.img" containing a heavily compressed "archlinux" file shrinked from 155 Mb to 38 Mb which is an actual filesystem with a minimal Linux System.

As often happens it is a sort of "matrioshka", I accessed it by mounting the .iso with 172 sectors offset in Imdisk, then opening the archlinux.img in 7-zip and then opening (still with 7-zip) the archlinux file.

 

The MBR/GPT part, as said before, is a "mess", I am attaching (just for the fun of it) how gdisk sees it and a quick dir of both the FAT volume (when mounted in Imdisk as hard disk volume with 172 sectors offset) and of the CDFS volume when mounted in IMDISK as CD/DVD (whole file).

 

And I suggest also having a look at it in Isobuster, which can highlight some more trickery.

 

Wonko

 

Nice : had not thought about telling ImDisk to mount the whole image as CD/DVD.

 

As a whole, I did not try to understand what the author of this thread is trying to achieve (turn an iso into a vdi and mount it?).

I was focusing on how to mount this VDI image (and incidently ensuring my proxy was not faulty ).

[Wonko the Sane]

Would it work to specify a partition number explicitly at devio command line?

devio --dll=proxy.dll;dllopen shm:test_proxy archiso.vdi 2

or

devio --dll=proxy.dll;dllopen shm:test_proxy archiso.vdi 3

etc

 

Even though devio defauls to first partition found in the partition table, you could specify other partitions as well.

If devio doesn't check the partition ID in the MBR, then it may work , if it does, the EF partition ID will stop it in its tracks.

 

I tried (on XP) to mount the "whole" .iso (not the converted .vdi) via the Microsoft VSS driver and of course Disk Manager saw the 64 Mb partition but wouldn't allow assigning a drive letter to it.

 

But, just like erwan.l just posted, I am not sure about what the OP wants to do (or more generally can be done) with it once mounted.

 

Wonko

[Olof Lagerkvist]

It should work, devio does not check any partition id values. It simply uses the partition number you specify, or partition 1 if you do not specify any partition number. To manually specify to use the entire image without parsing partition table at all, specify 0 as partition number at the devio command line (this is usually not used together with ImDisk but is required when using devio together with Arsenal Image Mounter or similar which require full disk images).