You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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:
ethanjli
changed the title
Enable managing bootloader/kernel files used before early boot
host/files: Enable managing bootloader/kernel files used before early boot
Jun 14, 2024
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.
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 theexports
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 thestage set-next
subcommand, and also whenstage 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:
The text was updated successfully, but these errors were encountered: