apertis-update-manager-rollback manual
low
- Image Types:
- fixedfunction-armhf / fixedfunction-arm64 / fixedfunction-amd64
- Image Deployment:
- OSTree
- Type:
- functional
Description
Test the automatic rollback and blacklist mechanism of apertis-update-manager. The automated version of this test: https://qa.apertis.org/aum-rollback-blacklist.html
Resources
- A static encrypted update bundle file of the same architecture, variant and version as the testing image
- A Fat32 USB flash drive, preloaded with the encrypted update bundle at the root of the disk
- The latest static encrypted update file can be downloaded at the same location than the Apertis image. It has the same basename, and a '.delta.enc' extension
- The static encrypted update file should be copied to the flash drive using the name 'static-update.bundle.enc'.
- A PC must be connected to DUT serial port
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:
- Lilliput/LVDS touch screens must be connected to the respective targets
$ git clone --branch apertis/v2024dev0dev1 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
- Install boot-delay service
- Check the initial deployment
- Prepare the copy of commit and deploy to allow the upgrade to the same version
- Command below shows you an initial commit ID, for instance
- Get the Collection ID and ref
- Create the list of files to skip and ensure there are some files in these directories
- Create the commit with changed timestamp and skipped list from above to allow upgrade with recent update file
- Deploy the prepared commit
- Wait until the system is booted again and check the deployment
- The booted commit (started with '*') must have ID which we prepare and the initial commit ID should be marked as '(rollback)'
- Check booted deployment have no file objects which we skip
- Remove the initial deployment
- Reboot the system
- Check the current deployment
- Start the user interface agent with mode preventing automatic system reboot after update
- Plug the USB flash drive into the device
- The update starts automatically
- After the update, the device does *not* reboot automatically
- Check that the user interface agent reports the pending update
- Remove the USB flash drive
- Check if there is pending deployment and reboot the DUT
- During boot a message will be displayed with a countdown
- Restart the device a first time by pressing the restart button before the countdown is over.
- Restart the device a second time by pressing the restart button before the countdown is over.
- Restart the device a third time by pressing the restart button before the countdown is over.
- The system should be able to detect the rollback mode and boot the system in rollback mode
- On platforms using U-Boot (iMX.6 SABRELite, Raspberry Pi, R-Car, etc.), Boot should warn about initiating the rollback boot (altbootcmd)
- On platforms using UEFI (amd64), by default there's no information that rollback mode has been detected
- Wait for system boot
- Wait a few seconds after the boot to allow ostree to undeploy the deployment. Check the update has been rolled back and that only single deployment exists.
- Start the user interface agent
- Plug the USB flash drive with the same update file into the device
- Check that the user interface agent reports the system is up to update
- Check the journal log should mention that the update ID has been blacklisted
$ sudo ./aum-offline-upgrade/boot-delay-install.sh
$ sudo ostree admin status
$ export BOOTID=$(sudo ostree admin status | sed -n -e 's/^\* apertis \([0-9a-f]*\)\.[0-9]$/\1/p'); echo $BOOTID
$ export CID=$(sudo ostree refs -c | head -n 1 | tr -d '(),' | cut -f 1 -d ' '); echo COLLECTION_ID=$CID
$ export REF=$(sudo ostree refs -c | head -n 1 | tr -d '(),' | cut -f 2 -d ' '); echo REF=$REF
$ ls -1d /usr/share/locale /usr/share/man /usr/share/zoneinfo > /tmp/skip
$ du -sh /usr/share/locale /usr/share/man /usr/share/zoneinfo
$ export NEWID=$(sudo ostree commit --orphan --tree=ref=$BOOTID --add-metadata-string=ostree.collection-binding=$CID --bind-ref=$REF --timestamp="1 year ago" --skip-list=/tmp/skip); echo "New commit: $NEWID"
$ sudo ostree admin upgrade --allow-downgrade --deploy-only --override-commit=$NEWID --reboot
$ sudo ostree admin status
$ du -sh /usr/share/locale /usr/share/man /usr/share/zoneinfo
$ sudo ostree admin undeploy 1
$ sudo ostree admin status
$ sudo updatectl --register-upgrade-handler &
** Message: Upgrade status: Checking
** Message: An upgrade is pending
$ sudo ostree admin status
$ sudo reboot
Warning: Bootlimit (3) exceeded. Using altbootcmd.
Hit any key to stop autoboot: 0
switch to partitions #0, OK
mmc0 is current device
Scanning mmc 0:1...
Found /extlinux/extlinux-rollback.conf
Retrieving file: /extlinux/extlinux-rollback.conf
$ sudo ostree admin status
$ sudo updatectl &
** Message: 09:21:45.026: Upgrade status: Checking
** Message: 09:21:45.300: System is up to date
$ sudo journalctl -ef --unit apertis-update-manager
May 01 09:21:45 apertis apertis-update-[363]: mount added : /media/APERTIS
May 01 09:21:45 apertis apertis-update-[363]: mount added : /media/update
May 01 09:21:45 apertis apertis-update-[363]: Ostree static delta starting
May 01 09:21:45 apertis apertis-update-[363]: Metadata read from commit '710dbec2943510e4deb279cd6738a4a1a5b589eb6c4976e486d056e0308a02e1': {'ostree.ref-binding': <['apertis/v2024dev0/armhf-uboot/fixedfunction']>, 'ostree.collection-binding': <'org.apertis.os'>}
May 01 09:21:45 apertis apertis-update-[363]: Revision '710dbec2943510e4deb279cd6738a4a1a5b589eb6c4976e486d056e0308a02e1' is marked as blacklisted; skipping
May 01 09:21:45 apertis apertis-update-[363]: Ostree already up to date
Expected
The system is able to detect rollback situation
The system is able to use rollback configuration for bootloader
The "failed" update is rolled back
"Failed" update is marked as blacklisted
Apertis-update-manager is able to detect blacklisted update and refuse to update the system with it