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

[Thomas Schmitt]

Hi,

Steve Langasek wrote:
> Reading https://lists.debian.org/debian-cd/2019/07/msg00007.html was very
> helpful in clarifyingthe options needed to get the image structure we
> are looking for.

At least the ISO would comply to the specs, although this is in no way
mandatory for boot success. :))

> this does not address the /EFI/BOOT consideration at this point

Akeo has a valid point with demanding support for the method of unpacking
the ISO content to a FAT filesystem. Not only is it less dangerous than
our flat image copy onto the whole USB stick, but it is also something
that MS-Windows users are used to.

The price for having a copy of the EFI partition tree in the ISO should
be bearable.

On the other hand, this won't work with legacy BIOS (at least not without
tricky post-processing of ISOLINUX) and it invites problems with filenames.

This brings me to a question about .deb file names.
I see in
  https://packages.debian.org/sid/allpackages?format=txt.gz
that many packages have version texts with ":". Like
  a2ps (1:4.14-5 [alpha, amd64, ...
But the .deb file of a2ps does not show the "1:" part:
  http://ftp.de.debian.org/debian/pool/main/a/a2ps/a2ps_4.14-5_amd64.deb

Being a mere sponsored uplader, i fail to find the description how the
version gets transmogrified before becomming part of the .deb file name.
If it is clear that no ":" can sneak in via version, this risk about FAT
filenames would be much reduced.
(There remains the risk of stubborn package maintainers, though.)

I understand from Akeo's initial protest that currently the filenames in
Ubuntu ISOs are not an obstacle for the copy method which he defends.
Nevertheless, it would be re-assuring if there was a rule or algorithm
which prevents ":" from getting into .deb names.

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