Alpha ISO will not boot in VMWare Fusion 2.05

[nicholas]

The haiku-alpha.iso from haiku-r1a1-rc-hrev32945-x86gcc2hybrid-iso.zip does not boot in VMWare Fusion 2.05 yet boots perfectly well in VirtualBox 3.04 on the same machine.

I've tried a couple of earlier builds and the same problem occurs.

I've attached the serial debug output to this ticket.

[nicholas]

Screengrab of failed boot process

[VinDuv]

Same problem here, with the same Fusion version.
Some comments:

• It is not just about booting: any ISO image attached to the VM will not be recognized by Haiku.
• Booting and using reals CDs works without problems in my case.

[VinDuv]

Serial log when attaching an image/a real CD to the VM

[nicholas]

I just noticed that this ticket is assigned to Axel D who is on vacation until 23rd September.

The Alpha 1 release slated for 14th September so unless it is re-assigned to someone else the bug will stop anyone who uses VMWare Fusion from testing Haiku on release day.

Is it possible to have this re-assigned?

[marcusoverhagen]

This appears to be a problem with partition scanning. Perhaps Ingo can look into it. Adding to alpha1 milestone.

[bonefish]

From the disk device manager perspective the log looks OK:

KDiskDeviceManager::_ScanPartition(/dev/disk/atapi/0/slave/0)
[...]
  trying: file_systems/cdda/v1
[...]
  returned: 0.6
[...]
  scanning with: file_systems/iso9660/v1

Whatever goes wrong, it's either in the scan_partition() hook of the ISO9660 module (given how chatty it is earlier, the lack of output is probably not a good sign) or later.

I don't have the time to look into this, so whoever wants to examine the problem, feel free.

[mmlr]

It looks basically OK. The disk is recognized and the session module is picked up. But the partition offset and size are off limits. Also note the "failed to publish partition 2: Invalid Argument", which is probably caused by the messed up negative size. The session partitioning_system module uses the disc Table Of Contents (TOC) to determine session offsets and sizes, so most probably the TOC data returned is invalid. It is possible that reading the TOC failed due to problems in ATA, that the TOC data returned is in a format we do not support/account for, or that the emulation is broken. The problem with the CD TOC is that it is on a part of the CD that is not included with the ISO images. Therefore the emulation has to come up with a guess as to how the CD is layouted (usually they assume a single session with the size of the image). This killed off the dual track BeOS CD images, as they relayed on this information but couldn't provide it as part of the image. BeOS CD images could therefore not be booted in emulators unless you had a way to specify this extra information (I've added the -cdtoc option to QEMU to do that for example, other emulators may have had support for the CUE sheets that essentially only exist to contain that information). To verify any of this you'd need a version of the session partitioning_system module that has debugging enabled and dumps the TOC information it reads. I will upload and provide a link to a minimal CD image that only contains the boot floppy image with the debugging added. Please try this image and post a new serial log from that.

[mmlr]

Please try ​http://haiku.mlotz.ch/haiku-boot-only.iso.zip and attach another serial log. Under QEMU btw. the session module fails with an invalid TOC as well, but it then simply detects the ISO9660 filesystem directly and publishes that as a partition directly.

[korli]

vmware player 2.05 haiku-boot-only.iso

[nicholas]

Serial debug log for haiku-boot-only.iso

[nicholas]

Uploading VirtualBox 3.04 serial debug log in case it can be of use.

[nicholas]

VirtualBox 3.04 serial debug log

[nicholas]

Serial debug log for haiku-boot-only.iso

[nicholas]

Re-attached FULL serial debug lof for VMWare Fusion 2.05 using haiku-boot-only.iso

[mmlr]

The problem is that the TOC returned by VMWare has an incorrect track start value. It has pseconds set to 0, but it really should be 2 to yield an LBA of 0. This seems to be a bug in VMWare. Still we could be smart about it and recover/warn about this case. Using LBA 0 if all p values are 0 should be sensible.

[mmlr]

Worked around in hrev32990, applied to alpha branch in hrev32991. Closing it, please test when images become available and reopen if still present.

[nicholas]

Same thing happens with the haiku-r1a1-rc-hrev32998-x86gcc2hybrid-iso

Attaching debug log for this version.

[nicholas]

Serial debug log for haiku-r1a1-rc-hrev32998-x86gcc2hybrid-iso

[mmlr]

That's sadly not a full log. I think serial debug output has been disabled for the alpha, so you need to manually enable it from the boot loader (pressing space at the start of the boot process). Can you please post a full log?

[korli]

Should be fixed in hrev33003

[nicholas]

Sorry, i forgot to enable the boot option.

Attaching full log now.

[nicholas]

Serial debug log for haiku-r1a1-rc-hrev32998-x86gcc2hybrid-iso FULL DEBUG

[korli]

Applied in alpha branch in hrev33013. Closing it, please test when images become available and reopen if still present.

[nicholas]

Works perfectly with Alpha1 build hrev33023.

Thanks for fixing it so quickly! :)