Draft: Fix rollback-blacklist test on EFI systems
The rollback-blacklist test is currently failing on amd64 using GRUB EFI systems.
This MR fixes the case where the alternative boot conf has been removed, which happens after a rollback.
It also fixes the checking on the update flag after a successful update has been performed. However, this is an ongoing discussion as the u-boot case is not matching this behavior.
Merge request reports
Activity
assigned to @adalessandro
mentioned in issue infrastructure/apertis-issues#206
Summarizing: +cc @sjoerd
-
This MR fixes the rollback test on grub-efi systems.
- There's no issue on the ostree rollback test sequence, but fixes were required on how the bootcount file was processed.
- The above means that no manual reboot nor other steps needed to be added. The LAVA test job definition remains the same
-
Commit !42 (c76fd4ec)
- After the rollback, there's no bootcount conf (i.e. no
ostree-0-2*.conf). Because of this, test was failing reporting: "No boot counter found". - This is fixed by detecting the EFI directory first, then considering the above case as default values, i.e. no update is in progress and no bootcount/limit values are set.
- After the rollback, there's no bootcount conf (i.e. no
-
Commit !42 (ae5baaca)
- This is to be discussed, as there's a difference with the u-boot case. The rollback-blacklist test is expecting the update flag to be enabled after a successful update.
- This is currently working fine on u-boot based systems, but not in the grub EFI (blessing) case. After a successful boot, blessing is resetting the alternative boot conf file:
ostree-0-2*.conf(i.e. suffix is removed). As the no-suffix filename is considered as a disabled update flag, the checking fails.
The last item should be discussed, to understand first if this is the correct expected behavior on grub/efi systems. If both u-boot and grub AUM behaviors are correct, we need to adapt the test to process each case separately in that phase.
Edited by Ariel D'Alessandro-