VirtualBox

Ticket #7415 (reopened defect)

Opened 5 years ago

Last modified 4 weeks ago

VB does not support LBA-64

Reported by: knguyen Owned by:
Priority: major Component: other
Version: VirtualBox 3.2.8 Keywords:
Cc: Guest type: Windows
Host type: Linux

Description (last modified by michaln) (diff)

Host = Fedora Core 64bit Guest = Windows Server 2003 64bit

Host has a disk-array configured in raid6 mode, using LBA64 to hold 40TB, /dev/sdb Use VBoxManage to create vmdk file that linked to /dev/sdb Register vmdk file to windows-VM

First-boot: OK. Windows VM was able to 'see' the new disk , disk1, in diskmgmt.msc. Perform conversion to GPT disk to fully use 40TB..

Second-boot: FAILED. Windows VM cannot be booted. VB log file show this: 0:00:02.857 Guest Log: BIOS: CDROM boot failure code : 0003 00:00:02.857 Guest Log: BIOS: Boot from CD-ROM failed 00:00:02.860 Guest Log: BIOS: Booting from Hard Disk... 00:00:03.094 Guest Log: BIOS: int13_harddisk: function 15, unmapped device for ELDL=82 00:00:03.157 Guest Log: int13_harddisk: function 42. Can't use 64bits lba

forum discussion:  http://forums.virtualbox.org/viewtopic.php?f=7&t=34131&p=152869#p152869

Attachments

virtualbox_4_3_30_64bit_edd.diff.gz Download (107.9 KB) - added by sobomax 5 weeks ago.
Patch to implement 64-bit EDD in BIOS for v4.3.30
virtualbox_5_0_0_64bit_edd.diff.gz Download (109.5 KB) - added by sobomax 5 weeks ago.
Patch to implement 64-bit EDD in BIOS for v5.0.0
virtualbox_4_3_30_64bit_edd.rev1.diff.gz Download (103.6 KB) - added by sobomax 5 weeks ago.
Patch to implement 64-bit EDD in BIOS for v4.3.30 (revised to replace OpenWatcom bits)
virtualbox_5_0_0_64bit_edd.rev1.diff.gz Download (105.2 KB) - added by sobomax 5 weeks ago.
Patch to implement 64-bit EDD in BIOS for v5.0.0 (revised to replace OpenWatcom bits)
virtualbox_5_0_0_64bit_edd.rev2.2.diff Download (28.8 KB) - added by sobomax 5 weeks ago.
Patch to implement 64-bit EDD in BIOS for v5.0.0 (revised to keep VBoxSCSI API compatible)
virtualbox_5_0_0_64bit_edd.rev2.diff Download (28.8 KB) - added by sobomax 5 weeks ago.
Patch to implement 64-bit EDD in BIOS for v5.0.0 (revised to keep VBoxSCSI API compatible)

Change History

comment:1 Changed 5 years ago by TrenShadow

Same issue here.

Host = Solaris Express 11 64bit Guest = Windows Server 2003 32bit (Windows Home Server)

Host has 4TB zpool with a zfs block device volume created on top of it, then converted to raw vmdk. Guest has 200GB vdi mounted as SATA 0 as boot drive, and this 4TB vmdk mounted as SAS 0.

Booting guest and manipulating the 4TB drive as a MBR type partition table (limited to 2TB) works fine. When I convert to GPT and reboot (even manually selecting the 200GB SATA as boot drive) it fails to boot with error:

00:00:10.007 Guest Log: BIOS: Booting from Hard Disk... 00:00:10.258 Guest Log: BIOS: int13_harddisk: function 15, unmapped device for ELDL=82 00:00:10.419 Guest Log: int13_harddisk: function 42. Can't use 64bits lba

comment:2 Changed 5 years ago by klaus

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

Booting off a MBR formatted disk bigger than 2T doesn't work. MBR partitioning doesn't support more than 2T, so you're asking for something which is impossible. See the problems with the 3T hard disks which just came out. Ask Microsoft if you don't believe what I'm saying. They support GPT only for non-boot drives in systems using a traditional BIOS. Any OS which uses the BIOS to access such big disks is severely broken.

EFI would in principle support booting off a disk partitioned with GPT, however this isn't a supported config at the moment for anything but MacOSX.

comment:3 Changed 4 years ago by JurgenD

  • Status changed from closed to reopened
  • Resolution invalid deleted

I do reopen this ticket because the devteam did not read pretty well the ticket.

I do have the same problem with FreeBSD 8 and pure GPT partitioning. There is no MBR in such case at all. The GPT comes in to solve the 2T limit, as the 4 primary partition limits. The previous poster did mention, he started with MBR, but converted his disk to GPT.

I did test this with a image from a real system. The image does run perfectly on other hypervisors, but Virtualbox fails with the error.

It seems virtualbox fails in FreeBSD x64 to use a GPT format with the error:

FATAL: int13_harddisk: function 42. Can't use 64 bits lba

comment:4 Changed 4 years ago by peetaur

I have the same problem, but my boot disk is not large; it is only 256 MB, with a GPT label.

I was able to boot with 2 256 GB disks and 5 3TB virtual disks attached, but after adding the ZFS file system to the larger disks (which I assume must be setting up a 64 bit LBA), the next boot failed. The large disks actually seemed to work perfectly fine before the reboot, since the OS was handling it rather than VirtualBox. VirtualBox shouldn't need to read my 3TB disks at all. (FYI: The small root system is also ZFS, and booted properly before adding more disks)

Certainly you could add a simple feature, to just let us boot off of the supported small disk we select, forgetting about whatever errors/lack of support there might be on/for the other disks.

