Introduction
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 (http://www.ubuntu.com/), a popular linux distribution.
These instructions work on the Cr-48 as originally shipped. There are several magic numbers that may differ on other Chromium OS-based machines.
In the examples below:
The Cr-48 shell is formatted like this.
The Chromium OS build chroot is formatted like this.
The standard linux workstation shell is formatted like this.
Fair warning
This is kind of a cheat. The Cr-48's boot process does not support initrd (http://www.ibm.com/developerworks/linux/library/l-initrd.html), which is required by Ubuntu. That leaves us three possibilities:
1. Use the existing Chrome OS kernel with the Ubuntu rootfs.
2. Recompile the Ubuntu kernel to do without initrd (ugh).
3. Modify the Chrome OS bootstub to handle initrd (double-ugh).
Let's take door #1.
Free up some SSD space for Ubunt
To begin our journey, first switch the Cr-48 into developer mode (http://sites.google.com/a/chromium.org/dev/chromium-os/developer-information-for-chrome-os-devices/cr-48-chrome-notebook-developer-information) 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 (http://www.chromium.org/poking-around-your-chrome-os-device#TOC-Get-the-command-prompt-through-VT-2) (press [ Ctrl ] [ Alt ] [ => ]), and log in as user 'chronos' (no password required), then run sudo bash.
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):
localhost ~ # cgpt show /dev/sda
start size part contents
0 1 PMBR (Boot GUID: 045E5C92-6F57-9B46-BDCC-99BFF876E469)
1 1 Pri GPT header
2 32 Pri GPT table
266240 22622208 1 Label: "STATE"
Type: Linux data
UUID: 1844A16D-AEC9-7C4B-9553-C3EB4814F6BB
4096 32768 2 Label: "KERN-A"
Type: ChromeOS kernel
UUID: D176DC60-81F1-654E-8953-E3D28019738C
Attr: priority=3 tries=0 successful=1
27082752 4194304 3 Label: "ROOT-A"
Type: ChromeOS rootfs
UUID: 0193CA51-DA12-9847-A715-C90433E55F60
36864 32768 4 Label: "KERN-B"
Type: ChromeOS kernel
UUID: F1A2C65C-CC22-FF4A-A8BC-67BA233F3D40
Attr: priority=0 tries=15 successful=0
22888448 4194304 5 Label: "ROOT-B"
Type: ChromeOS rootfs
UUID: B3361FB5-4DAC-9344-B7E5-870B7AC5FEA1
34 1 6 Label: "KERN-C"
Type: ChromeOS kernel
UUID: B6954485-4295-9749-956A-C315B01FB684
Attr: priority=0 tries=15 successful=0
35 1 7 Label: "ROOT-C"
Type: ChromeOS rootfs
UUID: 5B5202B5-F74B-714E-9538-ADE56B2E5662
69632 32768 8 Label: "OEM"
Type: Linux data
UUID: 84971802-0D1C-504B-9CB5-DEA896F0AD3F
36 1 9 Label: "reserved"
Type: ChromeOS reserved
UUID: 77375DA6-8F07-704A-BBF4-2BCA662BFDFF
37 1 10 Label: "reserved"
Type: ChromeOS reserved
UUID: 6880F478-EB05-8B4B-B951-94A96076263E
38 1 11 Label: "reserved"
Type: ChromeOS reserved
UUID: 12DDC236-8FDF-4049-9A2D-10FAB17D3AA9
233472 32768 12 Label: "EFI-SYSTEM"
Type: EFI System Partition
UUID: 045E5C92-6F57-9B46-BDCC-99BFF876E469
31277199 32 Sec GPT table
31277231 1 Sec GPT header
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:
• KERN-A and ROOT-A on partitions /dev/sda2 and /dev/sda3
• KERN-B and ROOT-B on partitions /dev/sda4 and /dev/sda5
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 /dev/sda6 and /dev/sda7, respectively.
However, initially they are too small so, first we need to grow them by stealing from the upper half of the stateful partition, STATE (/dev/sda1). Initially, STATE is 22622208 512-byte sectors, or just under 11 GB. From this we'll set aside 16 MB for KERN-C, and 5 GB for ROOT-C.
umount /mnt/stateful_partition
cgpt add -i 1 -b 266240 -s 12103680 -l STATE /dev/sda
cgpt add -i 6 -b 12369920 -s 32768 -l KERN-C /dev/sda
cgpt add -i 7 -b 12402688 -s 10485760 -l ROOT-C /dev/sda
Using these values ensures that only the original STATE partition is affected.
Now the partition table should look something like this (changes in bold):
localhost ~ # cgpt show /dev/sda
start size part contents
0 1 PMBR (Boot GUID: 045E5C92-6F57-9B46-BDCC-99BFF876E469)
1 1 Pri GPT header
2 32 Pri GPT table
266240 12103680 1 Label: "STATE"
Type: Linux data
UUID: 1844A16D-AEC9-7C4B-9553-C3EB4814F6BB
4096 32768 2 Label: "KERN-A"
Type: ChromeOS kernel
UUID: D176DC60-81F1-654E-8953-E3D28019738C
Attr: priority=3 tries=0 successful=1
27082752 4194304 3 Label: "ROOT-A"
Type: ChromeOS rootfs
UUID: 0193CA51-DA12-9847-A715-C90433E55F60
36864 32768 4 Label: "KERN-B"
Type: ChromeOS kernel
UUID: F1A2C65C-CC22-FF4A-A8BC-67BA233F3D40
Attr: priority=0 tries=15 successful=0
22888448 4194304 5 Label: "ROOT-B"
Type: ChromeOS rootfs
UUID: B3361FB5-4DAC-9344-B7E5-870B7AC5FEA1
12369920 32768 6 Label: "KERN-C"
Type: ChromeOS kernel
UUID: B6954485-4295-9749-956A-C315B01FB684
Attr: priority=0 tries=15 successful=0
12402688 10485760 7 Label: "ROOT-C"
Type: ChromeOS rootfs
UUID: 5B5202B5-F74B-714E-9538-ADE56B2E5662
69632 32768 8 Label: "OEM"
Type: Linux data
UUID: 84971802-0D1C-504B-9CB5-DEA896F0AD3F
36 1 9 Label: "reserved"
Type: ChromeOS reserved
UUID: 77375DA6-8F07-704A-BBF4-2BCA662BFDFF
37 1 10 Label: "reserved"
Type: ChromeOS reserved
UUID: 6880F478-EB05-8B4B-B951-94A96076263E
38 1 11 Label: "reserved"
Type: ChromeOS reserved
UUID: 12DDC236-8FDF-4049-9A2D-10FAB17D3AA9
233472 32768 12 Label: "EFI-SYSTEM"
Type: EFI System Partition
UUID: 045E5C92-6F57-9B46-BDCC-99BFF876E469
31277199 32 Sec GPT table
31277231 1 Sec GPT header
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:
dd if=/dev/zero of=/dev/sda bs=131072 seek=1040 count=47280
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.
proceed to part 2 ► (http://www.windows7newsinfo.com/smf/index.php/topic,13937.0.html)