The test ubuntu-core-upgrade is failing in pi3, the loop that checks the “$(bootenv snap_mode)” != “” never finishes. The test fails because of kill-timeout and the value for bootenv snap_mode is “try”.
The error is reproduced with the branch 2.28.4
I am adding some logs that could help to understand why it is failing.
The logs are “interessting”. What I see is that the “snap_mode=try” is not updated which is peculiar because the uboot.env has the following line: snappy_boot=if test "${snap_mode}" = "try"; then setenv snap_mode "trying"; saveenv; if test "${snap_try_core}" != ""; then setenv snap_core "${snap_try_core}"; fi; if test "${snap_try_kernel}" != ""; then setenv snap_kernel "${snap_try_kernel}"; fi; elif test "${snap_mode}" = "trying"; then setenv snap_mode ""; saveenv; fi; run loadfiles; setenv mmcroot "/dev/disk/by-label/writable ${snappy_cmdline} snap_core=${snap_core} snap_kernel=${snap_kernel}"; run mmcargs; bootz ${loadaddr} ${initrd_addr}:${initrd_size} 0x02000000 (from https://paste.ubuntu.com/25728843/). This indicates somehow the reboot did not go through the normal uboot boot process. The output of /proc/cmdline would be great here, I suspect that the kernel commandline is also the same, i.e. that the new core was not booted and the current core is still used. This then makes snapd assume there is a revert accross the reboots (the message “cannot finish core installation, there was a rollback across reboot” happens when the name/revision of the core is the same).
… just for the record, I run the tests one more time (this time with my pi3 connected via eth cable instead of wifi, not sure if that’s relevant at all), this time all 5 runs passed.