-
-
Save DennisLfromGA/cd3455530cec2a5a1ef4 to your computer and use it in GitHub Desktop.
#!/bin/sh -e | |
C_ROOT='' | |
C_KERNEL='' | |
## | |
## Exits the script with exit code $1, spitting out message $@ to stderr | |
error() { | |
local ecode="$1" | |
shift | |
echo "$*" 1>&2 | |
exit "$ecode" | |
} | |
## | |
## Ensure this script is run from a Cros shell (as chronos or superuser) | |
if [ "x$USER" != 'xchronos' -a "x$SUDO_USER" != 'xchronos' ]; then | |
error 1 "This script has to be run from a Cros shell (as chronos or superuser) - exiting!" | |
fi | |
#Following routine borrowed from @drinkcat ;) | |
ROOTDEVICE="`rootdev -d -s`" | |
if [ -z "$ROOTDEVICE" ]; then | |
error 1 "Cannot find root device." | |
fi | |
if [ ! -b "$ROOTDEVICE" ]; then | |
error 1 "$ROOTDEVICE is not a block device." | |
fi | |
# If $ROOTDEVICE ends with a number (e.g. mmcblk0), partitions are named | |
# ${ROOTDEVICE}pX (e.g. mmcblk0p1). If not (e.g. sda), they are named | |
# ${ROOTDEVICE}X (e.g. sda1). | |
ROOTDEVICEPREFIX="$ROOTDEVICE" | |
if [ "${ROOTDEVICE%[0-9]}" != "$ROOTDEVICE" ]; then | |
ROOTDEVICEPREFIX="${ROOTDEVICE}p" | |
fi | |
## | |
## 0.Disable verified boot : (You could do this later, but you have to do this before step 5. IT WON'T BOOT OTHERWISE!) | |
echo "## 0.Disable verified boot" | |
echo -n "Changing system to allow booting unsigned images: " | |
sudo crossystem dev_boot_signed_only=0 || ( echo; error 2 "*** Couldn't disable 'verified boot'" ) | |
echo 'crossystem dev_boot_signed_only=0' | |
sleep 3 && echo | |
## | |
## 1.Get current root & assign current kernel | |
echo "## 1.Get current root & assign current kernel" | |
echo -n "Determining current kernel = " | |
C_ROOT=`rootdev -s` | |
if [ $C_ROOT = ${ROOTDEVICEPREFIX}3 ]; then C_KERNEL=2; else C_KERNEL=4; fi | |
echo "$C_KERNEL" | |
sleep 3 && echo | |
## | |
## 2.Copy the existing kernel configuration into a file | |
echo "## 2.Copy the existing kernel configuration into a file" | |
echo "Copying current kernel into file = kernel$C_KERNEL" | |
sudo /usr/share/vboot/bin/make_dev_ssd.sh --save_config /tmp/x --partitions $C_KERNEL || ( echo; error 2 "*** Couldn't create kernel config file" ) | |
sleep 3 && echo | |
## | |
## 3.Edit the config file and add 'disablevmx=off' + 'lsm.module_locking=0' to the config line | |
echo "## 3.Edit the config file and add 'disablevmx=off' + 'lsm.module_locking=0' to the config line" | |
if grep --color 'disablevmx=off lsm.module_locking=0' /tmp/x.$C_KERNEL ; then | |
echo; error 255 "*** Kernel configuraiton already modified - exiting" | |
fi | |
echo -n "Editing /tmp/x.$C_KERNEL to append = " | |
sudo sed -i -e 's/$/ disablevmx=off lsm.module_locking=0/' /tmp/x.$C_KERNEL || ( echo; error 2 "*** Couldn't edit kernel config file" ) | |
echo "disablevmx=off lsm.module_locking=0" | |
sleep 3 && echo | |
## | |
## 4.Save the current kernel configuration and reload the new one | |
echo "## 4.Save the current kernel configuration and reload the new one" | |
echo -n "[ press ENTER to continue - Ctrl-C to abort ] "; read DOIT | |
echo "Reloading the kernel configuration from /tmp/x.$C_KERNEL" | |
sudo /usr/share/vboot/bin/make_dev_ssd.sh --set_config /tmp/x --partitions $C_KERNEL || ( echo; error 2 "*** Couldn't reload kernel configuration" ) | |
sleep 3 && echo | |
## | |
## 5.reboot, and enjoy VT-x extensions | |
echo "## 5.reboot, and enjoy VT-x extensions" | |
echo "All done - rebooting..." | |
echo -n "[ press ENTER to continue - Ctrl-C to abort ] "; read DOIT | |
sudo reboot | |
exit |
Updated script to append 'lsm.module_locking=0' in addition 'disablevmx=off'.
Dennis
If a another script were created to reverse what enable-vmx.sh changed (maybe called unenable-vmx.sh) would a Chromebook boot into Verified boot again?. Seems if the saved kernel bits were restored (bit-for-bit) so that the hash/digital sign matched Googles, it might boot verified mode (unless something else permanently flags the kernel modifications)? From what I have read, "Verified Boot" while in Developer mode gives a little more security. Assuming any of the above would work, we could execute the enable-vmx only when we need to run a 64Bit VirtualBox VM then execute unenable-vmx.sh to reestablish verified boot.
BTW, Thanks for making your enable-vmx.sh script available!!
Regards, Ron
Script changed to accommodate root devices ending in a number like 'mmcblk0', etc. - thanx @drinkcat
How do I run this script?!
I had it working once, but after a clean reinstall of chrome os, crouton, etc. it fails again.
My kernel is adjusted. Running the enable-vmx.sh script says its ok already. disablevmx=off.
But when I start my virtual box I get the message that VT-x is not supported by the BIOS.
Do I need to redo something in the installation of Vbox itself?
Thanks in advance, Patrick
I'm seeing the same issue. Prior to the latest ChromeOS update that happened yesterday I could start 64bit VM using VT-X in Virtuallbox in Crouton. However now, after the ChromeOS update, I'm getting the error message "VT-x is disabled in the BIOS (VERR_VMX_MSR_VMXON_DISABLED)". However I just repacked using the manual steps and verified and it still doesn't work. Something broke with the ChromeOS update?
@DennisLfromGA Maybe you should update your script. changing the boot command line can be done much easier. See https://github.com/dnschneid/crouton/wiki/Repack-kernel-to-Enable-VT_x-for-Virtualbox I updated the wiki with the better method.
Re-written to use simplified routine suggested by @divx118 - thanx ;)
... and tweaked USER logic to actually work - again ;) ...
After the latest beta update for ChromeOS, I'm also getting the "VT-x is disabled in the BIOS (VERR_VMX_MSR_VMXON_DISABLED)" in VirtualBox in trusty. I know it was working before the update. Anyone else had the same issue and have a resolution?
Same problem here, since yesterday's update I get the VT-x error -- which I've never seen before.
CrOS just updated, and suddenly I'm getting the VT-x error also, leaving my 64-bit guest in the mud. The previous CrOS updates up to this one seemed fine after I ran the scripts, but not this time. Any ideas? Thanks.
Update: Shutting down and restarting fixed it where reboots did no good at all.
Does doing this give access to /dev/kvm in crouton?
UPDATE: the answer is no... it does not :-/
Updated script to ensure it is run from a Cros shell (as chronos).