IMG booting on Qemu but not on VirtualBox

[davide8226]

Dear all,
I have a img file that correctly boots with Qemu, but in VirtualBox I got "No bootable medium found".

Anyone with ideas?

[scottgus1]

Is the Qemu VM booting successfully from EFI? If so, the Virtualbox VM must, also.

As best as I can see, Virtualbox does not boot directly from an img file. How are you converting the img to a disk file Virtualbox can use?

[davide8226]

It is a raw .iso, i.e. the same you can dump on a USB drive (to install an OS, in this case).
The content is not EFI, it is an old-fashioned MBR.

It perfectly boots and runs on Qemu, but gets a "No bootable medium found" on VirtualBox...

[scottgus1]

It is a raw .iso, i.e. the same you can dump on a USB drive (to install an OS, in this case).

If the ISO were an actual bootable CD image that could be burned to a CD and a PC can boot from it, then it is usable in Virtualbox. Qemu may have extra capability for handling files that Virtualbox does not have.

Please test the img by burning it to a CD and trying to boot a physical computer from it. If the physical computer boots from it, then there could be a problem with Virtualbox. If the PC does not boot from it, then the problem is in the img.

What is the OS in the img? Do you have a download link so we can test the img?

[mpack]

I'm not sure that MBR is relevant to an ISO image. MBR is the PC-standard first sector on a DOS or Windows filesystem. The filesystem on a CD is described by ISO 9660.

Also, AFAIK "MBR" refers to the first sector on partitioned media (i.e. hard disks and USB drives) - it contains the partition map. The map indicates several potentially bootable volumes, each of which begins with a boot sector.

Certain kinds of media, e.g. floppies and CDs, never contain MBRs. There is only one partition, and the first sector is a boot sector (if bootable), not an MBR. AFAIK all of the code in the boot sector is intended to be executable.

The above is my understanding, I don't claim to be an expert on PC booting.

Additional wrinkle: I have a feeling that the legacy BIOS is designed to read the first sector and boot from it: i.e., as far as the legacy BIOS is concerned, an MBR doesn't exist. So the start of an MBR sector would indeed contain executable code. This code would decode the partition map and then load and jump to a volume boot sector.

The extent to which this applies to ISOs... dunno. I didn't think they worked the same way.

[mpack]

@Scott: I think "IMG" is just the conventional extension for ISO images on MacOS hosts. That's why VirtualBox accepts it in ISO selection dialogs. It can be booted from like any other ISO.

[fth0]

FWIW, on a macOS host, the VirtualBox optical disk file selection dialog offers "All virtual optical disk files (*.dmg *.cue *.viso *.iso *.cdr)" in addition to "All files (*)" and the single choices.

In QEMU, ".img" is used as a file extension for virtual disk images, especially in command examples where you don't want to limit yourself to one of the choices like ".qcow2", ".vdi" or ".vmdk". In consequence, it's often used for raw images of all kind.

[mpack]

Yes, "raw" or "img" indicates a raw disk image. "ISO" indicates a raw disk image of an optical disk containing an ISO 9660 (or derivative) filesystem.

IMO, if it's an ISO then it should be called an ISO, not raw or img. When I saw "img" being used here I first thought we were talking about floppy images.

[mpack]

@Davide:

I think Scott has to be on the right track when he asked if it's an EFI (GPT) image. A EFI BIOS would not execute the code in sector 0, so it would not be upset if you put crap in there. Instead the EFI BIOS has native support for GPT partitions, it will go looking for the boot manager partition (usually containing a FAT filesystem) and run the code from there.

[davide8226]

Sorry, I did not get your point.

The raw .iso has been "transformed" from Joliet ISO format to a raw image that can be written on and booted from a USB drive. The fact that there should not be issues in the conversion should be witnessed by the fact that Qemu is able to boot (and run, afterwards) the setup procedure of the involved OS.

If I look at the MBR, it seems correctly formed. Here is a dump of it, anyway:

