grub-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Daniel Kiper
Subject: Re: [PATCH v2 0/3] Add support for EFI file system transposition
Date: Tue, 20 Dec 2022 18:51:16 +0100
User-agent: NeoMutt/20170113 (1.7.2)

On Fri, Nov 25, 2022 at 05:22:14PM +0000, Pete Batard via Grub-devel wrote:
> Changes from v1:
> - Rebased against latest GRUB
> - Validated patches against coding guidelines
> - Clarified comments
>
> Note: If you are interested in testing this series, I have jolted down some 
> guidelines at:
> https://gist.github.com/pbatard/0deddbd71eefc35a3ed0b08e12a9e7e3
>
> ------------------------------------------
>
> 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 since 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 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. 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 carried out 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. We only apply 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 both Debian and Ubuntu, which, in the fragmented
> world of Linux distribution, is as good as a standard as you will 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.

For all patches Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>...

Thank you for working on this feature!

Daniel



reply via email to

[Prev in Thread] Current Thread [Next in Thread]