Mark the active slot from update_engine instead of /postinstall.
In Chrome OS, we were reliying on the /postinst script to generate the
verity hashes and mark the new kernel as bootable. This means that we
also need to run /postinst from the other (not verified) slot when
doing a user-initiated rollback. The update_engine already interacts
with the bootloader via the BootControlInterface to mark the other slot
as unbootable and check if there are other slots available for
rollback.
This patch moves the responsibility of marking the new slot as bootable
from the /postinst script to the update_engine, introducing a new
SetActiveBootSlot() method in the BootControlInterface. Chrome OS
builds will continue to mark the new slot as active from /postinstall
in order to be compatible with old builds, resulting in the new slot
marked as active twice during a successful normal update.
Bug: 23523562
Test: cros flash and image to the new daemon; rolled it back
Change-Id: I02502d7b8e85523a6eb9a7721053739e8381d266
diff --git a/boot_control_interface.h b/boot_control_interface.h
index 36f2caf..2fe6890 100644
--- a/boot_control_interface.h
+++ b/boot_control_interface.h
@@ -65,6 +65,12 @@
// Returns true on success.
virtual bool MarkSlotUnbootable(Slot slot) = 0;
+ // Set the passed |slot| as the preferred boot slot. Returns whether it
+ // succeeded setting the active slot. If succeeded, on next boot the
+ // bootloader will attempt to load the |slot| marked as active. Note that this
+ // method doesn't change the value of GetCurrentSlot() on the current boot.
+ virtual bool SetActiveBootSlot(Slot slot) = 0;
+
// Mark the current slot as successfully booted asynchronously. No other slot
// flags are modified. Returns false if it was not able to schedule the
// operation, otherwise, returns true and calls the |callback| with the result
