OS X boot-args clobbered

[Charles B. Mc Kennie]

Since OS X Tiger, it has been possible to control how the PC is booted

º Safe Mode º Single User Mode º Verbose Mode

(Sooner? I became an Apple user with Leopard 10.5.3)

When Snow Leopard is run as a virtual machine under VirtualBox, this is not possible, does not work.

VirtualBox is unceremoniously clobbering boot-args with “keepsyms=1 -v -serial=01”, thusly preventing the invocation of desirable modes

This is the output from nvram command with option “-p”

Upon boot

SystemAudioVolume	i
platform-uuid	%00%00%00%00%00%00%10%00%80%00%08%00'%15%c8%aa
boot-args	keepsyms=1 -v -serial=0x1

After issuing ‘sudo nvram boot-args=“-v” ‘ (Verbose mode)

SystemAudioVolume	i
platform-uuid	%00%00%00%00%00%00%10%00%80%00%08%00'%15%c8%aa
boot-args	-v

Upon restart, with no verbosity

SystemAudioVolume	i
platform-uuid	%00%00%00%00%00%00%10%00%80%00%08%00'%15%c8%aa
boot-args	keepsyms=1 -v -serial=0x1

The setting for boot-args for Verbose mode has been lost in this example.

= = = = = = = = = = =

This does beg the question, of course:

º If VirtualBox knows how to setboot-args, why can’t Safe, Verbose, Single-User modes not be requested at startup/boot of the virtual machine?

​https://forums.virtualbox.org/viewtopic.php?f=9&t=58473#p271661

[Charles B. Mc Kennie]

sudo nvram boot-args="-x" This command will have the system always boot into Safe Mode.

sudo nvram boot-args="-s" This command will boot the system into Single User mode without needing to hold Command-S at startup.

When the OS X vm is restarted, "nvram -p" always returns "boot-args keepsyms=1 -v -serial=0x1", not the "-x" or "-s" requested.

Why is OS X not being permitted to use "safe mode" ??????? Or "single user mode" ??????

[galitsyn]

Please consider to use

VBoxManage setextradata <vm> "VBoxInternal2/EfiBootArgs" <value>

to set boot-args variable.

Setting firmware NVRAM variables using "nvram" tool within guest in runtime is not supported.

[Charles B. Mc Kennie]

Replying to galitsyn:

Please consider to use

VBoxManage setextradata <vm> "VBoxInternal2/EfiBootArgs" <value>

to set boot-args variable.

Setting firmware NVRAM variables using "nvram" tool within guest in runtime is not supported.

Such usage of VBoxManage setextradata <vm> "VBoxInternal2/EfiBootArgs" <value> is not documented, even in Section 14 Known limitations. An update to the manual would stem the questions (assumes RTFM, though)

Perhaps, this should also be included in section(s) that discuss EFI/UEFI

[Charles B. Mc Kennie]

And this should be compatible with the needs/requirements of the other *nix OSs

[Charles B. Mc Kennie]

Replying to galitsyn:

Please consider to use

VBoxManage setextradata <vm> "VBoxInternal2/EfiBootArgs" <value>

to set boot-args variable.

Setting firmware NVRAM variables using "nvram" tool within guest in runtime is not supported.

I tried

VBoxManage setextradata <vm> "VBoxInternal2/EfiBootArgs"   "-x"

in order to enter Safe Mode and the VM did not boot. I changed the value to "x" and, while the vm booted, it was not Safe Mode; nvram -p yielded "x", not "-x". In other words, not working V4.2.10

[Charles B. Mc Kennie]

I tried

VBoxManage setextradata <vm> "VBoxInternal2/EfiBootArgs" "keepsyms=1 -x -serial=01"

and the vm will not boot at all

[galitsyn]

In 4.3.12 we updated User Manual:

• added mention about "VBoxInternal2/EfiBootArgs" and "boot-args" connection (see section 3.12.2);
• updated section 14.2 (Known Issues): currently not possible to boot OS X guest in Safe Mode.

[aeichner]

Please reopen if still relevant with a recent VirtualBox release.

[Charles B. Mc Kennie]

galitsyn wrote in comment 7

In 4.3.12 we updated User Manual:

added mention about "VBoxInternal2/EfiBootArgs" and "boot-args" connection (see section 3.12.2); updated section 14.2 (Known Issues): currently not possible to boot OS X guest in Safe Mode. comment:8 Changed 3 days ago by aeichner

The updates are still in the User manual. So, what is obsolete?

[Socratis]

Nothing is obsolete. 'aeichner' was simply closing all the "bugs" that had not had a comment in the past two years (excellent move). There are several OSX-related bugs that might be re-opened in the next couple of days, simply because they haven't been amended with recent evidence. This is one of them.

[Charles B. Mc Kennie]

the document change should have closed this.

the evidence was adequate then and is still adequate; nothing more to add.