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
- 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):
- Copy the test directory aum-offline-upgrade to the target device:
- Log into the target device:
$ git clone --branch apertis/v2026dev1 https://gitlab.apertis.org/tests/aum-offline-upgrade.git
$ DUT_IP=<device-ip>
$ scp -r aum-offline-upgrade user@$DUT_IP:
$ ssh user@$DUT_IP
Execution Steps
- 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
- Enter test directory
- Run the script preparing the system
- Reboot the system
- Before starting the Phase 4, ensure the previous steps have been successful, the following command should return '3':
- 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
- Check that bootlimit has been exceeded, by looking at u-boot logs
- Check that after booting the original deployment has been used with:
$ cd aum-offline-upgrade
$ ./run-test-aum-rollback-bootcount.sh
$ cat /var/run-phase
$ 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