survive a failed kernel install and let callers see failed applies

[cclements]

install_kernel() moves /boot/kernel to kernel.old, then untars the new set
directly into place. If tar dies partway through — disk full, I/O error, bad
media — the function exits, but by then the pending marker has already been eaten
and /boot/kernel is a partial stub. Nothing retries, and the loader will pick that
stub by default on the next boot, so a headless machine ends up stuck at the loader
prompt until someone reaches a console and boots kernel.old by hand. The 05-upgrade
hook in core makes this worse than it sounds, because it reboots the moment any
later stage succeeds (see companion PR opnsense/core#10647).

The fix is to put the old kernel back whenever tar or kldxref fail. I looked at
keeping the pending marker for a retry instead, but that is actively dangerous with
the current layout: a second attempt starts by deleting kernel.old — the only good
kernel left — and then moves the wreckage into its place. Restoring immediately is
the safe shape.

Second change: the deferred apply paths (-K/-B/-P) now exit 2 on failure instead
of 1. Exit 1 stays reserved for "no pending marker", which is what the comment in
those branches already promises ("must error out to prevent reboot"). Until now a
caller literally could not tell that apart from an apply that destroyed something,
and core's boot loop used plain success/failure as its only signal. With this, the
matching core change stops the boot sequence on exit 2 instead of stacking base and
packages on top of a broken kernel. Compatibility works out in both directions: old
core with new update treats any non-zero as before, and new core with old update
keeps seeing exit 1 everywhere, so the loop behaves exactly like today.

The FAILURE=2 flag flips on right after the marker is consumed, and the deferred
paths never call fetch_set (that belongs to the lowercase fetch modes), so every
exit_msg it affects really is a botched apply. The base/kernel version-mismatch
abort in the -B path used a bare exit 1, sidestepping exit_msg; it now honours the
flag too, so the boot hook reports the aborted upgrade instead of finishing the
boot without a word.

Known limitation I left alone on purpose: a pkg-level failure inside install_pkgs
(-P) still falls out with exit 0, because the function swallows the result of the
pkg upgrade run. That's pre-existing behaviour, P is the last stage in the boot
sequence, and by that point kernel and base have already applied and rebooted
cleanly, so there is nothing destructive left to protect. Fixing the reporting
there felt like a separate discussion.

🤖 Generated with Claude Code

[fichtner]

I’m open to improving this, but not via AI. Nobody ever raised a relevant bug report before and there is at least a partial red herring in this analysis.

[fichtner]

Thinking about it I’m not sure what an atomic way to switch would be… does the system boot with kernel.old in place while kernel is not there? We could also extract to kernel.new first and move directories afterwards but also not atomic. There is also the possibility of using „nextboot“ and switching kernel after a successful boot. However, intermittent boot failures or operational issues like premature reset or boot loader usage could prevent the kernel from switching post-boot correctly.

Other consideration is whether the partial extract state is even recoverable since it can depend on a system event, not just an operational issue with a single command. @AdSchellevis mentioned this in the write config PR.

Cheers,
Franco