[03:57] <blahdeblah> Hoping someone can point me at the right keywords to search on...  I've got an Ubuntu server AWS AMI being built by packer and it works fine, but when it is instantiated into an instance, it comes up with grub-efi-amd64-signed unconfigured because the device id of the boot volume is (obviously) different.
[03:58] <blahdeblah> What this means is that it expects interactive fixing by selecting a new boot device on which to install grub.
[03:58] <blahdeblah> If I just use 'DEBIAN_FRONTEND=noninteractive dpkg --configure --force-confdef grub-efi-amd64-signed' it uses the old value, which is wrong.
[03:59] <blahdeblah> However, when I configure it interactively, it automagically works this out and suggests a new (correct) boot device.
[03:59] <blahdeblah> How can I configure it to use that new, correct boot device using the noninteractive frontend?
[04:10] <blahdeblah> Even purging and reinstalling grub-efi-amd64-signed and shim-signed doesn't seem to introduce correct behaviour from the start...
[04:13] <blahdeblah> Looking at the guts of /usr/lib/grub/grub-multi-install it seems like it should be able to work it out based on the mounted /boot/efi and go from there, but the script explicitly sets the debconf prompt to critical.
[04:13] <blahdeblah> I'm reluctant to butcher that script into a custom thing which just overrides all the prompts and tells it to just do it - that feels like an unmaintainable course.
[04:48] <blahdeblah> Best I've come up with so far is to work out the right device name myself and run: echo "grub-common grub-efi/install_devices select /dev/XXXX" | debconf-set-selections --verbose
[04:55] <blahdeblah> Seems to work: echo "grub-common grub-efi/install_devices select $(mount | awk '/boot.efi/ {print $1}')" | debconf-set-selections
[04:55] <blahdeblah> This feels very hacky to me.  Hope someone can suggest something more elegant.
[05:33] <blahdeblah> Hmmm, so it seems https://cloudinit.readthedocs.io/en/latest/reference/modules.html#grub-dpkg is supposed to take care of this.
[05:42] <blahdeblah> Seems like maybe the packer build of this isn't clearing out the cloud-init state to allow it to rerun when a new instance starts?  I would have thought that would be the default, but perhaps the team who maintains them is using an out-of-date config.
[08:54] <Paddy_NI> Hello I am having trouble with an Ubuntu Server install on a mini pc. I am no longet able to ping the internet from it or ping the machine itself on my LAN. I tried assigning it an IP inside "/etc/netplan/00-installer-config.yaml".  This system does report in "ip addr" that it has the ip address but I still cannot communicate with it.
[08:55] <Paddy_NI> I am wondering if this is because I installed "openresolv" because wg-quick comlained about its absense.  FYI wireguard is not essential here as I was just experimenting. 
[08:56] <Paddy_NI> I install openresolv and rebooted. Wireguard seemed to be working perfectly. I then disabled it via "sudo systemctl disable wg-quick@wg0.service" and now no internet or lan IP.
[08:57] <Paddy_NI> Or rather have now uninstalled openresolv
[11:42] <luna__> https://www.youtube.com/watch?v=i9fhkpGdv0Y&
[12:08] <luna__> actually did learn something from that
[15:05] <blackboxsw> blahdeblah: I think cloud-init would like a bug on the reproducer steps for that path and the included /var/log/cloud-init.log (or cloud-init collect-logs) as I'm not sure what steps are implied by " AWS AMI being built by packer and it works fine, but when it is instantiated into an instance, " and the end state of said instance. Generally when an instance is created from an AMI a new instance-id is provided by AWS. 
[15:06] <blackboxsw> That new instance-id from AWS metadata service tells cloud-init to re-run all configuration which should have handled the setup of said instance.
[15:07] <blackboxsw> If, for some reason the instance-id wasn't changed on the newly created instance, cloud-init would remain completely inert on that final boot
[16:34] <esv> and is that a bug?
[16:57] <esv> hey folks, a customer is trying to install libaws-bin which depends on libasis2019, but they an error message saying it won't get installed, also it says: E: Broken packages
[16:58] <esv> could a install with --force work? any workarounds? 
[17:04] <Odd_Bloke> esv: Which Ubuntu release?  And what's the full error message?
[17:31] <esv> it's 2 packages, so I'm going to paste the output for one.
[17:33] <esv> https://pastebin.ubuntu.com/p/8gkJzVzC29/
[18:20] <Odd_Bloke> esv: I thought the problem was installing libaws-bin?  (And, again, which Ubuntu release?)
[18:28] <esv> 20.04 get the same message for both pkgs 
[18:42] <sarnold> hah does apt upgrade actually take arguments like that?
[18:50] <genii> sarnold: Nope