/srv/irclogs.ubuntu.com/2016/06/03/#ubuntu-kernel.txt

=== FourDollars_ is now known as FourDollars
=== Trevinho_ is now known as Trevinho
=== lfaraone_ is now known as lfaraone
=== logan_ is now known as Guest62971
=== Guest62971 is now known as logan-
xnoxapw, any plans to do mainline builds for s390x?12:04
xnoxe.g. http://kernel.ubuntu.com/~kernel-ppa/mainline/v4.6-yakkety/12:04
apwxnox, hmmm, i wonder how we decide12:05
xnoxwe are way ahead of everyone else and quite often bugs like "works everywhere but ubuntu" is actually "broke in mainline since X.Y"12:05
xnoxthere is ppc64el builds....12:05
xnox*are12:05
apwxnox, seem we have a nice non-maintable list ... yay ... so presumably for X+ right ?12:06
xnoxapw, yes please.12:07
apwxnox, ok added, deployed, and a v4.6 rebuild requested12:08
apwxnox, we'll see what happens12:08
xnoxcool12:08
=== JanC is now known as Guest27710
=== JanC_ is now known as JanC
rtgcyphermox, UEFI test kernels at ppa:canonical-kernel-team/unstable12:39
apwrtg, there was a lot of failure messages in my inbox, was that intentional "don't waste cycled build" failures ?12:40
rtgapw, I had trouble getting 3.13 to build. It wasn't parsing the ABI number correctly when I added a '~uefi' into the version. I prolly forgot to cancel one of the failing builds before uploading again.12:41
apwrtg, ahh ok12:41
rtgit still doesn't build arm64, but I think we can just turn off UEFI on that arch12:42
apwrtg, sounds like we are missing some packaging back there12:42
apwrtg, in older releases likely yes we can, but newer ones it may well exist i think12:42
rtgapw, yeah, I was too tired to figure it out, so I just dropped the '~uefi'12:42
rtgvivid and wily built OK12:43
rtgapw, did you change CONFIG_UNIX=m in the mainline build ?12:58
apwrtg, no, that comes directly from the unstable configs13:01
apwrtg, so bugger, that means i will ahve to rebuild that _again_ when you fix it13:01
rtgapw, one of the bug reporters suggested the correct fix was in udev or initrd, though I suppose I could revert the config change for now13:01
apwxnox, ok s390x builds are now in there anyhow13:01
apwrtg, it is a trick chicken and egg issue as module loading is handled on demand by udev13:02
rtgapw, reverted and pushed13:03
apwrtg, i'll respin that 4.6 so it gets the update13:03
apwand whoever was testing and failing, can retest13:03
=== inaddy is now known as tinoco
cyphermoxrtg: great. so does that mean there hasn't really been much testing for all of it?14:09
cyphermoxrtg: apw: how far are we from a kernel SRU cycle so we can SRU $everything $everywhere ? ;)14:10
rtgcyphermox, I've done my own local testing to make sure it does what I think it should. I'm sure these patches could use a bit more exposure.14:10
apwcyphermox, we start a new cycle next week, so nominally patches need to be avilable today to hit this cycle14:10
rtgcyphermox, next SRU cycle starts Monday14:11
cyphermoxright, I'm trying to decide if we want to SRU everything now and test there if we're confident enough that things are good, or wait another three weeks or whatever to give us time to test everything in a PPA, on all releases, upgrades, etc.14:11
apwcyphermox, if we wait 3 weeks can we still hit the point release ?14:12
rtgcyphermox, given the difficulties consumers of DKMS may face, I'd advise testing, testing, testing14:12
cyphermoxit definitely wouldn't be better to fail to validate and block other things though14:12
cyphermox16.04.1 would be July 21st, we'd start to cut it close14:13
cyphermoxI said three weeks, but I really means next one of your SRU cycles14:14
rtgcyphermox, are all of the user space bits well on their way to -updates ?14:14
apwcyphermox, will all the rest of the bits be out before then, and do they have to be, i assume they do14:14
cyphermoxrtg: no, things will land along with the kernel, in proposed at the same time14:14
apwrtg, in theory all of this new code is rendered sterile of we turn off enforcement by default right ?14:14
apwrtg, so we could consider applying all but that (assuming there is a kernel command line to turn it on for testers)14:15
rtgapw, its a CONFIG option only right now14:15
rtgotherwise it kinda defeats the purpose14:15
cyphermoxyeah, I think we shouldn't mess with that especially since it's pretty much what we want to test14:16
apwmamarley, the v4.6 mainline kernel has been rebuilt with the AF_UNIX thing reverted (in theory)14:19
mamarleyapw: Cool, thanks!14:19
=== tyhicks` is now known as tyhicks
cyphermoxrtg: what about a precise kernel? that seems to be missing from the PPA (or I'm not looking at the right place)17:24
rtgcyphermox, the Precise kernel did not support signed modules, so we'll have to make do with the LTS Trusty kernel17:25
cyphermoxthat's not in the PPA though?17:26
rtgcyphermox, nope, but you can install the Trusty kernel by hand into a Precise user space17:27
cyphermoxthis is a cutoff point at which we won't be making any more of any kernels that can't do signed modules, otherwise we'd be diminishing the value of having a new key (although we haven't got a new key just yet, that will go later)17:28
rtgcyphermox, personally I think we should just leave Precise as is.17:29
rtgthat, or you'll have to make the new shim dependent on LTS Trusty kernel.17:30
cyphermoxas long as we're supporting precise, I think we can't discount the fact that there may be kernel or other updates -- there's just one key for signing Secure Boot stuff, so I think we need to care about it17:33
cyphermoxafaict that's 10 more months of support, seems unlikely that there won't be some security issue to fix within that time, but I won't pretend I pay much attention to how often kernel SRUs happen on precise :)17:34
rtgcyphermox, I really don't know either, but I'm sure there will be at least one.17:35
cyphermoxok17:36
cyphermoxso we should start validating 16.04 since 16.04.1 what's coming up fastest; then trusty (point release in august), and as time permits wily and precise17:39
rtgcyphermox, ack17:39
cyphermoxrtg: do you have time to do testing on your own with everything? I mean including the userland bits and enabling dkms packages, upgrading to a new release, etc. ?17:40
rtgcyphermox, we also support LTS Utopic and Vivid for awhile yet.17:40
cyphermoxI have the userland pieces at ppa:cyphermox/efi17:40
cyphermoxok17:40
rtgcyphermox, as long as a QEMU instance is OK for testing17:41
cyphermoxneedless to say this all means it can't land in the SRU cycle this coming Monday17:41
cyphermoxrtg: should be17:41
cyphermoxyou'll want to insert certificates to enable secureboot with the right signature checking17:41
rtgcyphermox, that is how I tested these kernels thus far, i.e., enrolled my own keys17:42
cyphermoxhttps://wiki.ubuntu.com/SecurityTeam/SecureBoot17:42
cyphermoxright17:42
rtgcyphermox, yep, I used jdstrand's script to enroll keys. worked like a charm17:42
cyphermoxI have an unbroken system that can do hardware SB with the MS keys now, so I'll reinstall 16.04 there now and start it17:43
cyphermoxrtg: cool; I haven't had as much luck, but I was able to enroll keys otherwise17:43
rtgcyphermox, I don't have a bare metal box that will allow me to enroll keys, so I've had to use QEMU.17:43
cyphermoxwell17:44
cyphermoxthe only keys you ever need enrolled are the Microsoft ones17:44
cyphermoxwe're not changing shim itself, so past this it can be done programmatically in MokManager17:44
cyphermoxI think the wiki is missing the relevant info for this; I'll see about adding it17:44
rtgok, good point17:45
cyphermoxMS> at the firmware level17:45
cyphermoxCanonical> at the MokManager level17:45
cyphermoxthis means your signing keys for the PPA also need to happen at the MokManager level17:45
rtgI guess that is a change from what I understood needed to happen.17:46
cyphermoxsudo mokutil --import $cert17:46
cyphermoxwhat did you understand?17:47
rtgI thought we had to update shim with a new key.17:47
cyphermoxwe will17:47
cyphermoxbut we're not there yet17:47
rtgok17:47
cyphermoxthat will be the very last piece, along with an updated grub that disables loading unsigned17:47
rtgcyphermox, lemme know when the wiki is updated and I'll get started testing.17:48
cyphermoxrtg: ok, but you got the jist of it -- you want to re-sign stuff with your own key since we don't have the PPAs certificate, and then import that cert with the mokutil command above17:49
rtgyup17:49
cyphermoxon reboot that will get you a blue screen that will have you confirm adding the key17:49
rtgmakes sense17:50
rtgcyphermox, that reminds me, you don't expect older kernels to read that key from MOK, right ? Only Xenial+ knows how to do that.17:51
rtgthe only recourse for DKMS users on anything prior to Xenial is to disable secure boot.17:52
* rtg pops out for some lunch17:55
cyphermoxwell, we at least expect that sudo mokutil --disable-validation will DTRT, and let people boot and load unsigned kernels.18:18
cyphermoxand load unsigned modules18:18
rtgcyphermox, yes. I have tested that functionality.18:22
cyphermoxrtg: right18:41
cyphermoxwell, I'm writing a trusty image to USB now to give this a shot ; I need to test something else to at the same time anyway18:42
=== Serge is now known as hallyn
cyphermoxrtg: will you add linux-lts-wily and others to the ppa?20:02
rtgcyphermox, not unless you really want me to. The non-LTS Wily kernel is functionally identical, just built with a newer toolchain.20:04
cyphermoxrtg: it's kind of easier to just dist-upgrade the system with the PPAs enabled rather than mucking around to install various extra packages20:07
cyphermoxwe want to make sure upgrades between distros and package upgrades will work, so it's good to be able to pick things up as if they were from the official archive.20:07
rtgcyphermox, alright, but it'll likely be Monday before they are ready.20:08
rtgcyphermox, I assume you want all 4 LTS kernels in Trusty ? e.g., Utopic, Vivid, Wily, Xenial20:09
cyphermoxideally, yes. we want to test everything very carefully and then do the uploads to proposed20:09
rtgcyphermox, ok20:09

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!