kukui改造计划 —— 彻头彻尾失败的折腾

2026 年 4 月 4 日 星期六(已编辑)
/ ,
1

kukui改造计划 —— 彻头彻尾失败的折腾

前记

2026 年 3 月 12 日，我购入了一台 Lenovo IdeaPad Chromebook Duet 10.9（初代）。这台机器虽然性能有限，但可玩性极高。到手后发现卖家已关闭操作系统验证，启动界面提供进入 Legacy BIOS 和从 USB 启动的选项，这让我开始期待 EFI 引导的开放性能为 kukui 带来更多可能。2026 年 4 月，受够了内置虚拟机的低性能和 flatpak 对 ARM 二进制包支持不足的问题，我决定彻底移除 ChromeOS。

目标

  • 机器：Chromebook Duet
  • SoC：MT8183
  • 代号：kukui
  • 目标：将 Linux 安装到 eMMC，基本清除 ChromeOS
  • 目标发行版：Arch Linux ARM

摘要：

  1. 先用 Cadmium 官方 Debian release 建立可启动的 Chromebook 内核/引导链。
  2. 再将 eMMC 上的 IntRoot 根分区替换为 Arch Linux ARM 的 rootfs。
  3. 短期继续使用 Cadmium 的内核。
  4. Arch 只接管用户态，不接管内核分区。

Episode I：借用 velvet-os 的 KERN 分区，尝试替换 rootfs

1. 了解 Chromebook 启动链

最初误以为可以刷入通用 UEFI 固件，但实际并非如此。Chromebook 的启动链 为：

  • Coreboot（Google 定制）
  • depthcharge（验证启动）
  • 设备专用 kernel / DTB

无法将其转换为通用 UEFI 启动。

通过搜索找到 Arm的Chromebook手动切换AB分区 cgpt使用教程 Ubuntu双系统共存 改温度墙，其方法是：

  • 使用 cgpt 切换 ChromeOS 的 A/B 启动分区。
  • 在不破坏 ChromeOS 前 12 个分区的前提下，缩小 ROOT-B 或调整 stateful 分区，为 Ubuntu 腾出空间实现双系统。
  • 仍依赖 Chromebook 的原生启动方式和特定分区布局。

这种方式腾出空间小，且无法完全移除 ChromeOS，不符合我的需求。因此我需要寻找现成的 KERN + rootfs 方案。

2. 发现 velvet-os

在 velvet-os/imagebuilder 中发现该项目支持在 ARM64 Chromebook 上运行 Debian，并且支持 kukui。将镜像烧录到 U 盘后，顺利进入了 velvet-os。

于是产生一个想法：保留 USB 上 velvet 的 KERN 分区，将 rootfs 替换为 Arch Linux ARM。

3. 尝试替换 rootfs

查看内核命令行：

cat /proc/cmdline

输出为：

root=LABEL=rootpart

当时认为可以新建一个分区存放 Arch Linux ARM 的 rootfs，并将 LABEL 设为 rootpart，即可无痛切换到 Arch。

操作步骤：

# 创建新分区，配置 DNS，下载并解压 Arch Linux ARM rootfs
wget -O - http://os.archlinuxarm.org/os/ArchLinuxARM-aarch64-latest.tar.gz | sudo tar -xzpf - -C /mnt/arch
# chroot 进行最小初始化，修改分区 LABEL，重启

但重启后 Arch 的 TTY 键盘驱动/按键映射出现严重问题：键盘难以触发，输入不显示文本（类似密码输入模式），内置和外接键盘均如此。

原因分析：当时复用的 velvet/stb 内核（6.12.50-stb-cbm）并非 Arch 通用的 Chromebook 内核，可能存在键盘驱动和 keymap 双重问题。

4. 更换内核尝试与失败

尝试安装 Arch 的 Chromebook 内核：

pacman -S --disable-sandbox linux-aarch64-chromebook

但安装脚本将内核 blob 直接写入了 /dev/sda5（当时的 Arch 根分区），破坏了分区数据。

原因：linux-aarch64-chromebook 包的安装脚本会将 Chromebook kernel blob 写入块设备，而 chroot 环境中 /boot 未正确指向目标设备，导致误写。

相关讨论见 velvet-os/imagebuilder#150。其中提到有人成功使用 linux-aarch64-chromebook 在 kukui 上运行 Arch，但需要正确设置分区和内核安装位置。这条路最终搁置，但或许这才是更正确的答案。

5. 尝试使用 stb-cbm 内核重新生成 KERN 分区

在 velvet 中生成新的、适合 kukui/krane 的 Chromebook KERN 分区镜像，并刷入 USB 的 KERN 分区：

sudo env NO_FLASH=1 CUSTOM_ROOT_PARAMETER='root=LABEL=archnew rootwait rw' vtbuild "$(uname -r)"
sudo env NO_FLASH=1 CUSTOM_ROOT_PARAMETER='root=LABEL=archnew rootwait rw' CUSTOM_SUFFIX='-archnew' vtbuild "$(uname -r)"

sudo dd if=/boot/vmlinux.kpart-initrd-6.12.50-stb-cbm+-archnew of=/dev/sda2 bs=4M status=progress conv=fsync
sync

