6.2 KiB
hp-chell project notes
Agent-accessible host
- hp-chell (
hp-chell.lan.1qaz.ca) — KDE neon (Debian-based) x86_64 laptop (Intel Core m7-6Y75, 4 cores, 15GiB RAM, 117GB disk, Intel HD Graphics 515), full sudo (nopasswd) accountagent-user(uid 60123). Provisioned 2026-09-03.- Auth: SSH key preferred (this machine's
~/.ssh/id_ed25519.pubis already in the host'sauthorized_keys) —ssh agent-user@hp-chell.lan.1qaz.ca. - Fallback password: stored in local Bitwarden vault, item id
1db3b9f6-a82e-4692-846a-b4bb002a5be6(name "agent-user@hp-chell.lan.1qaz.ca (SSH)") — fetch withbw get password 1db3b9f6-a82e-4692-846a-b4bb002a5be6(vault must be unlocked;bw unlock). - Host inventory/specs: see
~/AGENT_INFO.mdon the host itself. Original provisioning prompt saved at~/AGENT_PROMPT.txton the host. - Groups: adm,cdrom,sudo,dip,plugdev,lpadmin,sambashare,docker. Has docker, tailscale0 interface (not connected as of provisioning), python3.12, git, jq, rsync, tmux.
- Auth: SSH key preferred (this machine's
Hardware identity (confirmed via sudo dmidecode -t system -t baseboard -t bios)
This is a real HP Chromebook 13 G1 ("chell" board), converted from ChromeOS to a normal Linux boot via custom coreboot firmware (MrChromebox project) and now running KDE neon as its OS.
- BIOS/firmware:
coreboot, versionMrChromebox-2606.1(release date 07/14/2026) — confirms MrChromebox custom firmware, not stock ChromeOS firmware. (WasMrChromebox-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 NameChell, FamilyGoogle_Glados, Serial5CD732BLC9—Chell/Gladosis the Google Chrome OS board/reference codename for the HP Chromebook 13 G1. - Baseboard: Manufacturer
Google, Product NameChell, SerialPFYTU018J90043. - 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 onsda(117GB), suggesting an internal drive swap/upgrade was done as part of the conversion.
Kernel 7.x black-screen bug (diagnosed and fixed 2026-09-03)
Multiple kernels are installed: 6.17.0-42-generic (and -35) work fine at
boot. 7.0.0-30-generic (and -14) hit a cold-boot display bug: the panel's
backlight comes on but no image ever appears — looks like a dead screen.
Root cause: on a 7.x kernel, i915's very first modeset at boot (Xorg/
Weston auto-configuring the panel's native 3200x1800@60) leaves pipe A
stuck — dmesg shows a CPU pipe A FIFO underrun right after Reducing the compressed framebuffer size.... Everything above that layer (DRM
connector/plane/CRTC state, backlight sysfs, Xorg/Weston logs) reports
fully healthy — eDP-1 connected/enabled/dpms=On, pipe active, plane
visible with real framebuffer content — yet the panel shows nothing. A
second modeset (any resolution change via xrandr) reliably un-sticks
the pipe and it works perfectly afterward, including back at full native
resolution and 12bpc color. This is a kernel/i915 bug, not specific to a
display server — confirmed identical failure under both Xorg (sddm
default) and Wayland (sddm + weston, via DisplayServer=wayland in
sddm.conf.d, which needs the weston package or it silently falls back
to X11).
Ruled out (each verified, none of these were the actual cause):
- Dim/stale backlight (
/var/lib/systemd/backlight/...restoring a low saved value) — this was a real but separate red herring encountered early in diagnosis; fixed by just adjusting brightness once logged in normally. Not the cause of the later, reproducible black-screen bug. cros-ec-gpio: Failed to attach ACPI GPIO chip/EC:ENABLE_BACKLIGHTGPIO name collisions — present identically on working 6.17 boots too.i915.nuclear_pageflip=0boot param — was already present during the original failures; adding/removing it makes no difference (legacy atomic-modeset override, irrelevant on modern i915; also needlessly taints the kernel — removed from/etc/default/grub).i915.enable_fbc=0,i915.enable_psr=0,i915.enable_sagv=0— each tried individually via kernel cmdline, none fixed it.
Fix in place: /usr/share/sddm/scripts/Xsetup (SDDM's root-run hook,
fires right after the X/Wayland server starts, before the greeter draws)
detects a 7.* kernel via uname -r and runs
xrandr --output eDP-1 --mode 1600x900 — a second modeset that un-sticks
the pipe. 1600x900 was chosen (rather than cycling back to native) since
it's an exact half of the panel's native 3200x1800 (clean 2x integer
scaling) and it's only the greeter — the actual logged-in Plasma/Wayland
session correctly renews the modeset itself and comes up at full native
3200x1800 with 125% scaling, confirmed working. No kernel cmdline
workarounds are needed — /etc/default/grub's GRUB_CMDLINE_LINUX_DEFAULT
is back to a clean 'splash'.
Confirmed reliable across multiple clean sudo systemctl poweroff /
power-on cycles. The GRUB default entry (index 0, GRUB_DEFAULT=0) auto-
selects the newest installed kernel, so 7.0.0-30-generic is what boots
by default now; 6.17.0-42-generic remains available via the GRUB
"Advanced options" submenu as a known-good fallback if ever needed.
Setup script for a fresh install: setup-i915-kernel7-fix.sh (in this
repo) installs the Xsetup fix and sets GRUB_TIMEOUT=5 /
GRUB_TIMEOUT_STYLE=menu so the boot menu is visible for 5s. Idempotent,
safe to re-run.
2026-09-03, post firmware update: updated coreboot from
MrChromebox-2512.2 to MrChromebox-2606.1 via the MrChromebox firmware
utility, then rebooted. First boot after the flash appeared to hang after
the Plymouth splash (same visual symptom: backlight on, no image) and
required a forced power-off. The next boot after that came up clean at
SDDM with the Xsetup fix applying normally (empty /tmp/xsetup- modeset.log, one FIFO underrun as expected, pipe un-stuck as usual) —
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
problem. If it happens again right after a firmware update, try a forced
power-off + power-on before assuming anything is actually broken.