Bootloader can't find boot volume, booting from 'cdrom-raw' under vmware

[aldeck]

hrev21847, real hardware and vmware, ​http://haikubeat.free.fr/files/testing/livecd_cue.zip (created on R5 with pauloestrela's script)

The bootloader loads well but can't find any boot volume on the cd (it finds them on harddrives though)

See attached serial log (real hardware, only the cd drive is plugged)

[aldeck]

serial log

[axeld]

What exactly do you mean by "the cd drive is plugged"? :-)

[aldeck]

that is, in this serial log, the harddrive was unplugged :-)

btw, sorry for the "HTML preview not available" on the attachment, first time it does this

[nielx]

Moving all livecd related tickets to alpha1

[mmu_man]

Ok, hrev24211 fixes loading of modules from the floppy. It still doesn't find the partition though.

[jackburton]

Can we close this ? It's working since hrev24224.

[aldeck]

I still have the problem with some of my test machines and vmware. I'd like to test a bit further.

[aldeck]

Ok, i re-tested, i got it to work on 3 real hardware machines. Good work Francois :)

It still doesnt work under vmware though, i'm seeing a (ultra fast) message before the bootloader starts:

"no boot path found, scan for all partitions..." "Could not locate any supported boot device!"

See attached serial log.

PS: mmu_man, can you add a haiku-cd.cue example or file somewhere, for us poor windows burners? :-) (see attached cue file)

[mmu_man]

Added 3rdparty/nero/haiku-cd.cue as hrev24230.

[mmu_man]

As for the serial log, it doesn't seem to find the tgz data... maybe your BIOS doesn't like 1.44 floppy emulation... IIRC some work with 2.88 only. Try changing the count=1440 to count=2880 in build/jam/ImageRules.

[aldeck]

Replying to mmu_man:

Try changing the count=1440 to count=2880 in build/jam/ImageRules.

Tried that without success.

[jackburton]

I can confirm this bug happening on vmware lplayer here.

[aldeck]

Ok, just tested a few more things:

1. booting from the hd bootloader, i can't continue booting on cd (even on a cd with a one track image only)

1b. continuing to boot on hd. both the bootimg and full image are found and automounted by tracker.

df gives:
/boot       bfs     100.0M    3.7M   QAM-P-W   /dev/disk/ata/0/master/raw
/bootimg    iso9660   3.2M      0M   ----P--   /dev/disk/atapi/1/master/0
/Haiku1     bfs     100.0M    5.0M   QAM-P--   /dev/disk/atapi/1/master/1

2. booting from the cd bootloader, continuing boot on hd. You can see below that the haiku image from the cd is not there.

   df gives:
   /boot       bfs     100.0M    3.7M   QAM-P-W   /dev/disk/ata/0/master/raw
   /bootimg    iso9660   3.2M      0M   ----P--   /dev/disk/atapi/1/master/raw
   

Hope this helps

[mmlr]

About VMWare: are you sure that VMWare emulates multi-track CD-Roms correctly at all? In fact, when using an image file of a CD there is no way to tell where one track starts or ends. This is due to the fact that this information is stored in the TOC of the CD, which is not part of images (hence why you have to use a CUE-Sheet to burn, as the application cannot know either). Under Bochs or QEMU, when emulating a CD from an image, a single track CD with the full size of the image is emulated because of that. I hacked in the -cdtoc option in the BeOS version of QEMU to specify the starting sectors of tracks to circumvent that. When emulating using a real CD as a source though, they will read and use the TOC of that CD. So if you are using VMWare with a CD image you might not be able to get this to work. What you can try to test whether or not the multi track CD is emulated correctly is to boot Haiku from the HD image and have the CD image attached and then see if you have both, the iso9660 and the BFS track available in the mount menu.

[aldeck]

Replying to mmlr:

About VMWare: are you sure that VMWare emulates multi-track CD-Roms correctly at all?

