host/files: Enable managing bootloader/kernel files used before early boot

[ethanjli]

Currently, the only way to manage files on the OS is to have them be exported into the exports subdirectory of a staged pallet bundle, and then (during early/mid-boot) overlay-mount (or bind-mount) files/directories within the exports subdirectory to locations on the filesystem (e.g. /usr and/or /etc). However, this mechanism does not enable us to manage files in /boot, which are on a separate partition and are used (for the bootloader and/or the kernel) before Forklift can be used. If we want to manage such files (e.g. /boot/config.txt on a Raspberry Pi SD card) as part of the process of staging a pallet, then we will need to directly modify/replace those files during the [dev] plt stage command, before it commits the new staged pallet bundle as the next one to apply.

For example, maybe we can have a shell script which copies the new bundle's exports/boot subdirectory into /boot/forklift/stages/(id)/exports/boot and then copies /boot/forklift/stages/(id)/exports/boot/config.txt to /boot/config.txt (hard-linking would be better, but the /boot partition on the RPi SD card is vFAT and vFAT doesn't support symlinks or hard-links). Then this script could be run as a hook by the [dev] plt stage subcommand (and also by the stage set-next subcommand, and also when stage apply reverts from the next staged pallet to the current staged pallet if the next one can't be applied - and in that latter case we'd want to be able to run a hook script to reboot after falling back from a failed apply, so that the running containers aren't inconsistent with /boot/config.txt and other OS files until the next boot). Ideally, hooks could be delivered by Forklift and/or by the host OS, and hook scripts would be placed into drop-in directories.

For more context about the boot partition, refer to:

• https://0pointer.net/blog/linux-boot-partitions.html
• https://github.com/raspberrypi/documentation/blob/develop/documentation/asciidoc/computers/configuration/boot_folder.adoc

[ethanjli]

What if [dev] plt stage experiences a partial failure? We don't really have a way to roll back /boot/config.txt from a broken file to a known-working file upon a failure...which is not good for making upgrades safe. Ideally, we would instead make use of Raspberry Pi's A/B booting facility to swap between different boot partitions. To support that, there needs to be a clean way for Forklift to plug into an A/B boot-partition-swapping mechanism; and maybe the source-of-truth for Forklift's stage store file needs to be stored/loaded that way partition? This may require some careful thinking.