apertis-update-manager-amd64-rollback manual
low
- Image Types:
- fixedfunction-amd64
- Image Deployment:
- OSTree
- Type:
- functional
Description
Test the automatic rollback and blacklist mechanism of apertis-update-manager.
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
Execution Steps
- 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
- When the >Shell prompt is seen execute bootx64
- Wait for 2 seconds and press the reboot button
- Repeat this 4 times followed by a reset and 1 more time to let it boot completely
- To check the bootcount status enter FS0:, then ls
- boot count is correctly set for ostree-0-2 +0-4 means there is 0 left boot and 4 tries
- 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 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
$ Shell> FS0:
$ FS0:\> ls
Directory of: FS0:\
12/14/2020 03:15 <DIR> 512 EFI
12/15/2020 09:21 <DIR> 512 loader
12/15/2020 08:37 <DIR> 512 ostree
0 File(s) 0 bytes
3 Dir(s)
$ FS0:\> ls loader\entries
Directory of: FS0:\loader\entries\
12/14/2020 03:15 <DIR> 1,024 .
12/14/2020 03:15 <DIR> 512 ..
12/15/2020 08:37 565 ostree-0-1.conf
12/15/2020 08:37 565 ostree-0-2+0-4.conf
2 File(s) 1,130 bytes
2 Dir(s)
$ 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/v2022/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
UEFI is able to detect rollback situation
UEFI 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