Can't make UEFI image with Kali

[neheb]

So Kali Linux recently announced support for EFI booting: http://www.kali.org/news/kali-1-0-8-released-uefi-boot-support/

I assume I have to use GPT with UEFI in Rufus to make a proper image. But it errors saying that I need an EFI bootable ISO.

Looking at the ISO, it seems to have an efi.img file under the "boot" folder which seems to differ from what Microsoft does with their Windows 8 ISOs(efi folder). There is no "efi" folder in the root directory of the kali ISO.

Is this an issue with Rufus?

[pbatard]

Looking at the ISO, it seems to have an efi.img file under the "boot" folder which seems to differ from what Microsoft does with their Windows 8 ISOs(efi folder).

Or from what the UEFI specs indicate an EFI bootable drive should provide, which (for x64 targets) is a \EFI\BOOT\bootx64.efi executable.

Kali may indicate that they support EFI boot, but if they don't have that file on their ISO, they are not EFI compliant. This is an issue with Kali.

[pbatard]

I tested that if you extract the /boot/efi.img from the ISO, you can use it with Rufus to create an EFI bootable USB. This seems to boot OK up to GUI mode, which I assume is stuck because it tries to access files that are on the ISO, and that aren't present on the .img itself.

Now, why the Kali people didn't just place the content of that .img on the ISO itself so that you'd have the /efi/boot/bootx64.efi and make that ISO dual bootable (which, by the way, tails and other distros seem to have no trouble doing) is beyond me.
And since the use of a /boot/efi.img is an entirely nonstandard way of booting, I am not planning to try to add extra code in Rufus to detect such a file and enable UEFI boot.

As this issue has nothing to do with Rufus, but with Kali having chosen to deviate from the EFI bootable specs and create their own custom incompatible boot method, I'm going to close the issue.

[GunnerMBT]

So how can we actually make it UEFI bootable?

[charles-dyfis-net]

@pbatard, please forgive me for contradicting your prior comment: /boot/efi.img isn't itself a filename encoded anywhere in the EFI standard, but it can be part of valid, standards-compliant EFI boot media.

In short: The EFI standard incorporates (a subset of) two different filesystem standards: FAT (FAT32 mandated for hard drives, FAT12 and FAT16 supported for removable media), and ISO9660 with El Torito extensions (which are mandatory) embedding a FAT12 or FAT16 image.

An ISO image using these extensions might be created with something like:

mkisofs [...] -eltorito-alt-boot -e FAT16_PATH -no-emul-boot

...where FAT16_PATH is something like, in the present case, boot/efi.img, and where when that image is mounted it contains /EFI/BOOT/BOOTx64.EFI.

[pbatard]

#63

[pbatard]

But really the Kali people should know better than use El-Torito with UEFI when everybody else uses the standard HD loaders from EFI/boot, and with good reason. If Kali wants to make life harder for developers of ISO → USB applications like Rufus, whereas they just have to take a look at the myriad of Linux distros who handle dual BIOS+UEFI boot, and handle it well, to take some hints, then they'll have to wait until I have nothing better to do than invest some time in their non-defacto EFI boot.

It's the same with BIOS: You can always create your own super-specific ISO loader, that complies with El-Torito or whatever. But when you clearly don't design that loader with the idea that people will want to convert your ISO to USB, and shouldn't have to jump through hoops to do so, don't come complaining if Rufus won't support it. Heck, it took me about 1 month full time development to sort out a Windows XP bootable ISO -> Windows XP bootable USB process I could be happy about. But I'm not going to do the same for Kali (or some Acronis ISOs, which I also see requested quite a lot), because it simply isn't a sensible investment.

[charles-dyfis-net]

To be clear: My interest isn't in Rufus, but in making sure the record is clear given the amount of Google juice this ticket has for queries re: UEFI booting of ISO media in general.

---

Pointing out Tails isn't a great example -- their current (1.7) release ISO isn't actually UEFI-compliant, and, when burned to DVD media or running on emulated CD hardware, fails to boot on legacy-free firmware (tested against a current shapshot of TiannoCore EDK2, which is intentionally free of legacy support).

The El Torito catalog on the tails ISO has architecture 0 (standard x86), whereas an EFI entry would have an architecture 239 (0xEF) El Torito entry pointing to a FAT filesystem. isohybrid --uefi, which tails doesn't use, would (1) run only against ISO media with such an El Torito header pointing to a FAT filesystem, and (2) would create MBR and GPT partition tables pointing to the same FAT filesystem to allow that ISO to still be EFI-booted if copied to non-CDROM media -- but again, the tails ISO can't be UEFI booted as distributed; instead, it merely contains files that would make UEFI-bootable media if those files were to be copied onto a compliant FAT filesystem.

I'm not presently volunteering to write code to read an ISO's El Torito header and then (presumably using mtools) copy contents out of the embedded FAT filesystem pointed to by same; however, that would be the correct mechanism to support (all!) truly UEFI-compliant ISO media.

[pbatard]

Pointing out Tails isn't a great example

Okay, then have a look at Debian or Arch. As I said, the Kali people really just have to look around.

however, that would be the correct mechanism to support (all!) truly UEFI-compliant ISO media.

Assuming that distro maintainers, who don't seem to care that much about booting from USB in the first place (else they would be using the defacto EFI boot from HDD) have somehow written scripts that do detect USB media.

I think openSUSE (and derivatives) want to have a word with you. Heck, even distros who try to help their users, by doing the right thing™ and allowing them to simply copy the ISO content to a FAT32 USB drive to make it UEFI bootable (don't even need an app to do that!), still get some stuff wrong.

I truly wish you'd volunteer to write the code. That would probably give you a better perspective on why what may sound like a relatively trivial operation, to an external observer, is guaranteed to be anything but.

[lock]

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue if you think you have a related problem or query.