[Bug 1895131] Re: Groovy Desktop *BREAKS* the most common method of creating UEFI bootable drives for Ubuntu installation

[sudodus]

@Akeo,

I have seen the problem that you address in this bug report, and I was
afraid that it may cause problems for you[r tool] and others who use
extracting methods. Thanks for speaking out load about it.

There is an additional problem too, that some computers do not even boot
from cloned drives in UEFI mode (See https://bugs.launchpad.net/ubuntu-
cdimage/+bug/1886148/comments/65 and the following comments).

@C.S.Cameron,

I have managed to loop mount the latest Groovy daily iso files (both in
BIOS mode and UEFI mode) and make it boot. But it seems that I have not
made that process work in all possible cases yet ...

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

Title:
  Groovy Desktop *BREAKS* the most common method of creating UEFI
  bootable drives for Ubuntu installation

Status in casper package in Ubuntu:
  Confirmed

Bug description:
  As opposed to 20.04, Groovy Desktop decided to do away with the EFI
  boot files that used to reside in `/EFI/BOOT/` on the ISO, and instead
  moved them away into a FAT image located at /boot/grub/efi.img.

  While this works fine when writing the image in DD mode, it completely
  **BREAKS** the common method, used by many many users on Windows,
  MacOS and other platforms, of simply formatting a USB drive to FAT32
  and then copying the whole ISO content there in order to create a UEFI
  bootable Ubuntu installation media.

  Please bear in mind that this method of creating UEFI boot media is favoured by many on account that:
  * It doesn't require the installation of third party software like balenaEtcher or Rufus to create the media, especially on Windows
  * It is less risky to use than dd, on account that it's less prone to making a mistake with regards to the target disk. Especially, not everyone has access to 'dd', or is familiar enough with it, or even wants to use it if there exists an alternative that lets them access the content of their drive (e.g. on Windows).
  * It leverages the *NATIVE* ability of UEFI to pick a bootloader from /EFI/BOOT/ which was introduced precisely to make the creation of bootable media through third party utilities (including dd) a thing of the past.

  So, let me start by giving a stern warning here:

  UBUNTU PEOPLE, BY HIDING THE EFI BOOT FILES AWAY IN THE ISO, YOU ARE
  **NOT** HELPING YOUR USERS. INSTEAD, YOU ARE ACTIVELY **DEGRADING**
  THE USER INSTALLATION EXPERIENCE. PLEASE DON'T DO THAT!

  My questions therefore are twofold:

  1. What on earth was the rationale behind this move? What exactly is
  to be gained here?? Ubuntu 20.4 was perfectly fine with the GRUB boot
  files in /EFI/BOOT/ on the ISO file system structure, and, as pointed
  out above, it's hard to see how hiding these files away in efi.img is
  going to improve user experience when this breaks the simplest method
  of creation of a UEFI bootable media. So what prompted this sudden
  unwarranted change, and why didn't anybody realize that this would
  make the Ubuntu media creation experience subpar in terms of UEFI
  install?

  2. Can this change please, please, **PLEASE**, be reverted? I know
  that drinking the ISOHybrid kool-aid and putting your eggs into one
  basket by declaring that `dd` is now the "one true way" of creating
  UEFI bootable media is very seducing from a maintainer's perspective.
  But don't remove features that helped foster the image of Ubuntu being
  focused on user-friendliness, and that are **ACTUALLY** used by more
  people than you realize. Else you may find that a move that actively
  prevents people from installing Linux in a manner they've been using
  for years, and that really has no reason to be broken because it's
  what UEFI was designed for, will be percieved as a **STRONG
  INDICATION** that Ubuntu is no longer caring about its users...

  Thank you.

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