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.

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1962470

Title:
  Jammy Live installer not producing booting gpt partition table / EFI
  partition hard drive installations

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1962470/+subscriptions


-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

Reply via email to