Survive kernel updates on a /boot this small

A dnf upgrade to 7.1.8 installed the kernel rpm cleanly, then ran /boot out
of space. dracut wrote no initramfs, and because kernel-install stops at the
first failing plugin, 95-c630-devicetree never ran either — leaving a boot
entry with neither an initrd nor a devicetree line, which on this machine can
never boot. dnf reported success and nothing retried.

A kernel costs ~336 MiB here: a 210 MiB hostonly=no initramfs, a 98 MiB
dtb-<kver> directory carrying every board's device tree, plus vmlinuz and
System.map. Three of those cannot fit 1 GiB, so /boot goes to 2 GiB and
installonly_limit drops to 2.

Also fixes the quieter half of the same trap. snd-soc-wsa881x lives outside
the kernel package, so the speakers go silent after any kernel update with
nothing in the logs to explain it. c630-wsa881x rebuilds it and
96-c630-wsa881x.install calls it on each kernel-install add — always exiting
0, since a plugin failure is precisely what caused the damage above.

grub.cfg gains the next_entry one-shot block that has been carried by hand all
along, so testing a kernel costs a power cycle rather than a rescue.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_011XgGF5wfxLDAybVnNz6eNQ

docs/install.md

@@ -125,6 +125,54 @@ sudo date -u -s "2026-07-27 16:33:00"
 Any roughly-correct time will do; it only has to be later than the packages
 were signed.
 
+## Kernel updates and a full /boot
+
+A kernel costs about 336 MiB here — a ~210 MiB initramfs (built `hostonly=no`,
+so it carries the whole driver and firmware set), a ~98 MiB `dtb-<kver>`
+directory because `kernel-core` ships every board's device tree, plus vmlinuz
+and System.map. Three of those do not fit a 1 GiB `/boot`, which is why images
+now use 2 GiB and `installonly_limit=2`.
+
+If `/boot` does fill up, the failure is quiet and genuinely dangerous:
+
+1. The kernel rpm installs fine — `rpm -V` is clean and the module tree is
+   complete.
+2. `50-dracut.install` then dies on ENOSPC, so **no initramfs is written**.
+3. `kernel-install` stops at the first failing plugin, so
+   `95-c630-devicetree.install` never runs and the boot entry gets **no
+   `devicetree` line** — which on this machine means it can never boot,
+   because the UEFI supplies no device tree.
+4. `dnf` reports success. Nothing retries, and later `dnf upgrade` runs look
+   clean because they no longer touch the kernel.
+
+So an update can leave a kernel that is installed, listed in the boot menu, and
+unbootable. To check whether it actually completed:
+
+```sh
+rpm -q kernel-core                       # what rpm thinks is installed
+ls /boot/initramfs-*                     # one per kernel, or the update failed
+sudo grep -L devicetree /boot/loader/entries/*.conf   # any output is unbootable
+```
+
+To repair it, free space first, then redo the two steps that were skipped:
+
+```sh
+sudo dnf remove kernel-core-<old-version>
+sudo dracut --force --kver <kver> /boot/initramfs-<kver>.img
+sudo /etc/kernel/install.d/95-c630-devicetree.install add <kver>
+```
+
+Both are idempotent. Test the result with a one-shot boot rather than by
+changing the default, so a kernel that hangs costs only a power cycle:
+
+```sh
+sudo grub2-editenv /boot/grub2/grubenv set next_entry=c630-<kver>
+sudo reboot
+```
+
+Note that `speakers go silent after a kernel update` is the same event wearing a
+different hat — see `c630-wsa881x` in [firmware.md](firmware.md).
+
 ## If it does not boot
 
 The kernel command line is the first thing to change. It lives in