EDK2 support for ext4 file system

[kowalski100]

I know this my sound silly for a UEFI application to have access non ESP partition but I am working on a UEFI application that requires access to an EXT4 partition for loading some file e.g. virtual machine etc.

is it possible to load file using EDK2 or in other words does EDK2 has support for ext2/3/4 partition? If it has, a dummy code will be highly appreciated.

[bexcran]

rEFInd has drivers for various filesystems including ext4: https://www.rodsbooks.com/refind/drivers.html#selecting

rEFInd ships with a small collection of read-only EFI filesystem drivers. These are:

Ext2fs—This driver originated with rEFIt. It's useful for reading Linux kernels from a separate /boot partition, or even from a root (/) filesystem, if you use ext2fs on it. Although it's called an "ext2fs" driver, it also works with ext3fs.
Ext4fs—Stefan Agner modified the rEFIt/rEFInd ext2fs driver so that it could handle ext4fs. I'm including this as a separate driver from the ext2fs driver, although the ext4fs version can handle ext2fs and ext3fs, too. Providing both drivers enables easy filesystem separation—for instance, you can use ext2fs on a /boot partition and ext4fs on your root (/) partition, to have the EFI scan only the former. This driver has some limitations and may not work with all ext4 filesystems. Although it supports (as of version 0.10.4) 64-bit pointers, this support is untested on over-16TiB volumes. As of version 0.6.1, this driver supports the meta_bg feature, which can also be used on ext2fs and ext3fs. Thus, it can handle some ext2fs and ext3fs partitions that the ext2fs driver can't handle. Beginning with rEFInd 0.13.0, this driver supports activation of the filesystem-level encryption code, but can not read encrypted files. (The OS can encrypt directories that rEFInd doesn't read, though.) You can learn about your ext2/3/4 filesystem features by typing dumpe2fs /dev/sda2 | grep features, changing /dev/sda2 to your filesystem's device.

Warning: In early 2022, Linux kernel developers began discussing the possibility of removing ReiserFS, and soon thereafter, a notice appeared in the kernel configuration tools to the effect that it has been officially deprecated and would be removed from the kernel in 2025. Although converting a small /boot partition from one filesystem to another is fairly painless, I must strongly caution against using ReiserFS for anything larger than /boot; and even using it for a /boot partition is not the best idea unless you have a compelling reason to do so. I intend to leave rEFInd's ReiserFS driver in place until its Linux kernel equivalent is removed, and maybe a bit longer; but ReiserFS is now officially deprecated in rEFInd, too.
ReiserFS—This driver originated with rEFIt. It can be used in the same way as the ext2fs and ext4fs drivers. Caution: If you use this driver, you should use the notail option in Linux's /etc/fstab file for the partition(s) you want the EFI to read. This is because the driver doesn't properly handle ReiserFS's "tail-packing" feature, so files can seem to be corrupted in EFI if you use this feature, which is disabled by notail. In my tests, this is the fastest of rEFInd's EFI filesystem drivers, so if you find your kernel load times are slow, you might consider moving your kernel to a ReiserFS /boot partition. (Such problems affect a small subset of EFI-based computers.)
Btrfs—Samuel Liao contributed this driver, which is based on the rEFIt/rEFInd driver framework and algorithms from the GRUB 2.0 Btrfs driver. I've tested this driver with simple one-partition filesystems on several installations, and with a filesystem that spans two physical devices on one (although I've made no attempt to ensure that the driver can actually read files that span both devices). Samuel Liao has used the driver with a compressed Btrfs volume. The driver will handle subvolumes, but you may need to add kernel options if you're booting a Linux kernel directly from a filesystem that uses subvolumes. Unfortunately, subvolume configuration varies from one Linux distribution to another. Prior to rEFInd 0.10.0, adding also_scan_dirs + @/boot to refind.conf was often necessary, but @/boot is now part of the default. Because subvolume configuration varies, though, you may need to adjust also_scan_dirs for your distribution's (or your own personal) setup. You may also need to check your existing GRUB configuration, or rely on refind-install or mkrlconf to create a suitable /boot/refind_linux.conf file (assuming you're already booted to your installation via GRUB or some other method). In particular, most distributions require passing an option like rootflags=subvol=@ to the kernel — but again, details vary. For those who live deep in the Btrfs "weeds," the refind-btrfs project provides tools to help you boot into Btrfs snapshots. I've not tried this project myself, but it looks interesting.

Tip: If you partition a USB flash drive and use dd to copy Linux .iso images to the drive's individual partitions, the rEFInd ISO-9660 driver enables rEFInd to boot multiple Linux distributions' installers from the USB flash drive. I can't promise this feature will work with all distributions, but it does work with some.
ISO-9660—This driver originated with rEFIt's author, but he never released a final version. Its code was improved by Oracle for use in its VirtualBox product, and then further modified by the authors of the Clover boot loader. If your firmware doesn't provide its own ISO-9660 driver, this one can be helpful; however, you may need to install it on your hard disk before you can read an optical disc.
HFS+—Oracle wrote this driver, apparently with some code taken from open source Apple examples. It was then further modified by the Clover authors. I expect this driver to have limited appeal to most rEFInd users. Macs don't need it, since Apple's EFI implementation provides its own HFS+ driver, and HFS+ isn't normally used on UEFI-based PCs. Some CDs are mastered with both ISO-9660 and HFS+, or even with HFS+ alone, and it's conceivable that an HFS+ driver would be useful when accessing such discs. Also, one unusual feature of this driver is that it can read files from within an Apple LVM setup, which Apple's own EFI HFS+ driver can't do. The upshot of this feature is that if you load this driver on a Mac that uses Apple's LVM, rEFInd is likely to show two macOS boot options. Ordinarily this is pointless, but it could be helpful if your Recovery HD volume becomes damaged. I'm providing the driver mainly because it compiled cleanly with no extra work, aside from providing a Makefile entry for it.

Warning: I've received multiple reports of system hangs when using the NTFS driver; however, I've been unable to replicate the problem. (The problem is probably triggered either by interactions with specific EFIs or by unique features of the "problem" NTFS volumes.) I therefore recommend avoiding the NTFS driver unless it's absolutely necessary, and as of rEFInd version 0.11.5, this driver is no longer built by default. See the BUILDING.txt file in the rEFInd source code package for information on building this driver, if you need it. Alternatively, you can use a pre-built binary from rEFInd 0.11.4.
NTFS—Samuel Liao contributed this driver. As of rEFInd 0.11.5, this driver is not built by default; see the Warning sidebar to the right. Note that this driver is not required to boot Windows with rEFInd, since Windows stores its EFI boot loader on the (FAT) ESP, and the BIOS boot process (generally used when dual-booting on a Mac) relies only on the partition's boot sector, which is read without the benefit of this driver. Reasons to use this driver include:
If you want to use Windows to write large files, such as RAM disk images, to be read from EFI.
If you have a Mac and NTFS data partitions, loading this driver should exclude those data partitions from the boot menu. (rEFInd provides several other means of hiding unwanted boot entries, though.)
If you have a Mac that dual-boots with Windows, using this driver should provide NTFS volume names in the boot menu.

All of these drivers rely on filesystem wrapper code written by rEFIt's author, Christoph Phisterer.

Although Linux filesystems are all case-sensitive, these drivers treat them in a case-insensitive way. Symbolic links work; however, rEFInd gnores symbolic links, since many distributions use them in a way that creates redundant or non-functional entries in the rEFInd menu. You should be able to use hard links if you want to use a single kernel file in multiple ways (say for two distributions).
Finding Additional EFI Drivers

As already noted, I know of few EFI drivers for EFI hardware, aside from those that are built into motherboards' EFI implementations. I do, however, know of a few EFI filesystem drivers, in addition to those provided with rEFInd:

Pete Batard's efifs drivers—This project is an EFI driver wrapper around GRUB 2's filesystem drivers. Once compiled, the result is that GRUB 2's drivers become standalone EFI filesystem drivers, loadable independently or by rEFInd. (rEFInd version 0.8.3 or later is required.) The last time I checked (driver version 1.3; February, 2020), several drivers, including NTFS, exFAT, ext2fs, ReiserFS, Btrfs, JFS, and XFS, are usable. The previous time I tested them (version 0.7), some drivers were slow, and they hung on some computers, such as one of my Macs. They may have improved since then, and are likely to improve more in the future. Note that the ext2fs driver from this set works with ext3fs and ext4fs, too. In addition to the main link, you can check the github repository for the source code.
The LKL driver project—I have yet to look closely at this project, but I think it's a porting of the Linux kernel's filesystem drivers to EFI. The developer stated on the EFI developers' mailing list that they aren't yet stable, as of November 2016, and as of February of 2021, there appears to have been no development in several years.
rEFIt's ext2fs and ReiserFS drivers—You can gain read-only access to ext2fs, ext3fs, and ReiserFS volumes with these drivers, originally written by Christoph Pfisterer. You can use the binaries in the refit-bin-0.14/efi/tools/drivers directory of the binary package directly on a Mac. On a UEFI-based PC, though, you'll need to break the Mac-style "fat" binary into its 32- and 64-bit components. You can use my thin program for this job. As a practical matter, there's no advantage to using these drivers over rEFInd's drivers, since the latter are updated versions of the former.
Clover EFI's ISO-9660, ext2fs, ext4fs, and HFS+ drivers—This project is an offshoot of Tianocore, the main UEFI project, combined with a fork of rEFIt that's independent of rEFInd. Clover is primarily a Hackintosh boot loader, but it includes drivers for ISO-9660, ext2fs, ext4fs, and HFS+; however, building them requires a fair amount of expertise. These drivers are closely related to rEFInd's own drivers; however, Clover has a large number of developers working on it, and some of its drivers (especially the HFS+ driver) have diverged significantly from rEFInd's version.
VirtualBox's HFS+ and ISO-9660 drivers—These drivers are available in source code form, and come with VirtualBox binaries. I've not attempted to compile them myself, but I've seen a report that suggests they may include assumptions that require use of MinGW, a GCC-based compiler for Windows (and cross-compiler to build Windows executables under Linux). I don't know of a source for binaries suitable for use on EFI-based computers; if you want to use them, you'll need to figure out how to compile them yourself. As noted earlier, rEFInd's drivers are closely related to these.
Ext2Pkg—This driver, which hasn't been updated since 2012, appears to be an ext2fs/ext3fs driver built independently of the driver written by Christoph Pfisterer. The linked-to sites provide access to source code via git but do not provide binaries. When I built binaries, they failed to work. Under VirtualBox, the driver loaded but then hung when I tried to access an ext2 filesystem. On a 32-bit Mac Mini, I got error messages when I tried to access an ext2 filesystem. As I write, the code was last updated in March of 2012. If you check the project and it's been updated more recently, it might be worth trying. Otherwise, I can't recommend this driver. I mention it here only in case it improves in the future.
Paragon's UFSD—According to this 2013 blog post, Paragon Software has ported its Universal File System Drivers (UFSD) to EFI, providing "transparent access to NTFS, HFS+, ExFAT, and ExtFS" (sic). Neither the blog post nor the main UFSD page provides any download links, and it's unclear if the product is (or will be) available for free, on a pay basis, or even at all.
Apple's APFS—Apple provides an EFI driver for its Apple Filesystem (APFS), which is an optional feature of macOS 10.12 ("Sierra") and a mandatory feature of macOS 10.13 ("High Sierra") when using flash storage devices such as SSDs. When updating to macOS 10.13, your firmware should receive an update that includes this driver, so you shouldn't need to do anything to use APFS (with one caveat, described shortly). Apple also provides the driver as an EFI binary file, stored at /usr/standalone/i386/apfs.efi in the installed OS. You can load this driver from rEFInd, but doing so is likely to be pointless—on Macs, the driver should be built into the firmware, and on non-Macs, APFS is unlikely to hold files that rEFInd could use. On the off chance that a firmware update failed, though, copying this file to the rEFInd drivers subdirectory may enable you to boot macOS. Note that APFS includes built-in LVM-like features, similar to Btrfs. Under EFI, APFS volumes are identified by directories with UUIDs as filenames. This fact means that rEFInd 0.11.1 needed modifications to locate the macOS boot loader, since its location changed, as viewed from rEFInd. If you had used rEFInd 0.11.0 or earlier, update to macOS 10.13, and find that you can no longer boot macOS, try updating rEFInd to 0.11.1 or later.