Page 1 of 1

Ubuntu 3.13 guest (OSX10.9 host) unbootable under VB4.3.14

Posted: 19. Aug 2014, 10:47
by urilabob
Well, I guess the subject line says it all. The guest boots apparently normally under VB4.3.12, but crashes on boot under 4.3.14. When I try to boot it, it gets past the initial VirtualBox screen, moving on to a blank black screen, which disappears after about ten seconds, after which the machine shows in the Virtual Manager panel as ‘aborted’. Reverting to 4.3.12 allows it to boot again.

I think the problem may relate to the way I have the disks set up. The system disk is a normal vdi file. However the /home partition is on a separate writethrough VMDK. I do it this way so that the home directories can be shared with a directly-booted Ubuntu system that I sometimes run on the mac. It seems to be this partition which is causing the problem. Any suggestions on how to fix this would be great.

The first obviously worrying thing I see in the logs is

Code: Select all

00:00:00.736248 VMSetError: /Users/vbox/tinderbox/4.3-mac-rel/src/VBox/Storage/VD.cpp(5949) int VDOpen(VBOXHDD*, const char*, const char*, unsigned int, VDINTERFACE*); rc=VERR_NOT_SUPPORTED
00:00:00.736268 VMSetError: VD: error VERR_NOT_SUPPORTED opening image file '/Volumes/VB/VMDKs/pv_extra.vmdk'
This occurs in both successful (4.3.12) boots and unsuccessful (4.3.14) ones. However in both cases, the boot continues.

In the unsuccessful (4.3.14) boots, the last material I see in the logs is:

Code: Select all

00:00:05.666283 EHCI: USB Suspended
00:00:06.102417 AHCI#0: Reset the HBA
00:00:06.103765 AHCI#0: Port 0 reset
00:00:06.423505 AHCI#0: Port 1 reset
00:00:06.755611 AHCI#0P1: Read at offset 500277657600 (4096 bytes left) returned rc=VERR_EOF
00:00:06.756271 AHCI#0P1: Read at offset 500277657600 (4096 bytes left) returned rc=VERR_EOF
00:00:06.756392 AHCI#0P1: Cancelled task 9
00:00:06.756420 AHCI#0P0: Canceled read at offset 21613244416 (4096 bytes left) returned rc=VINF_SUCCESS
00:00:06.756434 
00:00:06.756435 !!Assertion Failed!!
00:00:06.756435 Expression: ASMAtomicReadU32(&pAhciPort->cTasksActive) > 0
00:00:06.756436 Location  : /Users/vbox/tinderbox/4.3-mac-rel/src/VBox/Devices/Storage/DevAHCI.cpp(6032) bool ahciTransferComplete(AHCIPort*, AHCIREQ*, int, bool)
00:00:06.756454 Inconsistent request counter
In the successful boots, I see

Code: Select all

00:00:05.951192 EHCI: USB Suspended
00:00:06.397412 AHCI#0: Reset the HBA
00:00:06.398645 AHCI#0: Port 0 reset
00:00:06.720534 AHCI#0: Port 1 reset
00:00:07.054147 AHCI#0P1: Read at offset 500277657600 (4096 bytes left) returned rc=VERR_EOF
00:00:07.054878 AHCI#0P1: Read at offset 500277657600 (4096 bytes left) returned rc=VERR_EOF
00:00:07.055446 AHCI#0P1: Read at offset 500277657600 (4096 bytes left) returned rc=VERR_EOF
00:00:07.055985 AHCI#0P1: Read at offset 500277657600 (4096 bytes left) returned rc=VERR_EOF
00:00:07.056582 AHCI#0P1: Read at offset 500277657600 (4096 bytes left) returned rc=VERR_EOF
00:00:07.057043 AHCI#0P1: Read at offset 500277657600 (4096 bytes left) returned rc=VERR_EOF
00:00:07.057807 AHCI#0P1: Read at offset 500277657600 (2048 bytes left) returned rc=VERR_EOF
00:00:07.057821 AHCI#0P1: Read at offset 500277659648 (2048 bytes left) returned rc=VERR_EOF
00:00:07.058222 AHCI#0: Port 1 reset
00:00:07.379872 AHCI#0P1: Read at offset 500277659648 (2048 bytes left) returned rc=VERR_EOF
00:00:07.379910 AHCI#0P1: Read at offset 500277657600 (2048 bytes left) returned rc=VERR_EOF
00:00:07.380291 AHCI#0: Port 1 reset
further read attempts continue for quite a few lines, but in the end the boot continues on and succeeds.

Re: Ubuntu 3.13 guest (OSX10.9 host) unbootable under VB4.3.

Posted: 19. Aug 2014, 11:34
by mpack
IMHO your "successful" boots are telling: those are error messages saying that the disk image has been truncated. Did you recently transport it? Say on a FATx medium with its 4GB file size limit?

What do you mean by a "Writethrough VMDK"? I suspect you might be talking about raw disk access? VBox does support something called writethrough as well, but it's something else entirely.

Incidentally, we prefer complete logs here (as zip attachments). Let us be the judge of which lines are significant.