sudo cgpt add -i 2 -P 10 -S 1 -T 2 /dev/sda
sudo cgpt add -i 1 -P 1 -S 0 -T 0 /dev/sda
sudo cgpt show /dev/sda

sync
sudo reboot

但键盘问题依旧存在。

Episode II：使用 Cadmium 引导，将 eMMC rootfs 换成 Arch Linux ARM

1. 第一条路：直接构建 Arch 镜像（失败）

在 Reddit 上看到 Cadmium 项目被多次提及，它是一个面向部分 ARM 笔记本的 Linux 安装器。这正是我需要的工具。

1.1 修改配置

将 config 中的 ROOTFS 改为 arch。

1.2 构建命令

./build-all cadmium-kukui-arch.img 8G

1.3 遇到的补丁问题

构建过程中出现致命错误：Cadmium 开始打一些不属于 kukui 的内核补丁，例如：

  • x1e80100.uart14.patch
  • x1e80100.slim7x-bt.patch

这两个补丁明显是给 Snapdragon X Elite / Yoga Slim 7x 用的，而非 MT8183 kukui。

报错信息：

Applying .../x1e80100.uart14.patch
can't find file to patch at input line 19
File to patch:

检查 kernel/build 脚本发现，在 mainline 内核树类型下，PATCHSUFFIX 被设为 patch，然后脚本会遍历 kernel/patches/ 目录下所有 .patch 文件并尝试打补丁，没有进行设备过滤。

1.4 继续失败

将无关补丁移走后：

mv kernel/patches/x1e80100.uart14.patch ../cadmium-patches-disabled/
mv kernel/patches/x1e80100.slim7x-bt.patch ../cadmium-patches-disabled/
rm -rf tmp/linux-aarch64
./build-all cadmium-kukui-arch.img 8G

后续又遇到其他补丁问题：

  • gru.0002-drm-rockchip-Only-wait-for-panel-ACK-on-PSR-entry.patch
  • kukui.unbreak-bluetooth.patch

均出现类似错误：

Reversed (or previously applied) patch detected!  Skipping patch.

说明这些补丁对当前 mainline 内核已过时或已上游化，但 Cadmium 脚本没有跳过已应用补丁的逻辑。

1.5 放弃直接构建 Arch

源码构建 Arch 镜像不稳定、不可复现，因此放弃。

2. 第二条路：使用官方 Debian release 作为基线

源码构建不靠谱，改用 Cadmium 官方 release 的 Debian 镜像作为基线，以获取已在 kukui 上验证可启动的 Cadmium 内核 + Chromebook 引导链。

2.1 实机测试

官方 Debian release 的 USB 镜像能在此 Duet 上正常启动。

2.2 安装 Debian 到 eMMC

在官方 release 上运行 ./install。由于 sid 中已无 ntpdate 包，安装过程中出现：

Error: Package 'ntpdate' has no installation candidate

但基础系统安装基本完成。

2.3 确认分区布局

安装后 eMMC 上形成以下关键分区：

  • IntKernelA
  • IntKernelB
  • IntRoot

USB 启动盘上对应：

  • ExtKernelA
  • ExtKernelB
  • ExtRoot

后续方案基于此：USB 上为已知可启动的 Cadmium 系统，eMMC 为目标系统。

2.4 手工替换 rootfs 为 Arch

不再让 Cadmium 直接生成 Arch 镜像，而是手工将 eMMC 的 IntRoot 分区内容替换为 Arch Linux ARM rootfs。

2.5 保留分区

尽量保留 IntRoot 分区本身，只替换内容。内核命令行可能引用 root 分区，保留分区可使 UUID/PARTUUID 一致，避免内核能启动但找不到 root 的问题。

2.6 挂载 IntRoot

mount /dev/disk/by-partlabel/IntRoot /mnt

2.7 解压前的准备

  • bsdtar 不存在：通过 apt update && apt install libarchive-tools 解决。
  • /mnt/etc/resolv.conf 是符号链接，直接写入会被拒绝。需先删除链接再创建普通文件：
rm -f /mnt/etc/resolv.conf
printf 'nameserver 1.1.1.1\nnameserver 8.8.8.8\n' > /mnt/etc/resolv.conf

2.8 解包 Arch Linux ARM rootfs

cd /tmp
wget <ArchLinuxARM tarball>
bsdtar -xpf <tarball> -C /mnt

然后补充基础配置：

  • /mnt/etc/hostname
  • /mnt/etc/fstab
  • /mnt/etc/resolv.conf

2.9 chroot 初始化

mount --bind /dev /mnt/dev
mount --bind /proc /mnt/proc
mount --bind /sys /mnt/sys
mount --bind /run /mnt/run
chroot /mnt /bin/bash

在 chroot 内换镜像源、初始化 keyring、升级系统等。

2.10 防止 Arch 覆盖内核

升级过程中，linux-aarch64-chromebook 等包可能会尝试将新内核写入设备。为避免破坏 Cadmium 引导链，需谨慎操作，或暂时不安装内核包。

