I don't understand that. "Link normally" is ambiguous.

Linux has much more powerful drivers for mapping a directory as a block device:
https://wiki.qemu.org/Documentation/9psetup

No need to use the half working vvfat.

Sorry, I was meaning to specify where is my efi file

https://gitlab.com/bztsrc/bootboot/-/tree/master/mkbootimg
Just remembered about this useful tool - if you still want to make ISOs. bzt is on the board - he just doesn't make it by here frequently.

Virtual Box has a VISO feature to create an ISO in memory, but I can't get it to boot UEFI from it. Reading through bzt's source I think I understand why it doesn't work.

Sorry, long time no see

I checked what is wrong, definitely, something is wrong when I generated the iso, because QEMU as well isn't able to execute my ISO file.

When I performed a , I have an error:

Nobody?

AFAIK you need UDF 1.02 as the only filesystem on it, and also it doesn't seem to have any boot info? Not sure if that's needed for UEFI though, but it is for BIOS obviously.

Why you say UDF, normally the uefi partition need to be formatted with FAT isn't it ?

Well not on an optical drive, which is read-only. .iso is an image for optical media/disc.

So what I'm suppose to do now ?

Did you try what I suggested? I don't use mkisofs, but try -udf option?

I didn't understand you asked me to try the -udf option. With the udf option, finally my iso is recognized correctly !

The only problem I have now is, I have to go to mounted iso with the uefi shell to exec the BOOTX64.efi. How when I generate my iso can I set it with the boot flag for efi ?

Well, an .iso image can have multiple filesystems on it. It's kind of complicated, but UEFI needs the UDF filesystem apparently, it's what it expects, like it expects FAT32 on other disks. (note that these filesystems share the same file data, so it's not duplicated, because it is read only so that works easily).

Do you mean to have it run automatically? Honestly not really sure about this one. Unless it's an UEFI setting (but probably not in a VM), if you find out how, share please, I'd like to know too.

Yeah, I don't come here often, sorry.

In short, in theory EFI supposed to handle the ISO9660 file system, but in practice it does not. The issue here is, the spec says "EFI interprets the [El Torito] “no emulation” image as an EFI system partition.", and most firmware implementations (TianoCore included) only accepts FAT for EFI system partition, nothing else (not ISO9960 nor UDF). Again, according to the spec it should, but in practice only FAT works. So what my mkbootimg tool does, it creates one FAT image, it places that into the disk image, and then it records the start position in the GPT as well as in the El Torito Boot Catalog. The source doing this is here (note: the boot catalog points to a FAT file system image, and not to the ISO9660 file system. That latter only has one text file, that's all).

FYI, one of my other projects, POSIX-UEFI has a simpler tool to create such bootable EFI images, efidsk.c. I believe you might find more suitable this for your needs than mkbootimg, as it uses the contents of a directory, pretty much the same way as mkisofs does. The resulting ESP image is wrapped in a GPT, so that the image is bootable under UEFI right away (as a disk or USB storage, but if you really want to use the obsolete and buggy EFI CD-ROM way, I can add El Torito Boot Catalog too into the image in no time, just ask). The efidsk tool is totally dependency-free, you won't need any EFI header or any third-party library to compile it, It Just Works(TM) sucklessly.

Hope this helps,
bzt