[14:53] cyphermox, hey, do you know a recent change that would trigger this question during a preseeded install with d-i ? http://paste.ubuntu.com/14478132/ [14:54] ah, nice [14:54] well, could be that I messed up a merge, didn't notice that one [14:54] cyphermox, it's the same preseeed we've been using for years for servers. would it be harmless to preseed this key or it's a real issue? [14:54] it's probably harmless to preseed [14:54] cyphermox, although on a manual installation there is no difference [14:55] but I think the intent in the past was to not have to, I'll need to check [14:55] could you file a bug? [14:56] cyphermox, will do [15:04] cyphermox, bug 1533243 [15:04] cyphermox, sorry I don't have more info, test artifacts are not attached to the result [15:05] thanks [15:05] no worries, that will be plenty I pretty much can just grep for that key and look again at my merge [20:27] xnox: Why did you add block-modules to generic/s390x.cfg? [20:29] xnox: "Add block-modules (depends on virtio-modules) for s390x" seems pointless with the kernel change to make those builtin. I think I'll revert that commit. [20:30] xnox: Or was there some other reason? [20:31] * infinity shrugs and leaves it there for now. [21:53] infinity, so apw wanted to make it a module on all platforms, rather than changing it to =y on s390x. [21:53] infinity, so i made the change, just in case. The net difference now is adding nbd module to the installer. [21:54] infinity, i don't know if apw will revert it to a =m everywhere. If he does, we will need block-modules in all/most d-i flavours. [21:54] xnox: It should still be in virtio-modules anyway (if it's =m), I'd say it's a bug that it was in block-modules. [21:54] xnox: But this works for now, I won't be too picky (already uploaded your change). [21:56] ok. [21:56] infinity, let me point that virtio-blk was in the wrong package to apw. cause we were slightly dilusional about it. [21:57] infinity, the whole bug was i went to boot cloud images, and virtio-blk was not in the initramfs, and was only in the -extra image.... [21:57] xnox: Err, surely this was about virtio-net anyway? [21:57] anyway all good now. [21:57] xnox: virtio-blk shouldn't be needed to boot the installer, it should be fetched over the network. [21:57] virtio-net and virtio-blk. Both were =m in -extra package and in block/virtio-udebs split [21:57] and i do need virtio-net and virtio-blk in the cloud-images initramfs. [21:58] virtio-blk can be fetched over the network true, in the d-i case. [21:58] Right, moving them to -virtual (either in image or =y) is correct, and yes, you need them in the cloud-init initrd, but that has nothing to do with d-i. [21:58] So, we probably should revert your change before we forget this conversation. :P [21:59] right. and apw wants to drop them from =y -> =m everywhere, as otherwise they are always loaded, and never unloaded. [21:59] And then make sure the kernel debs/udebs are correct if they go =m [21:59] right. [21:59] let me copy the irc log into a bug with actions to be done. [22:00] I'm not convinced virtio-modules needs to exist at all, except maybe as a dep of block-modules and nic-modules, if it has some common bits. [22:00] virtio-net should be in nic- and virtio-blk should be in block-, the more I think about it. [22:01] There's nothing about those drivers that make them any more "special" than any other block or nic device. [22:01] there is virtio-scsi and virtio-something else. [22:01] in virtio-udebs. [22:01] but yeah vitio-nic should be in nic-modules [22:03] Ahh, virtio-rng in virtio-modules. I wonder if that could just live somewhere else like kernel-image. [22:03] Anyhow, if you file a master bug with an IRC dump, I can work it out with Andy, we have a big TODO of "stuff that sucks with the kernel" that we're working through. [22:04] &> #ubuntu-kernel