VirtualBox

Ticket #3911 (closed defect: fixed)

Opened 5 years ago

Last modified 4 years ago

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

Reported by: ingo2 Owned by:
Priority: major Component: virtual disk
Version: VirtualBox 3.0.4 Keywords: drive not ready
Cc: ingo.steiner@… 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 Download (42.8 KB) - added by ingo2 5 years ago.
VBox.log (booting into OS/2-bootmanager -> "drive 1 not ready")
DISK1.MBR Download (512 bytes) - added by mckinnis 5 years ago.
Master Boot Record from Disk 1 that indicates not ready
mbr-166.bin Download (512 bytes) - added by ingo2 5 years ago.
MBR of a bootmanager installation under VBox 1.6.6 where this bug was not yet present

Change History

Changed 5 years ago by ingo2

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

comment:1 Changed 5 years ago 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

comment:2 Changed 5 years ago 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.

comment:3 Changed 5 years ago 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.

comment:4 follow-up: ↓ 5 Changed 5 years ago by ingo2

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

comment:5 in reply to: ↑ 4 Changed 5 years ago 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.

comment:6 Changed 5 years ago by ingo2

Today I checked with VBox 3.0.0._BETA1:

still the same (host Debian-Lenny amd64).

comment:7 Changed 5 years ago 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.

comment:8 Changed 5 years ago by TrevorPH

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

comment:9 Changed 5 years ago 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.

Changed 5 years ago by mckinnis

Master Boot Record from Disk 1 that indicates not ready

comment:10 Changed 5 years ago 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.

comment:11 Changed 5 years ago 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.

Changed 5 years ago by ingo2

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

comment:12 Changed 5 years ago 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!

comment:13 Changed 5 years ago 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.

comment:14 Changed 5 years ago 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.

comment:15 Changed 5 years ago by ingo2

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

comment:16 Changed 5 years ago by sandervl73

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

comment:17 Changed 5 years ago by mckinnis

Still there in the 3.0 release.

comment:18 Changed 5 years ago by ingo2

Confirmed :-[

comment:19 Changed 5 years ago 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

comment:20 Changed 5 years ago 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

comment:21 Changed 5 years ago 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.

comment:22 Changed 5 years ago 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.

comment:23 Changed 5 years ago by ingo2

fix will be included in the next maintenance release

GREAT - 1000 THANKS to the VBox-Team, Ingo

comment:24 Changed 5 years ago by frank

  • Status changed from new to closed
  • Resolution set to fixed

comment:25 Changed 5 years ago by ingo2

Confirmed - it is definitely fixed in 3.0.6 - THANKS

comment:26 Changed 5 years ago by frank

Thanks for your endurance :)

comment:27 Changed 5 years ago by madbrain

  • Status changed from closed to reopened
  • Resolution fixed 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 .

comment:28 Changed 5 years ago 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.

comment:29 Changed 4 years ago by klaus

  • Status changed from reopened to closed
  • Resolution set to fixed
Note: See TracTickets for help on using tickets.

www.oracle.com
ContactPrivacy policyTerms of Use