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

[Thomas Schmitt]

Hi,

> the EDK2/UEFI folks are more inclined to have the existing EDK2 code
> drive the specs, especially for boot, than the opposite.

It really was supposed to be the other way round this time. :))
But well, firmware is as firmware is.

As said, having a copy of the ESP tree in the ISO should be easy to
achieve and not occupy too much space, except on CD sized images, where
every MB matters.

> the naming scheme used for the ISO-9660 content needs to be more
> restrictive than what Rock-Ridge or Joliet allows, as, for instance,
> case sensitivity and special characters have to carefully considered,
> else a file name lookup that might work in an ISO-9660 environment might
> be broken for content that was extracted to FAT32/exFAT.

That might be a show stopper with Debian-ish distros. They have long package
names and there is no guarantee that filenames truncated to 8.3 are still
unique.

Mounting ubuntu-19.04-desktop-amd64.iso and doing

  for i in $(find /mnt/iso/pool) ; do basename "$i" ; done | sort | less

i get to these problematic name clusters:

  grub-efi-amd64-bin_2.02+dfsg1-12ubuntu2_amd64.deb
  grub-efi-amd64-signed_1.115+2.02+dfsg1-12ubuntu2_amd64.deb
  grub-efi-amd64_2.02+dfsg1-12ubuntu2_amd64.deb

  oem-config-gtk_19.04.9_all.deb
  oem-config-slideshow-ubuntu_146_all.deb
  oem-config_19.04.9_all.deb

With a Debian 9 amd64 DVD-1 image it is much worse because of more
packages.

Of whatever you can convince debian-cd or debian-live, the package names are
in the realm of the package maintainers.

Have a nice day :)

Thomas

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