Comment 9 for bug 1962470

I've tried to reproduce this problem in a VirtualBox VM, with no succcess. My suspicion is that there's been a regression somewhere (most likely in GRUB 2 or the Linux kernel) that's causing partial incompatibility with the older UEFI version used on your motherboard, Michael. I say "partial incompatibility" because the installer medium *IS* booting, which would not be the case if the incompatibility were 100% complete. (The installer medium uses GRUB 2 and the Linux kernel, just as does the installed system.)

Most of your reports don't clearly distinguish between the boot mode (EFI/UEFI vs. BIOS/CSM/legacy) and the partition table type (GPT vs. MBR). Although EFI-mode booting is generally associated with GPT, and BIOS-mode booting with MBR, the two are not completely linked; it is possible to boot in BIOS mode from a GPT disk or in EFI mode from an MBR disk. At least one of your tests (the one with both an ESP and a BIOS Boot Partition) was probably a BIOS-mode installation to a GPT disk. It's imperative that you understand and report BOTH your boot mode AND your partition table type for understanding this problem.

Your boot mode can be determined by looking at /sys/firmware. If that directory has a subdirectory called "efi", then you've booted in EFI mode; if not, then you've booted in BIOS mode (there can be other causes, but not in most normal Ubuntu boots).

Your partition table type can be determined by examining the partition table with parted or gdisk. The parted utility, when asked to show the partition table (with its "p" command), shows "Partition Table: gpt" or "Partition Table: msdos", for GPT and MBR, respectively. Using gdisk, you can type "sudo gdisk -l /dev/sda" (changing the device filename, as necessary) and look at the "MBR" and "GPT" lines under "Partition table scan." If the former reads "protective" and the latter reads "present", then the disk is a GPT disk; if the former reads "MBR only" and the latter reads "not present", then the disk is an MBR disk. (Other combinations denote a Hybrid MBR, which should be avoided; or some type of disk damage.)

I suggest you post more information on your motherboard's firmware. You can get this from dmesg output soon after booting. Try "sudo dmesg | grep -i EFI". Typically, the EFI version will show up in the first line or two of output, as in:

$ sudo dmesg | grep -i EFI
[ 0.000000] efi: EFI v2.70 by American Megatrends

If you get nothing, then either the computer has been running for too long (the information will eventually scroll out) or it's been booted in BIOS mode.

For diagnostic purposes, you might try booting in some way other than GRUB 2. Several other EFI boot loaders exist, including ELILO, SYSLINUX, and the kernel stub loader (which requires a boot manager such as rEFInd, systemd-boot, or even GRUB 2, although I believe the stock Ubuntu configuration of GRUB 2 doesn't use the stub loader). The kernel stub loader is built into the standard Ubuntu kernel. The easiest way to test booting with it is likely to be to install rEFInd (from the Ubuntu refind package); however, rEFInd does not directly support booting from XFS, so you'll need to do this from an ext4fs-based installation (or XFS for root [/] and ext4fs for /boot). ELILO and SYSLINUX will require more configuration effort -- and ELILO is pretty much a dead project at this point, AFAIK, although it could still provide useful diagnostic information. Both also require copying the kernel to the ESP. (See https://www.rodsbooks.com/efi-bootloaders/ for introductory information on using all of these tools.) Whatever you try, if you can get the computer to boot in EFI mode via a method other than GRUB 2, then it's likely that the problem is in GRUB 2; but if alternative boot loaders fail, then the problem is more likely to be in the kernel.