Several years ago I picked up a used Dell Chromebook 11 3189 (model code “Kefka”) to play with. At the time it was still receiving ChromeOS updates, had a sticky hinge that required some lubrication and manipulation to get working, and cost around $100 including the separately purchased power adapter. I’ve hacked on it in a wide variety of ways over the years, and the main interesting result is that I’m starting to think a hacked out-of-support x86 Chromebook is, in many ways, now better and cheaper than a Raspberry Pi in that role as a modern accessible extra computer to enable fearless play the Pi was intended to fill. I’ve been taking notes, so way too much detail below.
When I bought mine, I had three things I wanted to play with:
- Try ChromeOS.
- Try the various methods for getting more local utility out of ChromeOS.
- Check out hacking a Chromebook to run other OSes
ChromeOS is ..OK. It’s a browser appliance (which has become an extremely broad runtime environment) and terminal into leased time on a mainframe google’s cloud, but frankly that covers a lot of utility these days. It’s less of a passive-consumption-first device than a phone or tablet. I’m not managing a fleet, but the management features look pretty cool too. What’s not so cool is the limited support windows: each model of ChromeOS device has an “AUE” (Auto Update Expire) date where they no longer receive updates including security patches. This year’s potato and 5 years ago’s potato have surprisingly comparable specs – many basic Chromebooks at any nearly any time you look at the market since their introduction have 4GB RAM, 16 or 32GB solid state storage, a 1366×768 LCD, with whatever the cheapest SoC Intel is peddling that year is. There are a few platform integrity features added around 2018 that seem to be driving expiration dates recently… and good old planned obsolescence.
Local enhancements
There are several supported and “less-supported” ways to extend the local capabilities of a ChromeOS device. The supported options are crosvm based: The bundled ability to run many Android apps and “Crostini” Linux Environment feature which automatically sets up, essentially, a Debian Linux VM with some extra plumbing. Both go a long way toward inheriting capabilities from larger ecosystems. The Android app support is pretty seamless except for occasional holes in x86 support from software, and the occasional app that refuses to run under virtualization for (mostly bogus) “security” integrity reasons. The Linux VM behavior is also surprisingly well-integrated, the provided Termina terminal emulator is not the worst and the Sommelier apparatus they use for forwarding graphical software is surprisingly capable.
However, performance is mediocre even considering the feeble hardware, and you can’t automatically run a VM and/or its contents at startup, the latter of which is especially annoying for many of the vaguely-server-like things you might repurpose an old Chromebook for.
On the less-supported side (to be clear, less- not un-: Google intentionally publishes the documentation for developer mode which turns off a lot of “integrity protection”, and the methods for disabling write protection for even deeper tampering), there is Chromebrew, a package manager for injecting additional software into the native Linux system of the Chromebook, and crouton, an earlier, more-invasive, and less well-integrated option for chrooting the running system into a normal Linux userland. Crouton has somewhat better performance than crostini (no VM overhead), but is less well-integrated and seems to be largely superseded by the better supported option. Chromebrew is pretty cool in concept, and I played with it for a while, but I found it rather fragile and it broke on update a couple times in ways that were nontrivial to fix, so it probably isn’t something to be counted on.
None of these options solve devices no longer getting updates, and the object of hacker-y interest here is really the flip-side of the AUE date situation: once they’re out of support, you can get used/refurbished/unsold Chromebooks for cheap. Like really cheap. $40-80 for a single-quantity refurb including a charger, cheaper if you buy used and/or in lots. That makes them interesting for running your own software for cheap.
$50 of Computing
I think it’s extremely important to have access to at least one beater computer you can play with without significant fear of breaking. The series of (mostly cheap old hand-me-down) computers my parents kept me supplied with as a child/teen basically set the arc of my life, and I think a lot about how to create those conditions for others. Especially for young people, so they can develop an understanding of computers as comprehensible things that are empowering rather than the capricious magic mirrors so many people seem conditioned to treat computers as. It’s also important for older tech people to try stuff so we don’t become too calcified into our familiar environments.
The Raspberry Pi folks have really good philosophy on that, but (1) actually getting a Pi, especially at MSRP, has been difficult and (2) it requires quite a lot of tackle to make use of a Pi: you typically need at least a display, power supply, mouse, and keyboard in addition to the board. A single refurbished AUE chromebook is in the same price range as the bare Pi, and bundles all of those things into one portable unit, with only a loss of some exposed GPIO pins and component visibility. You lose a few accessible IO options (which do matter for a few neat Pi projects) and some transparency of construction, but even needing to pop the thing open and remove the write-protect screw teaches some of that lesson.
For the older nerd set, remember the Netpliance i-Opener and scene around hacking them? Same kind of story, you can get a complete mediocre PC for incredibly cheap with a trivial modification by hacking something sold as a terminal into a service that contains all the parts of a PC. But this time it’s avoiding e-waste instead of undermining a stupid business model.
Firmware
Hacking most x86_64 based Chromebooks to be a general purpose computer is actually pretty straightforward, thanks to Mr. Chromebox. Most modern Chromebooks boot with Coreboot and a payload called depthcharge, which is rather convenient because Coreboot is open-source, and someone who knows what they’re doing can build a compatible Coreboot image which run a different payload, such as the Tianocore UEFI payload that will behave like a typical modern commodity PC. Mr. Chromebox generates just such builds, as well as scripts and instructions to download and install them.
The only part that isn’t “just software” is that you need to disable the write protection to the boot flash. Depending on model, that is accomplished by one of a few simple methods; with a jumper or screw that opens a contact, or by removing the battery, or with the use of a gimmicked “Suzy-Q” USB-C cable in the newest models – most of the ones currently relevant as cheap beaters are a screw or battery out situation.
Software
Recent mainline Linux pretty much “just works” on Chromebooks. You’d expect it to, since ChromeOS itself is a gentoo-derived Linux distribution, but ChromeOS has some special patches and tricks higher in the software stack that are not always immediately well-handled in mainline.
I made an earlier attempt at doing the UEFI Coreboot flash thing on the same machine back in 2020 and things in mainline-Linux-land were not so good at that point. In particular some combination of the Linux i2c input drivers and Coreboot configuration caused a problem with the input devices that rendered it largely unusable. That has since been fixed, as have most other minor annoyances.
Suitable OSes: Small Linux systems. Storage-intensive distros like NixOS or any of the immutable-core-plus-container designs will probably not do well in 16-32GB of eMMC. The chrultrabook folks have been figuring out Windows and OS X on higher-spec Chromebooks with some success, but I’m more interested in turning e-waste into utility and/or education than the nicer more expensive machines.
I ended up installing Arch on the Dell 3189 I’ve been torturing, as I almost always do, because I know the tooling, and the packages are new enough that recent improvements will be present. Good old Debian, or OpenSuse, or a RHEL-like like Rocky or Alma would also be fine, at least as long as you don’t pick any exceptionally bulky packages to install, and you run a version new enough to fully support the hardware. It’s not hard to get a usable modern environment in ~8GB (which sounds absurdly decadent to me, but I realize there are decades of bloat enhancements which I’m sure provide some sort of tangible benefit to the user since you could easily fit a useful system in a few 10s of MB).
Smaller OSes (which I enjoy and think experiencing teaches you wonderful things), like Haiku or NetBSD are all actively wrestling with hardware support for common Chromebook “features” like the oddly-plumbed I2C input devices, quirky Bay/Cherry trail style half-SOC-half-external-codec style sound, and other cheap but ugly decisions that are easily papered over with OS customization. I’ve recently tried Haiku and NetBSD for sport and looked up their work on the drivers: Haiku R1B4 boots but sees no integrated input devices or sound, Haiku Nightly hrev57235 sees the mouse (which is interesting because it looks like the patch adding support should have been in R1B4), but it’s constantly drifting and spamming click events, and still no keyboard or sound. NetBSD9.0 loses track of its discs during boot, while 9.3 boots but with no integrated mouse/keyboard – there are patches under review in July ’23 to add support for them.
Selecting a Victim Chromebook
One does need to take a bit of care about the Chromebook you select if this sounds like fun. Most models are suitable, but some are less so.
ARM-based models are less-well-supported for repurposing, and require a different method. hexdump0815 maintains general tooling and documentation on github for Mainline Linux on ARM Chromebooks, including an image builder for Ubuntu and Debian images, and some ARM-focused distros like ArchLinuxArm support specific models – they make interesting platforms, but support is no where near as easy and systematic as the x86 options.
Among the x86 machines, look for models known to be supported by a Mr. Chromebox coreboot build, and with no serious problems on the Chromebook Linux Compatibility Sheet. If you buy mystery Chromebooks off the internet, there is a chance you will run into one which was enrolled in management, which will complicate the process – older models have an exposed SPI flash chip containing the firmware that you can access and flash with a $10 external programmer, but it’s not quite as trivial as running a script. I haven’t heard of a way to forcibly un-enroll a newer CCD-enabled Chromebook from management, so those may be effectively bricked if you can’t contact the organization managing it and get it removed from their end (unless it’s stolen they’re incentivized to cooperate; Google charges them based on the number of enrolled devices in their organization).
There are often batches of refurbished models being dumped on woot for reasonable prices, there are always a range of refurbished/used options on eBay, and (probably the source of the large-volume eBay sellers), there are usually govdeals government auctions from school systems unloading their out-of-support Chromebooks in lots of tens to hundreds, often for prices down near $10/pc.
I will note that once you’re in to the $100-150/machine price point, you’re probably better off buying some off-lease enterprise machine as a refurb than messing with a Chromebook, I’ve had a ton of mileage out of small refurbished Latitudes over the years, my 7250 and 7390 have been loyal companions. The hardware will tend to be nicer and less quirky than the “cost optimization” that gets packed into a Chromebook.
Findings
Hacking the firmware is, thanks to extensive work by others, pretty straightforward. Because ChromeOS is, fundamentally, Linux, the kernel support for these machines should be excellent, and for the most part it is. In reality, there are a few bits of secret sauce done in various layers of the stack that have not translated upstream and cause some minor friction, but most of them have been smoothed over at this point (again, by the extensive work of others). If you just want a cheap little Linux box to try things on, or drive a 3D printer (via Octoprint or whatnot), or to use in places it might get hurt (like in a workshop for music and manuals), they’re pretty excellent.
I’ve recently used mine to make my regularly-scheduled “How broken is the Wayland ecosystem” check-in, and things are Almost There™ with a significantly smaller almost than the last time I looked. Enough extensions have proliferated that it’s more-or-less possible to put together a usable environment. I even made a quick check on “Totally the best wayland experience” gnome and… their interaction model is so not to my taste I couldn’t figure out what was broken and what was working as intended. Lately it’s been running ricer-parts with Hyprland and Waybar (…and Swaylock, Swayidle, and Mako – it is ricer shit that you have to assemble yourself) and it’s pretty cool.
One nice discovery is that even though the standard Chromebook keyboard layout is a little sparse, the Search key under the left pinkie where (depending on who you ask) Caps Lock or Control belongs generates SuperL which makes a perfect “do system stuff” key since not much software uses it heavily. The keyboards in general aren’t quite as weird as they look, top row feature keys mostly actually produce F1-F9, “Lock” produces XF86Tools, etc.
Some of the most delightful discoveries I’ve made are only incidentally Chromebook related because of the slightly weird keyboards. wev is an input event viewer like xev for wayland: it lets you see what events different keys generate so you can map or manipulate them (and is annoyingly not all that widely available in distribution repositories yet). keyd is a tiny daemon that allows arbitrary, sophisticated, and system-wide keyboard remapping. It does it with a very small persistent process, that produces virtual devices so they work consistently across VTs, X, or Wayland sessions. It uses a simple configuration format that was not designed by the accretion of droppings of madmen over decades (lookin’ at you xkb). The virtual keyboard even show up with bus ID 0fac:0ade, and I’m delighted by hex puns.
I’m using keyd to fix the lack of PgUp/PgDn/Home/End keys on the Chromebook layout. I’ve had some laptops that use Fn+Arrow Keys for that, and am fond of it, so I configured Search+Arrow Keys and… it’s great. I like it so much I might start doing it on other machines. The whole configuration to accomplish that is:
### /etc/keyd/default.conf ###
[ids]
*
[meta]
down = pagedown
up = pageup
left = home
right = endThe Intel Bay/Cherry trail audio stack in many of the models that currently make attractive targets is a little unfortunate. It’s half baked in to the system-on-chip, and half delegated to an external codec, and it is rather particular about the bring-up procedure to make that work. The good news is, it mostly works in mainline Linux now. The bad news is the last few obvious problems were solved in releases made in late Aug. 2023. The devices are called ASoC, and the biggest issue I had on my 3189 was that the probing was confused about whether the attached codec present in my machine is a rt5640 or rt5645 – I had to drop a conf file in /etc/modprobe.d/ containing blacklist snd_soc_rt5640 to make the second wrong driver stop loading. There are occasional issues about pipewire not always setting a UCM (“Use Case Manager”, basically runtime configuration) on the card before touching it, causing it to spray “Baytrail Audio Port: ASoC: no backend DAIs enabled for Baytrail Audio Port” in the system log – there are patches to clean that up in both PipeWire and Linux that have just made it into releases at time of writing, which seem to clean up the last few annoyances on that front under Linux.
One final thing that isn’t working on most 2-in-1 models is tablet mode sensors. My 3189 has a touchscreen that flips back for tablet mode, and the software that cuts the keyboard when folded back under ChromeOS isn’t available in mainline Linux. I don’t know how representative the configuration in the 3189 is, but it has an accelerometer in each half of the body, plus a magnet and hall-effect sensor to determine when it is closed (the sensor is next to the ~ key, the magnet is in the display bezel). The hall effect switch is a pretty normal thing, the dual accelerometer is a little less so, but was presumably done because accelerometers are cheap and that setup can, in principle, “do the right thing” when tented or otherwise oddly oriented.
There is a package iio-sensor-proxy which turns accelerometer data into input events for Linux tablets, and watching sudo iio_info will show that both sensors produce vaid data… but there is this open bug in iio-sensor-proxy that folks have been hacking on for years to try to come up with a decent general solution for using the pair to detect fold orientation in 2-in-1s. It has made a little progress, but there is a ton of infrastructure that just doesn’t exist yet required to solve the problem in a general way.
Conclusion
Past-AUE Chromebooks make excellent hacker toys, and are arguably better suited than a Raspberry Pi to many of the common “Pi project” applications because of their integrated HID devices and pricetag in the tens of dollars.
The driver support is good and improving, and the hardware is a pleasing combination of cheap and sturdy that gives it a lot of utility. Chromebooks are consistent and available enough to build community effects around them which will make them ever better in the role.
The ones aimed at the education market and built to be “child resistant” are especially appealing as they are unusually physically robust, cheaply available in vast quantities, and there is a pleasing continuity to reusing them in an exploratory education role.
If I were a little wealthier and more social I might give in to the impulse to buy one of the many staggeringly cheap large lots, and pass them out to friends and curious young people like party favors on the condition they help hack their own.
