[00:02] <superm1> cyphermox: but doesn't the kernel need to read this variable to be able to make use of it?
[00:02] <superm1> if shim isn't updated by the time 16.04 is cut how will the variable be available?
[00:03] <cyphermox> nah, the kernel should be fine with MokSB at it currently is, shouldn't need the mirror copy
[03:41] <superm1> cyphermox: is this the series that will be used for enforcing secure boot in the kernel in Ubuntu? http://www.spinics.net/linux/fedora/linux-security-module/msg15999.html  I didn't notice any mentions of enforcement based upon MokSB, it seemed to me that it actually mirrored secure boot being turned on in the firmware
[03:55] <superm1> i don't see that patch series applied to xenial's kernel though, presumably nothing is enforcing right now
[05:03] <cyphermox> right, that's more or less the patch series (more or less becauseI pointed apw to the actual repo for fedora kernel packages)
[05:04] <cyphermox> indeed it's not currently applied, they need to do it
[05:05] <cyphermox> as for the variables themselves, the patches deal with SecureBoot and SetupMode, which is nice for whether secureBoot is enabled in firmware but doesn't tell you what's up with Mok/shim
[05:05] <cyphermox> we want to deal with a different variable at the shim level because you can't change SecureBoot or SetupMode from not in firmware
[05:06] <cyphermox> so mokutil sets MokSB, which modifies MokSBState when shim next runs, etc. etc. to disable validation at the shim level
[05:18] <cyphermox> the kernel needs to watch MokSBState to keep track of whether it needs to enforce module sigs (or really, how to treat a success at validating signature from shim); which already exists, and my commit adds MokSBStateRT which should only be needed in userland (ie. mokutil)
[05:20] <cyphermox> since the kernel gets to be in BS as well as RT, we don't absolutely need MokSBStateRT there for things to work
[05:21] <cyphermox> (also, MokSBStateRT can actually be modified after boot)
[05:21] <cyphermox> superm1: I'm still kind of new at all the EFI stuff, so I might be getting some of it wrong, but that's the jist of it
[05:23] <cyphermox> and now, I had already gone to bed and only meant to spend two minutes looking at something, and looking into this I had to put on my old pair of glasses, now I'm nauseated, so I'm going back to bed ;)
[12:49] <superm1> cyphermox: ah okay thanks that clears it up much better for me.  so what you're referring to is http://pkgs.fedoraproject.org/cgit/rpms/kernel.git/tree/efi-Disable-secure-boot-if-shim-is-in-insecure-mode.patch to control based on MokSBState.
[20:09] <nilsj> hi
[20:15] <nilsj> I'm trying to netboot the latest ubuntu, but since 2 hours I get "anna[5511]: WARNING **: no packages matching running kernel 4.4.0-16-generic in archive" .. any ideas how I can debug this?
[20:16] <nilsj> I'm using http://archive.ubuntu.com/ubuntu/dists/xenial/main/installer-amd64/current/images/netboot/ubuntu-installer/amd64/
[20:42] <cyphermox> nilsj: when did you download that netboot image?
[20:44] <cyphermox> I guess you may have been unlucky with the timing since 4.4.0-16.32 and the latest image got in about 3 hours ago, maybe you started this while things were not quite settled yet, especially if you're using a country mirror
[20:45] <nilsj> cyphermox: Now it's working. There was a windows of around 2-3 hours where it was broken..
[20:46] <cyphermox> right
[20:46] <nilsj> I always downloading the latest netboot image. Using https://github.com/jhaals/waitron with pixiecore. Pretty nice solution for netboot.
[20:47] <cyphermox> possibly time for stuff to settle on mirrors, I don't know
[20:47] <nilsj> Could this happen again when LTS is released?
[20:47] <nilsj> in case of kernel upgrade?
[20:47] <cyphermox> I suppose, if you try to install the image a very very short time after it's released
[20:48] <cyphermox> what mirror do you use?
[20:48] <nilsj> Usually de
[21:03] <xnox> nilsj, well when lts is released xenial/ download will be frozen. But instead you may see such transient issue with e.g. xenial-updates netboot images.
[21:10] <nilsj> okay, thanks.
[21:11] <xnox> in theory both kernel and d-i images publish simultaniously, but i'm guessing that pool/ & d-i images are syncing, without apt metadata updated yet.
[21:12] <xnox> and then d-i images are there, but hitting old metadata, waiting for pool/ to sync, cause only after pool/ the metadata is updated.
[21:12] <xnox> and then things are all good.
[21:26] <infinity> There is a short window in mirror sync where d-i images can be newer than package indexes, yes, but it's not long.
[21:28] <infinity> nilsj: If you want to make sure you're downloading an image that is synced, "apt-get update && apt-cache policy debian-installer | awk '/^  Candidate/ {print $2}'" and grab the netboot directory version that matches, instead of current/
[21:28] <infinity> nilsj: But that's just paranoia to avoid the few-minute window where it might be out of sync.
[21:29] <nilsj> Hopefully I don't have to re-install all the bare-metal servers soon.. ;)
[21:30] <nilsj> But it's automated.. but seriously, the debian installer and preseed with raid, md, lvm is pita.
[21:33] <xnox> nilsj, it's ugly any way one approaches. e.g. MAAS uses curtin installer, and then "recipe" for partitioning is defined in Yaml, but one also needs to specify all layers.
[21:34] <xnox> drives, block devices, raids, vgs, lvs, filesystems, mountpoints, in an ordered list of things with back references.
[21:37] <nilsj> I'll took a look into curtin some weeks ago, but didn't find useful documentation at this time.. the good thing is, now everything is working. :)