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

[Michael Lueck]

Starting up this weekend's Live DVD of Xubuntu, I am unable to produce a system that will boot EFI mode from the hard disk.

The BIOS is configured to EFI boot mode for the disks.

This last attempt, I manually wiped the partitions from the drive before launching the installer from the LiveDVD.

Check the partition table
sudo wipefs /dev/sda

Wipe the gpd partition table
sudo wipefs -a -t gpt -f /dev/sda

Double check that the wipe was successful with the first command, came back empty / blank.

Next started the Xubuntu installer from the desktop icon.

Chose manual partitioning, created the following
sda1 500M Primary EFI Boot
sda2 remainder Primary xfs /

Once the installation got done, I opened Gparted to confirm the partitions.
The EFI partition was mounted to /target/boot/efi
The XFS partition was mounted to /target/

The EFI partition had boot, esp flags on it.

I restarted the system, shuts down, exhibits the usual with Jammy defect 1962466, I push a key to restart, system goes through BIOS screens, then lands at a black screen with blinking cursor in the top left corner.

Getting systems to boot from the hard drive is very frustrating in the era of EFI boot. :-(

[Ubuntu QA Website (ubuntuqa)]

This bug has been reported on the Ubuntu ISO testing tracker.

A list of all reports related to this bug can be found here:
http://iso.qa.ubuntu.com/qatracker/reports/bugs/1962470

[Steve Langasek (vorlon)]

Why are you doing manual partitioning in this case? If the automatic partitioning boots successfully, it does not seem like an installer bug that the manual partitions you created do not correspond and do not work.

[Michael Lueck (mlueck)]

Greetings Steve,

I prefer XFS filesystem. As much as I understand, the only way to get Ubuntu / Xubuntu to use XFS is to do manual partitioning.

With legacy partitioning, then lately (past several versions) Ubuntu has been able to boot directly from XFS. Back around 2004/5 range, it was required to have at least a small ext2 or ext3 (later) /boot partition, and the rest could be XFS for the root partition.

Now with EFI systems, I have understood that it is back to having at least two partitions... an EFI partition first, which then following may be the main XFS partition.

As much as I have understood, this above is the state of Linux booting from XFS currently.

As far as where I first booked this bug against... I had forgotten that ubiquity was actually the package name for the installer. Please accept my apologies.

[Michael Lueck (mlueck)]

All right, significant more testing... about 10 drive wipe reloads of this test system. Finally I got the Xubuntu DVD from this past weekend to produce a bootable HDD.

Some of the failed attempts were:
BIOS UEFI enabled
gpt partition table
500MB EFI partition first
All the rest XFS partition

BIOS UEFI enabled
gpt partition table
All the drive XFS partition

BIOS UEFI enabled
Let Xubuntu auto partition the entire drive... some sort of ext4 scheme, which also failed to boot.

Works - produces booting system
BIOS UEFI disabled
msdos partition table created in Gparted
All the drive XFS partition created in Gparted
The installer warned this may not produce a bootable system.... on the contrary, this finally does boot properly!

Shall next try:
BIOS UEFI disabled
gpt partition table
500MB EFI partition first
All the rest XFS partition?

I thought for sure I had success before enabling UEFI boot in the BIOS / having a gpt partition table and EFI partition... back in December. I am really puzzled why the configuration is now giving me a fight. Too late to go back now.

At least the test system boots again. I can continue on with other beta testing. Please advise what combination you would like me to try to modernize the drive partitioning beyond an msdos partition table.

[Michael Lueck (mlueck)]

This morning I reloaded the computer again, selecting gpt versus dos for the partition table. I made the EFI and XFS partitions. The installer did not protest, and the resulting system will not boot. I reloaded it back to a single xfs root partition on a dos partition table, that boots.

Something wrong with gpt partition tables all of a sudden. I use gpt partition table with Xubuntu 20.04 perfectly fine... 500MB EFI partition, the rest as root XFS. Not right that I must now revert to a dos partition table in order to get a test system to boot.

There are the steps of me setting up the gpt trial this morning:

xubuntu@xubuntu:~$ sudo wipefs /dev/sda
DEVICE OFFSET TYPE UUID LABEL
sda 0x1fe dos
xubuntu@xubuntu:~$ sudo wipefs -a -t dos -f /dev/sda
/dev/sda: 2 bytes were erased at offset 0x000001fe (dos): 55 aa
xubuntu@xubuntu:~$ sudo wipefs /dev/sda
xubuntu@xubuntu:~$ sudo apt-get install mtools
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
Suggested packages:
  floppyd
The following NEW packages will be installed:
  mtools
0 upgraded, 1 newly installed, 0 to remove and 0 not upgraded.
Need to get 201 kB of archives.
After this operation, 413 kB of additional disk space will be used.
Get:1 http://archive.ubuntu.com/ubuntu jammy/main amd64 mtools amd64 4.0.33-1+really4.0.32-1 [201 kB]
Fetched 201 kB in 1s (236 kB/s)
Selecting previously unselected package mtools.
(Reading database ... 161715 files and directories currently installed.)
Preparing to unpack .../mtools_4.0.33-1+really4.0.32-1_amd64.deb ...
Unpacking mtools (4.0.33-1+really4.0.32-1) ...
Setting up mtools (4.0.33-1+really4.0.32-1) ...
Processing triggers for install-info (6.8-4) ...
Processing triggers for man-db (2.10.1-1) ...

xubuntu@xubuntu:~$ sudo wipefs /dev/sda
DEVICE OFFSET TYPE UUID LABEL
sda 0x200 gpt
sda 0xe8e0db5e00 gpt
sda 0x1fe PMBR

[Michael Lueck (mlueck)]

Still present in Xubuntu 20220402 Daily jammy-desktop-2022-04-02-amd64.iso

This morning I pulled down the daily build, burned it to a DVD.

I began by wiping the previous partitions, allowed the installer to guide me through creating:
500 MB EFI partition
The rest XFS mounted /

No complaints from the installer.

Resulted in a non booting hard drive. :-(

Started over, wiped the disk, manually crated a msdos partition with Gparted, then a single xfs partition. Installation warned about not being able to boot the system... however this legacy way the hard drive boots perfectly.

Major new defect with Xubuntu 22.04 that is not present in Xubuntu 20.04. I partition with gpt partition table, EFI / XFS as listed above with perfect success. Something odd that 22.04 cannot handle a gpt partition table.

[Michael Lueck (mlueck)]

With the same Xubuntu 20220402 Daily jammy-desktop-2022-04-02-amd64.iso I thought to do an automatic partitioning installation. I knew I would not end up with a XFS formatted root partition, but a booting system with gpt partition table would be better than a non-booting system.

The installer created the following partitions:

sda1 1MB BIOS BOOT
sda2 500MB EFI System
sda3 1TB / ext4

So, an additional partition my working Xubuntu 20.04.2 system did not require... the 1MB BIOS BOOT partition. I had high hopes... Nope! Still will not boot from the HDD. I mentioned in my failed installation test results I would update this same defect case with the results of the failed auto partition installation attempt.

The only way I can make Xubuntu 22.04 boot on this system is to manually bring up Gparted, create a blank MSDOS partition table, and then a single 1TB / xfs partition... it boots just fine with that legacy configuration... which I do not install as the BIOS is new enough to support UEFI Smart Boot... which I have that disabled.

Test system is based on a Intel DG33BU motherboard and Intel Core 2 Duo E8500 CPU

[Michael Lueck (mlueck)]

Perhaps has the EFI / UEFI BIOS compatibility changed over time?

Finally boot success using a ThinkPad T540p model 20BE-CT01WW and the Xubuntu 20220402 Daily jammy-desktop-2022-04-02-amd64.iso

Manual partitions as follows:
sda1 1MB BIOS BOOT
sda2 500MB EFI System
sda3 the rest / xfs

So seems system specific that Xubuntu is unable to boot from the internal disk on systems it is able to boot from the LiveDVD, install without complaints.

[Rod Smith (rodsmith)]

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-bas...

[Michael Lueck (mlueck)]

Thank you, Rod!

Booted to Xubuntu 22.04 LiveDVD
BIOS has UEFI disabled

xubuntu@xubuntu:/sys/firmware$ ls -al
total 0
drwxr-xr-x 5 root root 0 Apr 23 12:32 .
dr-xr-xr-x 13 root root 0 Apr 23 12:32 ..
drwxr-xr-x 5 root root 0 Apr 23 12:33 acpi
drwxr-xr-x 3 root root 0 Apr 23 12:33 dmi
drwxr-xr-x 20 root root 0 Apr 23 12:58 memmap
xubuntu@xubuntu:/sys/firmware$ sudo dmesg | grep -i EFI
[ 0.078686] clocksource: refined-jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 7645519600211568 ns
[ 1.477833] tsc: Refined TSC clocksource calibration: 3166.306 MHz
[ 80.771346] b43-phy0 ERROR: You must go to https://wireless.wiki.kernel.org/en/users/Drivers/b43#devicefirmware and download the correct firmware for this driver version. Please carefully read all instructions on this website.
xubuntu@xubuntu:/sys/firmware$

Booted to Xubuntu 22.04 LiveDVD
BIOS has UEFI enabled

xubuntu@xubuntu:/sys/firmware$ ls -al
total 0
drwxr-xr-x 5 root root 0 Apr 23 13:07 .
dr-xr-xr-x 13 root root 0 Apr 23 13:07 ..
drwxr-xr-x 5 root root 0 Apr 23 13:08 acpi
drwxr-xr-x 3 root root 0 Apr 23 13:08 dmi
drwxr-xr-x 20 root root 0 Apr 23 13:22 memmap
xubuntu@xubuntu:/sys/firmware$ sudo dmesg | grep -i EFI
[ 0.079762] clocksource: refined-jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 7645519600211568 ns
[ 1.522877] tsc: Refined TSC clocksource calibration: 3166.310 MHz
[ 78.934879] b43-phy0 ERROR: You must go to https://wireless.wiki.kernel.org/en/users/Drivers/b43#devicefirmware and download the correct firmware for this driver version. Please carefully read all instructions on this website.
xubuntu@xubuntu:/sys/firmware$

Seems Xubuntu 22.04 release just cannot detect EFI / UEFI support within the BIOS.

The Ubuntu / Xubuntu ISO DVD's seem to be intelligent enough to boot if the BIOS has only legacy support or new EFI / UEFI support. Perhaps that is the area of Ubuntu that has the issue... that the EFI / UEFI detector fails to detect, so boots in legacy support mode?

For this system, manually partitioning off the Live DVD with Gparted, msdos partition table, one large xfs partition mounted as root.