While Chrome OS verified boot protects against unintended system modification by malicious or buggy software, the ability to hack your own device is an intentional design feature of Google Chrome notebooks. The instructions for building your own version of Chromium OS, and installing it on a Cr-48 are given elsewhere. Some enthusiasts, however, may want to install something completely different. This page provides an example, showing how the official Chrome OS software can coexist with Ubuntu, a popular linux distribution. I'm assuming that you're already somewhat familiar with the Chromium OS development environment.
Caution: Modifications you make to the system are not supported by Google, may cause hardware, software or security issues and may void warranty. Be very careful.
These instructions work on the Cr-48 as originally shipped. There are several magic numbers that may change following software updates or on other Chromium OS-based machines. Even if the numbers don't exactly match, the basic idea is the same.
In the examples below:
This is kind of a cheat. The Cr-48's boot process does not support
Let's take door #1.
To begin our journey, first switch the Cr-48 into developer mode and reboot. When you see the blue frowny face with the "Chrome OS verification is turned off" message, either wait 30 seconds or hit Ctrl-D to boot immediately. This screen is always shown when booting in developer mode, to ensure that someone doesn't change your OS without your knowledge.
Switch to VT2 (press [ Ctrl ] [ Alt ] [ => ]), and log in as user 'chronos' (no password required), then run
To prevent the lock screen from logging you out of VT2, leave Chrome OS parked on the login screen. To prevent the backlight from dimming while in VT2, run sudo initctl stop powerd.
Take a look at the SSD layout. It should be something like this (the UUID values will all be different, of course):
The units are 512-byte disk sectors.
On Chrome OS there are several bootable images, each composed of a kernel and a root filesystem (rootfs). For a given image, the kernel and rootfs are stored on a pair of consecutive partitions. Two of these images, Image-A and Image-B, are for official Chrome OS:
When the Chrome OS autoupdater downloads a new image (every six weeks or so, as new versions are pushed out), it alternately stores it in Image-A and Image-B - whichever image isn't currently running. The autoupdater even runs in developer mode, as long as we are running an official Chrome OS image.
For Ubuntu, we'll use the currently unassigned Image-C, composed of KERN-C and ROOT-C on partitions
However, initially they are too small so, first we need to grow them by stealing from the upper half of the stateful partition, STATE (
Using these values ensures that only the original STATE partition is affected.
Now the partition table should look something like this (changes in bold):
At this point we should destroy the STATE partition contents, because otherwise at the next boot the startup scripts may notice that it's corrupted and will erase it using the old size (obtained from dumpe2fs) and not the new one. Best to be safe and just zap it now. This will take a couple of minutes to run:
To speed up SSD access, we use a block size of 131,072 bytes (128 KB), which aligns with the SSD erase size.
And now reboot so that the startup script recreates the required files in the stateful partition. This will do a safe wipe first, so you'll have to wait a bit (again).
At this point we're through fiddling with the partition table, so you may want to go back to VT2 and set a password according to these instructions.
First, although the Cr-48 CPU and BIOS is 64-bit, the kernel and rootfs are presently 32-bit. Since we're reusing the Chrome OS kernel, we'll download and use the 32-bit ubuntu-10.10-desktop-i386.iso from an Ubuntu CD mirror. For example:
Second, even in developer mode, the Cr-48 will only boot external drives that are signed by Google. That means we can't (easily) use the normal Ubuntu live installer. Instead, I'll create an empty disk image file with a 5G partition on it, and use VirtualBox to install into that. Then I'll transfer that raw partition onto the Cr-48.
To install VirtualBox (and its command line management tool,
I'll do this on my normal linux workstation, of course. I'll create the file inside the chroot so I can use the cgpt tool, but I'll run VirtualBox from outside. We could create the file using fdisk, but using cgpt ensures all the numbers match. You could also build the cgpt tool for use external to the chroot, but whatever.
We'll need our disk image to be a little larger than 5G so it has room for the GPT headers.
So, do the following in the Chromium OS chroot:
From outside the chroot, translate the binary into a virtualbox disk:
Launch the VirtualBox GUI (
Boot the virtual machine and install Ubuntu onto
Once Ubuntu is installed, working and updated, shut the virtual machine down and convert the
Now, we'll extract just the Ubuntu rootfs partition from the binary file:
Next, we copy the ubuntu rootfs directly to the Cr-48 ROOT-C partition (
Note: the root filesystem is a huge file that will take quite a while to upload. This is much less painful with a fast network connection, so, if possible, use a USB-to-ethernet adapter to avoid going through Wi-Fi.
If you have to use Wi-Fi, you can reduce the wait with a bit of compression (thanks to Jay Lee for pointing this out):
If your network is flaky you might find it easier to use
You can see that it worked by mounting the new rootfs and looking around:
While we're looking, let's copy the
We'll need to copy all the kernel modules too.
That should do it.
The next step is to copy the currently running Chrome OS kernel to KERN-C (
If this prints
If this prints /dev/sda5 (ROOT-B), then our kernel is on /dev/sda4 (KERN-B).
Assuming our kernel is on /dev/sda2 (KERN-A), copy it to /dev/sda6 (KERN-C):
Now we need to change the kernel command line to use our Ubuntu rootfs instead of a Chrome OS rootfs. For this, we'll use
Extract the existing kernel command line from KERN-C, and save it to a file named
The default Chrome OS kernel command line looks something like this:
The only editor on the Cr-48 is qemacs, so open foo.6 with qemacs:
Edit the file to look like this:
Then save (Ctrl-x Ctrl-s) and exit (Ctrl-x Ctrl-c). qemacs occasionally gets confused, so double-check to be sure you have the right content:
The kernel command line is part of the kernel partition, and the entire partition must be cryptographically signed in order to work. We can't replace the command line part without affecting the entire kernel partition. The script will save a backup copy before replacing the partition content, but we shouldn't need it.
At this point we should have the following situation:
Image-A is an official Google Chrome OS which can boot either in normal mode or dev-mode.
Image-B is (or will be after the first autoupdate) another official Google Chrome OS which can boot either in normal mode or dev-mode.
Image-C is Chrome OS kernel with a modified command line and an Ubuntu rootfs, which can only boot in dev-mode.
Next, we adjust the priority among the images so we can try out our Ubuntu image. The image priority is an attribute of its kernel partition. Run
4096 32768 2 Label: "KERN-A"
36864 32768 4 Label: "KERN-B"
The priority determines the order in which the BIOS tries to find a valid kernel (bigger is higher, zero means don't even try). The tries field is decremented each time the BIOS tries to boot it, and if it's zero, the kernel is considered invalid (this lets us boot new images without looping forever if they don't work). The successful field overrides the tries field, but is only set by the OS once it's up and running.
Let's change the priority of KERN-C to 5:
This makes KERN-C the highest priority, but only gives us one chance to boot it. That way if it doesn't work, we're not completely stuck.
If you reboot now, you should come up in Ubuntu! Note that Computer Science Standard Answer #1 applies: It Works For Me™
If something went wrong and Ubuntu crashes or you powered off, the tries field for KERN-C will have been decremented to 0 and you'll fall back to booting Chrome OS.
Assuming that Ubuntu booted and you could log in, go to Applications->Accessories->Terminal to get a shell, and run
This will mark the Ubuntu kernel as valid, so it will continue to boot next time.
Now you can switch back and forth between the official Chrome OS release and Ubuntu just by flipping the dev-mode switch. Going from dev-mode to normal mode erases STATE (
This works because although KERN-C has the highest priority, it isn't signed by Google. In dev-mode that's okay, but in normal mode it will be rejected by the BIOS. Since we've set the successful flag to 1, the BIOS won't mark it invalid but will just skip it each time. This makes the normal-mode boot time slightly longer, but only by a second or two.
Of course you could also switch between images from within dev-mode just by manually setting the priorities with
Note that if the normal image autoupdates, it will probably change the kernel priorities so that Image-C is no longer the highest and the next time you switch to dev mode, you will
a) have a long wait,
b) still be running Chrome OS, and
c) have to use cgpt to raise the KERN-C priority again.
But, because autoupdate only switches between Image-A and Image-B, the Ubuntu kernel and rootfs shouldn't be affected.
Recompiling the Ubuntu kernel should be possible, with a few caveats:
First, you'll have to modify or reconfigure the kernel to not use initrd. initramfs should work though.
Second, official Chrome OS still has a few closed-source hardware drivers. The pure open-source Chromium OS experience is therefore a bit sub-optimal, although still quite useable.
Third, if you use the 32-bit image, you'll also have to modify the kernel source to boot correctly from the 64-bit Chrome OS BIOS.
See http://git.chromium.org/cgi-bin/gitweb.cgi?p=kernel.git;a=commit;h=a7cfa1075c04df162d58dc2ed93df6045e9c3271 for details.
If you use a 64-bit image it shouldn't need the boot hacks, but driver support is much less robust.
Finally, you'll have to sign the kernel yourself and put it into the KERN-C partition. That is actually the easiest step, but it's not really well documented. Look in the developer pages.
The Chrome OS BIOS is a modified EFI BIOS. The bootstub is a standard EFI Application, but it's embedded in the kernel image in a dedicated partition type, rather than accessible through a FAT filesystem. To decrease boot time, the BIOS does not discover or pass the standard disk drive handles to the bootstub, so the bootstub doesn't know anything about disks or filesystems. There is also no Compatibility Support Module in the BIOS. In theory
If you want to take this on, go for it. That would let us create a kernel partition that just contained an EFI bootloader, which could then chain-boot to external USB drives, etc. That might be kind of cool.
Some clarification in response to the wharrgarbl resulting from this howto...