aum-rollback-bootcount manual

critical

Image Types:
fixedfunction-armhf / fixedfunction-arm64
Image Deployment:
OSTree
Type:
functional

Description

Apertis update manager: Rollback bootcount This test ensures that the update manager is able to rollback to an old deployment in case of bootcount exceeded.


Pre Conditions

  1. Clone the tests repository from another computer (Note that the branch being tested may change depending on the release, please make sure to clone the correct branch for the release in question):
  2. $ git clone --branch apertis/v2026dev1 https://gitlab.apertis.org/tests/aum-offline-upgrade.git
  3. Copy the test directory aum-offline-upgrade to the target device:
  4. $ DUT_IP=<device-ip>
    $ scp -r aum-offline-upgrade user@$DUT_IP:
  5. Log into the target device:
  6. $ ssh user@$DUT_IP

Execution Steps

  1. For Phase 1-3, perform the actions 2 to 4 to move to the next phase, the actions prepare the system and run the test in the appropriate phase
  2. Enter test directory
  3. $ cd aum-offline-upgrade
  4. Run the script preparing the system
  5. $ ./run-test-aum-rollback-bootcount.sh
  6. Reboot the system
  7. Before starting the Phase 4, ensure the previous steps have been successful, the following command should return '3':
  8. $ cat /var/run-phase
  9. For Phase 4, power cycle the board just after the u-boot message 'Hit any key to stop autoboot: X' and before 'Starting kernel ...', repeat it for three times to increase bootcount beyond the limit
  10. Check that bootlimit has been exceeded, by looking at u-boot logs
  11. Check that after booting the original deployment has been used with:
  12. $ ostree admin status

Expected

If the test succeeds you will see a log entry

Warning: Bootlimit (3) exceeded. Using altbootcmd.

...

Found /extlinux/extlinux-rollback.conf

Retrieving file: /extlinux/extlinux-rollback.conf

Notes

  • Make sure to boot from the device configured for rollback, if not the bootcount will not be increased
  • The test uses internet
  • The test will prepare the system to perform an OTA update
  • It requires five phases, which require a manual reboot to complete
  • Phase 1 is to prepare the system with a version that can be updated. During this phase, an error message will be displayed: cat: /var/run-phase: No such file or directory (os error 2)
  • Phase 2 aims to clean the old deployment to allow the update
  • Phase 3 performs the OTA update
  • Phase 4 is to simulate a boot failure three times to exceed the bootcount
  • Phase 5 is to check that the system rollback to the previous state