t.go
<elopio> to work around the workaround I will just have to increase the maxWaitRetries.
<Chipaca> elopio: and you're waiting for bootok?
<elopio> Chipaca: I'm waiting for snappy_mode=regular
<Chipaca> elopio: and is that better, or worse than waiting for boot ok?
 * sergiusens wonders if it is beer o clock already
<Chipaca> sergiusens: it is!
<elopio> Chipaca: better, I think. Instead of checking the service, we check it's effect.
<Chipaca> sergiusens: you should come visit. can't have beer on my own (and ellie doesn't do beers)
<elopio> *its
<elopio> it's beer-on-hangout o'clock.
<Chipaca> elopio: so, yeah, looks like you're already doing the right thing and all :)
<Chipaca> elopio: wrt increasing maxWaitRetries, maybe instead have an arch-dependent base?
<Chipaca> elopio: ie scale checkInterval by some bogomips factor
<elopio> Chipaca: that would be nice.
<Chipaca> var bogomips = map[string]int{"arm": 100, "amd64": 1, etc}
<Chipaca> and index it on GOARCH
<elopio> I'll make a card to be able to configure the wait, with a delay factor.
<elopio> but anyway, this is a bug :) Instead of working it around, somebody should fix it.
 * elopio looks at somebody.
<Chipaca> elopio: which is the bug, exactly?
<Chipaca> elopio: that you can ssh in before you can log in?
<elopio> Chipaca: you can sign in before boot-ok. both ssh and normal log in through serial. And if you are fast with a rollback, that makes the boot crazy.
<elopio> https://bugs.launchpad.net/snappy/+bug/1498293
<ubottu> Launchpad bug 1498293 in Snappy "after a successful update and reboot, the bootloader snappy_mode is set to 'try'" [Critical,Triaged]
<elopio> on bbb you don't have to be super fast. I actually can reproduce this manually.
<Chipaca> elopio: so that's the bug
<Chipaca> elopio: not that "try" thing :)
<Chipaca> so, we want the boot-ok to be done *before* ssh and getty lets people in
<Chipaca> pitti: do you remember offhand whether there's a target that would let us do that easily?
<elopio> Chipaca: I think so. You could fix the rollback 