running "snap refresh core" on an UbuntuCore device locks you out until reboot

[Oliver Grawert]

if you run "snap refresh core" on a current UbuntuCore install you never get access to the prompt back until the system rebooted into the new core.

there is a "[/] Setup snap "core" (1829) security profiles (phase 2)" message owning the console until the reboot kicks in. at the same time the shceduled reboot locks down ssh access (any ssh attampt is only answered with: "System is going down.")

the snap refresh command used to give you console access back before so you could issue "sudo shutdown -c" if you did not want a reboot yet. this is not possible anymore with the current behaviour.

if it is desired behaviour to not allow the user to intercept the reboot (which i dont belive it is) then

"reboot scheduled to update the system - temporarily cancel with 'sudo shutdown -c'"

should be changed to not indicate you can still interact with the system ...
if it is not desired behaviour the bug should be fixed :)

at http://paste.ubuntu.com/24498125/ is a log of the behaviour, neither ctrl-c nor any other attempt to get a prompt back to issue "sudo shutdown -c" has been fruitful here.

[Oliver Grawert (ogra)]

doing another test, i just noticed, hitting ctrl-c wildly eventually gets me the console back, so it seems to only randomly accept it ...

(before it actually simply finished the "security profiles (phase 2)" task on its own though, without the need to ctrl-c at all)

[Paul Larson (pwlars)]

I'm noticing that on some rare occasions, we see devices finish the core update and not hang until reboot, but I don't think anything intentional has been done to fix this yet, right?

[Tony Espy (awe)]

A couple of recent comments about this as I've been discussing this behavior with customers.

First, when I perform manual refreshes and the 10m reboot countdown starts, I always ssh into the device in a new session and issue a 'sudo reboot now'.

In my recent conversation about this, the customer in question didn't use a new ssh session, but instead used ctrl-c, not realizing that this cancels the refresh of the core or kernel snap which triggered the reboot. The customer then immediately rebooted the system, and was complaining that the system wasn't responding when they tried to ssh back into the system. This was probably due to the fact that when the system came back up, it automatically refreshes again and applies the updates that had previously been canceled, effectively triggering yet another reboot.