-
Zygmunt Krynicki authored
The new boot/grub package implements boot.Protocol for GRUB, based on the three environment variables documented below. This implementation is compatible with both the legacy and the EFI version of GRUB. It does not rely on any EFI-specific features. The internal protocol between the userspace and the bootloader is organized with three GRUB environment variables. There is one variable which needs to be permanently present and two variables which participate with the try-boot mechanism. The SYSOTA_BOOT_ACTIVE variable must be either set to "A" or "B" and define the slot which is booted into outside of the update process. When an update is attempted SysOTA sets SYSOTA_BOOT_NEXT to the name of the slot, again either "A" or "B" that the bootloader should boot next. The bootloader script guarantees that this slot is only booted into once by deleting the variable before transferring control. Before erasing the variable, the value is copied to SYSOTA_BOOT_TESTED. Back in userspace, SysOTA can commit or rollback the update transaction by looking at this variable and either erasing it (rollback) or copying it to SYSOTA_BOOT_ACTIVE (commit). Signed-off-by:Zygmunt Krynicki <zygmunt.krynicki@huawei.com>
Zygmunt Krynicki authoredThe new boot/grub package implements boot.Protocol for GRUB, based on the three environment variables documented below. This implementation is compatible with both the legacy and the EFI version of GRUB. It does not rely on any EFI-specific features. The internal protocol between the userspace and the bootloader is organized with three GRUB environment variables. There is one variable which needs to be permanently present and two variables which participate with the try-boot mechanism. The SYSOTA_BOOT_ACTIVE variable must be either set to "A" or "B" and define the slot which is booted into outside of the update process. When an update is attempted SysOTA sets SYSOTA_BOOT_NEXT to the name of the slot, again either "A" or "B" that the bootloader should boot next. The bootloader script guarantees that this slot is only booted into once by deleting the variable before transferring control. Before erasing the variable, the value is copied to SYSOTA_BOOT_TESTED. Back in userspace, SysOTA can commit or rollback the update transaction by looking at this variable and either erasing it (rollback) or copying it to SYSOTA_BOOT_ACTIVE (commit). Signed-off-by:Zygmunt Krynicki <zygmunt.krynicki@huawei.com>
Loading
Analyzing file…
Loading