Opened 10 years ago

Closed 10 years ago

Last modified 10 years ago

#4439 closed bug (fixed)

Alpha ISO will not boot in VMWare Fusion 2.05

Reported by: nicholas Owned by: nobody
Priority: normal Milestone: R1/alpha1
Component: - General Version: R1/alpha1
Keywords: Cc:
Blocked By: Blocking:
Has a Patch: no Platform: x86

Description

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.

Attachments (8)

Haiku Alpha VMWFusion.jpg (77.5 KB ) - added by nicholas 10 years ago.
Screengrab of failed boot process
log.txt (6.6 KB ) - added by VinDuv 10 years ago.
Serial log when attaching an image/a real CD to the VM
serial.txt (25.2 KB ) - added by korli 10 years ago.
vmware player 2.05 haiku-boot-only.iso
HaikuAlphaSerialDebug.2.txt (70.7 KB ) - added by nicholas 10 years ago.
Serial debug log for haiku-boot-only.iso
Vbox_Serial_Debug.txt (4.3 KB ) - added by nicholas 10 years ago.
VirtualBox 3.04 serial debug log
HaikuAlphaSerialDebug.txt (71.2 KB ) - added by nicholas 10 years ago.
Serial debug log for haiku-boot-only.iso
HaikuAlphaSerialDebug.3.txt (9.0 KB ) - added by nicholas 10 years ago.
Serial debug log for haiku-r1a1-rc-hrev32998-x86gcc2hybrid-iso
HaikuAlphaSerialDebug.4.txt (68.8 KB ) - added by nicholas 10 years ago.
Serial debug log for haiku-r1a1-rc-hrev32998-x86gcc2hybrid-iso FULL DEBUG

Download all attachments as: .zip

Change History (25)

by nicholas, 10 years ago

Attachment: Haiku Alpha VMWFusion.jpg added

Screengrab of failed boot process

comment:1 by VinDuv, 10 years ago

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.

by VinDuv, 10 years ago

Attachment: log.txt added

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

comment:2 by nicholas, 10 years ago

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?

comment:3 by marcusoverhagen, 10 years ago

Milestone: R1R1/alpha1
Owner: changed from axeld to bonefish

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

comment:4 by bonefish, 10 years ago

Owner: changed from bonefish to nobody

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.

comment:5 by mmlr, 10 years ago

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.

comment:6 by mmlr, 10 years ago

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.

by korli, 10 years ago

Attachment: serial.txt added

vmware player 2.05 haiku-boot-only.iso

by nicholas, 10 years ago

Attachment: HaikuAlphaSerialDebug.2.txt added

Serial debug log for haiku-boot-only.iso

comment:7 by nicholas, 10 years ago

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

by nicholas, 10 years ago

Attachment: Vbox_Serial_Debug.txt added

VirtualBox 3.04 serial debug log

by nicholas, 10 years ago

Attachment: HaikuAlphaSerialDebug.txt added

Serial debug log for haiku-boot-only.iso

comment:8 by nicholas, 10 years ago

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

comment:9 by mmlr, 10 years ago

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.

comment:10 by mmlr, 10 years ago

Resolution: fixed
Status: newclosed

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

comment:11 by nicholas, 10 years ago

Resolution: fixed
Status: closedreopened

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

Attaching debug log for this version.

by nicholas, 10 years ago

Attachment: HaikuAlphaSerialDebug.3.txt added

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

comment:12 by mmlr, 10 years ago

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?

comment:13 by korli, 10 years ago

Resolution: fixed
Status: reopenedclosed

Should be fixed in hrev33003

comment:14 by nicholas, 10 years ago

Resolution: fixed
Status: closedreopened

Sorry, i forgot to enable the boot option.

Attaching full log now.

by nicholas, 10 years ago

Attachment: HaikuAlphaSerialDebug.4.txt added

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

comment:15 by korli, 10 years ago

Resolution: fixed
Status: reopenedclosed

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

comment:16 by nicholas, 10 years ago

Works perfectly with Alpha1 build hrev33023.

Thanks for fixing it so quickly! :)

comment:17 by nielx, 10 years ago

Version: R1 alpha1R1/alpha1
Note: See TracTickets for help on using tickets.