ARM Chromebook Linux Install

Table of Contents


Update on Feb 16 2015 This will probably be my last ever update on the ARM chromebook, which I now consider a big mistake on my part. I switched to an intel machine that works so much better with linux. Everything worked out-of-the-box or with a little minor tweaking. I will never go back to an ARM machine again. Here is a list of things that frustrated me with the ARM chromebook, and now work flawlessly with an Acer chromebook.

  • I can chat using google talk, and make video calls using skype and google hangouts
  • I can watch flash video online when I need to unwind.
  • Dropbox works natively; this is a large part of my work. I no longer want to run unison and rsync using cronjobs. This is great for backup, but its not like having a simple efficient syncing daemon that I do need to worry about.
  • Netflix works on google chrome
  • Pulseaudio works pretty well too. I'm tired of the manual buggery with ALSA.
  • All my function keys work in XFCE and gnome. I did have to tweak somethings with xmodmap, but this is trivial and highly customizable. A modern alternative to xmodmap is xbindkeys.

Update from 2014 I tried the crouton chroot environment, and it works really well. However, if you want your own clean complete Ubuntu desktop, with all the customizability it brings with it, a chroot isn't sufficient.

One way to install your own clean Ubuntu desktop is through the Chrubuntu script, which has become fairly sophisticated and installs several different flavors and releases of Xubuntu, Lubuntu and Ubuntu desktop. I highly recommend it.

However, there are many things that it does not do, which includes setting up your keyboard, user accounts, customizing your touchpad and configuring sound. If you're interested in learning a little bit about how all of this --including bits of the Chrubuntu script-- works, my guide may be of some use to you. If not, just use Chrubuntu.


My Dell XPS M1210 died after 5 or 6 years of use. It had a shitty battery and power cable, both of which I replaced under warranty. Then, they failed again. It had served me well. I had a few simple requirements for a new laptop:

  • Portability: I knew that I would be traveling by bus and train a lot, so I needed something very light that I could put in my backpack and forget about. This translates to a max weight of about 2lbs.
  • Battery Life: If there’s one thing that’s very annoying, it’s a computer that needs to be plugged in every few hours. Trust me, this is critical. You’re not going to be near a power outlet all the time, even in a university building. I would estimate my minimum requirement to be about 5-6 hours of battery life under light (no video, audio) use.

  • Cost: I was willing to spend up to $500, but would prefer to spend less. I was not willing to sacrifice warranty and peace of mind.

  • Operating System: A full-fledged operating system is key, and I’m most comfortable with linux. I do recognize that it’s an extremely tiresome operating system, and that it’s not for everyone.

  • Keyboard: I knew that I would be using my laptop for fairly long periods while on the move. A good keyboard was, erm… key.

  • Storage: I needed about 1-2GB of personal storage in addition to space for the operating system. I didn’t expect to be doing serious computing on my laptop, and neither did I plan to store a lot of music on it. UPDATE Aug 31 2014: This turned out to be wrong. I programmed in python, ran simulations, compiled LaTeX code; essentially, my laptop became my primary computing machine.

  • Computing Power: A powerful CPU is only necessary if you’re doing things that need a powerful CPU. I wasn’t going to be doing that. Light web browsing and LaTeX composition, and not very processor intensive tasks. That said, flash-heavy websites and streaming video run better with a fast processor.

  • Output ports: I needed VGA output, preferably, since most projectors have only VGA input.