I'm testing with a real cd (which works on real hw), ide1:0.deviceType = "cdrom-raw" in the .vmx file.

[...] boot Haiku from the HD image and have the CD image attached and then see if you have both, the iso9660 and the BFS track available in the mount menu.

That's what i just tested in my previous comment. Sorry if i wasn't clear, and thanks for the infos :-)

[mmu_man]

You can also just use the floppy image and use the bfs image as a single track CD. For qemu: qemu -cdrom generated/haiku.image -fda generated/haiku-boot-floppy.image -boot a

[aldeck]

Replying to mmu_man:

You can also just use the floppy image and use the bfs image as a single track CD. For qemu: qemu -cdrom generated/haiku.image -fda generated/haiku-boot-floppy.image -boot a

François, i'm not sure you're replying to me, but if you read carefully my previous comment, i've basically tried this already to see if it could help you, besides i'm talking about running from the normal two tracks cd under vmware not qemu :-/

[mmu_man]

I was talking about testing cd images, as said it's not easy or even supported on qemu and vmware. So using a floppy image + haiku.image as single track cd instead should have the same functional behaviour, for testing, which avoids burning a cd.

[franxico]

Replying to aldeck:

It still doesnt work under vmware though, i'm seeing a (ultra fast) message before the bootloader starts:

"no boot path found, scan for all partitions..." "Could not locate any supported boot device!"

I kinda have the same message, but in real hardware:

"No boot path found, scan for all partitions *panic* mmu_free: asked to unmap out of range region (0x8010b000, size 1000) Press any key to reboot"

Tried with rev24521 built from Haikuware.

[mmadia]

Can this be re-tested or closed?

[aldeck]

Created a fresh dual track cd with, jam haiku-boot-cd, jam haiku-image, burnt with the .cue file under linux with Brasero.
It still works on real hardware. Although the issue on vmware is still there (reading from the raw cdrom drive).

Changing the title as part of issue was fixed back then, still a quite unlikely test-case but might help iron out things. Removing from milestone R1/alpha.

[mmu_man]

Also note with the upcoming fs layer atop ISO it might not be a problem anymore.

[aldeck]

Note it has never been a "problem" for me :) The question is do we want that to work or not?

Similar issue with an iso9660 created with jam haiku-cd, hrev29242 (tested booting ok on real hardware), not finding any boot volume (vmware with the real cd 'cdrom-raw')

Same when booting from the iso image file (ie: with ide0:0.deviceType = "cdrom-image", ide0:0.fileName = "haiku-cd.iso")

QEMU boots ok though: qemu -cdrom haiku-cd.iso

[aldeck]

(In #3451) duplicate, will update #1364 with this testcase

[aldeck]

quoting diver from duplicate #3451 "Vmware server can't boot off ISO, the same iso is working just fine in vbox"

[luroh]

aldeck: want to keep this one around still?

[aldeck]

Replying to luroh:

aldeck: want to keep this one around still?

Depends if the bug is around still :) I personally don't give a damn, but on principle i guess it doesn't hurt to keep it if someone is investigating a related issue in the future, did anyone test recently?

[luroh]

Doubt it, guess I'll have to give it a go.

[luroh]

If this is a bug in Haiku then yes it's still present in hrev39815. Tested with gcc2 versions of haiku.image + haiku-boot-cd.iso. CD burned in Linux with Brasero + cue file (cdrdao required). Tested in VMware Player 3.1.3, screenshot and serial output attached.

The same CD boots fine on real hardware, but hangs at the red rocket in Vbox 3.2.12.

[scottmc]

Can you recheck this with a recent Haiku build? Can you test it with both the nightly anyboot and then the CD ISO images burned to CDs and let us know how the testing goes?

[luroh]

Seems fixed. Tested with gcc2 hrev44849 versions of haiku.image + haiku-boot-cd.iso. CD burned in Linux with Brasero + cue file (cdrdao required). Tested in VMware Player 5.0.1. The CD also boots fine on real hardware.