Brunch Framework: Running ChromeOS on an x86_64 PC

What Brunch actually does with a ChromeOS recovery image

ChromeOS ships on hardware that Google controls. The recovery image for a given Chromebook is signed for that board, and a generic PC is not that board. Brunch's job is to close that gap: it takes an official recovery image and produces a generic x86_64 ChromeOS image that a normal UEFI machine can boot.

The audience is narrow and the README is explicit about it. You need an x86_64 computer with UEFI boot support, administrative privileges, and what the project calls "an entry level understanding of the linux terminal." The supported CPU list starts at Intel 10th Gen and covers AMD Ryzen. Older Intel and AMD CPUs, discrete GPUs, virtual machines and ARM CPUs are all listed as unsupported. That is not a soft recommendation. Brunch is a kernel-compatibility exercise, and the README says hardware support depends on general Linux kernel hardware compatibility, so anything the Linux kernel does not handle will not work here either.

The project also carries a warning that most distribution pages would bury. Brunch "is not the intended way for ChromeOS to work," and at some point ChromeOS could become incompatible with it and delete data unexpectedly, including on non-ChromeOS partitions. The README recommends using it only on a device with no sensitive data and keeping data synced with a cloud service. Treat that as the price of admission, not boilerplate.

The ROOTC partition, the EFI partition and the parts Brunch adds

The mechanism is described in the README in one sentence: Brunch uses a 1GB ROOTC partition containing a custom kernel, an initramfs, the swtpm binaries, userspace patches and config files, plus a specific EFI partition to boot from it.

That split explains the project's shape. The recovery image supplies ChromeOS itself. Brunch supplies the layer that makes a generic PC look enough like a Chromebook for that image to start. The custom kernel and initramfs handle early boot on hardware ChromeOS was never built for. The swtpm binaries provide a software TPM, which matters because ChromeOS expects a trusted platform module to be present. The userspace patches and config files adjust the running system after boot.

Grub sits in front of this. The README points at a "Modify the Grub bootloader" section and says the same kernel command line options recommended for your device should be passed through the Grub bootloader. Kernel command line options are therefore a first-class configuration surface, not an afterthought. Peripheral support follows the same logic: the README warns that camera, microphone and touchpad may not work, or may need troubleshooting.

The repository root is small: .github/, Images/, LICENSE, README.md, Readme/, and a brunch.der file. The install and troubleshooting documentation lives in the Readme/ directory rather than in the main file.

Installing Brunch: linuxloops or the manual guides

There are two paths. The newer one is linuxloops, a separate tool that the README describes as allowing installation of Brunch with a GUI. The manual path is split into a Linux guide and a Windows guide, both under Readme/.

Before either path, you pick a recovery image by CPU. The README maps Intel 10th gen to "jinlon," Intel 11th gen and above to "voxel," and AMD Ryzen to "gumboz," each linked to a cros.tech device page. Getting this wrong is not a cosmetic mistake, since the recovery image is the base the whole build sits on.

The README does not reproduce the step-by-step commands in the main file, so there is no install command to quote here without inventing one. What it does give is the shape of the workflow and where the real instructions live:

# Identify your recovery image first, then follow the matching guide:
# Intel 10th gen      -> jinlon
# Intel 11th gen+     -> voxel
# AMD Ryzen           -> gumboz
#
# Install path A: linuxloops (GUI)
# Install path B: Readme/install-with-linux.md
# Install path C: Readme/install-with-windows.md

After installation, the first real task is usually not an app but a fix: passing the kernel command line options your device needs through Grub, then working through whatever peripheral does not come up. The troubleshooting-and-faqs page is the reference for that, and it also covers changing kernels and framework options. The README's own support channel is a Discord server, which tells you something about the kind of problems users hit. They are device-specific and often need a second pair of eyes.

Where Brunch fails, and why the failure is expensive

The most serious limitation is the one the project states itself. Because Brunch is not how ChromeOS is meant to run, a future ChromeOS change could break compatibility and delete data unexpectedly, and the README notes this can reach non-ChromeOS partitions. A dual-boot setup does not isolate you from that.

