VirtualBox

Ticket #3911 (reopened defect)

Opened 7 months ago

Last modified 1 month ago

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

Reported by: ingo2 Assigned to:
Priority: major Component: virtual disk
Version: VirtualBox 3.0.4 Keywords: drive not ready
Cc: ingo.steiner@gmx.net Guest type: other
Host type: Linux

Description

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.

Attachments

VBox.log (42.8 kB) - added by ingo2 on 2009-05-02 12:48:07.
VBox.log (booting into OS/2-bootmanager -> "drive 1 not ready")
DISK1.MBR (0.5 kB) - added by mckinnis on 2009-06-18 23:50:47.
Master Boot Record from Disk 1 that indicates not ready
mbr-166.bin (0.5 kB) - added by ingo2 on 2009-06-19 12:21:48.
MBR of a bootmanager installation under VBox 1.6.6 where this bug was not yet present

Change History

2009-05-02 12:48:07 changed by ingo2

  • attachment VBox.log added.

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

2009-05-02 17:10:19 changed by 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

2009-05-09 01:22:01 changed by madbrain

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

2009-05-28 02:14:25 changed by 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.

(follow-up: ↓ 5 ) 2009-05-30 12:46:12 changed by ingo2

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

(in reply to: ↑ 4 ) 2009-06-18 06:14:39 changed by mckinnis

Replying to ingo2:

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

Confirmed. Running under Ubuntu 9.0.4.

2009-06-18 19:25:31 changed by ingo2

Today I checked with VBox 3.0.0._BETA1:

still the same (host Debian-Lenny amd64).

2009-06-18 20:07:19 changed by 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.

2009-06-18 20:13:16 changed by TrevorPH

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

2009-06-18 22:18:38 changed by 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.

2009-06-18 23:50:47 changed by mckinnis

  • attachment DISK1.MBR added.

Master Boot Record from Disk 1 that indicates not ready

2009-06-18 23:52:06 changed by 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.

2009-06-19 12:19:58 changed by 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.

2009-06-19 12:21:48 changed by ingo2

  • attachment mbr-166.bin added.

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

2009-06-19 12:35:17 changed by 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!

2009-06-19 15:50:24 changed by 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.

2009-06-23 18:00:27 changed by 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.

2009-06-25 15:45:11 changed by ingo2

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

2009-06-25 16:05:28 changed by sandervl73

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

2009-07-01 18:48:15 changed by mckinnis

Still there in the 3.0 release.

2009-07-01 20:01:08 changed by ingo2

Confirmed :-[

2009-08-05 17:13:20 changed by 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

2009-08-11 13:17:52 changed by 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

2009-08-11 13:41:47 changed by sandervl73

  • version changed from VirtualBox 2.2.2 to VirtualBox 3.0.4.

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

2009-08-11 21:10:19 changed by frank

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

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

2009-08-11 21:34:50 changed by ingo2

fix will be included in the next maintenance release

GREAT - 1000 THANKS to the VBox-Team, Ingo

2009-09-10 08:27:59 changed by frank

  • status changed from new to closed.
  • resolution set to fixed.

2009-09-11 11:38:00 changed by ingo2

Confirmed - it is definitely fixed in 3.0.6 - THANKS

2009-09-11 12:17:18 changed by frank

Thanks for your endurance :)

2009-10-12 03:39:41 changed by madbrain

  • status changed from closed to reopened.
  • resolution deleted.

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 .

2009-10-12 23:51:04 changed by 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.

© 2009 Sun Microsystems, Inc.
Contact – Privacy policy