=== cpaelzer__ is now known as cpaelzer
=== didrocks999 is now known as didrocks
[09:38] <LocutusOfBorg> juliank, hello, you there?
[09:38] <LocutusOfBorg> I tried to upgrade an Ubuntu 20.04 installation and got this
[09:38] <LocutusOfBorg> https://paste.ubuntu.com/p/wh7p4b7ng4/
[09:38] <juliank> LocutusOfBorg: yes
[09:39] <LocutusOfBorg> I'm pinging you because looks suspiciusly related to 1872077
[09:39] <juliank> that's suboptimal
[09:39] <LocutusOfBorg> but I have a recent grub
[09:39] <juliank> LocutusOfBorg: new disk?
[09:39] <LocutusOfBorg> mmm that usb key is not connected
[09:39] <LocutusOfBorg> it was probably connected when the system was installed
[09:40] <juliank> it should have prompted you for the missing disk, though
[09:40] <LocutusOfBorg> I run apt-get dist-upgrade, no graphics
[09:41] <LocutusOfBorg> oh well there is a grub in proposed...
[09:43] <juliank> Well it's a debconf prompt
[09:43] <xnox> i would try dpkg-reconfigure..... but not sure on which package =)
[09:44] <LocutusOfBorg> I tried dpkg-reconfigure, and failed, as well as the one in proposed
[09:45] <LocutusOfBorg> I even tried a grub-install
[09:45] <LocutusOfBorg> sudo dpkg-reconfigure grub-efi-amd64-signed
[09:45] <LocutusOfBorg> fails because not fully installed
[09:47] <LocutusOfBorg> sudo dpkg-reconfigure grub-pc does something
[09:47] <LocutusOfBorg> and dpkg-reconfigure on every grub-package seems to do mostly nothing
[09:48] <juliank> gotta dpkg --configure -a I assume
[09:48] <juliank> well dpkg --configure grub-efi-amd64-signed
[09:48] <LocutusOfBorg> fails with that error
[09:49] <LocutusOfBorg> https://paste.ubuntu.com/p/QGmQWkzPTH/
[09:49] <juliank> Set set -x to /var/lib/dpkg/grub-efi-amd64-signed.postinst and /usr/lib/grub/grub-multi-install and run it again
[09:49] <LocutusOfBorg> sorry for LANG
[09:49] <juliank> and attach a dump of debconf-get-selections | grep grub-efi
[09:50] <juliank> xnox: I wish we were using UUIDs for grub disks rather than the physical ids :/
[09:50] <juliank> Such that I can copy my disk to a new one and it still works
[09:51] <LocutusOfBorg> https://paste.ubuntu.com/p/f6DDkVckST/
[09:51] <juliank> but I just copied the existing code rather than trying to improve it :)
[09:52] <juliank> LocutusOfBorg: It seems to me like you have no ESPs on that system
[09:52] <LocutusOfBorg> I don't even know what esp is
[09:52] <juliank> The EFI system partition
[09:53] <juliank> INPUT critical grub-efi/install_devices_disks_changed
[09:53] <juliank> is skipped
[09:53] <juliank> but then it also had no choices
[09:54] <juliank> one of the partition types should be 0xef
[09:54] <juliank> a FAT partition
[09:54] <juliank> I think what you have here is a weird system with a wrong ESP
[09:54] <juliank> Like, it's a FAT partition that contains ESP contents
[09:55] <juliank> but it has the wrong partition type in the partition table
[09:55] <juliank> some systems can boot from those
[09:55] <LocutusOfBorg> here my mount https://paste.ubuntu.com/p/DkZT39kVqh/
[09:55] <cjwatson> juliank: disks don't have useful UUIDs - filesystems do
[09:56] <LocutusOfBorg> I have a /boot/efi
[09:56] <juliank> cjwatson: hmm yes, for ESPs UUIDs would work, but I copied code that installed to disks/partitions
[09:56] <juliank> LocutusOfBorg: Yes, so you selected that USB stick at one point during upgrading, and that ESP mounted to /boot/efi was migrated to the debconf database too
[09:57] <juliank> But it's not actually a proper ESP
[09:57] <cjwatson> That code was specifically designed for BIOS
[09:57] <juliank> cjwatson: I'm not sure how much it matters, though, because who copies their entire ESP?
[09:57] <juliank> :D
[09:57] <LocutusOfBorg> juliank, I did a upgrade and dist-upgrade without touching anything... do you have an hotfix?
[09:58] <juliank> LocutusOfBorg: Open fdisk, and change the paritition type of /dev/sda1 from 0xb to 0xef
[09:59] <juliank> 0xb is 32-bit FAT, 0xef is ESP (which is also 32-bit FAT, well technically a subset, but who cares)
[10:00] <LocutusOfBorg> well, it worked!!!
[10:00] <LocutusOfBorg> looks like it prompted me for the change and only one selection was available
[10:00] <LocutusOfBorg> now, let me add some background
[10:00] <LocutusOfBorg> we use systemback to install systems easily
[10:00] <juliank> cjwatson: I guess debconf skips multichoice questions with no choices?
[10:00] <LocutusOfBorg> so that might have broken with 20.04 even if really tested
[10:01] <juliank> xnox: So ... I guess we also need to show any VFAT partition on the system, not just proper ESPs
[10:02] <juliank> xnox: Because clearly LocutusOfBorg's system booted from that ESP despite it having the wrong partition type in the partition table
[10:03] <juliank> which raises more questions
[10:03] <juliank> There are hidden 32-bit, hidden 16-bit, and of course 16-bit FAT partitions
[10:03] <juliank> and some more strange partition types
[10:03] <juliank> i found this list https://thestarman.pcministry.com/asm/mbr/PartTypes.htm
[10:04] <juliank> Maybe we need to look at the file system
[10:04] <juliank> rather than the partition
[10:04] <juliank> At least, if that's been a choice previously, it should be shown
[10:06] <juliank> LocutusOfBorg: Could you put the data into a bug report?
[10:06] <juliank> this clearly needs fixing
[10:06] <cjwatson> juliank: Uh, I don't remember.  Do you need me to dig?
[10:07] <juliank> cjwatson: Nah, i was just curious a bit
[10:07] <cjwatson> "Unlike select lists, multiselect questions are visible if there is just one choice."
[10:07] <cjwatson> say the docs
[10:07] <juliank> right, we had no choices at all here which is not a useful choice to have :D
[10:08] <juliank> But that means I miss a prompt for systems that have no suitable partition
[10:08] <cjwatson> They're actually visible if there are zero choices, which seems to me to be a possible bug
[10:08] <juliank> Like "Your system does not have a suitable EFI system partition. Cannot continue."
[10:08] <juliank> Though
[10:08] <juliank> Hmm
[10:08] <juliank> It should ask the _empty question
[10:09] <cjwatson> Oh of course, multiselect obviously has to be visible with one choice because multiselect is more like a set of checkboxes than a radio button or whatever
[10:09] <juliank> yup
[10:09] <juliank> So I need to see why the code never prompted grub-efi/install_devices_empty despite there being no disks found
[10:10] <juliank> Ah
[10:10] <juliank> hmm
[10:18] <LocutusOfBorg> juliank, against which package?
[10:18] <LocutusOfBorg> grub2 right?
[10:18] <juliank> LocutusOfBorg: grub2
[10:18] <LocutusOfBorg> ack, affecting groovy and focal
[10:18] <juliank> yeah
[10:19] <LocutusOfBorg> I'll point this link to the bug report
[10:19] <LocutusOfBorg> https://irclogs.ubuntu.com/2020/10/12/%23ubuntu-devel.html
[10:21] <juliank> LocutusOfBorg: Helpfully it's the first discussion today, even :D
[10:21] <LocutusOfBorg> it is :D
[10:22] <LocutusOfBorg> #1899462
[10:25] <LocutusOfBorg> LP: #1899462
[10:25] <ubottu> Launchpad bug 1899462 in grub2 (Ubuntu Groovy) "grub2, cannot upgrade due to EFI partition type mismatch" [High,New] https://launchpad.net/bugs/1899462
[10:31] <juliank> LocutusOfBorg: thanks
[10:31] <LocutusOfBorg> thanks to you for the great help!
[10:31] <LocutusOfBorg> I admit this seems a serious bug to me, it prevents upgrades...
[10:32] <juliank> ack
[10:33] <juliank> It affects a few people
[10:33] <juliank> But it's obviously not a problem for most
[10:33] <LocutusOfBorg> I don't know if the system was still bootable after this "incomplete upgrade"
[10:33] <LocutusOfBorg> this is why I just set up high severity
[10:33] <juliank> It probably was, yes
[10:33] <LocutusOfBorg> oh this is less worrysome then :P
[10:34] <juliank> The EFI binaries are single binaries, they don't need external modules, and will continue to work if not updated
[10:34] <juliank> Well, except the new shim does not trust old grubs
[10:34] <juliank> um
[10:34] <juliank> old grubs were revoked
[15:01] <seb128> bdmurray, hey, did you have any chance to poke at the retracers issue on 20.10?
=== _hc[m] is now known as _hc
[15:15] <bdmurray> seb128: A little bit and then I discovered an issue with the Launchpad retracers which I sorted out. I'll look more at the Error Tracker ones today.
[15:25] <seb128> bdmurray, thanks
[15:27] <seb128> bdmurray, do buckets with a failed retrace get stucked on the status until someone reset them or something or do they keep trying to retrace new reports until they get a successful backtrace?
[15:29] <bdmurray> seb128: They keep retrying for 20.10 as of last week or so - I'd missed that.
[15:31] <bdmurray> seb128: I do see a lot more "Create" links on the errors.ubuntu.com page for 20.10
[15:32] <seb128> bdmurray, right, still not for the top of the list though, still somewhat weird
[15:34] <bdmurray> yeah, gnome-shell has quite a few failures