-
Notifications
You must be signed in to change notification settings - Fork 53
ADRs
What is the status, such as proposed, accepted, rejected, deprecated, superseded, etc.?
What is the issue that we're seeing that is motivating this decision or change?
What is the change that we're proposing and/or doing?
What becomes easier or more difficult to do because of this change?
Proposed
To boot the recovery system today the bootloader needs to mount the recovery image on a loopback device.
Also secure-boot is currently not supported for squashfs recovery systems since our grub2 artifacts do not include the signed squashfs module.
The following code paths deploy recovery systems:
- build-disk: Uses the recovery image to deploy bootloader and the recovery system. Uses CreateImageFromTree directly.
- build-iso: Brings it's own grub configuration, but uses the provided bootloader and extracts kernel+initrd to a boot//loader/ directory. Uses a custom variety of DumpSource and directly calling utils.CreateSquashFS
- install: Deploys the system image and uses it as a snapshot source to deploy the recovery image. Uses DeployImage.
- upgrade-recovery: Uses DeployImage directly.
We should consider extracting the kernel and initrd from the image to be able to directly boot the recovery system without loopback devices.
While doing this we should also refactor the mentioned commands to deploy the recovery image in the same way.
This should unify our code-base to use the same deployment of recovery system in all code paths.
We remove the need for loopback devices when booting the recovery system. This means we take another step toward being bootloader agnostic.
We will also be able to secure-boot our expandable disk images and use compression without affecting secure-boot status.