aum-rollback-bootcount manual
critical
- Image Types:
- fixedfunction-armhf / fixedfunction-arm64 / fixedfunction-amd64
- 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/v2024 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 following actions to move to the next phase, the actions prepare the system and run the test in the appropriate phase
- Enter test directory
- Set environment variables
- Set additional variables which will be use to generate the image file path base on the images available in the server, as example
- Run the actual test
- Reboot the system
- For Phase 4, power cycle the board just after starting the kernel, repeat it for three times to increase bootcount beyond the limit
- Check that bootlimit has been exceeded, by looking at logs
- Check that after booting the original deployment has been used
$ cd aum-offline-upgrade
$ source /etc/os-release
$ ARCH=`dpkg --print-architecture`
$ BASEURL="https://images.apertis.org" BOARD="uboot" IMGPATH="daily/$VERSION"
$ common/run-test-in-systemd --timeout=1200 --name=rollback-bootcount env DEBUG=2 RELEASE=$VERSION ARCH=$ARCH BASEURL=$BASEURL IMGPATH=$IMGPATH IMGDATE=$BUILD_ID IMGTYPE=$VARIANT_ID BOARD=$BOARD ./run-test-ota-auto.sh
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
- 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