[11:39] <apw> stgraber, https://bugs.launchpad.net/ubuntu/+source/lxc/+bug/1517426 ... seems lxc is failing its autotests for what looks like a bad dep
[11:52] <caribou> can someone ping my nick again, please ?
[11:58] <apw> caribou, ?
[12:01] <caribou> apw: thanks!
[14:33] <gpiccoli> Hello, I don't know if this is the right place for asking help on this, but I'm having trouble in saving logs of kernel crashes on Ubuntu 14.04.3. Sorry to bother with this
[14:33] <gpiccoli> I have the linux-crashdump and the following parameter on my cmdline: "crashkernel=384M-2G:64M,2G-:128M"
[14:34] <gpiccoli> Even so, nothing shows up on /var/crash after a crash (I'm using sysrq for testing)
[14:34] <gpiccoli> Any clue?
[14:37] <apw> gpiccoli, is crash dumping enabled, i don't think it is by default when the package is installed
[14:37] <apw> caribou, ^
[14:38] <gpiccoli> apw, I followed some procedures of wiki page - I notice the following line on my dmesg: "Reserving 128MB of memory at 128MB for crashkernel (System RAM: 4096MB)"
[14:38] <caribou> apw: yes, it needs to be enabled in /etc/default/kdump-tools :
[14:38] <caribou> gpiccoli: ^
[14:38] <gpiccoli> wow, nice! thanks caribou and apw !
[14:38] <caribou> gpiccoli: USE_KDUMP=1 and then sudo kdump-config load (assuming that you have rebooted & crashkernel= is present)
[14:38] <apw> gpiccoli, do fix the wiki if it isn't correctly indicated in there
[14:38] <gpiccoli> Should I document this on wiki? OR is it already there, and I missed?
[14:39] <apw> gpiccoli, that you missed it implies it is not well enough presented even if it is there
[14:39] <caribou> gpiccoli: let me check. Which wiki are you looking at ?
[14:39] <gpiccoli> this one caribou: https://help.ubuntu.com/lts/serverguide/kernel-crash-dump.html
[14:40] <gpiccoli> apw, good point hehehe
[14:40] <caribou> gpiccoli: apw: it is under "Configuratino"
[14:40] <caribou> well "Configuration"
[14:40] <gpiccoli> wow, sorry caribou and apw
[14:40] <caribou> but I keep being asked to have it enabled by default
[14:41] <gpiccoli> My bad =//
[14:41] <caribou> gpiccoli: no worry
[14:41] <gpiccoli> caribou, what is the con in having this enabled by default?
[14:41] <apw> yeah np, documentation is lik that
[14:41] <caribou> apw: we talked about it in Austin, remember
[14:41] <caribou> gpiccoli: nothing really, it is mostly historical
[14:41] <apw> caribou, indeed, it does seem odd to install something which has no other purpose and not enable it by default
[14:41] <caribou> apw: agree
[14:42] <apw> if it needs configuration before enabling it makes sense, yes fine
[14:42] <gpiccoli> Is there a way to enable this flag automatically on linux-crashdump install ?
[14:42] <gpiccoli> Would be nifty
[14:42] <apw> gpiccoli, could be done, but it is i a change, and so needs discussing publically first
[14:42] <apw> in case there is a compelling reason not to that we are not htought of
[14:42] <caribou> apw: I just had a chat with bwh in #debian-kernel and he's fine with having the small initrd fix in Debian as well
[14:43] <gpiccoli> sure apw, I agree! I think it makes sense...for airheads like me heh
[14:43] <apw> caribou, nice, i thnk i  saw you chatting
[14:43] <caribou> apw: so I'm thinking of pairing this change with defaulting to Yes
[14:43] <apw> gpiccoli, for the casual user you want it to work as best it can without config, even if power users will want to change things
[14:43] <caribou> apw: with the option of setting it to False if needed
[14:43] <gpiccoli> Great caribou and apw!!! 
[14:44] <apw> caribou, might be woth sending out some kind of rfc on that if you havent, to ubuntu-devel or something
[14:44] <caribou> then I'll push both changes to Debian/Sid so it syncs to Xenial
[14:44] <apw> something more focused if there is one
[14:44] <caribou> apw: ubuntu-devel & ubuntu-kernel maybe ?
[14:44] <apw> works for me
[14:44] <caribou> k
[14:44] <apw> i can't see you getting any responses at all :)
[14:45] <caribou> apw: that's what happened with my post to debian-kernel :-)
[14:46] <apw> caribou, :)
[14:47] <caribou> apw: the kernel ML is kernel-team@lists.launchpad.net, right ?
[14:49] <apw> caribou, ack
[14:53] <apw> caribou, approved your post
[15:17] <gpiccoli> apw, caribou: I'm still with no luck
[15:17] <caribou> gpiccoli: let me run a  quick test
[15:17] <gpiccoli> Even with those modifications, only a file named kexec_cmd is created
[15:17] <gpiccoli> I'm on PPC64 kvm _guest_
[15:17] <caribou> oh, ppc64
[15:18] <gpiccoli> What I need is only the log, I don't even need the vmcore
[15:18] <caribou> gpiccoli: any chance I can access it remotely ?
[15:19] <gpiccoli> Unfortunately no caribou, I'm very sorry
[15:19] <gpiccoli> It's private network only
[15:19] <caribou> gpiccoli: np
[15:19] <gpiccoli> I can perform any test you want although
[15:19] <gpiccoli> Note: I already could generate those dumps in the past days
[15:19] <gpiccoli> Reinstalled the system and now, it does not work
[15:20] <apw> gpiccoli, big or little endian (powerpc or ppc64el debian arch)
[15:21] <gpiccoli> ppc64el
[15:21] <gpiccoli> apw ^
[15:22] <caribou> gpiccoli: would you be able to capture the console output during one of your test ?
[15:22] <gpiccoli> ok, 
[15:22] <gpiccoli> what dfo you need to see?
[15:22] <gpiccoli> *do
[15:22] <caribou> gpiccoli: well, the portion between the kernel panic & the reboot
[15:23] <gpiccoli> ok, I can put here, but we have not too much output there
[15:23] <apw> gpiccoli, i would pastebinit, rather than putting it in ir
[15:23] <apw> irc
[15:24] <gpiccoli> good idea apw! I'll paste some more info too =)
[15:30] <gpiccoli> apw, caribou: http://pastebin.ca/3259739
[15:30] <gpiccoli> Do you need after QEMU boot logs?
[15:30] <gpiccoli> I sttoped on QEMU first line, can past the rest here if you want
[15:31] <gpiccoli> I should check my loglevel too...
[15:32] <caribou> gpiccoli: well, there's nothing after the sysrq-trigger, you should have the panic backtrace, etc
[15:33] <gpiccoli> There you go!
[15:33] <gpiccoli> What do you think that can be happening?
[15:34] <gpiccoli> It's like if crashes are not being even dumpeed
[15:34] <gpiccoli> *dumped
[15:34] <caribou> gpiccoli: ? same pastebin ?
[15:35] <apw> caribou, well you see it starting to do osmething, as it emits what looks like half of the first line of a kernel boot ?
[15:35] <gpiccoli> caribou, I'm sorry - I didn't understand your question marks hehe
[15:35] <caribou> apw: it should start by displaying the panic() msg
[15:36] <apw> caribou, he is saying that is all he gets, "there you go you are seeing what i see" not "there you go some more information"
[15:36] <caribou> gpiccoli: I thought you had pasted more information somewhere else
[15:36] <apw> english, sooooo unambigious
[15:36] <gpiccoli> yes apw, thanks!!!
[15:36] <gpiccoli> your got right my expression. Sorry caribou
[15:36] <caribou> gpiccoli: can you paste the result of "sudo kdump-config show" pls ?
[15:36] <gpiccoli> I'm not so good in english, so it can be entirely my bad - sorry
[15:37] <gpiccoli> sure!
[15:37] <caribou> gpiccoli: no worry:)
[15:37] <apw> the SLOF line is the indicator that we are booting a new right, after the crash would have been completed if it had occured
[15:38] <gpiccoli> caribou, apw: http://pastebin.ca/3259751
[15:42] <caribou> gpiccoli: what's the result of cat /sys/kernel/fadump_enabled ?
[15:42] <caribou> long shot
[15:43] <gpiccoli> caribou:
[15:43] <gpiccoli> root@ubuntu:~# cat /sys/kernel/fadump_enabled
[15:43] <gpiccoli> cat: /sys/kernel/fadump_enabled: No such file or directory
[15:43] <gpiccoli> =0
[15:43] <caribou> gpiccoli: ok, just wanted to check, this is a PPC specific dump mode
[15:44] <gpiccoli> ok, great!
[15:44] <gpiccoli> BTW, thanks verym uch for your help
[15:46] <apw> slangasek, i think it was you who asked why our testing depended on exim4.  I think i have just found out (well cking did), it seems the aslr test in QRT uses starting/stopping exim as part of its payload
[15:47] <cking> namely because of bug https://bugs.launchpad.net/bugs/504164
[15:49] <caribou> gpiccoli: I'm going to fetch a PPC64 iso & try to test it locally. May take a little while 
[15:50] <gpiccoli> Thanks very very much caribou, I'm really appreciate your help =)
[15:50] <gpiccoli> I'll turn my guest off [some more people need the machine]
[15:51] <caribou> gpiccoli: well, I maintain that code so I would highly prefer to see it work ;-)
[15:52] <gpiccoli> hehehe =)
[15:52] <gpiccoli> Great to hear! 
[15:53] <gpiccoli> Your are a very nice maintainer, it's good to see such interest and effort
[15:53] <gpiccoli> Not all maintainers are as you, we all know heh
[15:58] <caribou> gpiccoli: Is using PPC64 as the VM architecture correct ?
[15:59] <gpiccoli> Hmmm..I don't know
[15:59] <gpiccoli> What are the possibilities?
[15:59] <gpiccoli> caribou ^
[15:59] <gpiccoli> I can check my VM here
[16:00] <caribou> gpiccoli: If I select ppc64le, it asks me for an existing image
[16:00] <gpiccoli> in libvirt sml we have:     <type arch='ppc64' machine='pseries-2.4'>hvm</type>
[16:00] <gpiccoli> *xml
[16:09] <caribou> gpiccoli: I'm getting near end of day. Can you email me the .xml description of your VM ?
[16:11] <slangasek> apw: ah, heh.  exim still seems a strange choice of mta then :)
[16:11] <apw> slangasek, its not as an mta, it is because that specific binary was a reproducer
[16:12] <slangasek> ahhh ok
[16:13] <gpiccoli> Sure caribou, thanks!!
[16:13] <gpiccoli> PM me your email
[17:28] <jderose> When is 4.2.0-19.23 expected to land in Wily updates?
[17:31] <apw> jderose, iirc we are about 2 weeks out
[17:33] <apw> jderose, assuming not kitten killers it is slated to release by the 28th
[17:34] <jderose> apw: much thanks! i wasn't sure whether I was reading the kernel newsletter correctly or not :)
[17:34] <apw> jderose, yep, the dates are intentionally vague to let things move around for emergencies and regressions
[19:56] <cristian_c> jsalisbury: hello