[14:24] <bladernr-malta> anyone know who owns libxslt?  I need someone to take a look at https://bugs.launchpad.net/ubuntu/+source/libxslt/+bug/1449626
[14:45] <dandruczyk_work> Anyone else get hit with 14.04LTS 3.13.0-51.84 kernel panic'ing on boot ???  all of my environments got killed by this today and i have to rollback to .49
[14:46] <dandruczyk_work> http://imgur.com/y1531Bl
[14:47] <penguin42> hmm that's not fun
[14:47] <dandruczyk_work> seems tied to any process that uses unix domain sockets (in this case php5-fpm was starting up which uses them)
[14:48] <penguin42> I've not got a 14.04LTS to hand
[14:48] <dandruczyk_work> env runs on VMware ESXi 5.5, evey node panic'd (over 12) shortly after boot,  the SQL servers made it slightly longer before they hit the same failure
[14:49] <penguin42> lets see, 14.04 is trusty isn't it, I've got a VM I've not booted in a while
[14:50]  * penguin42 updates it
[14:51] <penguin42> dandruczyk_work: Bug report it anyway and then lets see if anyone else hits it
[14:51] <dandruczyk_work> working on it,  the link is not easy to find
[14:52] <penguin42> dandruczyk_work: Just run ubuntu-bug linux    from any ubuntu terminal on a 14.04 box
[14:52] <dandruczyk_work> the main issue is since this is on vmware esxi I cannot capture the top part of the OOPS
[14:53] <penguin42> yeh, that's life - if you can get a serial console output you might be able to, if you're really lucky it'll be in some logs on disk
[14:54] <dandruczyk_work> the trouble with "ubuntu-bug linux" is that it'll be on the WORKING kernel,  not the failed one. , I'll have to patch something together, otherwise it'll generate a bogus report against the wrong kernel release
[14:54] <penguin42> no, it's ok
[14:54] <penguin42> it's OK to run the report using the working one and attach the screenshot
[14:55] <penguin42> I'd boot to the failing one, then reboot to the working one, if you're lucky there maybe some boot logs from the failed boot
[14:55] <dandruczyk_work> k
[14:56] <penguin42> I mean sure it would be best to report it on the failing kernel, but hey that's ok when stuff is that broken
[14:56] <dandruczyk_work> yeah it never gets past the crash to a prompt to do anything, so i have to do it from a working one
[14:58]  * penguin42 has to go out in a few minutes, but please post the bug number you get here, and also add it as a comment to https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1444141 
[14:59] <penguin42> If I had to guess I'd bet it's the fix that went in for bug 1439441 that's audit related
[15:04] <dandruczyk_work> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1450504
[15:08] <penguin42> I've marked it as 'critical'
[15:08] <dandruczyk_work> thanks
[15:10] <penguin42> did you add a comment to that other bug?
[15:11] <dandruczyk_work> i have not, should I
[15:12] <penguin42> I will
[15:13] <penguin42> added
[15:13] <dandruczyk_work> i just did,  sorry if i stepped on you
[15:13] <dandruczyk_work> parallel paths..
[15:13] <penguin42> hehe oh well
[15:13]  * penguin42 waits for his VM to finish upgrading
[15:22] <penguin42> dandruczyk_work: 51.84 booted into a desktop fine here in a kvm quest
[15:22] <dandruczyk_work> is audit enabled and do you have apache installed and enabled?
[15:22] <penguin42> hmm, it'll be a default trusty install, so probably not - what's the quick way to enable audit?
[15:24] <dandruczyk_work> service auditd start?
[15:24] <penguin42> ok, just give me a sec
[15:24] <dandruczyk_work> though you may need to configure the rules.
[15:25] <dandruczyk_work> in my case I saw the crash when apache tried to start,  but my apache config isn't anything close to "stock",
[15:25] <dandruczyk_work> I suspected the issue was either with audit or unix domain sockets..,  let me turn off audit on my test vm nad see how it explodes..
[15:26] <penguin42> yeh, I've got auditd running and apache installed now
[15:27] <penguin42> ok, so not immediately triggering - anyway, got to go out, add stuff to the bug if you figure more out
[15:28] <dandruczyk_work> k,  my setup uses php5-fpm using unix domain sockets and apache configured to use fastcgi passthrough over those sockets...
[15:28] <dandruczyk_work> a somewhat unconventional setup, but works well.
[15:29] <dandruczyk_work> with audit disabled it managed to boot and startup OK
[15:45] <dandruczyk_work> my audit rules trigger it.  unable to handle kernel NULL pointer dereference at (null)   in strlen+0x0/0x30
[15:45] <dandruczyk_work> details at the end of:  https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1444141