So, I was mostly looking for a decent piece of hardware to install linux on.
There were several computers I considered:

  1. Samsung Series 5 Chromebook, Old version: This had a nice snappy Intel processor, 4GB of memory, 16GB of hard disk space, and a nice keyboard that reviews raved about. Cost, about $400. People complained about the build quality, though.
  • Samsung Series 5 Chromebook, New version: This had slightly better specs and build quality than the older series 5 version.

  • Samsung ARM chromebook (ARM CB): This was built on an ARM processor, had a 11" screen, was only $250, and had a 16GB SSD. This was quite a strong contender from the beginning.

  • Acer Chromebook: This had a 350GB conventional platter based hard
    drive, an Intel processor, and otherwise similar specifications to
    the Samsungs.

  • Used Macbook Air 11’’ or 13’’: You can get a decent one for about $350 - $500 on Craigslist, but they’re usually about a year old, and the warranty doesn’t transfer. And god knows in what shape they’d be in and whether they'd fail in a few months.

  • Asus Vivo book, Lenovo Idea pad and others. Some of these were decent pieces of hardware in the $400 - $600 range.

  • The most difficult choice was between the Acer and the ARM CBs, and a visit to Best Buy settled this. The ARM CB’s keyboard felt much better, and it felt less "plasticky". Nevertheless, it seemed like a good choice since it satisfied most of my requirements.

    1. Portability: The ARM CB weighed about 2.2lbs, whereas the Acer weighed about 3lbs.
  • Battery Life: 6 hours of medium-to-light use on the ARM, compared to about 4 on the Acer.

  • Cost: The Acer and the ARM were $200 and $250 respectively

  • Operating System: They both ran ChromeOS. The main problem was that the ARM CB didn't have an official Ubuntu build. I would have to rely on other people building this for me.

  • Keyboard: Addressed above.

  • Storage: The Acer had 350GB to the Samsung’s pitiful 16GB, but conventional hard-drives are so much slower, noisier and ran so much hotter than solid state devices. I decided that I didn’t need much storage if I was only going to edit LaTeX files. If I really needed extra storage, I could augment it with an external SD-CARD.

  • Computing Power: Tests did show that the Acer seemed a little snappier compared to the ARM, but this was mostly on the ChromeOS. The difference was marginal and performance wasn’t really an issue for me.

  • I finally decided to go with the ARM CB.

    Why linux and not ChromeOS?

    ChromeOS is based loosely on a Gentoo Linux distribution. It has a nice slick interface, a working shell that you can access (in Developer mode), Flash, Netflix, and perhaps even HDMI output.

    However, it has some drawbacks:

    • No package management system. Ubuntu, Arch, Fedora and other linux distributions do so well because the have good package management systems. Most packages one could ever need are in the distributions repositories. Debian’s apt-get system, for example, is very good at avoiding dependency-hell.

    One could get around this by compiling everything from source, but good luck keeping track of all your libraries and programs.

    • No rootfs access: The rootfs in ChromeOS is read-only, and this makes custom configuration messy. One could do something about this, but it involves a little bit of hacking.
  • Minimal set of installed packages: ChromeOS comes with a very minimal set of installed packages. The bash shell is workable, but the version of Vim installed is very very bare bones. If you like emacs, well, tough luck.

  • So, a light minimal distribution of linux would give me exactly what I needed from the Chromebook: a package manager, an X-Windows system with a low-footprint window manager, internet access, a LaTeX distribution, and perhaps even a working Mathematica or python installation.

    Picking a Linux Distribution

    It’s best to start with a some history; a little literature review if you will. The earliest Chromebook hacks were published on the website by a Google engineer (Bill Richardson).

    There were several other people who made guides on it, including Olof Johannson at this Google+ page, on Oct 28, 2012. He installed Ubuntu. Then came Jay Lee, who wrote a simple script that automates (in essence) the process described by Olof and Bill. Ubuntu on Chromebooks was dubbed “Chrubuntu” and erm... the rest is history. Jay Lee has started a blog at ARM has also been promoting platforms using its chips, and they’ve been big on linux. An ARM engineer produced this guide. On this guide, I learnt a little about the structure of linux, that I will recount in brief.

    Linux has a pretty simple setup:

    • Kernel: This is the core that communicates with and manages the hardware. It’s a tiny little package, rarely exceeding 50MB.
  • Root-filesystem (rootfs): This is the filesystem where the root partition / is mounted as the system is booted up. Once there’s a kernel in place, you need programs that’ll communicate with the kernel and its modules to produce, for example, a gui; this is what the rootfs contains.

  • The contents of the rootfs vary from distribution to distribution, and typically contain a set of programs and utilities that will help get the system to a minimal operational state. This is how the same linux kernel can run under several different distributions.

    So one could run any distribution one pleases just by getting a copy of the appropriate rootfs. It’s important to note that kernels and root-filesystems are architecture specific. Programs built for Intel processors wouldn’t usually work on programs built for ARM CPUs. So although most linux programs are open source, they have to be compiled for the specific architecture. There are several ways of compiling a kernel and building a rootfs. However, as in life, it’s easiest if you get someone else to build the kernel and rootfs for you. For the ARM processor, the usual suspects -- Fedora, OpenSUSE, ARCH-Linux, and Ubuntu -- provide rootfs.

    I wasn’t very familiar with OpenSUSE and Fedora (although I use RedHat at work), and wanted to check out Arch-Linux at some point. Unfortunately, they only had a massive 8GB rootfs. With the OS taking up 8GB, this wouldn’t leave enough room for ChromeOS or my own files. Or so I thought. You see, the easiest way to make a copy of a working rootfs is to get it working on your own system and then use the dd command as follows:

    [code lang=bash]
    dd if=/dev/partition of=/backup-media/partition-image.img
    gzip /backup-media/partition-image.img

    dd makes a perfect copy of a partition, and this includes the free space in the partition. Gzip usually compresses this fairly well, and the size of the image falls in half. Perhaps I’ll try Arch the next time.

    Then, I learned that ARM and several other companies including Samsung were part of this non-profit consortium that built linux for the ARM platform. They were Ubuntu-based, and produced drivers, kernels and rootfs. They had several light rootfs that were built for specifically for systems that had minimal resources. Since the distribution was Ubuntu-based, it came with Debian’s apt package management system, which is terrific. Upgrading packages and (eventually) distributions would be a piece of cake. So I chose to go with a Linaro rootfs called ALIP, which stands for the “ARM Linux Internet Platform” built on the light LXDE window manager. It has such a light footprint that it uses only 200-300 MB of RAM and boots in less than 10 seconds. Compare this to Ubuntu’s Unity or Gnome, which will gobble up gigabytes of RAM with just a few programs running. So the choice of rootfs, at least, was clear.

    Installing Linux on the Chromebook

    Developer Mode

    To begin hacking the Chromebook, you need to put it into developer mode. This tells the ChromeOS firmware that you will be booting your own kernels, and that it shouldn’t freak out. Developer mode is initiated using what Google calls the “three finger salute”. As indicated on this page, you do the following:

    To invoke Recovery mode, you hold down the ESC and Refresh keys and
    poke the Power button.

    Once Recovery Mode is initiated, the computer reboots and shows you a
    white screen with a warning. You need to hit

    Ctrl + D

    to boot the computer into Developer Mode. There is no prompt on the first splash screen that tells you, “hit Ctrl+D to get Developer mode”. You just need to know it. When in developer mode, you need to hit Ctrl+D to boot the computer every time. There’s no easy fix for this, unless you do a little more hacking: there appears a way to bypass this “verified boot” process. However, we won't get into this here.

    Once you do this, ChromeOS takes about 10 minutes to put the computer into Developer mode. This seems to erase your personal files (and importantly, the stored wireless passwords). It should show a login screen once it finishes booting.

    Partitioning the Chromebook

    The next step is to partition the Chromebook and set aside a kernel
    partition and root partition for Linux. Boot into ChromeOS, and pull up
    the virtual terminal by hitting


    this should get you to a root prompt. ChromeOS appears to have the following users: root, chronos, guest. One can choose to add more. The chronos user is the one the gui runs under, and it has a home directory that you can put things into (/home/users/chronos). As root, run:

    cgpt show /dev/mmcblk0

    which results in a display of the form

    start        size    part  contents

    0 1 PMBR (Boot GUID: xxxx-xxxx-xxxx-xxxxxxxxxxxx)
    1 1 Pri GPT header
    2 32 Pri GPT table
    282624 3194880 1 Label: "STATE"
    Type: Linux data
    UUID: xxxx-xxxx-xxxx-xxxxxxxxxxxx
    20480 32768 2 Label: "KERN-A"
    Type: ChromeOS kernel
    UUID: xxxx-xxxx-xxxx-xxxxxxxxxxxx
    Attr: priority=3 tries=0 successful=1
    26578944 4194304 3 Label: "ROOT-A"
    Type: ChromeOS rootfs
    UUID: xxxx-xxxx-xxxx-xxxxxxxxxxxx
    53248 32768 4 Label: "KERN-B"
    Type: ChromeOS kernel
    UUID: xxxx-xxxx-xxxx-xxxxxxxxxxxx
    Attr: priority=1 tries=6 successful=0
    22384640 4194304 5 Label: "ROOT-B"
    Type: ChromeOS rootfs
    UUID: xxxx-xxxx-xxxx-xxxxxxxxxxxx
    3477504 32768 6 Label: "KERN-C"
    Type: ChromeOS kernel
    UUID: xxxx-xxxx-xxxx-xxxxxxxxxxxx
    Attr: priority=5 tries=2 successful=1
    3510272 18874368 7 Label: "ROOT-C"
    Type: ChromeOS rootfs
    UUID: xxxx-xxxx-xxxx-xxxxxxxxxxxx
    86016 32768 8 Label: "OEM"
    Type: Linux data
    UUID: xxxx-xxxx-xxxx-xxxxxxxxxxxx
    16450 1 9 Label: "reserved"
    Type: ChromeOS reserved
    UUID: xxxx-xxxx-xxxx-xxxxxxxxxxxx
    16451 1 10 Label: "reserved"
    Type: ChromeOS reserved
    UUID: xxxx-xxxx-xxxx-xxxxxxxxxxxx
    64 16384 11 Label: "RWFW"
    Type: ChromeOS firmware
    UUID: xxxx-xxxx-xxxx-xxxxxxxxxxxx
    249856 32768 12 Label: "EFI-SYSTEM"
    Type: EFI System Partition
    UUID: xxxx-xxxx-xxxx-xxxxxxxxxxxx
    30777311 32 Sec GPT table
    30777343 1 Sec GPT header

    I’ve replaced the GUID(s) in the above snippet with xxxs, but they'll usually be some numbers. A bootable pair of partitions is a kernel about 16MB in size (although the kernel itself is typically about 3 to 4MB), and a rootfs that’s fairly large. The sizes are in units of sectors, and for the (current) Chromebook EMMCs, we know 1 sec = 512 bytes. Originally, all the root partitions were at 2GB, and the partition labeled stateful was about 10GB. The stateful partition is where ChromeOS keeps it’s user specific files, and if you want to give ChromeOS a little room to breathe, resize this to 1GB and resize ROOT-C to 9GB. You’re going to install the rootfs in ROOT-C, and the kernel in KERN-C. There are two options for you here:

    1. Steal the part of the Chrubuntu script that does this for you - it’s fairly straight forward to edit it. The Chrubuntu script gives you a 9GB ROOT-C. We will describe how to do this below.
  • Resize the partition using a utility like cgpt or partx that’s already on the Chromebook. Both these utilities are on the sucky side of things, since you’ll have to muck about with sector sizes. If you want to do the partitioning yourself, there are plenty of resources on the internet.

  • We will describe option 1: Open up the file 34v87, and scroll down to the part where there are a bunch of cgpt statements involving ROOT-C and KERN-C. You can comment out the rest of the script,
    with statements like

    [code lang=bash]
    if [ ! -d /mnt/stateful_partition/ubuntu ]

    and then run it using

    sudo bash 34v87

    The system should display

    Your system is repairing itself

    In a few minutes, it ought to reboot. Once you reboot, you have to make a filesystem on the newly resized rootfs partition. You do this after logging in as root with

    mkfs.ext4 /dev/mmcblk0p7

    Copying a rootfs image

    I chose to use a Linaro ALIP image, but you can use anything you like. The one I used can be found here at I copied it onto a USB thumb drive. Download it using wget:

    wget -O /media/usb_drive/image.tar.gz

    where /media/usb_drive/image.tar.gz is where your usb drive is mounted. Now you have to copy the files from the USB drive onto the internal EMMC. So mount the ROOT-C partition with

    mkdir /mnt/rootc
    mount /dev/mmcblkp7 /mnt/rootc

    It’s important to preserve permissions when you copy your files. So
    untar carefully with

    cd /mnt/rootc
    tar zxvfp /media/usb_drive/images.tar.gz

    I once faced a problem where it wouldn't boot because there was no proc directory on my filesystem backup. This is easily fixed by creating the directory.

    Copy kernel and its modules

    There are a few options for the kernel. Bill Richardson’s post covers the options: you can copy ChromeOS’s kernel, firmware and modules, build your own from source or use a standard Ubuntu kernel but modify the ChromeOS boot process. The ChromeOS boot process uses initramfs, whereas Ubuntu requires initrd. Wikipedia’s page on initrd says:

    In computing, initrd (initial ramdisk) is a scheme for loading a
    temporary root file system into memory in the boot process of the
    Linux kernel. initrd and initramfs refer to two different methods of
    achieving this. Both are commonly used to make preparations before the
    real root file system can be mounted.

    Compiling a kernel on your own is time consuming. Since the objective is to get a light linux system running quickly, we’ll copy the ChromeOS kernel over. To get a kernel running, you need to configure it to boot the right rootfs (/dev/mmcblk0p7 for us), and that’s the reason why you cannot simply use

    dd if=/dev/mmcblk0p2 of=/dev/mmcblk0p6

    First, Save the a new kernel configuration with

    echo "console=tty1 debug verbose root=/dev/mmcblk0p7 rootwait rw lsm.module_locking=0" > config

    Note that the original kernel configuration that Bill Richardson used
    included a bunch of options like

    console=tty1 init=/sbin/init add_efi_memmap boot=local rootwait ro noresume noswap i915.modeset=1 loglevel=7 kern_guid=%U tpm_tis.force=1 tpm_tis.interrupts=0 root=/dev/sda7 noinitrd

    but some of these are either equivalent or not necessary. It’s important to note that if you want to use swap, you must explicitly enable it here, in the kernel options. I don’t use much ram for the OS, and rarely require swap. However, a swap partition (or a swapfile) is necessary for hibernation. Suspend causes your battery to drain and so if you put it to sleep overnight, it will leave your computer dead in the morning. However, the swap space needs to be at least as 2GB, since this is the amount of RAM the Chromebook has! This isn’t a problem since our linux install will take only about 1.5-2GB of space. You might need to leave some room for your personal files and music. So you could choose to have your swap partition in an SDCARD.

    I chose not to enable swap for the following reasons:

    1. My light Xfce based setup boots in about 8 seconds.
  • Xfce has a “save your current session” option: Enabling this opens up the programs you had open in the previous session. This works as well as hibernation for me.

  • We now need to repack the kernel blob, and this is achieved using a
    utility called vbutil:

    [code lang=bash]
    vbutil_kernel \
    --pack newkern \
    --keyblock /usr/share/vboot/devkeys/kernel.keyblock \
    --version 1 \
    --signprivate /usr/share/vboot/devkeys/kernel_data_key.vbprivk \
    --config config \
    --vmlinuz /boot/vmlinuz-`uname -r` \
    --arch arm

    This “signs” the kernel, telling the ChromeOS firmware that the kernel is safe to boot. This process appears to be called “self-signing” your kernel, and ChromeOS allows you to boot such kernels only in developer mode!

    The kernel is in a file called newkern and this needs to be written to the KERN-C partition. This is done easily with a dd command:

    dd if=newkern of=/dev/mmcblk0p#

    where # is the number of the kernel partition KERN-C. Recall that you can find this out using the cgpt command. The copying process should take just a couple of seconds.

    UPDATE Aug 31 2014: On newer chromebooks, this does not work.
    They have done away with the /boot folder, and only the kernel partition remains. Instead of the --vmlinuz clause, we have


    However, I've not been able to look into what goes here. Simply dding the kernel from KERN-A or KERN-B does not work. It seems this is handled differently now but its handled correctly by the chrubuntu script has become fairly sophisticated. If you want to figure out how to do it yourself, read the chrubuntu script.

    You now need to tell the ChromeOS firmware that KERN-C has the highest priority, and it must be booted first. For future use, it’s best to make a file called boot_linux_first, and copy the following code into it

    # make linux bootable
      sudo cgpt add -i 2 -P 3 -T 1 /dev/mmcblk0
      sudo cgpt add -i 6 -P 5 -T 1 /dev/mmcblk0
    # now show status
      sudo cgpt show -i 2 /dev/mmcblk0
      sudo cgpt show -i 6 /dev/mmcblk0

    and make the file executable. The cgpt command takes the partition
    number in the -i clause, gives it a priority (higher is booted
    earlier) given by the -P clause and tells the firmware to
    (presumably) try booting the partition -T times. Replace 2 and 6
    with the numbers appropriate to your system. The options are:

    Option What it does
    i partition number
    P priority value, highest is first
    S successful, whether boot is successful or not. I don’t really know what this option does. If you set it to 0, and the current kernel fails to boot, it will try other the kernels with lower priority.
    T number of times to try booting.

    The next step is to copy over the kernel and firmware modules. Assuming
    your linux rootfs is mounted at /mnt/rootc, run

    sudo cp -prv /lib/modules /mnt/rootc/lib/modules
    sudo cp -prv /lib/firmware /mnt/rootc/lib/firmware

    One utility that’s extremely useful is cgpt, and this will help you boot
    into ChromeOS later:

    cp -pv /usr/bin/cgpt /mnt/rootc/usr/bin/

    Now it’s time to reboot into your new linux system. Type:

    sudo reboot

    Making things work in Linux

    If everything went well, you should be booted into a linux desktop. Since I chose the Linaro ALIP tarball, my instructions will be for that system. There are several things to fix. And we will explore this section by section.

    Users, Groups and Hostname

    The Linaro rootfs has a default user called linaro with the default password linaro. You should remove this user and create one of your own with a strong password. Before deleting the Linaro user, there are a couple of things you must do: First, the Linaro user is a part of several groups, and the new user you create should belong to all these groups if you want to use the Xwindows, login to networks, and use the sound card. Second, the LXDE system is set to login the Linaro user automatically, and you need to switch this to your new user.

    We will be saving a lot of configurations and backups. So create an easy-to-find location that you will not accidentally delete. Let’s do this first. Open a terminal, and open up a sudo shell with

    sudo -s


    [code lang=text]
    mkdir -p /backup/
    chmod 777 /backup/

    To list the groups the linaro user belongs to, type

    groups linaro > /backup/groups-linaro.txt; cat /backup/groups-linaro.txt

    This saves it to a file if you forget, and the cat statement lists the content of the file. The next command creates a user called myusername that belongs to all the groups the linaro user belonged to:

    useradd myusername -m -G`cat /backup/groups-linaro.txt | sed 's/linaro : linaro //' | sed 's/ /,/g'` 

    Then, create a password with

    passwd myusername

    Remember, the new user you create had better be in the sudoers list. To see if everything worked, use the groups command again. To append a user to the another group, use

    usermod myusername -a -Gsudo

    You can see if the user was correctly added with:

    id myusername

    You may also change your login shell to bash with:

    usermod myusername -s/bin/bash

    And do a test login with

    login myusername

    to see if everything works. An interesting tip that worked well for me was to make the uid and gid of my user the same as the uid and gid of the chronos user on the ChromeOS side. This way, my files were more easily accessible from both sides.

    Next, you need to edit the lightdm login manager configuration file at
    /etc/lightdm/lightdm.conf. Change the autologin line (or remove it
    completely) in the file:


    You should also customize your hostname. List the current hostname with


    Change the hostname by editing the file /etc/hostname, and then run
    the hostname init script:


    Now you can reboot the system, and if everything worked, delete the
    linaro user:

    userdel -r linaro

    A new window manager

    Some research online shows that although LXDE is a light, speedy desktop environment, it’s relatively new and has its issues. So I decided to go with the XFCE desktop environment, which has been around for a while. There are many ways to install this, and one is to just install the Xubuntu package from the ubuntu repositories:

    aptitude install xubuntu-desktop

    There are several packages that are essential for any xfce system.
    Make sure that they’re installed:

    • xfce4-mount-plugin
  • xfce-volumed

  • xfce4-panel

  • xfce4-mixer

  • xfce4-datetime

  • xfce4-battery-plugin

  • squeeze or file-roller: archive managers

  • Mounting the chrome partition

    Some configuration files must be copied from the chrome rootfs. Note that it’s a read-only filesystem, and must be mounted as such:

    [code lang=text]
    mkdir -p /mnt/root3
    mount -o ro /dev/mmcblk0p3 /mnt/root3

    To mount it everytime you boot, you must add the partition to your /etc/fstab file. Mine looks like this:

    /dev/mmcblk0p3    /mnt/root3  ext4    user,ro     0   0   


    To get the audio working, we’ve got to copy drivers from the ChromeOS side. Assuming your’ve already mounted the ChromeOS partition, run,

    [code lang=text]
    sudo cp -rv /mnt/root3/usr/share/alsa/ucm/* /usr/share/alsa/ucm
    alsaucm -c DAISY-I2S

    What we’ve done here is essentially copy a User Case Manager (UCM) profile for alsa. This provides a layer of abstraction for applications that want to use sound. Test your sound using


    If it works, you’d be lucky. Usually, the default state has to be set too. There are many devices on the sound card, and many volume settings. I tried getting it to work by manually adjusting the volume on different devices, but it didn’t work. The easiest method is to copy over the asound.state file from the ChromeOS side and incorporate it into your alsa setup:

    cp /mnt/root3/etc/asound.state /etc/asound.state
    alsactl -F -f /etc/asound.state restore

    where the -F option tells alsactl to force or restore as much of
    the previous state as possible. This asound.state file may or may not exist. The way to create one is to go into chromeOS, and login as root. In the chromeOS prompt, run

    sudo -s
    mkdir mmcp7 /dev/mmcblk0p7
    alsactl -f mmcp7/etc/asound.state store

    Then, reboot into linux, and restore using alsactl as above. This has worked several times for me.

    Alsa doesn’t mix different sounds by default; that is, if both your browser and vlc player are trying to access the sound device, only one of them will play. So you need to setup a mixer plugin in alsa, or install a sound daemon like pulseaudio. Pulseaudio does handles mixing sounds well and has a lot of functionality, but I chose to setup something simple with alsa itself. This was in keeping with our theme of “as light as possible, but no lighter”. You can setup alsa with some simple mixing functionality with an .asoundrc file. The configuration file sets up the alsa dmix plugin. Mine can be found in my dropbox.


    Save the following in a file called /etc/X11/xorg.conf.d/50-touchpad.conf

    [code lang=text]
    Section "InputClass"
    identifier "touchpad"
    MatchIsTouchpad "on"
    Option "FingerHigh" "5"
    Option "FingerLow" "5
    Option "HorizTwoFingerScroll" "on"

    This enables basic Touchpad functionality. There are several things you can enable, including Circular Scrolling, which is quite cool. You can enable it with the option: Option "CircularScrolling" "on"


    Wireless should be working by default, unless you have to connect to a WPA2 enterprise network - this is more a linux problem than anything else. After a lot time attempting to connect to these networks, most of the errors seemed to be coming from some openssl module. You can usually connect to these by just ignoring certificates.

    Network manager works fine for me, although it occasionally used to give me some trouble with frequent disconnections. To fix this I switched to using the command-line tool wpa_supplicant and wicd, a light gui based tool. Some people prefer wicd to network manager since it's lighter.

    In the end, it turned out that I all I needed to do was to wait a few weeks until google released a new wireless driver, a new kernel module called


    Once installing this and NetworkManager, I stopped running into wireless problems.


    Sun doesn’t seem to have released Java binaries for the ARM processor. So you would have to use openjdk, and the icedtea browser plugin which runs Java applets. I installed the following:

    aptitude install openjdk-7-jre icedtea-7-plugin 

    Then visit the Java test page to see if everything works.


    UPDATE Nov 02 2013 (Thanks to commenter Charles Amith): Flash works with the pepperflash plugin, but you need to run it as the superuser. Copy the pepper flash plugin from the directory


    Then, run

    sudo chromium-browser --user-data-dir=/tmp --ppapi-flash-path=/

    UPDATE: Sep 01 2014 I've again lost compatibility between the flashplugin and the chromium-browser version I have installed. Developers from the chromium forums told me the flashplugin is closely coupled to google-chrome official versions, and if they work at all with the open source chromium-browser, it's just a matter of luck. The only hope is gnash, which works well for a fair number of purposes.

    I've recounted a little bit of my struggle below.

    I struggled with flash a lot, Adobe hasn’t released a flash plugin for ARM-linux. I tried android versions of the plugin, but nothing seemed to work. However, note that flash works on the ChromeOS side. This is because the Chrome browser has a custom flash plugin called pepperflash. Several forums discussed using this with the chromium browser (the open source version of Google Chrome), which is installed by default in the Linaro rootfs. This did not work for me, but you might have better luck.

    The flash plugin is in file called in


    along with other files that describe the flashplayer version. After looking at the contents of to determine the version number, I ran

    chromium-browser --ppapi-flash-path=/opt/google/chrome/pepper/ --ppapi-flash-version=11.6.602.180 --enable-plugins

    This gave me the error:

    [ERROR:flash/platform/pepper/pep_module.cpp(143)] Browser does not support interface PPB_AudioInput(Dev);0.3|PPB_AudioInput(Dev);0.2.

    and failed to load flash. Looking at the about:plugins page in the browser shows the following

    Flash - Version: 11.6.602.180
    Shockwave Flash 11.6 r602
    Name:   Shockwave Flash
    Description:    Shockwave Flash 11.6 r602
    Version:    11.6.602.180
    Location:   /opt/google/chrome/pepper/
    Type:   PPAPI (out-of-process)
         MIME types:    
         MIME type  Description File extensions
         application/x-shockwave-flash  Shockwave Flash .swf
         application/futuresplash   FutureSplash Player .spl
         Disable   Allow

    which seems to indicate that the browser at least tried to load the plugin.

    There are other people who claim they have it working.

    • (
  • (

  • (

  • (

  • (

  • I then tried installing the from Adobe’s website. I
    copied the file everywhere:


    I also tried several different versions of the file: Android, i386, etc.

    In fact, if you try to copy over the chrome binary from the ChromeOS side and run it, it complains about libraries. Once you copy over the libraries, it brings up an entire ChromeOS desktop inside a window. There is a chrome browser window inside the desktop, and it crashes instantaneously. I don’t know how to call the browser alone and not the entire desktop. Perhaps this is not possible.

    In any case, HTML5 videos work quite well inside linux - this means newer videos on youtube work. Things like quicktime don’t, but one probably needs to get ARM versions of the Medibuntu driver package. I haven’t looked into this as yet.

    I finally came across the gnash package which is an open source flash implementation. It is several versions behind Adobe Flashplayer, which means that it can only run older flash based videos. I’ve tested it on several Youtube videos and it works on most of them.

    Power management

    Power management tools can be installed using

    aptitude install pm-utils

    This installs several utilities like pm-powersave, pm-hibernate, pm-suspend, pm-suspend-hybrid. But except for pm-suspend, the rest do not work swap enabled. As I mentioned earlier, I chose not enable swap.

    Setting keys up: xmodmap

    The keyboard isn’t setup completely in your linux Chromebook. So volume buttons and brightness buttons don’t work - they’re mapped to function keys F6 through F10. What’s even worse is that there aren’t any Home, End, PgUp, or PgDown keys. I fixed this by making some custom mappings. Since most civilized people rarely use the Caps Lock key, I mapped the Caps Lock key to Mode_switch, a special key for the XWindows system. Then one can setup the following key mappings:

    Key combination Action
    Mode switch + Up PgUp
    Mode switch + Down PgDown
    Mode switch + Left Home
    Mode switch + Right End

    and so on. This is done with the help of two programs: xmodmap and xev. First, you need to find out what your CapsLock key is mapped to. Startup xev with


    and a small window pops up. Hit caps lock and the program should spit out something like this:

    KeyPress event, serial 31, synthetic NO, window 0x3000001,
        root 0x101, subw 0x0, time 1626557, (77,102), root:(671,418),
        state 0x0, keycode 133 (keysym 0xff7e, Super_L), same_screen YES,
        XLookupString gives 0 bytes: 
        XmbLookupString gives 0 bytes: 
        XFilterEvent returns: False
    KeyRelease event, serial 34, synthetic NO, window 0x3000001,
        root 0x101, subw 0x0, time 1626689, (77,102), root:(671,418),
        state 0x2000, keycode 133 (keysym 0xff7e, Super_L), same_screen YES,
        XLookupString gives 0 bytes: 
        XFilterEvent returns: False

    Mine happened to be mapped to the keysym SuperL, but yours could be different. Keycodes are hardware specific, but keysyms are hardware independent. So you could remap your SuperL to modeswitch on all computers with the same code. Now, you need to print out your current keycode mappings with:

    xmodmap -pke > keymap.txt

    Open keymap.txt and you will see a bunch of code like this:

    keycode  67 = F1 F1 F1 F1 F1 F1 XF86Switch_VT_1 F1 F1 XF86Switch_VT_1
    keycode 110 = Home NoSymbol Home
    keycode 111 = Up NoSymbol Up
    keycode 112 = Prior NoSymbol Prior
    keycode 113 = Left NoSymbol Left
    keycode 114 = Right NoSymbol Right
    keycode 115 = End NoSymbol End
    keycode 116 = Down NoSymbol Down

    The structure of a keycode line is as follows:

    [code lang=text]
    keycode = <key number> = <bare keypress> <Shifted keypress> <Mode_switched keypress> <Shift+Mode_switched keypress>

    This describes which keysyms are called when a keycode is either bare, modified with Shift, modified with Mode_switch, or with Shift and Mode_switch pressed together. The keysyms Prior and Next stand for PgUp and PgDown respectively. So I made a file called .Xmodmap in my home directory that does the following:

    1. Exchanges the functions of Control_L and Caps_Lock (Super_L)
  • Maps Mode_switch + key to the Home, End, PageUp and PageDown buttons described above.

  • Maps Shift + F# to XF86AudioLowerVolume XF86AudioRaiseVolume XF86AudioMute, and to the similar brightness functions XF86MonBrightnessDown and XF86MonBrightnessUp to the appropriate "F" key on your chromebook keyboard. Note that if you mapped these to Mode_switch + F# key, it does not work. I do not know why.

  • My Xmodmap file can be found here


    HDMI works on my TV, but there is limited functionality. Look into xrandr to see how to control output. It only works sporadically for me. It does work reasonably well on the chromeos side. If you want to convert HDMI to VGA for use with a projector, this externally powered HDMI to VGA is the only one that works. Note that the cable matters so called active HDMI to VGA converter does not work. Apparently, the chromebook USB port does not supply the converter enough power, as far as I can tell. In contrast, the other Conversions Technology converter comes with its own DC power supply.

    Again, I must emphasize HDMI performance is a hit or a miss. Do not rely on it to work from the linux side until we have better drivers and software.

    In contrast, the Acer chromebook HDMI works flawlessly.


    • Recovering OS cost: If you choose to buy a windows laptop that you just want to install linux on, you could consider getting back the cost of windows included in the price of the laptop. This is typically about $60 for Windows 7. Several have received refunds from the manufacturer! But many fail, since you have to persistent and sit for hours on the telephone with Customer Service. I didn’t want to be bothered with this.

    • Things that don’t work: Dropbox, with their closed source binaries do not have an ARM build as yet.

    • For next time: I’d probably just install crouton, or Ubuntu with Gnome3.

    • If I had to make the choice again: Samsung ARM Chromebook versus the Acer ARM chromebook, I'd probably choose the Intel based Acer.