| Description | Either intentionally or unintentionally, sometimes between 2022.x and 2023.3, the Kali ISOs introduced a regression in that it is no longer possible to use File System Transposition to create a working UEFI bootable media.
For reference, per the GRUB mailing list, File System Transposition (FST) is [1]:
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.
As described in the 'Steps To Reproduce' below, it basically means that, instead of using dd to write the Kali ISOHybrid, one should be able to just format a flash based media to FAT32, extract the content of the Kali ISO there, and use that to boot a UEFI system.
With Kali 2022.x, this method used to work just fine.
With Kali 2023.3, this no longer works, and instead the user ends up with a GRUB error prompt.
[1] https://www.mail-archive.com/[email protected]/msg34346.html |
|---|
| Additional Information | Considering that there is a non-negligible possibility that Kali maintainers may be tempted to dismiss this issue as a "Why should we care about FST? Users should only ever use dd to write a Kali ISOHybrid anway.", we feel we need to highlight the following with regards to the reason why treating ISOHybrid ISOs as glorified dd images is actually doing a disservice to people who are trying to install Linux on account that:
- Because Windows does not come with dd, Windows users are then being forced to install third-party utilities such as balenaEtcher or Rufus to write an ISOHybrid using dd, which, for a security focused distribution, is less than ideal. Part of the reason for FST is to allow the creation of media, on any base OS (Linux, Mac, Windows, *BSD) without the need to install any third party utilities.
- Writing an ISOHybrid in dd mode restricts the user's ability to edit config files. As a matter of fact, the reason we were notified about this regression is because an existing Kali user was using Rufus (which for all intent and purposes uses FST when the user elects to write an ISOHybrid image in "ISO Mode") so that they could modify their GRUB configuration to their liking.
- Writing an ISOHybrid in dd mode prevents the user from being able to copy additional files that may be critical for a successful installation, such as WiFi firmware blobs, etc. Nor everybody has two media at hand.
- A lot of Windows users are left under the impression that the media creation process did not work if it was created through dd, on account that Windows will no longer list any content on the device or make it look like it drastically reduced in size, leading them to not even attempt to try to boot the media. From my experience, this is actually a very widespread problem for first time Linux users coming from Windows.
There are also some advanced functionality that FST does provide, that DD mode cannot, such as the ability to install a Linux distro using a single media for both source and target (Which is something that is used for instance to install Debian using a single USB 3.0 drive on SBC based devices such as the Raspberry Pi [2]).
All in all then, we hope that one will understand how restricting ISOHybrid creation to dd copy only is doing a disservice to users, because it deprives them of the freedom to create an installation media in the conditions that may be much more appropriate to them.
Furthermore, it also needs to be stressed out that Debian, which appears to be what Kali is based on, does make a very deliberate effort to support FST, which is why we believe that this Kali issue is an involuntary regression, since following the Debian process should produce an ISO that can work both in DD and FST mode.
As a matter of fact, it can be determined that the issue with Kali is not due to a Debian regression, as one can run the latest Debian release and testing ISOs through the steps highlighted above, to validate that FST works just fine for the Debian ISOs. Thus, this issue appears to be restricted to Kali.
Now, while I did find the GRUB source repository for Kali (and validated that it appears to closely follow what Debian does [3]), I have been unable to find public data on how the Kali UEFI GRUB bootloaders are actually being built, so my guess is that the Kali build process has somehow been altered to not include some of the necessary GRUB modules that must be embedded in the GRUB EFI executable for FST to work. At the very least, these should include part_gpt, part_msdos and vfat. And to be comprehensive, one would also want to add ntfs and exfat. These needed to be embedded, rather than provided as separate modules to load, as they are required to access the partitions and file systems where additional GRUB modules can be loaded.
Thus I hope the Kali maintainers can fix FST support, as this is a feature that existing Kali users do rely to have the freedom to customise their boot media [4] in a manner that ISOHybrid-as-dd will never provide, and not see FST support through the narrow lens of "But restricting how users can create Kali bootmedia from ISOHybrid actually makes our job easier", which, if it needs to be reiterated, is something that the GRUB development team as well as the Debian maintainers have made a conscious effort to strive away from because they have come to the realisation that supporting both DD and FST on a equal footing does benefit all users.
Thanks,
/Pete
[2] https://forums.raspberrypi.com//viewtopic.php?f=50&t=282839
[3] https://gitlab.com/kalilinux/packages/grub2/-/commits/kali/master
[4] https://github.com/pbatard/rufus/issues/2312 |
|---|
