[09:11] <alexaf> Hello there. We are using bionic-server-cloudimg-amd64.img as provided by Ubuntu and we're experiencing a regression regarding GRUB terminal_output . We think that the issue is probably related to "grubx64.efi" bootloader binary. Given that this binary is provided as-is by the cloud image I'd like to track down how it was built. So the question: how is "grubx64.efi" built? Is there a repository
[09:11] <alexaf> tracking down changes between different releases of a cloud image? Thanks in advance.
[09:13] <alexaf> I already had a look at https://code.launchpad.net/cloud-images , but I don't think any of these repo is directly responsible for what I'm looking for
[09:16] <rbasak> alexaf: it's built by the grub2 source package
[09:17] <rbasak> alexaf: see https://launchpad.net/ubuntu/+source/grub2/+publishinghistory and https://git.launchpad.net/ubuntu/+source/grub2/log/?h=ubuntu/bionic-devel perhaps
[09:20] <alexaf> rbasak: oh okay. Will look into grub2 source package as well.
[09:21] <alexaf> rbasak: the efi binary is placed on a separate partition in cloud-images; I guess there's something creating that partition then copying over the binary there?
[09:33] <rbasak> Right
[09:41] <alexaf> rbasak: so how are these cloud-images being built?
[09:44] <rbasak> That's done by the livecd-rootfs source package I think. But this is getting towards the edge of my knowledge
[09:44] <rbasak> A cloud image is mostly just a disk image with a bunch of packages installed
[10:07] <alexaf> thanks rbasak
[10:42] <littlebit> hi people, I have question about using snap. I'm planning to install nextcloud and gitea through snap which is at first no problem but how can put both snaps, which are under different subdomains, on port 443
[11:08] <usr123> I just discovered mosh. It seems like a really good replacement for ssh. I wonder if there are any resources or books on such information, stating the tools and ways for common day to day tasks for backend developers?
[11:22] <isene> I have a badly broken letsencrypt/certbot setup. How do I unistall the whole shebang and start over? I'm on 18.04 with certbot installed via snap
[11:24] <isene> Basically, my site was only running http, I installed certbot and letsencrypt and broke the thing. Now my site is responding as it redirects to https which is misconfigured and the site is therefore not responding.
[11:27] <isene> Fixed it :-)
[11:50] <rbasak> isene: not sure how you did it, but certbot has a rollback command for exactly that situation
[12:10] <isene> rbasak: Just for future reference (in case I fuck up again) - what's the rollback command?
[12:20] <rbasak> isene: sorry I don't remember. Some argument to "certbot" IIRC. Try "certbot -h"?
[12:22] <isene> OKI
[14:36] <jamespage> icey, coreycb: can you do the initial MIR bug for python-invoke
[14:36] <jamespage> https://bugs.launchpad.net/ubuntu/+source/python-invoke/+bug/1892875
[14:36] <jamespage> then I can review
[14:39] <coreycb> jamespage: yes I'll take that
[14:39] <jamespage> ta
[15:16] <Blueking> how long time would it take to have hardware support on new amd cpu  zen3  ?
[15:19] <tomreyn> this primarily depends on how different those are from earlier architectures, and whether amd provides complete kernel patches in time.
[15:20] <tomreyn> plus the time span from when those patches are merged into mainline, and from then to when the next HWE kernel is released by canonical
[15:21] <tomreyn> Blueking: ^
[15:22] <Blueking> okey.. waiting for new amd cpu to arrive before upgrading..
[15:22] <tomreyn> well, not just 'the next HWE kernel', but 'the next HWE kernel that is based on a mainline kernel (as in >= version) that has the patches
[15:23] <tomreyn> backporting might also be possible, but unlikely.
[15:23] <Blueking> ordered motherboard with new intel ethernet chip (at that time) that ubuntu failed recognize :P
[15:24] <tomreyn> sometimes hardware producers don't provide linux support in time, and pressure is too high to go to market
[15:25] <Blueking> and I ordered this one -> https://www.icydock.com/goods.php?id=175
[15:25] <Blueking> uh wrong window
[22:29] <IngCr3at1on> hello. I'm having an issue installing ubuntu server 20.04 on a single SSD in a Dell R720XD server. Previously I had 19.10 on it for _some reason_ and decided it made more since to do a fresh install of an LTS instead of an upgrade... I'm running the installer and it's hitting `Could not set BootOrder: Invalid argument` (I had to record it on my phone cause it goes away to quick to actually read the output)
[22:30] <IngCr3at1on> Is anyone familiar with out to debug this? I can't go back to 18.04 either it would seem. Also for knowledge sake there are other drives in the server but they're all part of zpools and are not part of the installation
[22:32] <IngCr3at1on> I'm guessing it's more or less the same as https://bugs.launchpad.net/ubuntu/+source/shim-signed/+bug/1851955
[22:33] <IngCr3at1on> just not sure how to prove that since the installer doesn't really give me any fallback terminal or similar
[22:36] <sarnold> IngCr3at1on: my guess, disable CSM or Legacy in the bios
[22:38] <IngCr3at1on> it's already set to UEFI and I'm booting the USB device with the installer via the UEFI boot menu
[22:38] <IngCr3at1on> I could obviously try installing it using legacy but it would be nice if UEFI could work as it did previously just fine
[22:47] <IngCr3at1on> though since you mentioned CSM I'm curious now if the USB device is configured wrong... first time I've actually used rufus for lack of a usable linux machine lol...
[22:48] <IngCr3at1on> trying  `UEFI (non-CSM)`
[22:48] <sarnold> IngCr3at1on: the usb bootable media should cope with both legacy systems and uefi systems
[22:48] <IngCr3at1on> that's normally what I would think also but I'm running out of ideas over here lol
[22:56] <tomreyn> IngCr3at1on: is the bios up to date? usually the problem discussed in the bug report you mentioned is casued by buggy mainboard firmware.
[23:01] <IngCr3at1on> that made no difference sadly... I check tomreyn (I updated everything when I set it up previously but never know) just interesting that it was working anyway
[23:08] <tomreyn> IngCr3at1on: maybe try a cmos / nvram reset
[23:09] <tomreyn> dont do that if you have any important data stored there, though, such as hardware raid info
[23:12] <tomreyn> IngCr3at1on: also make sure you're using the ubuntu 20.04.*1* installer, not *0*, and if that still fails, use the option provided to carry out an in-place (non-persistent) subiquity (ubuntu server installer) upgrade to the latest version available.
[23:15] <tomreyn> the Dell R720XD design is eight years old, it's possible that it doesn't have a good uefi implementation, yet.
[23:37] <IngCr3at1on> tomreyn: thanks for the advice, I'm working on updating the bios and will go from there