[00:18] <phil__> Does anybody here know anything about pam_tally2.so, pam_tally2, and tallylog?
[01:27] <phil__> Does anybody here know anything about pam_tally2.so, pam_tally2, and tallylog?
[01:48] <tsimonq2> !patience | phil__ 
[01:48] <ubot5> phil__: Don't feel ignored and repeat your question quickly; if nobody knows your answer, nobody will answer you. While you wait, try searching https://help.ubuntu.com or http://ubuntuforums.org or http://askubuntu.com/
[01:53] <phil__> Apologies. I feel I've done a fairly extensive search (even of those forums) and I am simply not finding much. I'll remain patient.
=== rharper` is now known as rharper
=== swordsma- is now known as swordsmanz
[03:39] <hallyn> Why is master-next xenial kernel giving me gcc: error: unrecognized command line option ‘-fstack-protector-strong’
[03:39] <hallyn>  ?
[04:03] <Frogging101-chan> I want to append a custom name to the end of the kernel version. But CONFIG_LOCALVERSION breaks the build with the scripts
[04:03] <Frogging101-chan> How am I meant to do it?
[04:17] <dsmythies1> hallyn: You are getting "-fstack-protector-strong" becuase you are using an older version of the compiler. Perhaps you are using a 14.04 computer, like me. I just turn it off. Wait a minute...
[04:18] <dsmythies1> Hallyn: This is as of Ubuntu kernal configuration for kernel 4.4 series.
[04:19] <dsmythies1> hallyn: run this just before you start the compile: scripts/config --disable CC_STACKPROTECTOR_STRONG
[04:20] <dsmythies1> hallyn: Or use a new version of the compiler.
[04:20] <Frogging101-chan> I compiled GCC 5 on my 14.04-based (Mint 17.2) machine. Kernel compiles mostly fine but I'm having other build issues
[04:21] <hallyn> dsmythies1: i'm on xenial...
[04:21] <hallyn> but i'll try scripts/config --disable CC_STACKPROTECTOR_STRONG - thanks
[04:22] <dsmythies1> hallyn: Oh. I thought xenial was suing a new enough version of the compiler.
[04:22] <hallyn> D'OH!  i bet my environment from an arm cross compiler leaked
[04:22] <hallyn> sorry for the noise :)  
[04:28] <dsmythies1> Frogging101-chan: Are you compiling mainline kernel or Ubuntu version? It has been years since I compiled Ubuntu way, so my notes are old.
[04:28] <Frogging101-chan> dsmythies1: I used Git to checkout v4.4 and applied the .patch files from here http://kernel.ubuntu.com/~kernel-ppa/mainline/v4.4-wily/
[04:28] <Frogging101-chan> and then I do fakeroot debian/rules do_mainline_build=true binary-generic -j10
[04:29] <Frogging101-chan> (after setting up configs and setting the CONFIG_LOCALVERSION among other things)
[04:29] <Frogging101-chan> The CONFIG_LOCALVERSION is what breaks the build; it even says so on some Ubuntu wiki page
[04:31] <dsmythies1> I just do this: I never seemed to get things to work with the fakeroot stuff. I just do this: "time make -j9 bindeb-pkg LOCALVERSION=-stock"
[04:32] <Frogging101-chan> what is the reason to use the debian/ubuntu/whatever (can't figure out where that stuff comes from actually) scripts? 
[04:33] <Frogging101-chan> There seem to be a few different ways to do the same thing and one of them has more caveats
[04:34] <dsmythies1> or this: time make -j9 olddefconfig bindeb-pkg LOCALVERSION=-stock     (to just use defaults for any new config stuff)
[04:36] <dsmythies1> Someone will correct me if I am wrong, but you need to use the unutnu methods if you are going to submit chnages or use a PPA. I submit upstream, and not often, so only use mainline kernel, building the way I mentioned.
[04:36] <Frogging101-chan> ah
[04:36] <Frogging101-chan> all right
[04:37] <Frogging101-chan> does Ubuntu only patch the config or are there other patches I should apply to get it close to what Ubuntu has already?
[04:37] <Frogging101-chan> Because the existing config can be obtained from the OS as it's running already
[04:44] <dsmythies1> Frogging101-chan: For the PPA you referred to, it is just the mainline kernel. And yes, I just steal the ubuntu kernel config after I install the kernel from that PPA. For the real Ubuntu version (not out yet, but there is a PPA somewhere (Ithink)) , there is a lot of stuff done to it, making it different than mainline.
[04:45] <Frogging101-chan> well I've been on Git+config patches for a long time. Whatever I'm missing from the Ubuntu kernel doesn't seem to be causing issues
[04:54] <dsmythies1> Frogging 101-chan: I forgot to mention... After stealing the Ubuntu kernel config, run this: "scripts/config --disable DEBUG_INFO" or it will make an enormous kernel and take twice as long to compile.
[04:54] <Frogging101-chan> lol
[04:54] <Frogging101-chan> thanks :p
[04:54] <Frogging101-chan> what's that, debug symbols?
[04:55] <dsmythies1> Something like that.
=== lan3y is now known as Laney
=== Laney is now known as Guest80303
=== Guest80303 is now known as Laney
[09:50] <peaceful> Hi, i just found same bug i have: https://bugzilla.kernel.org/show_bug.cgi?id=110451
[09:50] <ubot5> bugzilla.kernel.org bug 110451 in Config-Tables "Boot fails on HP 6715s" [Normal,Assigned]
[09:51] <peaceful> How can i contribute to help solve it?
[09:57] <peaceful> cant boot laptop with kernel later than 3.19.0-25.26
[09:57] <peaceful> i also have hp compaq 6715s
[10:02] <peaceful> need some help to report  bug
[10:05] <apw> peaceful, so on whatever the last working version is, run 'ubuntu-bug linux', that will make a machine specific bug with your details
[10:06] <apw> peaceful, then add the infor that the above version is the latest which works, and point to the upstream bugzilla in there too
[10:06] <apw> peaceful, and then tell me the bug number and i'll find someone to help bisect it
[10:07] <peaceful> apw, ok but i see someone already reportred this bug. should i report again?
[10:07] <apw> peaceful, that is an upstream bug, so tracks the fix if any upstream, the ubuntu bug helps us track the fix in ubuntu itself
[10:09] <peaceful> apw, https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1529381
[10:09] <ubot5> Launchpad bug 1529381 in linux (Ubuntu) "[HP Compaq 6715s] Updating kernel renders system unbootable" [High,Triaged]
[10:09] <apw> jsalisbury, ^ hey that might be a bisection candidate for you
[10:10] <peaceful> this i found this
[10:10] <apw> peaceful, as our kernel has other stable bits on it, it can be a different fix as well
[10:10] <peaceful> hmm so how can i help to existing ubuntu bug report?
[10:11] <apw> well firstly you can mark it me-too at the top, you can also say you have the same issue as a comment
[10:12] <peaceful> okay
=== lool- is now known as lool
[10:15] <peaceful> apw what means assign to?
[10:16] <apw> peaceful, the assignee is the person who is owning the problem and who you should talk to before working on it (normally)
[10:16] <peaceful> should i assign?
[10:17] <apw> peaceful, to yourself, no it would be an engineer
[10:18] <apw> and we don't get much hung up on assigning bugs in the kernel, there are so very many of them
[10:18] <peaceful> ok
[10:19] <peaceful> i just commented i have same problem
[10:20] <apw> peaceful, ok this bug implies he found a commit which causes it, so that is quick to test.  i will produce a kernel based on 3.19.0-26.27 with just the commit removed to confirm that is the issue
[10:20] <peaceful> apw, ah okay, thanks i can test it
[10:21] <apw> peaceful, the builder is making it now, it'll be a little while
[10:21] <peaceful> apw, no problem thanks
=== Odd_Blok1 is now known as Odd_Bloke
[11:02] <apw> peaceful, http://people.canonical.com/~apw/lp1529381-vivid/
[11:02] <apw> peaceful, ok you will need a linux-image and linux-image-extra for your machine (i386 or amd64)
[11:03] <apw> peaceful, i386 for 32bit and amd64 for 64bit
[11:04] <peaceful> apw, thanks
[11:04] <peaceful> do i need linux-headers too?
[11:04] <apw> if you don't have dkms packages, then no
[11:05] <peaceful> not sure if i have
[11:06] <peaceful> apw, do you work for Canonical?
[11:07] <apw> peaceful, yeah, on the kernel team
[11:07] <peaceful> apw, nice :)
[11:07] <peaceful> Thanks for help i will test right now
[11:08] <apw> peaceful, having some people who are dedicated to these things cirtainly makes it easier to keep on top of
[11:08] <peaceful> apw, what's in linux-image-extra package?
[11:09] <peaceful> some kind of modules(drivers)?
[11:09] <apw> peaceful, bits you need on real hardware, linux-image is what you need in a virtual machine
[11:09] <apw> so linux-virtual only needs the first half, linux-generic needs both
[11:13]  * peaceful installing kernel
[11:14] <peaceful> apw, i have been frustrated with this problem :( i cant install current released linux distros, they have new kernels :/
[11:14] <peaceful> and im afraid to upgrade ubuntu
[11:14] <peaceful> glad i found someone that has same problem as me :)
[11:15] <apw> yeah it is good to not b unique
[11:15] <peaceful> im sure all who have hp compaq 6715s experience this
[11:15] <peaceful> but not many are tech guys who know how to report it :)
[11:20] <peaceful> apw, to my greatest surprise it booted up!
[11:20] <peaceful> 3.19.0-26-generic
[11:23] <peaceful> So now i have to wait for latest kernel release to fixed?
[11:23] <apw> peaceful, and if you could say that in the bug, under my call for testing
[11:24] <apw> peaceful, well that commit is applied to upstream stable but it also says we might want to revert it if it causes regressions which it clearly is
[11:24] <apw> peaceful, cirtainly someone need to investigate why it is blowing things up
[11:24] <peaceful> apw, ok i will comment that you helped me to fix it
[11:25] <apw> peaceful, comment to say that the kernel in my comment boots for you, that is useful info
[11:25] <peaceful> apw, sure
[11:25] <apw> peaceful, of course that is a vivid kernle, so there very well may not be another kernel for it
[11:25] <apw> as it goes off support in like 2 weks
[11:26] <apw> i also note that -26 is _anchient_ compared to vivid
[11:26] <apw> peaceful, have you tested anything recent at all ?
[11:26] <peaceful> apw, yep
[11:26] <peaceful> not booting
[11:26] <peaceful> i tested 4.3
[11:26] <apw> ok
[11:26] <peaceful> I didnt test 4.4, but guy in that bug report seems to ahve tested 4.4
[11:27] <peaceful> seems kernels later than 3.19.25.26 not booting at all
[11:27] <apw> now when it doesn't boot does anything happen at all, any kind of error or output
[11:27] <apw> if you boot without splash enabled
[11:27] <peaceful> i dont see any error
[11:27] <peaceful> it kind of stucks sometimes at different text
[11:28] <peaceful> and after freezing few seconds later black screen
[11:28] <peaceful> and only way to restart laptop is holding power button
[11:28] <peaceful> so i have no idea whats causing it
[11:28] <peaceful> There isnt consistency in showing error messages
[11:29] <peaceful> Its very strange
[11:29] <peaceful> But you something did and unbootable kernel booted up
[11:29] <apw> depending what that text is, getting a picture may be interesting
[11:29] <apw> right we know the commit which broke things, what is breaking whne its there is less clear
[11:29] <apw> likely it is a bios issue, given the nature of the commit
[11:30] <peaceful> apw, hmm
[11:30] <peaceful> well originaly this pc came with windows vista
[11:31] <apw> this commit makes it use the 64bit info the bios supplies over the 32bit info, which are supposed to be the same or your bios is broken :)
[11:32] <apw> cking, ACPICA global things (like acpi_gbl_use32_bit_fadt_addresses) are they exposed somewhere as changable ?
[11:32] <apw> cking, and remind me what the fadt even is ... stupid acronyms
[11:32] <peaceful> apw, sorry i dont know :/
[11:32] <peaceful> not sure what it is
[11:33] <peaceful> i have 32bit ubuntu now
[11:33] <peaceful> The guy on bug report has 64bit
[11:33] <peaceful> even though hp6715s has Amd sempron 64bit processor
[11:34] <cking> FADT - Fixed ACPI Description Table - this defines various fixed hardware ACPI information vita to an ACPI-compatible OS, such as the base address for the following hardware registers blocks
[11:34] <cking> *vital
[11:34] <peaceful> okay
[11:35] <cking> The PM register block addresses are 32 bit or 64 bit.  There are ways to determine if the kernel should be using the newer 64 bit addresses (like 32 bit fields being zero)
[11:37] <cking> sometimes firmware gets it broken, e.g. supplying two different 32 bit addresses, one in the 32 bit field in the 64 bit field
[11:38] <cking> peaceful, the firmware test suite (fwts) can check for a broken FADT, e.g. sudo fwts fadt -
[11:38] <peaceful> apw, ok i commented on both ubuntu and kernel websites
[11:38] <cking> apw, the acpi_gbl_use32_bit_fadt_addresses is not tweakable from user space
[11:39] <apw> cking, dman
[11:39] <apw> peaceful, yeah if you could run fwts at least we would know it is bios related or not
[11:39] <peaceful> apw, yes im installing fwts
[11:40] <cking> https://wiki.ubuntu.com/FirmwareTestSuite/Reference/fadt
[11:40] <peaceful> sorry guys what was the command to pastebin straight trough terminal?
[11:41] <cking> pastebinit ?
[11:41] <cking> peaceful, also output from "sudo fwts acpidump -" would be useful
[11:42] <peaceful> so the command would be sudo fwts fadt - | pastebinit ?
[11:42] <cking> i think so
[11:43] <peaceful> somehow not working: Bad API request, invalid api_dev_key
[11:43] <peaceful> ok ill do it manually
[11:44] <peaceful> http://paste.ubuntu.com/14589657/
[11:45] <peaceful> "sudo fwts acpidump -" : http://paste.ubuntu.com/14589663/
[11:46] <peaceful> hope it helsp
[11:49] <apw> cking, so i think fwts says it is fine, but the kernel blows chunks on it :)
[11:49] <cking> apw, yeah, well, there is a lot of stuff to check ;-)
[11:51] <peaceful> If i can help giving me you more info just say:)
[11:53]  * cking eyeballing the commit, kernel source and fwts output
[11:56] <cking> OK, so there is a bug in the firmware, 32 bit PM2 control block address is 0x00008800, where as the 64 bit PMS control block is 0x0000000000008100
[11:57] <cking> so the bios has got the 64 bit address wrong, hence the crash. There kernel has to follow what it is given, and the bios is lying on the 64 bit address
[11:57] <cking> s/PMS/X_PM2_CNT_BLK/
[12:00] <soee_> how is the work on 4.4 going ? :)
[12:01] <cking> apw, there should be a acpi_fadt_use_32_bit=[0|1] option, sigh
[12:04] <peaceful> cking, yeeey!
[12:05] <cking> apw, so if that fix is reverted, it probably breaks one lot of machines that get the 32 bit variant wrong, where as the commit breaks machines that get the 64 bit variant wrong.
[12:05] <cking> meanwhile, I'll get fwts fixed up to detect this discrepency.
[12:06] <cking> peaceful, can you run "sudo fwts --dump" and pastebin the acpidump.log just for reference.
[12:07] <peaceful> cking, sure
[12:08] <peaceful> cking, where that file is being saved?
[12:08] <cking> peaceful, hopefully in the directory you run fwts in
[12:09] <peaceful> ah yes sure
[12:09] <cking> :-)
[12:10] <peaceful> http://paste.ubuntu.com/14589797/
[12:12] <peaceful> in case you need:
[12:12] <peaceful> dmesg.log: http://paste.ubuntu.com/14589807/
[12:12] <peaceful> lspci.log: http://paste.ubuntu.com/14589809/
[12:13] <peaceful> dmidecode.log: http://paste.ubuntu.com/14589814/
[12:15] <cking> thanks peaceful.
[12:15] <cking> apw, so is a revert on that patch the way forward?
[12:15] <peaceful> cking, thanks you too
[12:44] <apw> cking, well the problem is the patch was applied in 3.19 and is still there unreverted, so now there is a lot of precident of it being that way round on newer kit
[14:30] <smoser> hey. looking for some guesses
[14:30] <smoser> we boot maas on iscsi root using an 'ephemeral image'.  http://maas.ubuntu.com/images/ephemeral-v2/daily/trusty/amd64/ .  In latest daily image 20160119 shutdown fails.  I believe the previous ( 20160114.4/) worked fine.  The manifest diff between the two is http://paste.ubuntu.com/14590395/ .
[14:30] <smoser> I see on the console of hung system http://i.imgur.com/qEFH4MN.jpg .
=== jdstrand_ is now known as jdstrand
[14:55] <beisner> smoser, similar for me with trusty + trusty kernel http://i.imgur.com/oKzFqvD.jpg
[15:33] <smoser> beisner, you're on iscsi root also, right ? thats commissioning or install environment of maas ?
[15:44] <beisner> smoser, deploying node from maas ui or from juju.
[15:45] <smoser> right.
[15:48] <peaceful> Hi everyone!
[15:49] <peaceful> apw, cking any news about my laptop kernel problem? :)
[15:49] <peaceful> oops
[15:50] <cking> peaceful, i'm building a kernel with a workaround in it and will update the bug when it's all ready
[15:51] <peaceful> cking, thanks a lot
[15:51] <cking> no problem
[15:52] <peaceful> Will latest kernel releases work on my laptop?
[15:53] <peaceful> cking, what do you suggest for me to do for example if I want to install ubuntu 15.10 but it has kernel 3.19.25+ which doesnt boot on my laptop?
[15:53] <cking> peaceful, lets test you H/W with the fix, and if that works and it is acceptible I will need to get the fix into other releases
[15:53] <peaceful> cking, ah ok thanks a lot
[15:55] <apw> yeah the wheels of open source grind slow
[15:56] <cking> especially if we need to test it, SRU it, and release it
[16:00] <peaceful> Okay :)
[16:00] <peaceful> Looking forward to it :)
[16:02] <cking> peaceful, check the bug report, it is ready to try out now
[16:04] <peaceful> cking, sure thanks
[16:29] <peaceful> Hi, cking! It works.
[16:29] <peaceful> 3.19.0-48-generic
[16:30] <cking> peaceful, excellent. I'll go ahead and SRU this fix. it will take some time to get through to release stage.
[16:30] <peaceful> at first i forgot to add "acpi_force_32bit_fadt_addr" in grub cmd line
[16:30] <peaceful> it didnt boot, but after addind that line it booted!
[16:30] <cking> yay \o/
[16:30] <peaceful> yey
[16:30] <peaceful> cking, thanks ;)
[16:30] <cking> no problem :-)
[16:31] <peaceful> cking, will this fix be only on ubuntu or other kernels too?
[16:32] <cking> peaceful, i'll SRU it for Wily and get it into Xenial too
[16:32] <cking> and for Vivid of course ;-)
[16:32] <peaceful> cking, thanks a lot
[16:32] <cking> my pleasure
[16:32] <apw> cking, i doub you will sru it for vivid, as vivid is dead
[16:32] <apw> or dead before we get a new sru cycle (i believe
[16:33] <cking> apw, can I squeeze the fix in, or is it too late for the final SRU cycle?
[16:33] <peaceful> cking, so kind will i need to use override parameter whenever i use new kernels on my laptop?
[16:33] <cking> i forgot it's EOL soon
[16:33] <cking> peaceful, afraid so
[16:33] <apw> henrix, have we rolled vivid for the last time ?
[16:35] <henrix> apw: we have; i expect 3.19.0-48.54 to be the last one
[16:35] <henrix> apw: we will continue to support it in trusty
[16:35] <peaceful> will this fix be pushed in mainstream kernel? :)
[16:36] <henrix> apw: so, we're still queuing patches for 3.19 in the master-next branch, which will come into the lts-vivid kernel
[16:37] <cking> peaceful, yes, I'll do that later today if I get some time
[16:38] <peaceful> What should i comment here? https://bugzilla.kernel.org/show_bug.cgi?id=110451
[16:38] <ubot5> bugzilla.kernel.org bug 110451 in Config-Tables "Boot fails on HP 6715s" [Normal,Assigned]
[16:41] <peaceful> Should i link your kernel with fix?
[16:47] <cking> peaceful, please do
[16:47] <xnox> apw, i have run file on the kernel image and it just says that it's a s390 kernel image....
[16:47] <xnox> is that enough test to figure out the image is or isn't compressed?
[16:48]  * xnox is not even sure if compressed kernels are supported.
[16:48] <apw> so i think that is "uncompressed" rather then the vmlinuz which is deffo compressed
[16:48] <apw> dont think so yet
[16:48]  * xnox goes to figure out what's happening on the rhel
[17:22] <peaceful> Thanks for help guys
[17:27] <peaceful> cking, how long will it take for fixes to go officially?
[17:39] <cking> peaceful, hopefully end of next week if all goes well
[17:44] <peaceful> cking, awesome :)
[20:52] <kfk2> It looks like the IPv4 version of static mfc/dev leaks fix (0e615e9601a15) was not applied to the latest trusty kernel (3.13.0-76.120) but the IPv6 version was (4c6980462f32b); was this a mistake?
[21:20] <kfk2> I wrote the wrong latest version; I'm looking at 76.121
[22:31] <apw> kamal, ^
[22:46] <kamal> apw, kfk2 is correct: this commit got missed for 3.13 or 3.19 -stable (the other one had a Fixes: tag that triggered its inclusion).   I'll get it applied:
[22:46] <kamal> 0e615e9 net: ipmr: fix static mfc/dev leaks on table destruction