Snap_mode=try on raspberry-pi

cachio 2017-10-12 22:24:05 UTC #1

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.

test output: https://paste.ubuntu.com/25728858/
journalctl: https://paste.ubuntu.com/25728828/
dmesg: https://paste.ubuntu.com/25728831/
syslog: https://paste.ubuntu.com/25728838/
fw_printenv: https://paste.ubuntu.com/25728843/

mvo 2017-10-13 08:13:02 UTC #2

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).

zyga 2017-10-16 07:41:41 UTC #3

FWIW: I was trying to reproduce this issue last week without success. My pi3-1 was flashed with the edge image from http://cdimage.ubuntu.com/ubuntu-core/16/edge/current/ubuntu-core-16-armhf+raspi3.img.xz

My SD card details:

zyga@localhost:/sys/class/block/mmcblk0/device$ grep "" * 2>/dev/null 
cid:02544d534130384706249800bd00b6d3
csd:400e00325b5900003b4f7f800a40004b
date:06/2011
erase_size:512
fwrev:0x6
hwrev:0x0
manfid:0x000002
name:SA08G
oemid:0x544d
preferred_erase_size:4194304
scr:0235800001000000
serial:0x249800bd
type:SD
uevent:DRIVER=mmcblk
uevent:MMC_TYPE=SD
uevent:MMC_NAME=SA08G
uevent:MODALIAS=mmc:block

I ran the following test:

SPREAD_EXTERNAL_ADDRESS=192.168.3.3:22 spread -v -debug -reuse -repeat 5  external:ubuntu-core-16-arm-32:tests/main/ubuntu-core-upgrade

pstolowski 2017-10-16 09:12:07 UTC #4

I tested this too (with custom-built pi3 beta image). Got slightly different error:

http://pastebin.ubuntu.com/25751741/

Versions of the snaps:

external:ubuntu-core-16-arm-32 .../tests/main/ubuntu-core-upgrade# snap list
Name        Version        Rev   Developer  Notes
core        16-2.28.5      3214  canonical  core
pi2-kernel  4.4.0.1075.75  43    canonical  kernel
pi3         16.04-0.5      6     canonical  gadget

pstolowski 2017-10-16 10:52:45 UTC #5

I re-tested from scratch (after re-flashing), the test passed twice and failed on 3rd attempt with same symptoms:
http://pastebin.ubuntu.com/25752176/

pstolowski 2017-10-16 15:45:38 UTC #6

… 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.