Get an SD card[]
As a bare minimum a 2GB card is needed, but at least 4GB is recommended. If performance is a concern, choose the model of SD card carefully. The only ones found in testing to have reasonable performance (i.e. at least comparable to mechanical disks under a random-write workload) are "SanDisk Extreme Pro SDHC UHS-1 95MB/s" models. See here for more details (link at the end of the article, then scroll down to the second table):
Flash Module Benchmark Collection
Strictly speaking, you don't have to use an SD card for this - a USB flash module will work just as well, and you may find a small USB stick more convenient, both because the SD card sticks out of the side, and because there are two USB ports on the back of the machine (i.e. there is still a spare USB port for another device after the USB flash module for the rootfs). Same caveat about the performance applies - most USB flash media has appalling performance. I am using a 64GB Kingston Data Traveler Mini module, and that only manages around 40-50 IOPS on random writes; better than most, but less than half of what the above mentioned SD card can manage.
Download RSEL6 rootfs Tarball[]
Get it from here: http://ftp.mirrorservice.org/sites/ftp.redsleeve.org/pub/yum/os/rsel6-rootfs-gui-20130927-1.tar.xz
This is a large RSEL6 GUI image with KDE GUI, the required Xorg drivers, and NetworkManager components to allow you to easilly connect to WiFi and yum install any additional packages you may require.
Prepare the SD Card[]
I used my Toshiba AC100 to prepare the SD card. The external SD card appears as /dev/mmcblk1 on those, to the instructions here reflect that. Adjust the device node name accordingly for your system.
Edit partitions using gdisk. Since SD cards typically have large erase block sizes and poor flash management, it is recommended to set sector alignment to 4MB. Use GPT partitions.
# gdisk /dev/mmcblk1
GPT fdisk (gdisk) version 0.8.4
Partition table scan:
MBR: protective
BSD: not present
APM: not present
GPT: present
Creating new GPT entries.
Command (? for help): o
This option deletes all partitions and creates a new protective MBR.
Proceed? (Y/N): y
Command (? for help): x
Expert command (? for help): l
Enter the sector alignment value (1-65536, default = 2048): 8192
Expert command (? for help): m
Command (? for help): n
Partition number (1-128, default 1): 1
First sector (34-62333918, default = 8192) or {+-}size{KMGTP}:
Last sector (8192-62333918, default = 62333918) or {+-}size{KMGTP}: +16M
Current type is 'Linux filesystem'
Hex code or GUID (L to show codes, Enter = 8300): 7f00
Changed type of partition to 'ChromeOS kernel'
Command (? for help): n
Partition number (2-128, default 2): 2
First sector (34-62333918, default = 40960) or {+-}size{KMGTP}:
Last sector (40960-62333918, default = 62333918) or {+-}size{KMGTP}:
Current type is 'Linux filesystem'
Hex code or GUID (L to show codes, Enter = 8300):
Changed type of partition to 'Linux filesystem'
Command (? for help): w
Final checks complete. About to write GPT data. THIS WILL OVERWRITE EXISTING
PARTITIONS!!
Do you want to proceed? (Y/N): y
OK; writing new GUID partition table (GPT) to /dev/mmcblk1.
The operation has completed successfully.
This creates two partitions: a kernel one and one for the root filesystem.
Create a filesystem on the root partition:
# mkfs.ext4 -b 4096 -E stripe-width=1024,discard /dev/mmcblk1p2
Mount the file system and extract the RSEL6 rootfs to it:
# mount /dev/mmcblk1p2 /mnt # pv rsel6-rootfs-gui-20130927-1.tar.xz | pxz -cd | tar -C /mnt -xf -
Edit etc/fstab on the new rootfs accordingly to the media you are using (e.g. set root to /dev/sda2 if you are using a USB stick). Then unmount the rootfs you created.
# umount /mnt
Enable Developer Mode on the Chromebook[]
Booting into recovery mode by holding both the escape and refresh keys on the keyboard and then pressing the power key. While in recovery mode, you can safely ignore any messages indicating the installation is broken. Press Ctrl+D while in recovery mode to enable developer mode. The prompt will ask for permission to clear all local data from the system before removing OS verification. This process takes about ten minutes. Once it is finished there will be a message indicating that OS verification is disabled. This message will now appear at every boot time to indicate your system is in developer mode. Press Ctrl+D to continue booting ChromeOS.
Put the ChromeOS kernel on the kernel partitions of the SD card[]
Once logged in and you have the SD card inserted, press Ctrl+Alt+T to open a crosh prompt.
Run "shell" to get a bash shell.
Run "sudo -s".
Be careful here, mmcblk1 and mmcblk0 are very easy to mistype, and doing so can be embarrasing. :)
Repack the Kernel[]
# cd /tmp # echo "console=tty1 root=/dev/mmcblk1p3 rootwait ro elevator=deadline lsm.module_locking=0 quiet" > /tmp/config # vbutil_kernel --repack /tmp/newkernel --keyblock /usr/share/vboot/devkeys/kernel.keyblock --version 1 --signprivate /usr/share/vboot/devkeys/kernel_data_key.vbprivk --config=/tmp/config --oldblob /dev/mmcblk0p2 --arch arm # dd if=/tmp/newkern of=/dev/mmcblk1p1 # crossystem dev_boot_usb=1 # cgpt add -i 1 -S 1 -T 5 -P 10 /dev/mmcblk1
Copy Kernel, Modules, Firmware Blobs and Keys to rootfs[]
The filesystem on the SD card used in this procedure automatically mounted as /media/removable/External\ Drive\ 2/. It might be different. Check with the 'mount' command if unsure.
# cp -af /lib/modules/* /media/removable/External\ Drive\ 2/lib/modules/ # cp -af /lib/firmware/* /media/removable/External\ Drive\ 2/lib/firmware/ # cp -af /usr/share/vboot /media/removable/External\ Drive\ 2/usr/share/ # cp -af /boot/*-3* /media/removable/External\ Drive\ 2/boot/ # umount /media/removable/External\ Drive\ 2/
Note that on newer ChromeOS installations the SD card is accessible via the "/media/removable/SD Card/" path rather than "/media/removable/External Drive 2/", so you may need to adjust the cp commands accordingly.
Run RSEL6[]
Reboot the Chromebook. Instead of pressing Ctrl+D, press Ctrl+U to boot from the SD card (or a USB stick). If all went well, RSEL6 boot process should stream down the screen.
Specific Configuration[]
Accelerated MALI Driver[]
The RSEL6 rootfs contains all the required Xorg drivers to get things up and running. No xorg.conf is necessary - everything gets autodetected and works with the standard frame buffer driver. The touchpad works with the Synaptics driver. The accelerated open-surce MALI driver is available from here:
http://ftp.redsleeve.org/pub/yum/soc/
Look for the xorg-x11-drv-armsoc packages (src.rpm and armv6l.rpm are available). Unfortunately, I have not managed to get them working (the machine locks up when starting X if you create a xorg.conf file to use the armsoc driver). So treat the packages as highly experimental. If you manage to get them working, please update the information here.
ChromeOS CMT Driver[]
The Xorg driver for CMT (enhanced touchpad support) is available from here: https://chromium.googlesource.com/chromiumos/platform/xf86-input-cmt/
Unfortunately, it requires kernel-headers from a more recent kernel than the currently available RSEL6 2.6.32 series to build (and the most recent version requires a newer Xorg, too). Source and binary rpms of this will be provided once source and binary kernel rpms for a suitable 3.4.0 kernel become available.
In the meantime, the synaptics driver (xorg-x11-drv-synaptics) works quite well, and is included in the rootfs tarball.
Real Time Clock[]
There is a known issue with the system clock on the Chromebook. For some reason, even though the hardware clock keeps correct time across reboots, the system clock forgets the time. This leads to the boot failing during fsck as it finds that the last mount time is in the future.
I have found a workaround for this problem. Create the following executable script (755 permissions):
# cat /etc/sysconfig/modules/hwclock.modules #!/bin/bash /sbin/hwclock --utc --hctosys
The executable scripts /etc/sysconfig/modules/*.modules execute very early in rc.sysinit, before fsck runs. The above script will set system time from hardware clock, which means that the time will be correct by the time fsck inspects the file systems, and everything will work smoothly.