install: write kernel-direct (kernel as BOOTX64.EFI), not splash chain
Symptom: install completed, UEFI boot entry registered, firmware loaded
"AC Native OS" entry → "Chinese characters scrolling, cuts to black,
falls to boot selector." Classic "EFI binary loaded but doesn't actually
boot" garbage display.
Cause: the install copied splash.efi as /EFI/BOOT/BOOTX64.EFI on the
destination disk (because source USB used systemd-boot universal layout
where splash chains to LOADER.EFI = systemd-boot, which then loads
KERNEL.EFI). On the source USB this works because all the chain
targets are present and firmware-discoverable on the same FAT. On the
freshly installed internal disk the SAME splash.efi fails — likely
because splash assumes a hardcoded partition GUID for LOADER.EFI that
doesn't match the new disk, or because the chain semantics don't
translate cleanly when boot is via NVRAM entry rather than firmware
fallback path.
Fix: install ALWAYS uses kernel-direct boot. The kernel itself is
copied as /EFI/BOOT/BOOTX64.EFI and runs as an EFI stub — its
CONFIG_CMDLINE has `initrd=\initramfs.cpio.gz` baked in so it finds
initramfs at the ESP root automatically. No splash, no systemd-boot,
no loader/entries, no chain.
This is exactly what the USB ACBOOT partition does and it boots
cleanly on the same hardware. We were just gratuitously using the
more complex systemd-boot layout for installs.
Also lifted the `&& systemd_boot_layout` gate on initramfs_src
discovery so the kernel-direct path can find /initramfs.cpio.gz on the
source USB regardless of whether the source had a systemd-boot layout.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>