Document ChromeOS Flex install on internal eMMC and GRUB chainload dual-boot

This commit is contained in:
2026-09-04 00:16:35 -04:00
parent 9f84f05578
commit 78e52ffb29
+57 -1
View File
@@ -15,7 +15,8 @@ This is a real **HP Chromebook 13 G1** ("chell" board), converted from ChromeOS
- BIOS/firmware: `coreboot`, version `MrChromebox-2606.1` (release date 07/14/2026) — confirms MrChromebox custom firmware, not stock ChromeOS firmware. (Was `MrChromebox-2512.2` / 01/25/2026 as of initial provisioning 2026-09-03; updated via MrChromebox firmware utility same day — see note below.) - BIOS/firmware: `coreboot`, version `MrChromebox-2606.1` (release date 07/14/2026) — confirms MrChromebox custom firmware, not stock ChromeOS firmware. (Was `MrChromebox-2512.2` / 01/25/2026 as of initial provisioning 2026-09-03; updated via MrChromebox firmware utility same day — see note below.)
- System: Manufacturer `Google`, Product Name `Chell`, Family `Google_Glados`, Serial `5CD732BLC9` — `Chell`/`Glados` is the Google Chrome OS board/reference codename for the HP Chromebook 13 G1. - System: Manufacturer `Google`, Product Name `Chell`, Family `Google_Glados`, Serial `5CD732BLC9` — `Chell`/`Glados` is the Google Chrome OS board/reference codename for the HP Chromebook 13 G1.
- Baseboard: Manufacturer `Google`, Product Name `Chell`, Serial `PFYTU018J90043`. - Baseboard: Manufacturer `Google`, Product Name `Chell`, Serial `PFYTU018J90043`.
- Implication: fanless Core m CPU, no way to add a fan — keep sustained-load expectations modest; eMMC (`mmcblk0`, ~29GB) is the original ChromeOS storage, while `/` lives on `sda` (117GB), suggesting an internal drive swap/upgrade was done as part of the conversion. - Implication: fanless Core m CPU, no way to add a fan — keep sustained-load expectations modest.
- **Storage correction (2026-09-04)**: `sda` (117GB, where `/` lives) is actually an external USB/SD card (`lsblk` shows `TRAN=usb`) — the whole KDE neon install boots from that external card, not from anything internal. The real internal eMMC (`mmcblk0`, ~29GB) was blank until 2026-09-04, when ChromeOS Flex was installed onto it — see "Dual boot" section below. (Superseded the original note here, which incorrectly assumed `sda` was internal.)
## Kernel 7.x black-screen bug (diagnosed and fixed 2026-09-03) ## Kernel 7.x black-screen bug (diagnosed and fixed 2026-09-03)
@@ -86,3 +87,58 @@ so this looks like a one-off "settle in" hiccup from the fresh firmware
flash itself, not a recurrence of the underlying i915 bug or a new flash itself, not a recurrence of the underlying i915 bug or a new
problem. If it happens again right after a firmware update, try a forced problem. If it happens again right after a firmware update, try a forced
power-off + power-on before assuming anything is actually broken. power-off + power-on before assuming anything is actually broken.
## Dual boot: KDE neon (USB) + ChromeOS Flex (internal eMMC)
2026-09-04: installed ChromeOS Flex onto the internal eMMC
(`/dev/mmcblk0`), which was blank (see storage correction above — the
KDE neon system boots from an external USB/SD card on `sda`, not from
anything internal, so writing to the eMMC was safe to do live from the
running system with zero risk to the neon install).
**How it was installed**: the Flex recovery image
(`chromeos_16640.57.0_reven_recovery_stable-channel_RevenMPKeys-v10.bin.zip`,
in `matt`'s `~/Downloads`) is a full raw GPT disk image — exactly what
the normal "boot from USB, then Install CloudReady/Chrome OS Flex" flow
`dd`s onto the target disk. Since neon's root already lives on external
media, that install flow was skipped entirely and the image was
streamed straight onto the eMMC instead:
```
sudo sh -c 'unzip -p "<path to .zip>" <path to .bin inside the zip> \
| dd of=/dev/mmcblk0 bs=4M status=progress conv=fsync'
```
Unzipped image is ~8.9GB; eMMC is 29GB, plenty of room (ChromeOS auto-
expands the stateful partition to fill the rest on first real boot).
eMMC write speed degraded over the transfer (~130MB/s at the start down
to ~9MB/s by the end, total ~18 min for 8.9GB) — looks like the eMMC's
SLC write cache exhausting partway through; expected/normal for eMMC of
this class, not a fault.
**Boot selection** — both OSes are reachable two ways:
1. **From GRUB** (neon's own boot menu, visible for 5s per
`GRUB_TIMEOUT`): a custom entry "ChromeOS Flex (internal eMMC)" was
added to `/etc/grub.d/40_custom`, which chainloads the eMMC's own EFI
bootloader:
```
menuentry "ChromeOS Flex (internal eMMC)" {
insmod part_gpt
insmod fat
insmod chain
search --no-floppy --fs-uuid --set=root CBE4-703E
chainloader /EFI/BOOT/BOOTX64.EFI
}
```
`CBE4-703E` is the FAT filesystem UUID of the eMMC's `EFI-SYSTEM`
partition (`mmcblk0p12`); `/EFI/BOOT/BOOTX64.EFI` is Chrome OS's
fallback UEFI loader (`crdyboot`) on that partition. Run
`sudo update-grub` after editing `40_custom` for changes to take
effect.
2. **From the firmware's own UEFI boot picker** (MrChromebox UEFI,
typically `Esc` during POST) — `efibootmgr -v` shows both `neon`
(Boot0005, on the USB stick) and `Internal eMMC` (Boot0001) as
registered entries, `BootOrder` currently `0005,0001,0000,0003,0002`
(neon first). If the USB stick is unplugged, firmware falls through
past the missing `neon` entry straight to `Internal eMMC` and boots
Flex automatically — no menu needed.