automatic reboot fails with rc.local crash

[Federico Gimenez]

Steps to reproduce:

Create a rolling/edge image (amd64):

$ sudo ubuntu-device-flash core rollling --channel edge -o snappy.img --developer-mode

(tested it with version 113)

Launch

$ kvm -m 768 -redir :8022::22 ./snappy.img

Update

$ ssh -p 8022 ubuntu@localhost
$ sudo snappy update

Make rc.local in the other partition provoke a crash on boot:

$ sudo mount -o remount,rw /writable/cache/system
$ printf '#!bin/sh\nprintf c > /proc/sysrq-trigger\n' | sudo tee /writable/cache/system/etc/rc.local
$ sudo chmod a+w /writable/cache/system/etc/rc.local
$ sudo grub-editenv /boot/grub/grubenv set snappy_mode=try
$ sudo grub-editenv /boot/grub/grubenv set snappy_ab=b
$ sudo reboot

Reboot. The system enters a loop trying to boot from partition b. In 15.04 (version 124 and before) this works fine, the system detects the failure and reboots to the previous partition.

[Michael Vogt (mvo)]

Critical because it appears to be a regression

[Michael Vogt (mvo)]

I can confirm this, I see a bootloop in rolling. From the timestamps of the boot it appears that
- ubuntu-snappy.boot-ok.service is run at 14:12:40
- rc.local is run at 14:12:41 which indicates that
so we need to fix the order of the ubuntu-snappy.boot-ok.service

[Leo Arias (elopio)]

@Federico, mvo: I don't get this. So mvo's branch doesn't fix the problem and the test still fails?

[Federico Gimenez (fgimenez)]

Leo, it's working in generic_amd64 rolling/edge #168 and generic_armhf rolling/edge #164, with previous images it was still failing.

I'll propose a branch for reenabling the test, thanks!

[Michael Vogt (mvo)]

This should be fixed in 16.04 now - the integration tests for it also run now.