Skip to content
  • Zygmunt Krynicki's avatar
    2e25ad6a
    boot: add grub bootloader support · 2e25ad6a
    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: default avatarZygmunt Krynicki <zygmunt.krynicki@huawei.com>
    2e25ad6a
    boot: add grub bootloader support
    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: default avatarZygmunt Krynicki <zygmunt.krynicki@huawei.com>
Loading Analyzing file…
Loading