2.11 首次启动失败

重启后从 eMMC 启动，未进入 Linux，而是卡在类似“系统正在进行一个关键更新，请勿关闭系统”的界面。这表明 ChromeOS 固件未能从 eMMC 内核分区成功启动，问题不在 rootfs 而在启动链。

2.12 排查启动问题

使用 cgpt show /dev/mmcblk0 检查分区状态，发现 IntKernelA 存在且类型正确（ChromeOS kernel），属性也正常（priority=10, tries=2, successful=1）。因此不是 GPT 标志位损坏，而是内核内容不对。

2.13 修复内核分区

将 eMMC 的 IntKernelA 恢复为与 USB 上 ExtKernelA 相同的 Cadmium 内核。可以重新运行安装脚本或直接复制内核分区内容。完成后，终于从 eMMC 顺利进入 Arch。

2.14 内核与模块不匹配

进入 Arch 后系统能启动，但键盘无反应。检查发现：

  • 当前运行内核：6.12.0-cadmium
  • Arch rootfs 中模块目录仅有：/lib/modules/6.9.10-1-aarch64-ARCH

内核与模块严重不匹配，导致 HID/输入驱动未加载。

2.15 复制匹配模块

从 live 环境复制与当前内核匹配的模块到 Arch：

mkdir -p /mnt/lib/modules
cp -a /lib/modules/6.12.0-cadmium /mnt/lib/modules/
mkdir -p /mnt/lib/firmware
cp -a /lib/firmware/. /mnt/lib/firmware/
sync

然后 chroot 执行：

depmod -a 6.12.0-cadmium

重启后，USB HID 设备在 dmesg 中显示正常的 input: 节点，键盘恢复。

2.16 安装图形环境

sudo pacman -S sway foot waybar wofi xorg-xwayland network-manager-applet

直接运行 sway 出现闪屏、花屏等图形异常。

2.17 修复花屏

通过环境变量强制软件渲染并禁用硬件光标：

WLR_RENDERER=pixman WLR_NO_HARDWARE_CURSORS=1 sway

之后 sway 可稳定进入，使用 Super + Enter 打开 foot 终端。

Episode III：验证阶段

网络

无 GUI 下通过 NetworkManager 和 nmcli 连接 Wi-Fi：

sudo pacman -S networkmanager
sudo systemctl enable --now NetworkManager
nmcli device wifi connect <SSID> password <password>

蓝牙

蓝牙功能基本正常：

sudo pacman -S bluez bluez-utils
sudo systemctl enable --now bluetooth
bluetoothctl
# power on
# agent on
# default-agent
# scan on

可正常发现控制器和设备。

声音

声音问题尚未完全解决。

初始状态

PipeWire 中只有 Dummy Output，但 aplay -l 和 arecord -l 能看到声卡：mt8183_mt6358_ts3a227_max98357，说明内核驱动已加载，ALSA 设备存在，问题在用户态配置。

问题定位

pactl list cards 显示声卡 Active Profile: off。手动切换：

pactl set-card-profile alsa_card.platform-mt8183-sound pro-audio

之后 PipeWire 中出现了多个真实 sink/source，但播放音频仍无声音输出。可能音频路由或输出路径尚未打通。

总结

已可用部分

  • 从 eMMC 启动
  • Arch Linux ARM rootfs
  • Cadmium 6.12.0-cadmium 内核
  • 内建键盘
  • 外接键盘
  • USB HID
  • Wi-Fi
  • 蓝牙
  • TTY 正常
  • sway 可进入（软件渲染模式）
  • 图形基本可用

尚未解决部分

  • 音频输出
  • 更优的图形加速
  • 完全摆脱 Cadmium 内核
  • 更完整的桌面体验

经验教训

  1. 不要一上来就硬啃 Cadmium 的 Arch build：对 kukui 而言，更可靠的路线是先使用官方 Debian release 建立可启动链，再手工替换 rootfs。

  2. Cadmium 当前 mainline 构建的 patch 逻辑过于粗糙：PATCHSUFFIX="patch" 导致所有 .patch 文件都会被打入，包括不属于目标设备的补丁，也会尝试打已过时的补丁。

  3. 混合内核与 rootfs 时，必须匹配 /lib/modules：只替换 rootfs 而不替换内核时，必须将运行内核对应的模块复制到 rootfs 中，否则会出现能启动但输入设备失灵等问题。

  4. 短期内不要急于让 Arch 接管内核分区：最稳定的策略是使用 Cadmium 内核 + Arch 用户态，而非自行封装 ChromeOS 内核分区。在系统稳定可用之前，不值得冒险切换内核来源。

最终形态：

Boot firmware: ChromeOS stock firmware
Boot chain: Cadmium / depthcharge-compatible kernel partition
Kernel: 6.12.0-cadmium
Rootfs: Arch Linux ARM
Storage: eMMC
GUI: sway (pixman + no hardware cursors)
Working: boot, keyboard, Wi-Fi, Bluetooth, TTY, basic GUI
Broken / incomplete: audio

使用社交账号登录

  • Loading...
  • Loading...
  • Loading...
  • Loading...
  • Loading...