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