=== himcesjf_ is now known as him-cesjf
[06:11] <alkisg> Good morning everyone.
[06:11] <alkisg> Why do Ubuntu installations under UEFI have both linux-generic and linux-signed-generic installed? Actually, isn't linux-signed-generic enough for any installation, either UEFI or BIOS?
[06:37] <alkisg> Erm, linux-signed-image-generic depends on linux-image-extra-XXX-generic, which in turn depends on linux-image-XXX-generic. So the packaging prevents us from only having the signed kernel installed. Would that be a bug to be reported?
[06:37] <alkisg> I.e. linux-image-extra-XXX-generic should Depend on EITHER the signed or non-signed kernels
=== himcesjf_ is now known as him-cesjf
[07:54] <xnox> alkisg, eh linux-signed-generic is no more than a detached signature, that is attached to an image.
[07:55] <xnox> alkisg, i wonder if we need linux-image-extra-XXX-generic-signed?! =)))))
[07:55]  * xnox thought we do need the image, ah, but i guess the unsigned metapackage is redundant.
[07:55] <xnox> interesting
[08:13] <alkisg> xnox: yes, I believe there's no point in having an unsigned version, but at the very least, allow uninstalling it by fixing the dependency there
[08:19] <alkisg> (I mean, an unsigned version could of course be available in the archives, but there's no point in ubuntu ever installing it automatically or even having it in live cds)
=== Elimin8r is now known as Elimin8er
[08:42] <xnox> alkisg, somehow it feels to me that we only want signed kernels, everywhere, even if nothing knows how to validate that on a given arch.
[08:43] <alkisg> xnox: sure, that would be fine; I'm not sure if people building the kernel locally can generate them though, so having the unsigned package in the archives will be needed as well?
[08:44] <alkisg> Personally I have no need for the unsigned version...
[08:44] <xnox> alkisg, yes, and well we need one too. Cause we build unsigned one first; then kick of a separate build which creates the signed one.... cause otherwise chicken-egg-problem
[09:16] <mhzlp> Hi everyone :-) I would like to raise a question here, before starting a launchpad ticket
[09:16] <mhzlp> Having a problem with one of my ubuntu machines. It is giving segfaults when loading specific kernel-modules (vendor-drivers for an isdn-card).
[09:16] <mhzlp> Output of dmesg states "kernel BUG at /build/linux-fOTvIb/linux-3.13.0/arch/x86/kernel", enclosed in a "---[ cut here ]---" block.
[09:16] <mhzlp> Problems started with the Meltdown/Spectre mitigation kernel versions, worked fine for years before that. 
[09:16] <mhzlp> Do you think it makes sense to submit this as a bug ticket?
[09:18] <klebers> mhzlp, Hi! Is this kernel module shipped by Canonical is it compiled out-of-tree?
[09:21] <mhzlp> klebers: it is a drivers package which is available for download at the hardware manufacturer. that is why i am asking
[09:22] <mhzlp> but they deliver the source code, so i built it with #139 and #141 kernel versions, but it failed. last working was #137
[09:24] <mhzlp> well not the built itself failed, the loading of the module afterwards did
[09:25] <klebers> that could be either a bug on the kernel itself or a bug on the driver that's causing the BUG to be called
[09:28] <mhzlp> then it would make sense to open up a bug report in launchpad too, right?
[09:29] <klebers> mhzlp, yes, please include the full stack trace (the 'cut here' block) and a link to download the driver package
[09:29] <klebers> mhzlp, is it possible to reproduce the issue without having the hardware?
[09:32] <mhzlp> will do, also have a strace of the module load prepared. to be honest, i am NOT sure about that, didnt try yet. there is a setup involved for the isdn cards, which afaik has some options for the SNs. Not sure if that would affect the module behaviour
[09:36] <mhzlp> thanks for the brief evaluation and the hints so far
[09:49] <apw> xnox, always signed> yes, and we have work in progress to fix that, but it was stalled awaiting to find out if older powerpc boot laoders will barf if we switc
[09:50] <xnox> urgh
[09:50] <apw> also it is somewhat back-burnered because of the meltdown debackle too
[09:51] <apw> xnox, but yes, there seems to be no obvious reason we cannot ship a single signed binary, well as long as no platform moves to having more than one way to sign
[09:51] <apw> xnox, indeed it was my plan-of-record to work on that over the "quiet time" in december ... so much for _that_
[09:56] <alkisg> apw: would it make sense to fix the image-extra dependency in the meantime, as it's a small fix? So that people that want to uninstall the non-signed kernel, are able to?
[09:57] <apw> alkisg, you cannot, if you remove that you have no kernel to attach the signature to
[09:58] <apw> alkisg, the signed package doens't contain the kernel, only the signature, and copies and attached it in postinst
[09:58] <alkisg> Thanks, looking (something still feels strange...)
[09:58] <apw> alkisg, trust me, i wrote that bit :)
[09:59] <apw> alkisg, the file /boot/vmlinuz-*.signed is not in apt control
[09:59] <apw> with highsight this was not a good plan, but it was about saving download time as you need to have bot
[09:59] <apw> both on a non-efi system, well ... we only wanted to use the signed one on efi systems
[10:00] <apw> to reduce risk when introducing it, now we have experience with it we know it is utterly
[10:00] <apw> fine in x86 at least, to boot a kernel with a signature on something which does not understand it
[10:01] <alkisg> apw: ok, all is fine, I was thinking that grub would list two kernels etc, but it doesn't, my misunderstanding
[10:02] <apw> nope because we did this, we also have to frig grub to hide the duplicate, all in all a poor design choice
[10:02] <apw> and one we are going to remedy, likely last decdember, oops
[10:02] <alkisg> :D
[10:03] <apw> it was actually my number1 priority for 2 days before meltdown was dropped in my lap
[10:03] <apw> such is the way of teh world
[10:03] <apw> the best laid plans of mice and men
[10:03] <alkisg> apw: regarding https://bugzilla.kernel.org/show_bug.cgi?id=198529, there's no response yet from the regression author, yet it affects a whole lot of i5 processors, would we care to fix it downstream?
[10:03] <ubot5> bugzilla.kernel.org bug 198529 in x86-64 "Reboot on kernel load due to 92a0f81d" [High,New]
[10:04] <alkisg> I.e. 32bit Ubuntu no longer loads on a wide range of i5 processors
[10:05] <alkisg> I also mailed him, he didn't respond to that either
[10:15] <apw> alkisg, we might have found a fix for that, if it is the same issue that wgrant found a fix for
[10:16] <apw> smb, do we have any test kernels with that 32bit iommu thing appplied ?
[10:16] <smb> apw, I have none
[10:19] <alkisg> I'm available for testing, please ping me if someone has such a 32bit test kernel at any time
[10:19]  * apw makes one
[10:20] <alkisg> ty!
[10:21] <apw> alkisg, what is your bug number ?
[10:21] <alkisg> apw: https://bugzilla.kernel.org/show_bug.cgi?id=198529 => I haven't filed one in launchpad
[10:21] <ubot5> bugzilla.kernel.org bug 198529 in x86-64 "Reboot on kernel load due to 92a0f81d" [High,New]
[10:22] <apw> alkisg, do you have an ubuntu bug ?
[10:22] <alkisg> no
[10:22] <apw> smb, do we have a bug for that patch yet ?
[10:22] <alkisg> I can file one if you want
[10:22] <smb> apw, there were several (i386) not booting
[10:24] <smb> https://bugs.launchpad.net/ubuntu/+source/linux-hwe/+bug/1744942, https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1745118
[10:24] <ubot5> Ubuntu bug 1744942 in linux (Ubuntu Artful) "Lenovo IdeaPad U460 fails to boot with 4.13.0-31.34~16.04.1" [High,Confirmed]
[10:24] <ubot5> Ubuntu bug 1745118 in linux (Ubuntu Artful) "Unable to boot with i386 4.13.0-25 / 4.13.0-26 / 4.13.0-31 kernel on Xenial / Artful" [High,Triaged]
[10:25] <smb> apw, there was a 3rd one but I am too lazy to search for that one as well
[10:26] <apw> smb, that 118 one looks the most general
[10:26] <smb> apw, yes, though the other one was reported first I believe
[10:27] <smb> but on hwe kernel
[10:27] <alkisg> I like the wgrant explanation on 118
[10:27] <alkisg> There's a test kernel there
[10:27] <alkisg> Should I try it or wait for yours, apw?
[10:27] <apw> alkisg, if there is one there, have at it
[10:28] <alkisg> Comment #14, https://people.canonical.com/~wgrant/linux-image-4.13.0-31-generic_4.13.0-31.34~16.04.1_i386.deb
[10:29] <smb> That probably is already having the fix which he then submitted upstream... or at least close
[10:31] <smb> https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git/patch/?id=55f49fcb879fbeebf2a8c1ac7c9e6d90df55f798
[10:31] <alkisg> Yeah that blames the same commit that I blamed all right
[10:32] <apw> alkisg, yeah i meant to mention it late last night, and forgot ... that is sounded similar enough to be worth testing
[10:33] <alkisg> Currently installing, will reboot/test in a few
[10:38] <alkisg> Yup, that fixed it. Thanks apw and smb and wgrant :)
[10:38] <alkisg> I'll cross-reference the bug reports
[10:38] <apw> wgrant is the man on that one
[10:38] <apw> alkisg, so that is intended to be in the next xenial/linux-hwe upload
[10:41] <alkisg> Very nice. There are still a lot of instabilities with 4.13, but that one was a show-stopper
[10:42] <alkisg> apw, smb, is https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git/patch/?id=55f49fcb879fbeebf2a8c1ac7c9e6d90df55f798 accepted upstream, i.e. should I close my upstream bug report now?
[10:44] <apw> alkisg, it is very nearly ipstream, it is now in the pti branch which normally goes to linus pretty quick
[10:44] <apw> alkisg, i would make sure you reference it in your bug
[10:45] <alkisg> ty, doing so
=== mamarley_ is now known as mamarley
=== juergh_ is now known as juergh
[22:32] <nacc> jsalisbury: fyi, LP: #1746818 is more fallout from the 16.04 HWE change to 4.13, if you wouldn't mind triaging
[22:32] <ubot5> Launchpad bug 1746818 in smb4k (Ubuntu) "smb4k on Kubuntu 16.04 working no longer with new hwe kernel 4.13" [Undecided,New] https://launchpad.net/bugs/1746818
[22:32] <nacc> (or someone else more relevant, if i'm wrong :)
[22:39] <TJ-> That reminds me of another: Bug #1743094
[22:39] <ubot5> bug 1743094 in linux (Ubuntu) "[regression] hibernation (freezes on resume) since 4.13.0-25.29" [Medium,Confirmed] https://launchpad.net/bugs/1743094
[23:02] <oursland> "fakeroot debian/rules binary" fails to build the kernel, giving an error that SPL/ZFS expect a fully built kernel.  Any suggestions to get past this error?
=== mwsb is now known as chu