Re: [edk2-devel] Cannot boot ISO on RamDisk

["Laszlo Ersek" <lersek@redhat.com>]

On 11/26/20 20:53, Nahim Souza via groups.io wrote:
> Greetings!
> 
> We are trying to implement an .efi application that receives an ISO file from an Android device, loads it into a buffer and try to boot an Operating System. To do this, we tested some implementations using Ram Disk but after creating the virtual disk and running BOOTX64.efi and found on the FAT32 partition, but some problems occur after boot, as if I did not find the other files in the ISO. To solve this problem, we tried some approaches:
> 
> * Change the parameters when calling RamDiskProtocol->Register() function (GUID and DevicePath)
> * Tried with different OS (Xubuntu, Windows 10, Windows 7, Ubuntu and OpenSuse)
> * Compared with HttpBoot implementation from EDK2, where we saw that an ISO file could be loaded into memory to boot an OS, but the RamDisk implementation in HttpBootRegisterRamDisk was very similar to ours
> Based on this, I have some questions:
> 
> * In our understanding, HttpBoot downloads the ISO and boots the OS using the RamDisk. Is that correct?

I think so.

https://github.com/tianocore/tianocore.github.io/wiki/HTTP-Boot#ram-disk-boot-from-http

> * We saw that RamDiskDxe has some dependencies from ACPI tables, since it uses NFIT (NVDIMM Firmware Interface Table) to save some persistent information. Is there some hardware/driver requirement to make the OS boot through RamDisk? Did we need to have this NVDIMM to support ACPI feature from RamDiskDxe?

The booted operating system needs to understand where to look for files
on the virtual disk. More precisely, the booted operating system must
understand that the particular reserved memory range *is* a RAM disk. If
there is no NFIT, the booted operating system will have no idea where to
load other files from.

A similar issue is discussed in this RHBZ:

https://bugzilla.redhat.com/show_bug.cgi?id=1671345

There, the problem was that the guest kernel in question didn't have a
driver for consuming the NFIT table. Different reason, same result --
the information describing the UEFI-originated virtual disk to the OS
was lost, so the OS couldn't finish booting.

> * Would you have any other suggestions for solving this scenario?

Make sure you have enough (contiguous) RAM, as the ISO can be large, and
you still need enough RAM left after the reserved memory allocation, for
booting the OS.

https://github.com/tianocore/tianocore.github.io/wiki/HTTP-Boot#ram-disk-image-size

HTH
Laszlo