00000000: 33c0 8ed0 bc00 7cfb 5007 501f fcbe 1b7c 3.....|.P.P....|
00000010: bf1b 0650 57b9 e501 f3a4 cbbd be07 b104 ...PW...........
00000020: 386e 007c 0975 1383 c510 e2f4 cd18 8bf5 8n.|.u..........
00000030: 83c6 1049 7419 382c 74f6 a0b5 07b4 078b ...It.8,t.......
00000040: f0ac 3c00 74fc bb07 00b4 0ecd 10eb f288 ..<.t...........
00000050: 4e10 e846 0073 2afe 4610 807e 040b 740b N..F.s*.F..~..t.
00000060: 807e 040c 7405 a0b6 0775 d280 4602 0683 .~..t....u..F...
00000070: 4608 0683 560a 00e8 2100 7305 a0b6 07eb F...V...!.s.....
00000080: bc81 3efe 7d55 aa74 0b80 7e10 0074 c8a0 ..>.}U.t..~..t..
00000090: b707 eba9 8bfc 1e57 8bf5 cbbf 0500 8a56 .......W.......V
000000a0: 00b4 08cd 1372 238a c124 3f98 8ade 8afc .....r#..$?.....
000000b0: 43f7 e38b d186 d6b1 06d2 ee42 f7e2 3956 C..........B..9V
000000c0: 0a77 2372 0539 4608 731c b801 02bb 007c .w#r.9F.s......|
000000d0: 8b4e 028b 5600 cd13 7351 4f74 4e32 e48a .N..V...sQOtN2..
000000e0: 5600 cd13 ebe4 8a56 0060 bbaa 55b4 41cd V......V.`..U.A.
000000f0: 1372 3681 fb55 aa75 30f6 c101 742b 6160 .r6..U.u0...t+a`
00000100: 6a00 6a00 ff76 0aff 7608 6a00 6800 7c6a j.j..v..v.j.h.|j
00000110: 016a 10b4 428b f4cd 1361 6173 0e4f 740b .j..B....aas.Ot.
00000120: 32e4 8a56 00cd 13eb d661 f9c3 5461 6265 2..V.....a..Tabe
00000130: 6c6c 6120 6465 6c6c 6520 7061 7274 697a lla delle partiz
00000140: 696f 6e69 206e 6f6e 2076 616c 6964 6100 ioni non valida.
00000150: 4572 726f 7265 206e 656c 2063 6172 6963 Errore nel caric
00000160: 616d 656e 746f 2064 656c 2073 6973 7465 amento del siste
00000170: 6d61 206f 7065 7261 7469 766f 0053 6973 ma operativo.Sis
00000180: 7465 6d61 206f 7065 7261 7469 766f 206d tema operativo m
00000190: 616e 6361 6e74 6500 0000 0000 0000 0000 ancante.........
000001a0: 0000 0000 0000 0000 0000 0000 0000 0000 ................
000001b0: 0000 0000 002c 507d 949f c2ea 0000 8001 .....,P}........
000001c0: 0100 0cfe ffd2 3f00 0000 c1ff ef00 0000 ......?.........
000001d0: 0000 0000 0000 0000 0000 0000 0000 0000 ................
000001e0: 0000 0000 0000 0000 0000 0000 0000 0000 ................
000001f0: 0000 0000 0000 0000 0000 0000 0000 55aa ..............U.

[fth0]

This is at least not a protective MBR (as used on GPT partitioned disks).

Please reproduce the failing boot and provide a (zipped) VBox.log file for further analysis.

[davide8226]

This is at least not a protective MBR (as used on GPT partitioned disks).

Please reproduce the failing boot and provide a (zipped) VBox.log file for further analysis.

Fine, here is attached!

For the sake of clarity and details, please notice that for this trial I have created a brand new machine (named "Test") and set the .iso as the image to use for booting in related field of dialog of the first step of the VM creation wizard procedure (I am sure that all these things can anyway be inferred from the log )

[mpack]

This is at least not a protective MBR (as used on GPT partitioned disks).

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

What I think you might find is that the boot sector is ignored because a UEFI system always boots from the boot manager on the primary drive. It might then look for a UEFI-aware boot folder on the CD, load and run a startup program from there. Hence my comment that Scott is moving on the right lines by talking about EFI.

[fth0]

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.

[fth0]

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.

For example, ISO images suitable for USB sticks often contain the MBR/GPT/APM in this System Area. The USB stick can then be used like a hard disk or like an optical disk.