Having some trouble getting the VM to recognize hard drive...

[ranma42]

Having some trouble getting the VM to recognize hard drive...

[ranma42]

That is unfortunately the part which is failure-prone and so far I have been unable to find a way to make it stable. Placing the disk on an IDE controller might help.

In any case, once you manage to boot the DVD image, enter Disk Utility immediately after choosing the language. Apparently if you go next and then open Disk Utility it usually will not show the disk (neither in Disk Utility, nor in the step for the selection of the destination).

[kencu]

Well, I had success on one occasion. I installed this MacOS VDI disk driver https://www.paragon-software.com/home/vd-mounter-mac-free/, which loaded and initialized the VDI disk. I then attached it as the only device to an IDE controller and one time - it worked. It loaded, I installed the system onto the disk, and rebooted with hope -- but argh -- will not find that disk again. In a real Mac, I'd hold down the option key while booting to bless a certain disk. I wonder if it's some setting like that in the PRAM.... it there a way to reset the PRAM in this VM?

[ranma42]

IIUC on virtualbox the nvram is actually volatile (if you want to set bootargs, it is possible to do so through the EFI settings) so I would expect the same for the PRAM.
Is it the only disk attached to the systems? If you already completed the installation, I would try removing the optical disc device (and possibly the whole SATA controller) and booting with just the hard disk as primary master on IDE (and even in this case, I would not expect the system to boot immediately 100% of the times :( ).

The good news is that (in my experience) after completing the setup, the boot becomes more reliable. This has probably something to do with the timing of some operations and caching the kernel modules seems to affect it.

[ranma42]

Could you try performing a verbose safe boot? It should be possible to set it up by running

VBoxManage setextradata YourVMName VBoxInternal2/EfiBootArgs '-v -x'

The boot will be slower, but it might provide more details about what is going on.

[kencu]

Well - weirdly, when I'm having trouble getting it to recognize the hard drive, it seems to work more reliably if I turn on screen recording. I know- makes no sense. Might be coincidence.

It works! I reinstalled a stock version of TigerVM strictly following your instructions, and although I had trouble getting it to load the hard drive again, with the screen recording trick, it loaded the hard disk. Then I turned screen recording off.

I'm on a fast-ish MacPro 5,1 with SSD drives, if that matters at all. I uploaded a webm recording of the failed load, and then the successful one -- probably useless, but perhaps you might see something in it.
Thanks! K
TigerVM-2017-04-23T00-32-30-028815000Z.webm.zip

[ranma42]

I believe that the hard drive issue might be related to some kind of race condition.
Activating screen recording might have affected the timing of the boot and "fixed" it.

I will add a note about the need to open Disk Utility immediately after the language selection (it is something I tripped into several times while trying to figure out the process).

[kencu]

Looks like there are a number of examples of this issue with MacOS guests, so it's not just this project. https://forums.virtualbox.org/search.php?keywords=Still+waiting+for+root+device&sid=9d9961952b4ed8abe161c360c53d2f37

[ranma42]

Yes, that seems to be one of the most fragile phases of the boot sequence :(
I am not sure if there is anything that can be done to make it more stable; I am going to close this issue, since you have eventually managed to get past the root device detection, but feel free to re-open if you manage to find further information.

Side note: I added the warning about the need to run "Disk Utility" immediately in e5e89a1#diff-04c6e90faac2675aa89e2176d2eec7d8R84.

[ranma42]

In some cases, the rd boot argument seems to be a somewhat effective way to get past the "waiting for the root device" message.
WARNING: this is not 100% guaranteed to fix the issue. It seems to work reliably in some cases and do nothing at all in others. In my environment it seems to reliably help with the boot from DVD, while even with this setting sometimes my VM still waits for the hard disk root device.

VBoxManage setextradata Tiger VBoxInternal2/EfiBootArgs 'rd=diskXsY'

will set your root device to diskXsY. Assuming that you are following the guide, the optical disk unit should be identified as disk1, while the hard disk should be disk0.

Instead of going with a trial-and-error approach, one can easily determine the partition Y with hdiutil:

$ hdiutil pmap mac_os_x_server_v10.4.7_universal_build_8k1079.dmg 

MEDIA: ""; Size 4 GB (7466042 x 512); Max Transfer Blocks 2048
SCHEME: 1 APM, "Apple Partition Scheme" [1]
SECTION: 1 of 2 Type:'MAP'; Size 4 GB; Offset: 1 - 7466042, (7466041 x 512); Overhead 1
ID Type                 Offset       Size         Name                      (4)
-- -------------------- ------------ ------------ -------------------- --------
 1 Apple_partition_map             1           63 Apple               
 2 Apple_Driver_ATAPI             64            8 Macintosh           
 3 Apple_HFS                      72      7465960 Mac_OS_X            
 4 Apple_Free                7466032           10 Explicit Record     

SECTION: 2 of 2 Type:'DDM'; "DDM", Name:"Driver Descriptor Map"
[ Not implemented ]

In fact, the Tiger server boot image I used for the guide had the boot partition would require disk1s3.

For "whole disk" images one would use no partition number, i.e. just disk1.