[05:36] <blackboxsw> Teridon: sorry for the long delay and glad you appreciated the SSH host key fix in cloud-init. updating the subiquity snap for your live installer won't get you the new cloud-init in your target system I don't think but I believe the following late-comands should update cloud-init in your target disk before reboot, so your ssh host key configuration would be honored after that final target system reboot  
[05:36] <blackboxsw> https://paste.ubuntu.com/p/Kz8q5TvZTd/ note the late-commands are actually run from within the ephemeral installer environment, but they'll chroot into the mounted /target in order to upgarde cloud-init on disk so that the final reboot will honor your custom user-data. This is only released on lunar for cloud-init at the moment. We expect to start an SRU to Bionic/focal/jammy and kinetic this week so cloud-init updates on those 
[05:36] <blackboxsw> series should be available soonish (~1 & a half weeks)
[05:36] <blackboxsw> note the sample passwd in that pastebin is just 'ubuntu'
[08:09] <Lope> why is ubuntu's /etc/apt/sources.list so complicated vs Debian?
[08:10] <Lope> with debian, you can have a perfectly functional system with a single line
[08:10] <Lope> but with Ubuntu you need a huge complicated file?
[08:11] <rbasak> Some users prefer to receive security updates only, some want all updates, and some want no updates, so we allow individual selection.
[08:11] <Lope> okay, I see.
[08:11] <Lope> That's actually pretty cool.
[08:12] <Lope> I've got a KVM VM, I've installed the linux-image-kvm IIRC. I saw there was also linux-image-virtual what's the diff?
[08:12] <Lope> They both say they're for VM's?
[08:14] <rbasak> I think -virtual has support for more virtual hardware or something like that, and therefore is bigger. I'm not sure though.
[08:15] <rbasak> The description of -kvm additionally says "minimal"
[12:34] <kanashiro[m]> ahasenack: could you take a look at this PR where I am fixing the docker-in-lxd DEP-8 test in lunar? This is the same solution I am going to apply in kinetic (both worked fine locally) https://github.com/tianon/debian-docker/pull/19
[12:34] -ubottu:#ubuntu-server- Pull 19 in tianon/debian-docker "Fix lxd test lunar" [Open]
[12:34] <ahasenack_> ok
[12:35] <kanashiro[m]> it is not failing in lunar right now but it is using a privileged lxd container
[12:35] <ahasenack_> so it was the backend?
[12:35] <kanashiro[m]> yes, it was that
[12:35] <ahasenack_> what was it using before, zfs?
[12:36] <kanashiro[m]> correct, the default
[12:36] <ahasenack_> can't you set that in the lxd init phase? Or is it better after?
[12:37] <ahasenack_> s/better/easier/ perhaps
[12:37] <kanashiro[m]> it could be done in the init phase I guess, I just tried to follow the docs
[12:37] <ahasenack_> ok
[12:38] <ahasenack_> and in older releases we don't need any of that? Not even the new security.* settings?
[12:38] <kanashiro[m]> the security.nesting=true was already present before
[12:39] <ahasenack_> yes
[12:39] <ahasenack_> it was the only one iirc
[12:39] <kanashiro[m]> the syscalls intercepts are the new ones
[12:39] <kanashiro[m]> yes
[12:40] <ahasenack_> ok, the storage thing, it's not for the lxd container itself (i.e., its root filesystem)
[12:40] <ahasenack_> you are just handing it over to docker itself
[12:40] <ahasenack_> which is fine
[13:58] <Teridon> blackboxsw: delayed response better than no response :-D  thx! 
[14:30] <kanashiro[m]> ahasenack: could you reject the docker.io package in kinetic-proposed? I'll be uploading the changes you approved using the same version
[15:24] <ahasenack> kanashiro[m]: done
[18:19] <habys> can anyone confirm `lunar-netboot-amd64.tar.gz` can't actually run the installer from the included files, but must still download the image iso?
[18:33] <habys> looks like it. Well I guess that could save you unzipping the iso to get the kernel and initrd.
[18:33] <habys> seems like it would be pretty nice to include the installer in the initrd and not need to download the iso at all.