| caribou | apw: smb: I'm thinking of changing my approach regarding the creation of symlinks to /boot/kdump/[initrd.img|vmlinuz] | 09:52 |
|---|---|---|
| caribou | I'm thinking of having /usr/sbin/kdump-config take care of the symlink management | 09:53 |
| 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:54 |
| 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:55 |
| 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:56 |
| 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:57 |
| 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:58 |
| 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. | 09:59 |
| 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:00 |
| 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 | 10:01 |
| 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:54 |
| gQuigs | (I actually did the reinstall because I accidentally removed the kernel - which I recovered, but then btrfs partition had other issues) | 14:55 |
| 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:57 |
| 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? | 14:58 |
| 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:02 |
| gQuigs | apw: I'll try to reproduce it and file a bug if I can | 15:19 |
| 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:20 |
| gQuigs | ok, will do | 15:26 |
| 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:41 |
| stgraber | jjohansen: what needs changing? | 15:42 |
| 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:47 |
| apw | stgraber, heh yeah there is that, erm, when i looked the profiles were very similar even T->W | 15:48 |
| 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 | 15:49 |
| === ming is now known as Guest10359 | ||
| 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:46 |
| apw | bah | 17:47 |
| 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:48 |
| 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:50 |
| stgraber | apw: arm64 and ppc64el always fail, only amd64 and i386 matter | 17:52 |
| 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:53 |
| 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:54 |
| 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:55 |
| 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:57 |
| apw | stgraber, it was meant to be to do with empty paths somewhere, removed things under other things, something like that | 17:58 |
| stgraber | hmm, ok, sounds like the description of most apparmor bugs ;) | 17:59 |
| apw | heh yeah there is that, sadly :) | 18:02 |
| 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:25 |
| stgraber | apw: still stuck | 18:27 |
| 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:46 |
| 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:49 |
| stgraber | oh, and that diff is pretty useless because it's not diffing the right thing... | 18:50 |
| gQuigs | infinity: attached the logs, but I still don't really understand why it was removed... | 19:08 |
| infinity | gQuigs: Well, it would have told you it was happening, assuming you used apt from the command line? | 19:11 |
| 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:12 |
| infinity | gQuigs: Lemme try this in a chroot with apt and see what it says. | 19:13 |
| 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:14 |
| 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:15 |
| infinity | Pretty sure d-i DTRT there, while ubiquity might not. | 19:16 |
| infinity | cyphermox: ^ | 19:16 |
| 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:17 |
| 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:18 |
| 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:19 |
| gQuigs | infinity: do you think a livecd test (on my hardware) would be useful? what extra logs/debug to take? | 19:21 |
| 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:22 |
| cyphermox | infinity: most things in ubiquity are just running d-i bits, were you talking specifically about the metas? | 19:27 |
| 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:29 |
| 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:31 |
| 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:33 |
| 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 | 19:34 |
| 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:41 |
| jjohansen | I just reinstalled and tested again, and it still works for me | 20:42 |
| stgraber | jjohansen: so I was told that wily's lxc is working properly, is that wrong? | 20:44 |
| jjohansen | stgraber: I think so but I didn't go in and verify last night | 20:45 |
| 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:46 |
| 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:47 |
| stgraber | jjohansen: ok, re-synced our apparmor in all upstream branches, will update the SRU now | 20:51 |
| jjohansen | stgraber: ack | 20:52 |
| === alai` is now known as alai | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!