Stop kernel upgrades writing entries that cannot boot

Simulating an upgrade — running kernel-core's %posttrans command by hand —
turned up two faults that had nothing to do with the full /boot, and would
have broken every future kernel install on their own.

95-c630-devicetree trusted $KERNEL_INSTALL_BOOT_ROOT. `kernel-install inspect`
reports "Layout: other, Boot Root: /boot/efi" here, because the ESP is all it
recognises, while Fedora's 20-grub.install writes BLS entries to
/boot/loader/entries regardless. So the hook looked for the device tree on the
ESP, did not find it, and skipped the patch — leaving an entry with no
devicetree line, which on this machine cannot boot. Paths in a BLS entry are
relative to the filesystem holding the entry, so the only correct boot root is
the one carrying both loader/entries and dtb-<kver>. Search for that instead.

dracut-config-rescue sets dracut_rescue_image=yes, so each install also built
a second ~210 MiB initramfs, which is what refilled /boot straight after it
was cleared. That image cannot boot this machine either: the rescue entry is
<machine-id>-0-rescue.conf, carrying no kernel version, so the devicetree hook
never matches it. Turned off.

Verified by rerunning the simulation: both kernels now have a devicetree line
and a present initrd, no rescue image is generated, snd-soc-wsa881x is rebuilt
automatically, and /boot holds at 72%.

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

docs/install.md

@@ -142,8 +142,30 @@ If `/boot` does fill up, the failure is quiet and genuinely dangerous:
    `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.
+4. `dnf` reports success — `kernel-install` is invoked from kernel-core's
+   `%posttrans` as `... || exit 0`, which swallows the failure. Nothing
+   retries, and later `dnf upgrade` runs look clean because they no longer
+   touch the kernel.
+
+Two things made that worse, both fixed, both worth knowing if you are reading
+an older image:
+
+**The devicetree hook used to skip silently even with space to spare.** It
+trusted `$KERNEL_INSTALL_BOOT_ROOT`, and on this machine `kernel-install
+inspect` reports `Layout: other, Boot Root: /boot/efi` — it recognises only
+the ESP. Fedora's `20-grub.install` ignores that and writes entries to
+`/boot/loader/entries` anyway, so the hook went looking for the device tree on
+the ESP, did not find it, and left the entry alone. The paths inside a BLS
+entry are relative to the filesystem holding the entry, so the hook now
+searches for the root that has both `loader/entries` and `dtb-<kver>` instead
+of being told.
+
+**The rescue image refilled `/boot` after every cleanup.** `dracut-config-rescue`
+sets `dracut_rescue_image=yes`, so each kernel install built a *second*
+~210 MiB initramfs. It could never boot this machine either: the rescue entry
+is named `<machine-id>-0-rescue.conf` and carries no kernel version, so the
+devicetree hook does not match it. `dracut_rescue_image="no"` in
+`/etc/dracut.conf.d/10-c630.conf` turns it off.
 
 So an update can leave a kernel that is installed, listed in the boot menu, and
 unbootable. To check whether it actually completed: