Don't require using systemd-boot to get automated firmware updates

[jmbaur]

Description of changes

Using systemd-boot is not a requirement for applying capsule updates. We can make the firmware update a systemd service, which gives us the behavior of running on every switch-to-configuration when the capsule update file changes.

Testing

Tested that the capsule update was successfully applied on an Orin AGX Devkit and a fused Xavier AGX Devkit.

[danielfullmer]

My concern with this is that the current behavior feels more correct (except for the fact that it's tied to systemd-boot). Currently, if you do a switch-to-configuration test, it does not try to apply a UEFI update, but if you do a switch-to-configuration boot or switch-to-configuration switch then it will apply the update. There's similar behavior in for systemd-boot updates in NixOS, where the systemd-boot update would only happen if you did a boot or switch. Unfortunately, I don't see another option that is not systemd specific to additionally do this update at the same time.

[jmbaur]

I've modified the change to not apply the capsule update if nixos-rebuild test is used. Surprisingly, there is little logic in switch-to-configuration regarding when test is the subcommand, only that the bootloader install script is not ran.

[danielfullmer]

I think that should be sufficient. Does this PR pass our uefi update test?

[jmbaur]

I think that should be sufficient. Does this PR pass our uefi update test?

Yes they do! With and without auto update enabled

[danielfullmer]

@jmbaur I believe this PR caused a regression in update behavior. Say we are upgrading from version X to version Y:

Previously, running nixos-rebuild boot against a NixOS system containing newer firmware Y (and with autoUpdate enabled), would drop the capsule update in the right folder on the ESP so that the firmware would pick it up and apply it during the next reboot reboot (before loading the new NixOS system). That would ensure that after a reboot, both the firmware and the NixOS system would be on the new version Y.

Now, because the update logic has been moved entirely into the firmware-update service, when running nixos-rebuild boot, nothing would get dropped into ESP, and during the first reboot, no capsule update would be applied. So after the first reboot it'd be running firmware version X with NixOS version Y. Then, after booting up the firmware-update service finally runs, so on the next reboot it'll come up with both firmware version and NixOS version Y.

I'm not confident that NVIDIA provides any guarantees for anything working if firmware and system software are mismatched. It hasn't been a problem for 35.3.1 -> 35.4.1 or 35.4.1 -> 35.6.0, but I don't want to depend on that going forward.

[danielfullmer]

I should have noticed this earlier. We don't want to run nixos-rebuild switch when upgrading major versions of Jetpack/L4T, since then the new version of the system would be running a different kernel version, etc.