"Drive 1 is not ready, Press any Key." before OS/2-Bootmanager starts => Fixed in SVN

[ingo2]

I have an annoying observation which exists since VBox 2.1.x (maybe already in last 2.0.x):

I've got several VDI's with an installation of OS/2 using the IBM bootmanager. They all boot smoothly in VBox 1.6.6. But when booting same vdi's in VBox 2.1 or 2.2 boot process stops before bootmanager menu is displayed and I get a message at the bottom of the screen saying literaly:

Drive 1 is not ready, Press any Key.

When hitting return booting continues normal. This does not happen when OS/2 is installed on 1st primary partition without use of bootmanager! In this case boot proceeds normally.

[ingo2]

VBox.log (booting into OS/2-bootmanager -> "drive 1 not ready")

[ingo2]

Here the probably relevant section from VBox.log:

00:05:09.935 Guest Log: BIOS: int13_harddisk: function 41, ELDL out of range 8c
609 	00:05:09.935 Guest Log: BIOS: int13_harddisk: function 41, ELDL out of range 8d
610 	00:05:09.935 Guest Log: BIOS: int13_harddisk: function 41, ELDL out of range 8e
611 	00:05:09.936 Guest Log: BIOS: int13_harddisk: function 41, ELDL out of range 8f
612 	00:05:09.936 Guest Log: BIOS: int13_harddisk: function 41, ELDL out of range 90
613 	00:05:09.937 Guest Log: BIOS: int13_harddisk: function 41, ELDL out of range 91
614 	00:05:09.937 Guest Log: BIOS: int13_harddisk: function 41, ELDL out of range 92
615 	00:05:09.938 Guest Log: BIOS: int13_harddisk: function 41, ELDL out of range 93
616 	00:05:09.938 Guest Log: BIOS: int13_harddisk: function 41, ELDL out of range 94
617 	00:05:09.939 Guest Log: BIOS: int13_harddisk: function 41, ELDL out of range 95
618 	00:05:09.939 Guest Log: BIOS: int13_harddisk: function 41, ELDL out of range 96
619 	00:05:09.940 Guest Log: BIOS: int13_harddisk: function 41, ELDL out of range 97

[madbrain]

I am seeing this problem as well. Same error message with boot manager, no error when booting directly from OS/2 primary partition.

[TrevorPH]

I also see this and it halts the boot process so that it needs manual intervention. On VBox 2.0.4 (the last version that works correctly for all my OS/2 needs) it works perfectly.

The boot manager error message was a problem a few years ago with (I think) AMI BIOSes. I did some disassembling of the boot manager code at that point and found that the problem was that BM gets the list of hard disks using INT 13 and then iterates through them checking that they are responding - the bug in the AMI BIOS then was that it was reporting IDE CD drives as hard disks but the test ready then failed and caused this error. But it was a long time ago so my recollection of the problem may not be accurate.

[ingo2]

This bug still persists in Version 2.2.4 which I tested today.

[mckinnis]

Replying to ingo2:

This bug still persists in Version 2.2.4 which I tested today.

Confirmed. Running under Ubuntu 9.0.4.

[ingo2]

Today I checked with VBox 3.0.0._BETA1:

still the same (host Debian-Lenny amd64).

[mckinnis]

Happens with 2.2.4 in WinXP as well, so I do not think it is a host problem.

I would consider it a minor bug since it does not prevent the IPL.

[TrevorPH]

Actually it does stop the IPL since it waits forever for a keypress.

[mckinnis]

I guess I should have said that it does not prevent the IPL completely.

Looks like a virtual BIOS problem to me. It is somewhat akin to the message one gets from the hardware when one tries to boot to a non-bootable disk. The virtual BIOS does not appear to recognize the MBR on the drive when bootmanager is installed.

[mckinnis]

Master Boot Record from Disk 1 that indicates not ready

[mckinnis]

I don't know if it will help, but I have uploaded an image of the master boot record from the drive that generates the not ready message.

[ingo2]

so that really was a good idea. So I will also upload the MBR from an installation with bootmanager under VBox 1.6.6. At this time all was still ok without the nasty "Drive1 not ready ..."

My guess is that something in virtual disk handling has changed - probably due to the facht that support for other disk-formats (like VMDK) was added by Sun.

[ingo2]

MBR of a bootmanager installation under VBox 1.6.6 where this bug was not yet present

[ingo2]

Forgot to mention:

attaching the very same VDI (from VBox 1.6.6, see mbr-166.bin) to VBox >2.0 brings up the "Drive1 not ready ..." message!

[ingo2]

I did compare both MBR's and found nothing essential.

The MBR is exactly the same (bytes 0 - 445). The only difference is in the partition table, first missmatch at byte 453.

Seems it is the virtual BIOS.

[ingo2]

Today I found there is a VBox 2.0.8 version available (latest in 2.0 branch).

That one still is ok with regard to this bug - probably that helps.

Would be nice to hear a comment from VBox-team whether they consider fixing this issue.

[ingo2]

Checked with VBox 3.0.0 Beta2 -> bug still persists :-(

[sandervl73]

We've seen your report, but haven't had time to investigate yet. Thanks.

[mckinnis]

Still there in the 3.0 release.

[ingo2]

Confirmed :-[

[ingo2]

Unfortunately it still persists in v3.0.4

It's really annoying, as you usually setup a sevice partition which requires use of OS/2-bootmanager.

Please fix

[ingo2]

Found this additional information:

int13 function 41 -> (with BX = 55AAh) is a check for the "Installation of the INT 13 
                     BIOS Extensions" in Memory.                                     

Seems this BIOS Extension is not implemented in the emulated BIOS, or has been removed in VBox versions > 2.0.8

[sandervl73]

That code hasn't changed as far as I can see.

[frank]

We finally found the reason for this bug. The fix will be included in the next maintenance release.

[ingo2]

fix will be included in the next maintenance release

GREAT - 1000 THANKS to the VBox-Team, Ingo

[ingo2]

Confirmed - it is definitely fixed in 3.0.6 - THANKS

[frank]

Thanks for your endurance :)

[madbrain]

I'm running 3.0.8 and this is still not fixed for me, unfortunately. Boot manager still displays this message and pauses. I did not try 3.0.6 .

[madbrain]

After I closed the virtual machine (as opposed to CTRL-ALT-DEL within it) and rebooted the host, the problem went away for good.