diff --git a/deploy/nixos/hardware/raspberry-pi-4.nix b/deploy/nixos/hardware/raspberry-pi-4.nix
index 50388e9..a30d22c 100644
--- a/deploy/nixos/hardware/raspberry-pi-4.nix
+++ b/deploy/nixos/hardware/raspberry-pi-4.nix
@@ -22,6 +22,28 @@
   # line documents/asserts it.)
   nixpkgs.hostPlatform = lib.mkDefault "aarch64-linux";
 
+  # Mainline kernel, NOT the Raspberry Pi vendor one.
+  #
+  # nixos-hardware's raspberry-pi/4 module mkDefaults boot.kernelPackages to
+  # the vendor kernel (linux-rpi, via common/kernel.nix). That kernel is in no
+  # binary cache — Hydra does not build nixos-hardware's overlays, and it is
+  # not in aiolabs.cachix.org either — so every Pi compiles a kernel from
+  # source, on an SD card, and recompiles on every bump. The first bring-up
+  # attempt spent hours on `CC [M] fs/overlayfs/inode.o` before anyone noticed
+  # what it was doing.
+  #
+  # Mainline aarch64 kernels are cached, and mainline demonstrably boots a
+  # Pi 4: it is what the stock NixOS aarch64 SD image runs. The vendor kernel's
+  # Pi-specific patches buy nothing this kiosk needs — display, USB serial and
+  # WiFi are all mainline, and vc4/v3d KMS has been mainline for years.
+  #
+  # Watch the graphics path when changing this. fkms-3d below is a
+  # nixos-hardware overlay built around the vendor kernel's firmware-KMS route;
+  # the mainline equivalent is full KMS (vc4-kms-v3d). If X ends up on the
+  # framebuffer with Electron rendering in software, that overlay is where to
+  # look — not the kernel choice, which is worth keeping either way.
+  boot.kernelPackages = pkgs.linuxPackages;
+
   # Bootloader: the aarch64 sd-image uses the extlinux-compatible generator;
   # nixos-hardware's rpi4 module wires the firmware/u-boot. No systemd-boot.
   boot.loader.grub.enable = lib.mkDefault false;