[11:21] <xnox> cyphermox, ack, thanks. let me continue that.
[11:28] <xnox> WARNING: The following packages cannot be authenticated!
[11:28]  * xnox is confused why make -C d-i update doesn't work for me =(
[11:33] <cjwatson> bootstrap archive lying around somewhere?
[11:33] <cjwatson> since it'll be grabbing stuff from the system apt config
[11:35] <xnox> ah
[11:41]  * xnox enables -updates & -security pockets.... cause this desktop used to run devel, but now is running wily and kind of needs those.....
[14:29] <xnox> are http://people.canonical.com/~ubuntu-archive/livefs-build-logs/?C=M;O=D meant to be updated?
[14:30] <cjwatson> xnox: no, that's only an archive of logs from before building in LP
[14:30] <xnox> ack.
[15:26] <cyphermox> xnox: if it helps I already had it build in a PPA...
[15:28] <cyphermox> https://launchpad.net/~mathieu-tl/+archive/ubuntu/installer-dev/+sourcepub/5755722/+listing-archive-extra
[15:28] <cyphermox> it also requires mokutil though, for which the MIR might have just been acked
[21:09] <samson-uo> Hi all, can someone point out where I should be looking to figure out how autopartitioning works? I'm trying to figure out if/when ubiquity decides to create a separate /boot partition.
[21:15] <superm1> cyphermox: so the intention is that if secure boot is enabled then only load signed kernel is what's causing this change?
[21:16] <cyphermox> samson-uo: you want to look at the partman-auto package
[21:16] <superm1> has there been any discussion about ways to extend the trust onto third party modules that are in archive at least?  building them on launchpad with new kernel or something similar?
[21:16] <cyphermox> superm1: for my ubiquity branch?
[21:16] <superm1> yeah
[21:18] <cyphermox> so, yeah, only when booted in UEFI *and* when secure boot is enabled
[21:20] <superm1> so with that combination it won't be possible to say install an aftermarket NVIDIA kernel module
[21:22] <cyphermox> well, yes
[21:22] <cyphermox> that's why there is a prompt for a password to disable secureboot
[21:22] <cyphermox> with it, you'd be back to the current state of things
[21:23] <superm1> you can't programatically turn off secure boot though, that will require going into the BIOS to change the setting
[21:23] <cyphermox> ah, shim does have some logic for this
[21:23] <superm1> for turning off secure boot?
[21:23] <cyphermox> not quite disabling secure boot in the BIOS, but not failing validation
[21:23] <superm1> oh....
[21:23] <superm1> it's cheating gotcha :)
[21:23] <cyphermox> yeah
[21:24] <cyphermox> by the time you're in shim, it's not the BIOS itself doing validation but shim doing it for us
[21:25] <superm1> right.  if you're breaking the trust relationship at the shim level why not instead generate a machine specific key for third party modules and sign the kernel modules with that key during build?
[21:25] <cyphermox> that is one possibility for the future yes
[21:25] <cyphermox> you still need to hook up importing the machine key, kind of similarly to disabling validation in shim
[21:26] <superm1> yeah i guess it's a very similar end result