[PATCH 0/3] Add support for EFI file system transposition

[PATCH 0/3] Add support for EFI file system transposition

[Pete Batard]

Hello everyone,

This series of patches adds file system transposition support, for UEFI boot media created with grub-mkrescue.

File system transposition means the ability to take the content of a UEFI bootable media and copy it, at the file system level, to a partition that was independently created and formatted by the user, while preserving the ability of the media to boot in UEFI mode.

We see this as a much needed improvement to GRUB when one of the core concept of EFI is to do away with the requirement to have to create boot media at the block level, one of the major pain points of BIOS systems' users.

Currently, grub-mkrescue fails to meet the goal of UEFI file system transposition on 3 accounts:

1. It does not include file system support for FAT or NTFS, whereas these are the native file systems supported by UEFI (with FAT being mandatory per UEFI specs, and with NTFS being found more and more commonly on x64 commodity hardware such as, from my direct experience, about any motherboards that has been produced by ASUS, Gigabyte or Intel in the past 10 years).

2. It uses a efi.img to embed the UEFI bootloaders, but does not keep a copy of these bootloaders on the ISO9660 file system itself, with the end result that, when copying the media at the file system level, the '/efi/boot/' directory and its content is missing.

3. It relies on volume UUID to locate the boot media, a method that does not survive transposition when the content is copied to a newly user-created partition.

The following patches fix each one of these issues. More specifically:

1. Adding fat and ntfs support can easily be added as additional modules and, considering that these are file systems natively supported on commonplace UEFI hardware, the benefits vastly outweighs the very limited increase in size.