Hardware support is the second boundary, and it is drawn tightly. Pre-10th-gen Intel and older AMD CPUs are out. Discrete GPUs are out. Virtual machines are out, which removes the obvious safe way to try Brunch before touching real hardware. ARM is out. If your machine falls outside the list, no amount of troubleshooting will move it inside.

Peripherals are a third, quieter problem. The README lists camera, microphone and touchpad as features that may not work or may need troubleshooting. On a laptop that is most of the interactive experience. On a desktop with an external keyboard and mouse it matters much less.

The maintenance cost is real but visible. Releases arrive on a steady cadence: r150-stable on 2026-08-01, r151-stable on 2026-08-23, r152-stable on 2026-09-13. The last push to the repository was on 2026-09-13, so the project is current. Each release tracks a ChromeOS milestone, and the README references a brcr-update tool by BiteDasher and a brunch-toolkit by WesBosch for update work, which suggests the upgrade path is a community workflow rather than a single official command. The README does not document rollback, so plan your own before an upgrade.

Brunch compared with installing a Linux distribution instead

The realistic alternative is not another ChromeOS-on-PC project. It is a conventional Linux distribution on the same hardware.

A mainstream distribution installs onto the machine directly, uses the kernel its maintainers ship, and expects standard PC firmware. Brunch inverts that. It keeps ChromeOS as the operating system and inserts a compatibility layer underneath, which is why it needs a 1GB ROOTC partition, an initramfs, swtpm binaries and userspace patches before anything boots. The difference in approach shows up in what you get afterward: a distribution gives you a package manager and a desktop you configure; Brunch gives you the ChromeOS interface with Android app support and Google's update model, assuming the underlying hardware cooperates.

That trade is the whole point. If you want ChromeOS specifically, on hardware you already own, Brunch is the path. If you want a working computer with the least friction, a Linux distribution is the shorter road, and the README's own hardware requirements are essentially a restatement of Linux kernel compatibility. You are already depending on Linux drivers either way.

A second alternative is simply buying a Chromebook. That sidesteps the data-loss warning, the kernel command line tuning, the peripheral troubleshooting and the milestone-chasing upgrade cycle in one move. Brunch exists for people who have decided not to do that.

Licence and the cost of keeping up with ChromeOS milestones

Brunch is licensed under GPL-3.0, and the LICENSE file sits at the repository root. The README credits Project Croissant, the swtpm maintainer, the Linux-Surface crew and the Chromebrew framework as work that was actively used when creating the project. If you redistribute a Brunch-based image, the GPL-3.0 obligations attach to the Brunch components. That is a statement about the licence, not legal advice, and it says nothing about Google's terms for the ChromeOS recovery image you supply yourself.

The upgrade cost is the part people underestimate. ChromeOS moves in milestones, and Brunch releases follow them: r150, r151, r152 within roughly six weeks. Staying current means repeating the build or update process regularly, and the README does not document a rollback procedure if a new milestone misbehaves on your hardware. The community tooling referenced in the README (brcr-update, brunch-toolkit) exists precisely because this is repetitive work. Budget time for it, and keep a known-good recovery image and your Grub configuration somewhere you can get back to.

Editorial conclusion

Brunch suits someone with a spare UEFI x86_64 machine, an entry-level grasp of the Linux terminal, and no sensitive data on the disk, who wants ChromeOS without buying a Chromebook. It does not suit anyone whose only computer holds irreplaceable files, anyone on pre-10th-gen Intel or an unsupported Ryzen part, or anyone planning to run it inside a virtual machine, since the README lists VMs as unsupported. Before committing, read the install-with-linux or install-with-windows guide under Readme/ and the troubleshooting-and-faqs page, and pick the recovery image that matches your CPU: jinlon for Intel 10th gen, voxel for 11th gen and above, gumboz for Ryzen.

Frequently asked questions

Official sources

1. Issues
2. License: GPL-3.0
3. README
4. Releases
5. sebanc/brunch on GitHub