IMG booting on Qemu but not on VirtualBox

[Martin]

So your image file is not an ISO 9660 cdrom image?
Did you try to attach it as a floppy or harddisk if it just contains a boot record which should be run?

[davide8226]

So your image file is not an ISO 9660 cdrom image?
Did you try to attach it as a floppy or harddisk if it just contains a boot record which should be run?

I have tried that indeed and it did not work.
It seemed anyway rather fair to me as file size is 650 MB (being the raw'ed transformation of a Joliet ISO cdrom image), which would mean a rather "big" floppy format...

[mpack]

AFAIK you won't find GPT partitioning on an ISO. It isn't part of ISO 9660.

ISO 9660 defines the first 16 sectors (32 kB) as System Area and leaves them alone, to facilitate hybrid boot architectures.

That would be woefully short of allowing for a GPT partition map. GPT specifies a partition map at the beginning, a backup partition map at the end, and reserved partitions set aside for specific purposes (i.e. a boot manager). I don't see any of that is at all compatible with "32 kb set aside at the beginning of the disk".

[davide8226]

00:00:06.372595 VMMDev: Guest Log: BIOS: CDROM boot failure code : 0005

This error code means that the VirtualBox BIOS didn't find an ISO 9660 Volume Descriptor ("CD001" missing) in sector 0x11, when looking for the Boot Record Volume Descriptor (BRVD). Note that ISO image sectors are 2048 bytes.

So it looks like the ISO image is not bootable. If you think that's not the case, please provide the first 64 kB of the ISO image.

Here are the first 64 kB (zipped) of the ISO image, which I confirm to be bootable (on Qemu, but not on VirtualBox).

[davide8226]

So your image file is not an ISO 9660 cdrom image?
Did you try to attach it as a floppy or harddisk if it just contains a boot record which should be run?

I have tried that indeed and it did not work.
It seemed anyway rather fair to me as file size is 650 MB (being the raw'ed transformation of a Joliet ISO cdrom image), which would mean a rather "big" floppy format...

I have now tried as well by using the same image as a hard drive of the VM, and it does not boot either (I would have not anyway expected a different behavior than specifying it as the image to use for booting in the first step of the VM wizard procedure as I tried at first...?)

[fth0]

That would be woefully short of allowing for a GPT partition map. GPT specifies a partition map at the beginning, a backup partition map at the end, and reserved partitions set aside for specific purposes (i.e. a boot manager). I don't see any of that is at all compatible with "32 kb set aside at the beginning of the disk".

The MBR is in LBA 0 (512 B), the Primary GPT is typically in LBA 1 - 33 (16 kB), the first ISO 9660 Volume Descriptor is in LBA 64 (ISO sector 16), and the Backup GPT is at some high LBA. Note that it's easy to get confused by two different sector sizes (512 and 2048) being applied to the same ISO image, which is a single image where all booting systems are mixed together (not a concatenation!).

But since seeing is believing and I think you mentioned to have a Debian 12 ISO file in some other thread, verify the following yourself:

Code: Select all

Protective MBR:
000001b0  20 a6 00 00 00 00 00 00  fb 31 46 27 00 00 80 00  | ........1F'....|
000001c0  01 00 00 ee e0 fb 00 00  00 00 80 08 77 00 00 fe  |............w...|
000001d0  ff ff ef fe ff ff 00 5c  00 00 20 4a 00 00 00 00  |.......\.. J....|
000001e0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
000001f0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 55 aa  |..............U.|

Primary GPT:
00000200  45 46 49 20 50 41 52 54  00 00 01 00 5c 00 00 00  |EFI PART....\...|

APM:
00000800  50 4d 00 00 00 00 00 02  00 00 00 01 00 00 00 02  |PM..............|
00000810  41 70 70 6c 65 00 00 00  00 00 00 00 00 00 00 00  |Apple...........|

ISO 9660 Primary Volume Descriptor:
00008000  01 43 44 30 30 31 01 00  20 20 20 20 20 20 20 20  |.CD001..        |

ISO 9660 Boot Record Volume Descriptor:
00008800  00 43 44 30 30 31 01 45  4c 20 54 4f 52 49 54 4f  |.CD001.EL TORITO|
00008810  20 53 50 45 43 49 46 49  43 41 54 49 4f 4e 00 00  | SPECIFICATION..|

[fth0]

Here are the first 64 kB (zipped) of the ISO image, which I confirm to be bootable (on Qemu, but not on VirtualBox).

This is most probably a raw hard disk image and not an ISO 9660 image. There is no ISO 9660 Volume Descriptor inside the first 64 kB at all. It starts with a regular MBR and has at least two NTFS boot sectors, which search for the NT loader (NTLDR).

Before using the image as a virtual hard disk in a VirtualBox VM, use VBoxManage convertfromraw setup_winxp.iso setup_winxp.vdi and attach the resulting VDI file to a VM.

[davide8226]

Here are the first 64 kB (zipped) of the ISO image, which I confirm to be bootable (on Qemu, but not on VirtualBox).

This is most probably a raw hard disk image and not an ISO 9660 image. There is no ISO 9660 Volume Descriptor inside the first 64 kB at all. It starts with a regular MBR and has at least two NTFS boot sectors, which search for the NT loader (NTLDR).

Before using the image as a virtual hard disk in a VirtualBox VM, use VBoxManage convertfromraw setup_winxp.iso setup_winxp.vdi and attach the resulting VDI file to a VM.

Ah ok, sorry I misunderstood your request. Please find here attached the first 64k (zipped) of the original Joliet iso file.

[davide8226]

Here are the first 64 kB (zipped) of the ISO image, which I confirm to be bootable (on Qemu, but not on VirtualBox).

This is most probably a raw hard disk image and not an ISO 9660 image. There is no ISO 9660 Volume Descriptor inside the first 64 kB at all. It starts with a regular MBR and has at least two NTFS boot sectors, which search for the NT loader (NTLDR).

Before using the image as a virtual hard disk in a VirtualBox VM, use VBoxManage convertfromraw setup_winxp.iso setup_winxp.vdi and attach the resulting VDI file to a VM.

By converting the raw image to a VDI, it finally boots. Thank you!

P.S.: But so, after all these things, I am curious... Which is the diagnosis of the issue?

[fth0]

P.S.: But so, after all these things, I am curious... Which is the diagnosis of the issue?

I'm not sure what you mean by "the issue"? I don't see any open VirtualBox related issue.

[scottgus1]

Which is the diagnosis of the issue?

Since the image did not work as an ISO but did work as a disk, I would guess that the image contents weren't a CD, so the ISO reader in Virtualbox went "Pfftt, what's this?" and turned up its nose. Whereas the disk reader said "Oooo, this feel good!!" and went ahead happily, so I surmise it was really a disk image or close enough thereto.

[mpack]

I think the moral of this tale is that a hard disk image does not become an ISO simply because you changed the file extension. It remains a hard disk image, only now with a misleading extension.

[davide8226]

I think the moral of this tale is that a hard disk image does not become an ISO simply because you changed the file extension. It remains a hard disk image, only now with a misleading extension.

Ok, so the fact that it initially booted in Qemu and not in VirtualBox (and still does not) is not a source of concern?
I'd guess that the definitive proof would be writing the image on a real USB drive, and see what would happen...?

Anyway, I have solved my problem thanks to the suggestion I got here to convert it to VDI. So, nothing more to expect or complain on my side.

I'll let the discussion about any right or wrong VirtualBox behaviour to you, experts

Thanks again!

[davide8226]

I think the moral of this tale is that a hard disk image does not become an ISO simply because you changed the file extension. It remains a hard disk image, only now with a misleading extension.

Did not get your point, as ISOs are the same kind of files you can download for Linux distro to create bootable USB drives (to be written as raw via dd, e.g.).
And, to my knowledge, bootable USB format is not a Joliet but they are mostly bootable by VirtualBox as some of you said in a previous post.

So, to me, it seems that the points here are two:
a) the raw image was ok
B) what remains unexplained is (instead) why VirtualBox boots it as a hard disk and not when indicated as the bootable device during the creation wizard procedure of a VM (I mean, the raw image of USB pendrive and of a hard disk should be the same in terms of "format"...).

Anyway, up to you

Thanks again

Best,
D

[davide8226]

Which is the diagnosis of the issue?

Since the image did not work as an ISO but did work as a disk, I would guess that the image contents weren't a CD, so the ISO reader in Virtualbox went "Pfftt, what's this?" and turned up its nose. Whereas the disk reader said "Oooo, this feel good!!" and went ahead happily, so I surmise it was really a disk image or close enough thereto.

Ah ok, it may be that way...!