2. Duplicating the 'efi.img' bootloaders onto the ISO9660 file system is also easily accomplished by dropping the use of a temporary directory to generate the 'efi.img' and instead moving copying that content to the ISO9660 root level. At this stage, we will point out that we consider it should really be the job of xorriso, rather than grub-mkrescue, to accomplish this duplication (hence why I am CC'ing Thomas), but we don't know the technical difficulties that result from trying to map back the content of a FAT image back onto the ISO9660 structure. There again, in terms of increase in size, we see the cost/benefit ratio as non issue.

3. Searching for the boot media is now be carried by looking for a '/.disk/<TIMEBASED_UUID>.uuid' file rather than an actual partition UUID, as real world usage does show that relying on specific labels or UUIDs being assigned to specific partitions is actually a brittle solution. Note that we only carry out these alterations for EFI boot, and don't modify the existing BIOS/Legacy media search method. It should also be noted that the reason we chose a '.disk/' directory to place the UUID file is because '.disk/' has become a de-facto standard to place disk related content for Debian and Ubuntu, which, in the fragmented world of Linux distribution, is as good as a standard as you can get. We did briefly consider using '/System/', but decided against it as this latter directory is geared towards MacOS usage, and we see going with a more generic dot directory as a better approach. We have validated that, if the added content already contains a '.disk/' directory, then our new '.disk/#####.uuid' file does get properly merged with that content.

With these limited changes, grub-mkrescue can now be used to produce media that properly survives file system transposition, thereby satisfying one of the implicit goals of EFI of allowing end-users to carry out the creation of bootable EFI media at the file system level exclusively.



Now, because this is relevant to this patchset (it's pretty much the motivation behind it), and because it is my understanding that some of the people creating ISOHybrid boot media, especially if they are using UNIX derivatives as their main work environments, are not always aware of the issues that arise from treating ISOHybrid as a glorified dd image, I will use this opportunity to elaborate on issues that arise from dealing with ISOHybrid media that lacks support for file system transposition.

But first I should point out that these notes should not be construed as criticism of ISOHybrid per se, as we very much recognise the great benefits of ISOHybrid and the major technical achievements that went into it. We however do see it as important to try to debunk the idea that, once you have an ISOHybrid image that works well for both dd and optical, your job is done and remind people who place their trust in ISOHybrid image that, for the reasons highlighted below, having a working dd image is only half the job.

And so, without further ado:

* One massive real-world problem, that Linux-oriented people tend to ignore, is that for the most widely used Operating System out there (Windows) the "ISOHybrid = dd" approach is a *MASSIVE* pain point for users, on account that the resulting media is either something that Windows will not mount, or only mount the ESP of, with the direct result that a fait amount of users assume that their media was not properly created and, therefore, don't even try to boot it. I genuinely cannot stress enough how this is far from being a limited problem, or something that one should feel entitled to ask Windows users to "just plow through". See for instance [1], [2], [3], [4], [5], [6], [7], [8], [9], [10], [11], [12] if you need some convincing of this, knowing that I could easily add a dozen more refs, and that I didn't have to look further than a couple days ago to find a recent one [4]. Thus, one of the results of *restricting* the creation of ISOHybrid media on Windows, through the use of block copy only, is that this will result in many users having a very poor first time experience of your ISOHybrid-contained software...

* Having a file system transposable UEFI media does open the door to some very desirable usage, such as single media OS installation (See for instance the installation of vanilla Debian on Pi 4 using a single media as installer and target [13]), which can be critical for of users of SoC based systems that do not have the luxury or resources to run to their (not-always-so-local) corner shop in order to buy another flash drive. Currently, I don't really see dd-written ISOHybrid media being able to provide that kind of feature whereas it is easy envision all kind of other scenarios where file system transposition can be a boon for users, such as allowing the copying of non-free WiFi firmware blobs onto the boot media, in order to be able to proceed with a networked installation...

* Formatting a partition, and even repartitioning a drive, is typically a lot less error prone for non tech-savvy users than using a dd like utility, in terms of preventing the erasure of the wrong disk. This is especially true on non Linux platforms where GUI tools or context menus will usually guide the user into selecting the appropriate target.

* dd writing a GPT-based ISOHybrid media does result in a disk that has an invalid backup GPT, on account that one never has a media that is the exact same size as the original image, thereby resulting in garbage residing in the last 33 sectors of the disk. Some pedantic UEFI firmwares, as well as some ill-programmed OSes (e.g. Windows 7 will BSOD on this) may take objection to an improper backup GPT...

* As mentioned earlier, one of the established goals of EFI was to get rid of the requirement to write any parts of a media at the block level to make it bootable. As such, it has been quite surprising to see a lot of the proponents of ISOHybrid to push for a complete 180 on this goal, by enforcing the use of block level tools. This is even more problematic as, for Windows users, this means installation of third-party software, which some users may rightfully take objection to, in terms of not adding potential holes into a trust chain that is critical for OS installation.

* Finally, there's really no reason why GRUB (and by extension Linux) boot media should remain inferior to Windows boot media in that respect, since Windows images have been designed to support EFI file system transposition for years. Thankfully, some major Linux distributions, such as Debian, Ubuntu and (for the most part) Arch, have grasped the importance of file system transposition for their ISOHybrid media, and are making a concerted effort to support it. But we do feel that it should very much have been the job of GRUB to lead the way in that respect.

Regards,

/Pete


[1] https://old.reddit.com/r/linuxquestions/comments/j4nolf/creating_a_bootable_usb_drive_for_linux
[2] https://old.reddit.com/r/ManjaroLinux/comments/gofq71/problem_with_rufus_310_and_manjaro_2001
[3] https://old.reddit.com/r/ManjaroLinux/comments/gjdpi4/cannot_create_bootable_usb_usb_size_shrinks_after
[4] https://old.reddit.com/r/Proxmox/comments/v2en1r/proxmox_couldnt_find_iso_before_launching_setup/iarz6hb/?context=3
[5] https://old.reddit.com/r/techsupport/comments/499b5c/usb_stick_capacity_shrunk_to_2mb
[6] https://superuser.com/questions/752874/16-gb-usb-flash-drive-capacity-down-to-938-mb
[7] https://forums.tomshardware.com/threads/usb-flash-drive-8gb-is-now-only-1gb.660997/
[8] https://www.eassos.com/blog/how-to-restore-usb-drive-back-to-full-capacity
[9] https://www.easeus.com/partition-master/fix-usb-drive-incorrect-size.html
[10] https://www.quora.com/After-making-my-32-GB-pen-drive-Kali-Linux-bootable-its-size-reduced-to-712-KB-Is-it-normal-If-not-then-how-can-I-fix-it
[11] https://askubuntu.com/questions/289971/usbs-storage-capacity-reduced-to-2-mb-from-16-gb
[12] https://askubuntu.com/questions/611325/capacity-of-pen-drive-shown-is-less-than-the-actual
[13] https://forums.raspberrypi.com/viewtopic.php?f=50&t=282839


Pete Batard (3):
  grub-mkrescue: Add support for FAT and NTFS on EFI boot
  grub-mkrescue: Preserve a copy of the EFI bootloaders on the ISO9660
    file system
  grub-mkrescue: Search by file UUID file rather than partition UUID for
    EFI boot

 util/grub-mkrescue.c | 60 ++++++++++++++++++++++++++++++++++----------
 1 file changed, 47 insertions(+), 13 deletions(-)

-- 
2.36.0.windows.1

[PATCH 1/3] grub-mkrescue: Add support for FAT and NTFS on EFI boot

[Pete Batard]

In order to add file system transposition support for UEFI, i.e. the ability
to copy the content of an ISO9660 grub-mkrescue ISO image onto user-formatted
media, and have that boot on UEFI systems, the first thing we need to do is
add support for the file systems that are natively handled by UEFI.
This mandatorily includes FAT and we also include NTFS as the latter is also
commonly supported on modern x64 platforms.

Signed-off-by: Pete Batard <pete@akeo.ie>
---
 util/grub-mkrescue.c | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/util/grub-mkrescue.c b/util/grub-mkrescue.c
index ba89b1394..1257476fb 100644
--- a/util/grub-mkrescue.c
+++ b/util/grub-mkrescue.c
@@ -754,6 +754,9 @@ main (int argc, char *argv[])
 
       grub_install_push_module ("part_gpt");
       grub_install_push_module ("part_msdos");
+      grub_install_push_module ("fat");
+      /* Many modern UEFI systems also have native support for NTFS */
+      grub_install_push_module ("ntfs");
 
       imgname = grub_util_path_concat (2, efidir_efi_boot, "bootia64.efi");
       make_image_fwdisk_abs (GRUB_INSTALL_PLATFORM_IA64_EFI, "ia64-efi", imgname);
@@ -831,6 +834,8 @@ main (int argc, char *argv[])
       free (efidir);
       grub_install_pop_module ();
       grub_install_pop_module ();
+      grub_install_pop_module ();
+      grub_install_pop_module ();
     }
 
   grub_install_push_module ("part_apple");
-- 
2.36.0.windows.1

[PATCH 2/3] grub-mkrescue: Preserve a copy of the EFI bootloaders on the ISO9660 file system

[Pete Batard]

To enable file system transposition support for UEFI, we also must ensure that
there exists a copy of the EFI bootloaders, that are currently embedded in the
efi.img for xorriso, at their expected UEFI location on the ISO9660 file system.

This is accomplished by removing the use of a temporary directory to create the
efi/ content, to instead place it at the root of the ISO9660 content.

Signed-off-by: Pete Batard <pete@akeo.ie>
---
 util/grub-mkrescue.c | 8 +++-----
 1 file changed, 3 insertions(+), 5 deletions(-)

diff --git a/util/grub-mkrescue.c b/util/grub-mkrescue.c
index 1257476fb..4596f0ea7 100644
--- a/util/grub-mkrescue.c
+++ b/util/grub-mkrescue.c
@@ -745,9 +745,8 @@ main (int argc, char *argv[])
       || source_dirs[GRUB_INSTALL_PLATFORM_RISCV32_EFI]
       || source_dirs[GRUB_INSTALL_PLATFORM_RISCV64_EFI])
     {
-      char *efidir = grub_util_make_temporary_dir ();
-      char *efidir_efi = grub_util_path_concat (2, efidir, "efi");
-      char *efidir_efi_boot = grub_util_path_concat (3, efidir, "efi", "boot");
+      char *efidir_efi = grub_util_path_concat (2, iso9660_dir, "efi");
+      char *efidir_efi_boot = grub_util_path_concat (3, iso9660_dir, "efi", "boot");
       char *imgname, *img32, *img64, *img_mac = NULL;
       char *efiimgfat;
       grub_install_mkdir_p (efidir_efi_boot);
@@ -828,10 +827,9 @@ main (int argc, char *argv[])
       xorriso_push ("-efi-boot-part");
       xorriso_push ("--efi-boot-image");
 
-      grub_util_unlink_recursive (efidir);
+      /* Don't unlink the efidir_efi_boot directory so that we have a duplicate on the ISO9660 file system. */
       free (efiimgfat);
       free (efidir_efi);
-      free (efidir);
       grub_install_pop_module ();
       grub_install_pop_module ();
       grub_install_pop_module ();
-- 
2.36.0.windows.1

[PATCH 3/3] grub-mkrescue: Search by file UUID file rather than partition UUID for EFI boot

[Pete Batard]

The final piece we need to add file system transposition support for UEFI
is to ensure that we can locate the boot media regardless of how the boot
partition was instantiated. Especially, we do not want to be reliant on
brittle partition UUIDs, as these only work if a boot media is duplicated at
the block level and not at the file system level.

To accomplish this for EFI boot, we now create a UUID file in a .disk/
directory, that we can then search for.

Signed-off-by: Pete Batard <pete@akeo.ie>
---
 util/grub-mkrescue.c | 47 ++++++++++++++++++++++++++++++++++++--------
 1 file changed, 39 insertions(+), 8 deletions(-)

diff --git a/util/grub-mkrescue.c b/util/grub-mkrescue.c
index 4596f0ea7..b7a387d8b 100644
--- a/util/grub-mkrescue.c
+++ b/util/grub-mkrescue.c
@@ -261,7 +261,26 @@ make_image_abs (enum grub_install_plat plat,
   load_cfg = grub_util_make_temporary_file ();
 
   load_cfg_f = grub_util_fopen (load_cfg, "wb");
-  fprintf (load_cfg_f, "search --fs-uuid --set=root %s\n", iso_uuid);
+  /* 
+   * A UEFI bootable media should support file system transposition (e.g. extracting
+   * an ISO9660 content to a FAT32 media that was formatted by the user). Therefore,
+   * for EFI platforms, we search for a specific UUID file rather than a partition UUID.
+   */
+  switch (plat)
+    {
+      case GRUB_INSTALL_PLATFORM_I386_EFI:
+      case GRUB_INSTALL_PLATFORM_X86_64_EFI:
+      case GRUB_INSTALL_PLATFORM_IA64_EFI:
+      case GRUB_INSTALL_PLATFORM_ARM_EFI:
+      case GRUB_INSTALL_PLATFORM_ARM64_EFI:
+      case GRUB_INSTALL_PLATFORM_RISCV32_EFI:
+      case GRUB_INSTALL_PLATFORM_RISCV64_EFI:
+	fprintf (load_cfg_f, "search --set=root --file /.disk/%s.uuid\n", iso_uuid);
+	break;
+      default:
+	fprintf (load_cfg_f, "search --fs-uuid --set=root %s\n", iso_uuid);
+	break;
+    }
   fprintf (load_cfg_f, "set prefix=(${root})/boot/grub\n");
 
   write_part (load_cfg_f, source_dirs[plat]);
@@ -745,10 +764,11 @@ main (int argc, char *argv[])
       || source_dirs[GRUB_INSTALL_PLATFORM_RISCV32_EFI]
       || source_dirs[GRUB_INSTALL_PLATFORM_RISCV64_EFI])
     {
+      FILE *f;
       char *efidir_efi = grub_util_path_concat (2, iso9660_dir, "efi");
       char *efidir_efi_boot = grub_util_path_concat (3, iso9660_dir, "efi", "boot");
       char *imgname, *img32, *img64, *img_mac = NULL;
-      char *efiimgfat;
+      char *efiimgfat, *iso_uuid_file, *diskdir, *diskdir_uuid;
       grub_install_mkdir_p (efidir_efi_boot);
 
       grub_install_push_module ("part_gpt");
@@ -757,36 +777,47 @@ main (int argc, char *argv[])
       /* Many modern UEFI systems also have native support for NTFS */
       grub_install_push_module ("ntfs");
 
+      /* Create a '.disk/<TIMEBASED_UUID>.uuid' file that can be used to locate the boot media. */
+      diskdir = grub_util_path_concat (2, iso9660_dir, ".disk");
+      grub_install_mkdir_p (diskdir);
+      iso_uuid_file = xasprintf ("%s.uuid", iso_uuid);
+      diskdir_uuid = grub_util_path_concat (2, diskdir, iso_uuid_file);
+      f = grub_util_fopen (diskdir_uuid, "wb");
+      fclose (f);
+      free (iso_uuid_file);
+      free (diskdir_uuid);
+      free (diskdir);
+
       imgname = grub_util_path_concat (2, efidir_efi_boot, "bootia64.efi");
       make_image_fwdisk_abs (GRUB_INSTALL_PLATFORM_IA64_EFI, "ia64-efi", imgname);
       free (imgname);
 
       grub_install_push_module ("part_apple");
       img64 = grub_util_path_concat (2, efidir_efi_boot, "bootx64.efi");
-      make_image_fwdisk_abs (GRUB_INSTALL_PLATFORM_X86_64_EFI, "x86_64-efi", img64);
+      make_image_abs (GRUB_INSTALL_PLATFORM_X86_64_EFI, "x86_64-efi", img64);
       grub_install_pop_module ();
 
       grub_install_push_module ("part_apple");
       img32 = grub_util_path_concat (2, efidir_efi_boot, "bootia32.efi");
-      make_image_fwdisk_abs (GRUB_INSTALL_PLATFORM_I386_EFI, "i386-efi", img32);
+      make_image_abs (GRUB_INSTALL_PLATFORM_I386_EFI, "i386-efi", img32);
       grub_install_pop_module ();
 
       imgname = grub_util_path_concat (2, efidir_efi_boot, "bootarm.efi");
-      make_image_fwdisk_abs (GRUB_INSTALL_PLATFORM_ARM_EFI, "arm-efi", imgname);
+      make_image_abs (GRUB_INSTALL_PLATFORM_ARM_EFI, "arm-efi", imgname);
       free (imgname);
 
       imgname = grub_util_path_concat (2, efidir_efi_boot, "bootaa64.efi");
-      make_image_fwdisk_abs (GRUB_INSTALL_PLATFORM_ARM64_EFI, "arm64-efi",
+      make_image_abs (GRUB_INSTALL_PLATFORM_ARM64_EFI, "arm64-efi",
 			     imgname);
       free (imgname);
 
       imgname = grub_util_path_concat (2, efidir_efi_boot, "bootriscv32.efi");
-      make_image_fwdisk_abs (GRUB_INSTALL_PLATFORM_RISCV32_EFI, "riscv32-efi",
+      make_image_abs (GRUB_INSTALL_PLATFORM_RISCV32_EFI, "riscv32-efi",
 			     imgname);
       free (imgname);
 
       imgname = grub_util_path_concat (2, efidir_efi_boot, "bootriscv64.efi");
-      make_image_fwdisk_abs (GRUB_INSTALL_PLATFORM_RISCV64_EFI, "riscv64-efi",
+      make_image_abs (GRUB_INSTALL_PLATFORM_RISCV64_EFI, "riscv64-efi",
 			     imgname);
       free (imgname);
 
-- 
2.36.0.windows.1

Re: [PATCH 0/3] Add support for EFI file system transposition

[Thomas Schmitt]

Hi,

Pete Batard wrote:
> 2. It uses a efi.img to embed the UEFI bootloaders, but does not keep a copy
> of these bootloaders on the ISO9660 file system itself, with the end result
> that, when copying the media at the file system level, the '/efi/boot/'
> directory and its content is missing.

I understand why this is desirable for the use case of preparing a
grub-mkrescue USB stick on MS-Windows.
Insofar i support the duplication of the FAT image content in the ISO 9660
filesystem.


> we will point out that we consider it
> should really be the job of xorriso, rather than grub-mkrescue, to
> accomplish this duplication (hence why I am CC'ing Thomas), but we don't
> know the technical difficulties that result from trying to map back the
> content of a FAT image back onto the ISO9660 structure.

xorriso would have to learn to unpack FAT filesystems. But FAT is not
really the topic of xorriso.
Given that the FAT filesystem is freshly composed by grub-mkrescue from a
readily prepared file tree on disk, i deem it more straightforward that
grub-mkrescue simply tells xorriso to put this tree into the ISO.

Either implicitely by having it in iso9660_dir (as patch [2/3] proposes)
or explicitely by a pathspec (like /efi=...temporary.disk.path...).
In the latter case the temporary disk file tree has to survive until the
xorriso run is finished.


Have a nice day :)

Thomas

Re: [PATCH 0/3] Add support for EFI file system transposition

[Pete Batard]

Hi Thomas. Thanks for replying.

On 2022.06.07 08:16, Thomas Schmitt wrote:
>> we will point out that we consider it
>> should really be the job of xorriso, rather than grub-mkrescue, to
>> accomplish this duplication (hence why I am CC'ing Thomas), but we don't
>> know the technical difficulties that result from trying to map back the
>> content of a FAT image back onto the ISO9660 structure.
> 
> xorriso would have to learn to unpack FAT filesystems. But FAT is not
> really the topic of xorriso.
> Given that the FAT filesystem is freshly composed by grub-mkrescue from a
> readily prepared file tree on disk, i deem it more straightforward that
> grub-mkrescue simply tells xorriso to put this tree into the ISO.

I agree that, in the case of grub-mkrescue, not having FAT unpacking in 
xorriso is not a major problem because we can easily sort it out.

My concern however lies with usage of xorriso outside the context of 
grub-mkrescue (so maybe part of this discussion is off-topic), where 
folks are going to be creating non GRUB based EFI ISOHybrid boot media, 
and use an efi.img as part of it on account that they've seen other 
projects do it, without realizing that they too should duplicate the 
efi.img content.

One example I have in mind is Solus, which is Syslinux based (or at 
least was Syslinux based last time I checked) with an efi.img based 
ISOHybrid, and where what we're doing for GRUB won't help.

So I do feel that xorriso will have to bite the bullet eventually and 
make sure that it unpacks the content of efi.img on its own.

Now, if you do agree with this general idea, then I *may* send you a 
patch, since I'm doing something similar in Rufus [1] (precisely on 
account that xorriso is not unpacking the content onto the ISO9660 file 
system structure, and I have to compensate for it). If I do that 
however, I should point out that this code will be based primarily on 
Syslinux's libfat [2] and also that, since it'll probably be a while 
before I do, we're still going to need that GRUB patch in the interim...

> Either implicitely by having it in iso9660_dir (as patch [2/3] proposes)
> or explicitely by a pathspec (like /efi=...temporary.disk.path...).
> In the latter case the temporary disk file tree has to survive until the
> xorriso run is finished.

I guess I'll let the GRUB project maintainers decide which of these 2 
approach they like best. I can amend my patchset if needed.

Regards,

/Pete

[1] 
https://github.com/pbatard/rufus/blob/746f91acc769b2b5b4ad44a31a1aa70e5619ae57/src/iso.c#L1531-L1663
[2] https://github.com/pbatard/rufus/tree/master/src/syslinux/libfat

Re: [PATCH 2/3] grub-mkrescue: Preserve a copy of the EFI bootloaders on the ISO9660 file system

[Thomas Schmitt]

Hi,

On Mon,  6 Jun 2022 17:50:32 +0100, Pete Batard <pete@akeo.ie> wrote:
> To enable file system transposition support for UEFI, we also must ensure that
> there exists a copy of the EFI bootloaders, that are currently embedded in the
> efi.img for xorriso, at their expected UEFI location on the ISO9660 file system.
>
> This is accomplished by removing the use of a temporary directory to create the
> efi/ content, to instead place it at the root of the ISO9660 content.
>
> Signed-off-by: Pete Batard <pete@akeo.ie>

Reviewed-by: Thomas Schmitt <scdbackup@gmx.net>
Tested-by: Thomas Schmitt <scdbackup@gmx.net>


I reviewed (modulo style aspects) and applied the patch [2/3] to a freshly
pulled grub-mkrescue.c . It compiles and produces (on Debian) an ISO with:

  grub/grub-mkrescue -d /usr/lib/grub/x86_64-efi \
                     --locale-directory=/usr/share -o test.iso minimal

(It would be more realistic if i knew how the Debian binary of grub-mkrescue
 knows that there is also /usr/lib/grub/i386-pc and combines it with
 x86_64-efi. If i use two -d options, then the latter overrides the former.)

Whatever, the resulting test.iso has EFI boot equipment of the same size as
the ISO from Debian's grub-mkrescue with the same arguments as above.
Different than with Debian's binary, there is now a directory tree /efi in
the ISO with 146 KiB of storage space (measured by xorriso -dus).


Have a nice day :)

Thomas

Re: [PATCH 0/3] Add support for EFI file system transposition

[Michael Schierl]

Hello Pete et al,


Am 06.06.2022 um 18:50 schrieb Pete Batard:
> Hello everyone,
>
> This series of patches adds file system transposition support, for UEFI boot media created with grub-mkrescue.
>
> File system transposition means the ability to take the content of a UEFI bootable media and copy it, at the file system level, to a partition that was independently created and formatted by the user, while preserving the ability of the media to boot in UEFI mode.
>
> We see this as a much needed improvement to GRUB when one of the core concept of EFI is to do away with the requirement to have to create boot media at the block level, one of the major pain points of BIOS systems' users.


I fully agree to these efforts, yet for a different reason.


It happens from time to time that I am (without any preparation) asked
to fix somebody else's computer (which probably does not boot or there
is another problem to use it for accessing the internet). In that case,
I always have a USB flash drive in my wallet that is USB2go capable
(i.e. has a second plug to connect to my smartphone) which is
partitioned as a single large FAT32 partition full of rescue tools
(acting as ESP) and some magic to be able to use some of the tools also
when booting in BIOS mode. Most of the tools are selectable from my GRUB
boot menu (secure boot capable, of course), yet some depend on specific
file names on the ESP, so I first need to rename some files on the
device to use them (which is not a problem as I can do this on my
Android smartphone prior to booting from the drive).

Also, sometimes while trying to help, I encounter an article about yet
another tool in the Internet, which I would like to download on my
smartphone and add to my USB drive to use right away. And here is the
caveat: To be able to do so, it either needs to come as an .iso (hybrid
or not) which is loopback.cfg bootable (i.e. has a loopback.cfg which
can be loaded from GRUB and then search the .iso on the ESP and boot
from it), or as an archive of an EFI system partition I can extract on
my smartphone (i.e. .zip or .iso) and copy to my USB drive (moving away
files that are in the way so that I can restore them afterwards).

And while lots of tools nowadays are "fit for UEFI" (unfortunately, not
so often Secure boot), finding an way to get those files on my USB drive
from my smartphone is often impossible, which means I cannot help them
right now and probably will have to do some "homework" before I meet
them next time.

Therefore, having more software that can be booted via either of the two
mentioned ways would help me as well (or other standard ways that
support the use case of adding software on demand without special apps
on an Android smartphone).


Just my 2¢,


Michael