=== doko_ is now known as doko | ||
cjwatson | popey: Looks like those packages you were asking about were auto-synced last night. | 08:03 |
---|---|---|
popey | super, thanks cjwatson | 08:08 |
jibel | Could someone approve update-manager 1:0.156.14.15 in precise-proposed? | 09:00 |
shadeslayer | hmmm, how's the libav transition going? | 10:39 |
jibel | cjwatson, ^ would you have time to review/approve update-manager in precise today? we need it for testing hwe eol notifications. | 10:41 |
cjwatson | jibel: doing | 11:21 |
jibel | cjwatson, thank you | 11:48 |
ChrisTownsend | cjwatson: Hi! You are the SRU vanguard today, correct? | 13:02 |
ChrisTownsend | cjwatson: If you saw my previous ping, no need to respond. | 13:36 |
cjwatson | http://people.canonical.com/~ubuntu-archive/component-mismatches.html new toy | 14:25 |
cjwatson | (also priority, architecture) | 14:25 |
cjwatson | also the next build of http://people.canonical.com/~ubuntu-archive/nbs.html should have a graph | 14:26 |
cjwatson | if anyone knows how to make YUI's numeric axes work more sensibly, let me know | 14:28 |
utlemming | infintiy, cjwatson: are either of you around? | 22:27 |
utlemming | infinity, cjwatson: due to bug #1336855 and the recent Grub SRU for 12.04 anyone running an HVM instance on AWS will lose their instance on reboot. | 22:28 |
ubot93 | bug 1336855 in cloud-init (Ubuntu) "[SRU] non-interactive grub updates for 12.04 break on AWS" [Critical,Confirmed] https://launchpad.net/bugs/1336855 | 22:28 |
infinity | utlemming: fun. | 22:45 |
utlemming | infinity: yup...and if there is a grub update for 14.04, they'll get burned too | 22:46 |
utlemming | infinity: do you have any guidance how to dig out of this hole? | 22:46 |
utlemming | infinity: I am leary to put the logic into cloud-init since cloud-init doesn't have a grub dependency | 22:47 |
infinity | utlemming: Erm, but the bug is in cloud-init? | 22:52 |
utlemming | infinity: right. So what happens is one first boot cloud-init sets a debconf selection for grub-pc "install_devices". Since it doesn't know to look at /dev/xvda and /dev/xvda, grub tries to install to /dev/sda (which is what the images originally had). | 22:53 |
infinity | utlemming: Isn't it as simple as making that 1-line change to cc_grub_dpkg.py? | 22:53 |
utlemming | infinity: nope. Because that module only runs once. | 22:54 |
utlemming | infinity: and then there is the race condition of a user who updates grub and then cloud-init | 22:54 |
infinity | utlemming: Then the bug log seems to lie. | 22:54 |
utlemming | infinity: adding a better, clarifying comment | 22:55 |
utlemming | infinity: clarified the bug | 23:01 |
infinity | utlemming: I'm confused how you got in this state in the first place. Wouldn't have the first run of cloud-init created a broken grub config straight up and this has been wrong since day 1? | 23:03 |
utlemming | infinity: the cloud image build process installs grub by hand, since we can't build the images in AWS. | 23:04 |
infinity | utlemming: That doesn't really answer my question. :) | 23:04 |
infinity | utlemming: Any kernel or grub upgrade would have broken this, so what introduced the bug, and how long has it been broken? | 23:05 |
utlemming | infinity: that part I am unsure of. But AWS just reported it. It has been broken since day one. Not having looked, I would guess that grub changed something such that the bits installed on disk don't work with the stuff in /boot/grub. | 23:06 |
infinity | utlemming: So, if we really wanted to make this smooth, we could SRU cloud-init with the 1-line fix, and have it conditionally re-run 'cloud-init-cfg grub-dpkg' in its postinst on upgrade from known-broken versions, *and* re-upload a grub SRU with Breaks: cloud-init (<< new_version), forcing cloud-init to upgrade before grub. | 23:10 |
infinity | utlemming: I'm not sure having this leak into the grub packaging is really worth the hassle, but if you always want upgrades to work, I'm not sure there's a cleaner way. | 23:11 |
utlemming | infinity: I _did_ start to go down that path, but had an issue with the fact that 'cloud-init-cfg grub-dpkg' runs debconf-set-selection, which runs into a debconf lock | 23:11 |
infinity | utlemming: Oh, I guess you could re-run grub-install on cloud-init postinst in the same condition that you run cloud-init-cfg grub-dpkg | 23:12 |
infinity | utlemming: There should only be a lock if you're running it in a part of your postinst that happens to be debconfy? | 23:12 |
utlemming | infinity: the cloud-init postinst is debconf'd, yes | 23:13 |
infinity | utlemming: Sure, but not the WHOLE postinst. :) | 23:13 |
infinity | utlemming: If nothing else, there's some convenient imaginary whitespace before or after the bits that are. | 23:13 |
utlemming | infinity: lol, okay, I'll look at doing that | 23:13 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!