You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Some RH/Fedora derivatives like Nobara have started using squashfs.img files that are larger than 4 GB.
However, the GRUB EFI bootloaders (/efi/boot/grubia32.efi, /efi/boot/grubx64.efi) used by these images (which I believe comes unmodified from Fedora) only includes supports for the following file systems: iso9660, fat, ext2, xfs and reiserfs.
This means that these ISO image are restricted to being written using dd only, on account that it is no longer possible to simply extract all the ISO files to a FAT32 volume (which is limited to files that are no more than 4 GB in size) and boot from such a media on a UEFI system, as was the case before. And of course, since UEFI systems do not have native support for ext2, xfs or reiserfs (and iso9660 being designed for read-only is too limited as a file system to be of much use), it is not really possible to use one of the file systems included in GRUB.
While we of course understand that using dd is the recommended method of creating boot media, we must stress out that there are some situations where using file extraction does have advantages over dd (such as for the provision of external drivers or user installation content on the same media), and, furthermore, with almost every recent motherboard from intel, ASUS, MSI, Gigabyte and other major manufacturers now including native UEFI support for NTFS as a file system, we do believe that there is a very strong case for ntfs to be included as a GRUB file system module, especially as it would solve the current issue of extracting ISO content for direct UEFI file system boot, even when that content includes a file larger than 4 GB.
As such, we formally request ntfs support to be added to GRUB (which should "just" be a matter of referencing that file system module in the existing binary creation process).
Now, obviously, since we are dealing with signed bootloaders, and, indirectly, with Secure Boot, there is some consideration to be had for the risk that adding an additional file system module to GRUB can have, especially as there have been some vulnerabilities discovered in that module in the past (that actually led to a Red Hat security advisory at https://access.redhat.com/errata/RHSA-2024:3184, which makes us wonder if the "fix" for those was for Red Hat to remove the ntfs module altogether, and that someone forgot to add it back once the vulnerabilities were fixed in GRUB). There is however no reason to believe that a module like ntfs is going to be more vulnerable than other modules GRUB file system modules like xfs or reiserfs, that are included, and furthermore, with SBAT, there exists a very solid means of addressing vulnerabilities if one is found.
Therefore, and especially, again, as modern UEFI firmware platforms do include native support for NTFS, just as they include native support for FAT, we do not believe that the a decision not to include ntfs support in GRUB (even if it may have seemed like a logically course of action at one stage), can stand in the long run, and we kindly request that NTFS support be added to the Red Hat/Fedora GRUB bootloaders.
Finally, we are making this request here, because our understanding is that GRUB related matters are dealt with the Red Hat installer team.
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
Uh oh!
There was an error while loading. Please reload this page.
-
Some RH/Fedora derivatives like Nobara have started using
squashfs.img
files that are larger than 4 GB.However, the GRUB EFI bootloaders (
/efi/boot/grubia32.efi
,/efi/boot/grubx64.efi
) used by these images (which I believe comes unmodified from Fedora) only includes supports for the following file systems:iso9660
,fat
,ext2
,xfs
andreiserfs
.This means that these ISO image are restricted to being written using
dd
only, on account that it is no longer possible to simply extract all the ISO files to a FAT32 volume (which is limited to files that are no more than 4 GB in size) and boot from such a media on a UEFI system, as was the case before. And of course, since UEFI systems do not have native support forext2
,xfs
orreiserfs
(andiso9660
being designed for read-only is too limited as a file system to be of much use), it is not really possible to use one of the file systems included in GRUB.While we of course understand that using
dd
is the recommended method of creating boot media, we must stress out that there are some situations where using file extraction does have advantages overdd
(such as for the provision of external drivers or user installation content on the same media), and, furthermore, with almost every recent motherboard from intel, ASUS, MSI, Gigabyte and other major manufacturers now including native UEFI support for NTFS as a file system, we do believe that there is a very strong case forntfs
to be included as a GRUB file system module, especially as it would solve the current issue of extracting ISO content for direct UEFI file system boot, even when that content includes a file larger than 4 GB.As such, we formally request
ntfs
support to be added to GRUB (which should "just" be a matter of referencing that file system module in the existing binary creation process).Now, obviously, since we are dealing with signed bootloaders, and, indirectly, with Secure Boot, there is some consideration to be had for the risk that adding an additional file system module to GRUB can have, especially as there have been some vulnerabilities discovered in that module in the past (that actually led to a Red Hat security advisory at https://access.redhat.com/errata/RHSA-2024:3184, which makes us wonder if the "fix" for those was for Red Hat to remove the
ntfs
module altogether, and that someone forgot to add it back once the vulnerabilities were fixed in GRUB). There is however no reason to believe that a module likentfs
is going to be more vulnerable than other modules GRUB file system modules likexfs
orreiserfs
, that are included, and furthermore, with SBAT, there exists a very solid means of addressing vulnerabilities if one is found.Therefore, and especially, again, as modern UEFI firmware platforms do include native support for NTFS, just as they include native support for FAT, we do not believe that the a decision not to include
ntfs
support in GRUB (even if it may have seemed like a logically course of action at one stage), can stand in the long run, and we kindly request that NTFS support be added to the Red Hat/Fedora GRUB bootloaders.Finally, we are making this request here, because our understanding is that GRUB related matters are dealt with the Red Hat installer team.
Thank you.
Beta Was this translation helpful? Give feedback.
All reactions