[09:52] <caribou> apw: smb: I'm thinking of changing my approach regarding the creation of symlinks to /boot/kdump/[initrd.img|vmlinuz]
[09:53] <caribou> I'm thinking of having /usr/sbin/kdump-config take care of the symlink management
[09:54] <caribou> since I have no way to know which is the proper initrd to use upon install/removal of kernel packages
[09:54] <apw> caribou, "make links point to the running kernels vmlinuz and corresponding smaller initrd" at load time ?
[09:54] <caribou> apw: yes
[09:55] <apw> caribou, not a bad idea _if_ you are sure you can write to the fs at the itme it happens
[09:55] <caribou> apw: because, if the kernel hook make the symlink, adding a newer kernel package will make the symlink to files that have not been booted yet
[09:56] <caribou> apw: yes, I think that root is mounted rw when kdump-config loads the kexec command; I'll check
[09:56] <apw> caribou, i'd expect it to be late enough indeed, but worth checking
[09:57] <smb> hm... or is that link required at all? if you can figure out what the link should be at boot time...
[09:57] <caribou> apw: and it makes the kernel hook simpler as it doesn't have to worry about the kdump-config specifics
[09:57] <apw> caribou, yeah
[09:57] <apw> smb, yes because it is baked into a config file the user may change
[09:57] <caribou> smb: yes, kdump-config relies on it to issue the kexec command
[09:58] <apw> smb, so they can make it a specific older kernel, or leave it be and they get the matching kernel
[09:58] <caribou> if the symlink doesn't point to an existing file, the kexec load command will fail
[09:58] <apw> and caribou that is a much saner semantic
[09:58] <apw> "kdump kernle will match your runnign kernel" always, not the latest one you installed but maybe not the one you booted
[09:59] <caribou> apw: then I can make kdump-config list available kernels & choose one specific to link as an option
[09:59] <apw> caribou, yep, all much nicer
[09:59] <caribou> apw: ok, I'll work on this.
[10:00] <apw> and right now they can just edit the config to make it point at a specific one
[10:00] <apw> right ?
[10:00] <caribou> apw: it will not make 15.10, doubtful on it being SRUed so we may have to increase crashkernel= for a while
[10:00] <apw> caribou, its presumably not huge huge ?   and it fixed a real bug ... so we might get it through
[10:01] <caribou> apw: right now, it default to the booted kernel and doesn't even use the variable in the config file
[10:01] <caribou> apw: maybe, we'll see
[10:01] <caribou> I should have it working by EOD
[10:01] <apw> caribou, nice thanks
[14:54] <gQuigs> I just did a fresh install of Wily and linux-headers-generic linux-image-generic thermald are showing up to be autoremoved
[14:54] <gQuigs> has the packaging changed to make that make sense?
[14:55] <gQuigs> (I actually did the reinstall because I accidentally removed the kernel - which I recovered, but then btrfs partition had other issues)
[14:57] <apw> gQuigs, no that is not correct, as withouth the first two you would not get updates, the third would be held on by the second iirc, somewhere linux-generic has gone missing, and it should not
[14:58] <apw> gQuigs, iirc if you file a bug against ubiquity it will upload the install logs which might help
[14:58] <apw> infinity, ^ is it ubiquity?
[15:02] <apw> stgraber, yo, so jjohansen has looked at that lxc test suite hang, and it seems the profile needs to be updated in T to something newer
[15:19] <gQuigs> apw: I'll try to reproduce it and file a bug if I can
[15:20] <apw> gQuigs, i suspect it doesn't happen all the time, else we'd hear about it a lot, if you still ahve the instance which failed, then the logs for the original install are kept for bug reporting
[15:26] <gQuigs> ok, will do
[15:41] <stgraber> apw: and how is that not a regression? :)
[15:41] <apw> stgraber, it is a regression, but the change in the kernel is for a cve
[15:41] <stgraber> ok
[15:42] <stgraber> jjohansen: what needs changing?
[15:47] <apw> stgraber, there is a new check int he profile, one which must have been added in later releases, as V is ok with this kernel change
[15:47] <stgraber> apw: would be helpful to know what exactly so we can SRU it ASAP
[15:48] <apw> stgraber, heh yeah there is that, erm, when i looked the profiles were very similar even T->W 
[15:49] <stgraber> lets see if I can diff those quickly then
[15:49] <apw> stgraber, its something mount related, hrm, and jj did check that the old kernel will not implode with the update, whatever it was
=== ming is now known as Guest10359
[17:46] <stgraber> apw: so far looks like it's stuck at the same spot, it's a pretty long test so maybe it's just not done yet, but doesn't look too good so far
[17:47] <apw> bah
[17:48] <apw> stgraber, so much for that fixing it, though i am sure jjohansen tested the same, we need to find out what needs putting in specifically to make sure its in the one you updated to
[17:50] <apw> stgraber, that said the ppc64el is just finishing so they wern't submitted that long ago, how long odes that whole suite take on i386 anyhow ?
[17:52] <stgraber> apw: arm64 and ppc64el always fail, only amd64 and i386 matter
[17:53] <apw> stgraber, right, i only entioned it because it is runiing, and it would have been submitted at the same time as the ones we care about, bounding how long ago it was run
[17:53] <stgraber> apw: yeah, I'm watching the live adt console here
[17:54] <stgraber> and amd64 and i386 got past test-symlink which means they're currently in test-ubuntu and have been for 20+ min from what I saw
[17:54] <apw> stgraber, right, same, i just don't know how long a good run takes
[17:54] <apw> 15m it seems, looking back 3 or 4
[17:55] <apw> if it is still at the same place in 15m then we need to fnid out from jjohansen what he had to add
[17:55] <apw> to confirm that was what we tried
[17:57] <stgraber> I still have a hard time understanding why the change I did would help. I mean all the other tests which also do start containers are passing fine...
[17:58] <apw> stgraber, it was meant to be to do with empty paths somewhere, removed things under other things, something like that
[17:59] <stgraber> hmm, ok, sounds like the description of most apparmor bugs ;)
[18:02] <apw> heh yeah there is that, sadly :)
[18:25] <gQuigs> apw: reported here - https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1506169  looks like linux-generic was installed, but removed by one of my first changes after install
[18:25] <ubot5`> Ubuntu bug 1506169 in ubiquity (Ubuntu) "fresh install - linux-headers-generic linux-image-generic python-notify thermald can be auto removed" [Undecided,New]
[18:27] <stgraber> apw: still stuck
[18:46] <infinity> gQuigs: Do you have the apt log(s) from that system too?
[18:46] <infinity> gQuigs: Certainly not an installer bug if something you install after the fact is removing linux-generic, but would still be good to hunt it down.
[18:49] <stgraber> jjohansen: when you're around. http://launchpadlibrarian.net/221223666/lxc_1.0.7-0ubuntu0.3_1.0.7-0ubuntu0.8.diff.gz isn't enough to fix the current hang in lxc-test-ubuntu, what else do we need?
[18:50] <stgraber> oh, and that diff is pretty useless because it's not diffing the right thing...
[19:08] <gQuigs> infinity: attached the logs, but I still don't really understand why it was removed...
[19:11] <infinity> gQuigs: Well, it would have told you it was happening, assuming you used apt from the command line?
[19:12] <infinity> gQuigs: It pays to actually read the "The following packages will be removed" stanza before saying yes.
[19:12] <gQuigs> infinity: :) indeed, except I was using the graphical drivers widget to install the nvidia driver
[19:12] <infinity> gQuigs: Oh, aptdaemon, not apt, so it happened behind the scenes with ubuntu-drivers-common.
[19:13] <infinity> gQuigs: Lemme try this in a chroot with apt and see what it says.
[19:14] <infinity> gQuigs: Your URL to the PPA is a 404.  Which PPA was it really? :)
[19:14] <gQuigs> infinity: - https://launchpad.net/~graphics-drivers/+archive/ubuntu/ppa
[19:15] <infinity> To be fair, there's also a minor installer bug here that we should be marking the second-level metas as manual too, I think.
[19:15] <infinity> So if someone decides to, say, remove headers, they don't lose their kernel.
[19:16] <infinity> Pretty sure d-i DTRT there, while ubiquity might not.
[19:16] <infinity> cyphermox: ^
[19:17] <infinity> Actually, this bug might be mine in the livefs creation.
[19:17] <infinity> I'll look in a second.
[19:17] <infinity> But none of that excuses a package bumping off linux-generic. :P
[19:18] <gQuigs> infinity: hmm, I did a vm test and just apt-get installing the packages doesn't mark it for removal
[19:18] <gQuigs> it= linux-generic
[19:19] <infinity> gQuigs: Indeed.  Doesn't here either.  Might have to mock an nvidia card being installed somewhere here, so I can reproduce the ubuntu-driver-common behaviour. :/
[19:21] <gQuigs> infinity: do you think a livecd test (on my hardware) would be useful?  what extra logs/debug to take?
[19:22] <infinity> gQuigs: I'd kinda want to drive, just to experiment.
[19:22] <infinity> gQuigs: Booting to a live session, installing SSH, and giving me access to abuse might be helpful. :P
[19:27] <cyphermox> infinity: most things in ubiquity are just running d-i bits, were you talking specifically about the metas?
[19:29] <gQuigs> infinity: hmm :P - but yea, I guess I might as well confirm that it's reproducible on just the livecd 
[19:29] <infinity> cyphermox: Yeah, the kernel/meta bits aren't d-i driven, IIRC.  But it's also mostly there in the livefs before ubiquity even touches it, so it might be my bug. :P
[19:29] <gQuigs> infinity: what would be the first thing you would look at/
[19:31] <infinity> gQuigs: I'd run 'ubuntu-drivers list' from the CLI after adding the PPA, check what it thinks it wants to do, try that in both apt and filtered through aptdaemon, experiment, I dunno.  No exact science here when debugging other people's software. :P
[19:33] <gQuigs> will give that a try in a bit
[19:33] <cyphermox> I'm supposed to have an nvidia card here somewhere, but I can't find it
[19:33] <infinity> cyphermox: Really?  The one I have here is larger that most computers, it's hard to miss.
[19:34] <infinity> But it's also in a machine I don't feel the overwhelming urge to reboot right this second.
[19:34] <cyphermox> well, I wouldn't have a machine to put it in anyway
[20:41] <jjohansen> stgraber: I added the rule
[20:41] <jjohansen>    mount options=(rw,bind) /dev/pts/ptmx -> /dev/ptmx,
[20:41] <jjohansen> to the lxc-start profile, that debdiff is NOT sufficient because it doesn't have a rule that matches
[20:42] <jjohansen> I just reinstalled and tested again, and it still works for me
[20:44] <stgraber> jjohansen: so I was told that wily's lxc is working properly, is that wrong?
[20:45] <jjohansen> stgraber: I think so but I didn't go in and verify last night
[20:46] <jjohansen> stgraber: now it is possible, there is another bug, something fixed in wily and not trusty that is also affecting this too. I haven't compared yet
[20:46] <stgraber> jjohansen: ok, so current diff from what I uploaded to trusty to current git master is:    mount options=bind /dev/pts/ptmx/ -> /dev/ptmx/,
[20:46] <stgraber> oops
[20:47] <stgraber> http://paste.ubuntu.com/12784047/
[20:47] <jjohansen> ah, yeah that diff should do it
[20:47] <stgraber> ok, so I need to cherry-pick that part into our stable branch too, then re-sru it...
[20:51] <stgraber> jjohansen: ok, re-synced our apparmor in all upstream branches, will update the SRU now
[20:52] <jjohansen> stgraber: ack
=== alai` is now known as alai