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

Thomas Schmitt 1895131 at bugs.launchpad.net
Fri Sep 11 07:34:04 UTC 2020


Hi,

i am the developer of xorriso. If there are problems after changing
the xorriso arguments i am ready to help identifying the cause.

My own opinion about how Debain (and Ubuntu) ISOs for BIOS|EFI from CD|HDD
should look like is to see in
  https://lists.debian.org/debian-cd/2019/07/msg00007.html
(It uses ISOLINUX for BIOS, but could well use GRUB software with the
appropriate xorriso options for GRUB MBR code. Its main theme is to abandon
the hacky layout with invalid GPT that was introduced by Fedora in 2012.)

This opinion is strictly oriented towards a single ISO that is flatly
copied to its storage medium. The trick (*) with just extracting the ISO
into a FAT filesystem is not generically supported by my proposals.
But of course it would be possible to have an unpacked copy of the
EFI System Partition in ISO directory /EFI/BOOT, so that the trick works
again.

(*) It is not specified in UEFI which demands that the EFI partition has
to be marked by type 0xEF in MBR table, or Type GUID
C12A7328-F81F-11D2-BA4B-00A0C93EC93B in GPT. But Microsoft Inc. obviously
supports this trick and thus firmware programmers will hardly disable it.

------------------------------------------------------------------------

My advise to developers of ISO post-processing software is to join forces
and to write down a specification about what they expect from a bootable
ISO which shall be subject to their activities.

I am ready to participate in discussions about such a specification.


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



More information about the foundations-bugs mailing list