comment:5 Changed 12 months ago by thesnaken

I know this an old thread, but it has never been properly addressed and evidently the bug still exists in VB 4.3.16. I have a FreeBSD with root-on-ZFS which works fine if it's the only drive. When I attach my 4TB drive as a raw device, the VM starts up fine but only the first time, i.e., before any geometry is created on that raw drive. However, once I put a GPT on it and add a ZFS partition, reboot results in:

int13_harddisk: function 42. Can't use 64bits lba

I tried attaching the drive to a SATA and a SCSI controllers as suggested elsewhere but to no avail. The raw drive has no boot code so there is no reason for VB to even look at that drive at boot time.

I'd really appreciate if someone could look into this. I'm trying to set up a NAS with a ZFS mirror over two physical drives which is not possible at the moment.

comment:6 Changed 6 weeks ago by sobomax

The issue is still valid. At the very least, the handling for that condition should be improved - instead of locking the emulator solidly (in fact it even blocks ctrl-alt-delete), the i/o function should just return error when 64-bit LBA is requested. Right now, it prevents operating system from booting even if all the boot loader code is trying to do is to read backup GPT table, which is usually at the end of the physical volume. In most cases even if that cannot be read the boot would be able to proceed properly, as long as the kernel and other boot files are within the first 2TB, which in practice is a condition that can be easily satisfied.

comment:7 Changed 5 weeks ago by sobomax

Suggested patch against 4.3.30 to implement that missing functionality is attached. I'll post patch for 5.x soon.

Changed 5 weeks ago by sobomax

Patch to implement 64-bit EDD in BIOS for v4.3.30

comment:8 Changed 5 weeks ago by michaln

  • Description modified (diff)

The patch looks reasonable, but if you want it to be accepted, we'll need two things: a) leave the Open Watcom files entirely out of it; we can implement the missing routines ourselves, and b) explicitly provide it under a MIT license or sign the Contributor Agreement (see https://www.virtualbox.org/wiki/Contributor_information ).

Changing the VBoxSCSI interface must be done very carefully as it may break saved states, so this will need attention.

Also, I'd stick with 'lba' instead of 'lba64' etc., it would reduce the size of the patch. Or is there some pressing need to rename the variables/struct fields?

comment:9 Changed 5 weeks ago by sobomax

Done and done. WRT VBoxSCSI, I think that particular interface only affects interaction between VBoxSCSI and BIOS, since both are embedded into the same binary there is no way for them to mismatch. Technically it's possible to make the interface fully backward compatible by just adding special case to map cbCDB == 0 into cbCDB = 16, but IMHO that would make interface even uglier than it already is. The OCA is signed and submitted. Please let me know if something else is needed from me.

Thanks!

Changed 5 weeks ago by sobomax

Patch to implement 64-bit EDD in BIOS for v5.0.0

Changed 5 weeks ago by sobomax

Patch to implement 64-bit EDD in BIOS for v4.3.30 (revised to replace OpenWatcom bits)

Changed 5 weeks ago by sobomax

Patch to implement 64-bit EDD in BIOS for v5.0.0 (revised to replace OpenWatcom bits)

comment:10 Changed 5 weeks ago by michaln

You probably didn't consider the case where VirtualBox is upgraded and a saved state from the previous version loaded. Then there's new VBoxSCSI "hardware" talking to the old BIOS code. So unfortunately yes, there is a trivial way for them to mismatch.

If you could please fix that, it'd be great. Yes, the interface is ugly because it was designed in a hurry without knowing the full requirements, but it still does the job.

Also, please leave the VBoxBiosAlternative bits out of the patch, we'll have to handle that ourselves anyway. It's just unnecessarily polluting the patch.

Other than that it looks great!

Also, can you please suggest some simple setup suitable for testing the patch?

comment:11 Changed 5 weeks ago by michaln

Oh, one more question: What's the purpose of setting PCHS for SCSI devices (which have no physical geometry)?

Changed 5 weeks ago by sobomax

Patch to implement 64-bit EDD in BIOS for v5.0.0 (revised to keep VBoxSCSI API compatible)

Changed 5 weeks ago by sobomax

Patch to implement 64-bit EDD in BIOS for v5.0.0 (revised to keep VBoxSCSI API compatible)

comment:12 Changed 5 weeks ago by michaln

Great, thanks. Now just the last thing... how do I test that the patch actually does what it says it does? Not that I don't believe you but we need some test scenario to prevent future regressions.

comment:13 Changed 5 weeks ago by michaln

Actually, one more thing. I can't find a record of you signing the OCA, but maybe you only signed it within the last few days? What was the date you signed it? Thanks.

comment:14 Changed 4 weeks ago by sobomax

michaln, the OCA was emailed on July 30st to the "oracle-ca_us@…". Please let me know if you still can't find it, I'll re-submit.

As for the test case, I am working on a reasonably small bootable VMDK FreeBSD image that would simulate 8TB GPT disk with kernel and other files located past 2TB mark, so that you can plug it in and test that it does what it's expected to do. Give me day or two to get that together.

comment:15 Changed 4 weeks ago by michaln

I can't find you on the OCA list (  http://www.oracle.com/technetwork/community/oca-486395.html ), assuming I'm looking for Maksym Sobolyev or perhaps some variant spelling. That said, I don't know how long it takes for the OCA to be processed, so if you signed it just a few days ago I'd wait a bit longer. I expect it takes at least a week, basically I wanted to know if you had signed the OCA a while ago or just recently.

A disk image with a test setup would be most welcome.

Note: See TracTickets for help on using tickets.

www.oracle.com
ContactPrivacy policyTerms of Use