Ubuntu Server 20.04.04 installer can't designate boot partition

Bug #1966621 reported by ebsf
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
subiquity
New
Undecided
Unassigned

Bug Description

The installer for Ubuntu Server 20.04.4 has no ability to designate an existing EFI system paretition as the boot partition.

The volume is already partitioned and has a valid 512MB EFI system partition formatted as FAT32 and with type code ef00 at /dev/sda1. The installer states that if this partition is selected as the boot partition, GRUB will be installed there. Unfortunately, the option to mount /boot is greyed out. Compounding the magnitude of the failure is that no means exists or is documented to mount boot in this partition. Obviously, the partition can't be deleted to accommodate this failure.

Expected behavior: The installer would recognize an existing formatted EFI system partition with type code ef00 as the boot partition without further configuration. The installer would go beyond saying what would happen if such a partition was designated the boot partition, to actually providing a means to make that designation, if the installer wasn't up to the task.

What happened instead: Nothing. No progress is possible because the installer can't accommodate an existing partition scheme.

Revision history for this message
Ubuntu Foundations Team Bug Bot (crichton) wrote :

Thank you for taking the time to report this bug and helping to make Ubuntu better. It seems that your bug report is not filed about a specific source package though, rather it is just filed against Ubuntu in general. It is important that bug reports be filed about source packages so that people interested in the package can find the bugs about it. You can find some hints about determining what package your bug might be about at https://wiki.ubuntu.com/Bugs/FindRightPackage. You might also ask for help in the #ubuntu-bugs irc channel on Libera.chat.

To change the source package that this bug is filed about visit https://bugs.launchpad.net/ubuntu/+bug/1966621/+editstatus and add the package name in the text box next to the word Package.

[This is an automated message. I apologize if it reached you inappropriately; please just reply to this message indicating so.]

tags: added: bot-comment
Paul White (paulw2u)
affects: ubuntu → subiquity
tags: added: focal
Revision history for this message
Heinrich Schuchardt (xypron) wrote :

The ESP is FAT formatted and therefore does not support symbolic links used for vmlinuz, vmlinuz.old, initrd.img, initrd.img.old.

Furthermore the FAT file system does not provide a log to recover if writing the kernel or initial ramdisk is interrupted.

The EFI system partition should be mounted as /boot/efi/ not as /boot.

Changed in subiquity:
status: New → Invalid
Revision history for this message
ebsf (eb-9) wrote :

@xypron thanks but your comments are unresponsive.

Kindly address the issue, which is that the installer fails.

Changed in subiquity:
status: Invalid → In Progress
Dan Bungert (dbungert)
Changed in subiquity:
status: In Progress → New
Revision history for this message
Michael Hudson-Doyle (mwhudson) wrote :

Your description definitely reads as if you are confusing /boot (where the kernel and initramfs go) and /boot/efi (where grub goes, to be read by the system firmware).

You should be able to select "Use as boot disk" from the actions for the disk when it has an existing ESP (and this will be done by default if any partition from this disk is selected to be mounted). If you can't do that can you extract the /var/log/installer/block directory? (If you're using a USB stick to install it will be stored on the USB stick in the 'writable' partition).

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.