pbatard / efifs Goto Github PK

I see you usually update these drivers roughly once a year.
Could you please include Btrfs "extent tree v2" support in this year's update? It presumably increases the mount time significantly.
I love how my box boots directly from Btrfs after injecting your driver into the motherboard's UEFI firmware but boot time is ridiculously slow this way (I guess the CPU is operating at it's lowest possible frequency during that time and these drivers might not be optimized for speed either).
The kernel mounts the HDD-based RAID filesystem without a few seconds with or without that new Btrfs feature but the motherboard firmware takes a few minutes in comparison. So, a theoretical ~50x speedup in firmware-mount time would be very very perceivable (could reduce minutes to seconds).

https://www.reddit.com/r/btrfs/comments/xgqct8/btrfsprogs_separate_block_group_tree_from_extent/

I tried to apply f2fs to UEFI on mobile device, but failed.
I found that the program runs to the function grub_f2fs_check_dentries and return after looping the function grub_f2fs_test_bit_le 27 times.
I printed value of ctx->bitmap, all zero.
How should I debug it?

After failing to build with EDK II (#10), I am now failing to build with GCC and make:

./set_grub_cpu.sh X64
make ARCH=x64 CROSS_COMPILE=x86_64-linux-gnu- -j 8 -l 8

And getting this error on both the latest release and on master.

[LD] btrfs_x64.efi
GNU ld (GNU Binutils for Debian) 2.28
  Supported emulations:
   elf_x86_64
   elf32_x86_64
   elf_i386
   elf_iamcu
   i386linux
   elf_l1om
   elf_k1om
   i386pep
   i386pe
/usr/bin/ld: unrecognized option '--subsystem'
/usr/bin/ld: use the --help option for usage information

I tried to write a efi application to read large files(more than 10G), when read file from offset 4155201536, the ntfs driver hangs and the exfat driver return device error。This offset does not exceeded 4G, so I tried to read from 4G above or just before EOF, it's OK. Yes, it's really strange.

I wanted to try out xfs with refind and downloaded the latest xfs_x64.efi file from the releases to my /efi/EFI/refind/drivers_x64 folder, but I'm not able to boot into the linux image.

Loading up an efi shell and going to that folder on fs0 and trying to load xfs_x64.efi I get one line: Image FS0:\EFI\refind\drivers_x64\xfs_x64.efi error in StartImage: Load Error.

The sha256 matches the one in the gh action, so it doesn't seem to be a corrupt file, any idea what I'm doing wrong ?

(I also tried an earlier release version, to no avail)

Hello.

I've downloaded "ext2_x64.efi" fle from your web but, after having loaded, when I remap filesystem in VirtualBox's UEFI Shell, nothing happens: my Ext4 partition continues just recognized as "blk", not "fs".

I don't know if it is a problem of your driver or it's a VirutualBox UEFI's implementation's one but I think it was worthy to open an issue about this, in order to debug the problem (hope I'm not mistaken).

Thanks a lot for your splendid project.

I am using qemu to test the fs drivers. i am using a virtual disk with two partitions one fat and other ext2.
when i load the ext2fs driver, It is showing error "could not read address 00000002:[12]
error:could not read block".

Currently, EfiFs uses EFI_DEVICE_PATH_TO_TEXT_PROTOCOL to convert a DevicePath to a string, since we need an immutable element to differentiate our file system devices, and since grub_open() took a string, the obvious choice was to use the Device Path derived string.

However this protocol is not guaranteed to be available versions of the UEFI firmware, and some older UEFI firmwares (e.g. ca. 2010-2012 Dell Optiplex and Dell Laptops) don't provide it at all, which results in FSBindingStart() returning with an error.

The easiest way to solve this issue might be to drop the DevicePath string altogether in EfiFs and use a fake string pointed to a DevicePath instead...

Had a quick question/issue about the possibility of executing efi binaries on newly loaded filesystems such as btrfs or ext4. I see that efifs is specifically denoted as read-only but was wondering if there is any way to also execute efi binaries that can be read. Thanks for any help.

This happens when loading the driver.
x64 ones are fine, and so are ia32 and x64 ones compiled with MSVC.

The guide present in the wiki doesn't seem to work anymore, as I can't find any .rsrc folder in vmware-vmx.exe.

Is this dependent on any vmware version? If so, which one?

Is there any other alternative? I can't find any open source efi.rom to add my DXE Driver to. Maybe I'm just using the wrong keywords.

Thank you for your attention.

when git submodule update at grub,It occured an error.as shown in the figure.

Running OVMF in qemu, going to the UEFI Shell, and entering load hfs_x64.efi yields Image 'hfs_x64.efi' is not an image. I'm not sure whether it's OVMF or EfiFs at fault, but the other EfiFs drivers that I've tried have worked so I'm assuming it's EfiFs. Both OVMF and EfiFs were built with both their latest releases and their latest commits on master.

Are there tools I can use to try and debug this?

Trying to follow the instructions at https://github.com/pbatard/efifs#bonus-commands-to-compile-efifs-using-edk2-on-a-vanilla-debian-gnulinux-91

I booted up a vagrant box with Debian 9.6 and ran this script:

#!/usr/bin/env bash

set -ex

sudo apt install nasm uuid-dev build-essential git

git clone --recurse-submodules -b edk2-stable201811 https://github.com/tianocore/edk2.git
git clone --recurse-submodules -b v1.3 https://github.com/pbatard/efifs.git
cd edk2
ln -s ../efifs EfiFsPkg
make -C BaseTools/Source/C -j 8 -l 8
source edksetup.sh
./EfiFsPkg/set_grub_cpu.sh X64
build -a X64 -b RELEASE -t GCC5 -p EfiFsPkg/EfiFsPkg.dsc -n 8

And I got this error:

"gcc" -g -fshort-wchar -fno-builtin -fno-strict-aliasing -Wall -Werror -Wno-array-bounds -ffunction-sections -fdata-sections -include AutoGen.h -fno-common -DSTRING_ARRAY_NAME=udfStrings -m64 -fno-stack-protector "-DEFIAPI=__attribute__((ms_abi))" -maccumulate-outgoing-args -mno-red-zone -Wno-address -mcmodel=small -fpie -fno-asynchronous-unwind-tables -Wno-address -flto -DUSING_LTO -Os -Wno-unused-but-set-variable -Wno-unused-const-variable -DFORMAT=efi-app-x64 -Os -DCPU_X64 -DGRUB_FILE=__FILE__ -DDRIVERNAME=udf -DDRIVERNAME_STR=\"UDF\" -DMDEPKG_NDEBUG -DDISABLE_NEW_DEPRECATED_INTERFACES -c -o /home/vagrant/edk2/Build/EfiFs/RELEASE_GCC5/X64/EfiFsPkg/EfiFsPkg/Udf/OUTPUT/src/grub.obj -I/home/vagrant/edk2/EfiFsPkg/grub/grub-core/fs -I/home/vagrant/edk2/EfiFsPkg/grub/grub-core/kern -I/home/vagrant/edk2/EfiFsPkg/src -I/home/vagrant/edk2/EfiFsPkg/EfiFsPkg -I/home/vagrant/edk2/Build/EfiFs/RELEASE_GCC5/X64/EfiFsPkg/EfiFsPkg/Udf/DEBUG -I/home/vagrant/edk2/EfiFsPkg -I/home/vagrant/edk2/EfiFsPkg/grub/include -I/home/vagrant/edk2/EfiFsPkg/grub -I/home/vagrant/edk2/EfiFsPkg/grub/grub-core/lib/minilzo -I/home/vagrant/edk2/MdePkg -I/home/vagrant/edk2/MdePkg/Include -I/home/vagrant/edk2/MdePkg/Include/X64 -I/home/vagrant/edk2/ShellPkg -I/home/vagrant/edk2/ShellPkg/Include -I/home/vagrant/edk2/IntelFrameworkModulePkg -I/home/vagrant/edk2/IntelFrameworkModulePkg/Include /home/vagrant/edk2/EfiFsPkg/src/grub.c
In file included from /home/vagrant/edk2/EfiFsPkg/src/grub.c:22:0:
/home/vagrant/edk2/EfiFsPkg/grub/include/grub/misc.h:35:0: error: "ARRAY_SIZE" redefined [-Werror]
 #define ARRAY_SIZE(array) (sizeof (array) / sizeof (array[0]))

In file included from /home/vagrant/edk2/MdePkg/Include/Uefi/UefiBaseType.h:20:0,
                 from /home/vagrant/edk2/MdePkg/Include/Uefi.h:23,
                 from /home/vagrant/edk2/Build/EfiFs/RELEASE_GCC5/X64/EfiFsPkg/EfiFsPkg/Ufs/DEBUG/AutoGen.h:16,
                 from <command-line>:0:
/home/vagrant/edk2/MdePkg/Include/Base.h:1317:0: note: this is the location of the previous definition
 #define ARRAY_SIZE(Array) (sizeof (Array) / sizeof ((Array)[0]))

This differs from the suggested commands only in that I am not building for arm/aarch64, and I checked out the latest releases of EfiFs and EDK II rather than master. However, switching to master yields the same result. I tried patching the grub header, but that just led to more of the same style of errors, so I gave up. I figure there must be something else wrong, or else no one would have been able to build this.

On 2 different devices I have tried adding the ext2 driver to the driver list (bcfg driver add ...) and indeed it gets loaded at startup (verified using drivers command). However, no ext2 partitions are detected.

Hi,
do you know someone can help us implementing zfs-drivers in refind?

Note: We don't intend to use grub or systemd but arch-linux and derivate.

I'm getting errors when building for x64, ia32 and arm with gcc.

Forx64:

[LD] btrfs_x64.efi
/usr/lib/gcc/x86_64-w64-mingw32/10.2.0/../../../../x86_64-w64-mingw32/bin/ld: /storage/linux/src/efifs/src/..//grub/grub-core/fs/btrfs.o:btrfs.c:(.text+0x1839): undefined reference to `grub_raid6_recover_gen'
collect2: error: ld returned 1 exit status
make[2]: *** [/storage/linux/src/efifs/src/../Make.common:166: btrfs_x64.efi] Error 1
make[2]: Leaving directory '/storage/linux/src/efifs/src'
make[1]: *** [Makefile:18: btrfs] Error 2
make[1]: Leaving directory '/storage/linux/src/efifs/src'
make: *** [Makefile:16: all] Error 2

For ia32:

[LD] btrfs_ia32.efi
/usr/lib/gcc/i686-w64-mingw32/10.2.0/../../../../i686-w64-mingw32/bin/ld: /storage/linux/src/efifs/src/..//grub/grub-core/fs/btrfs.o:btrfs.c:(.text+0x178e): undefined reference to `grub_raid6_recover_gen'
collect2: error: ld returned 1 exit status
make[2]: *** [/storage/linux/src/efifs/src/../Make.common:166: btrfs_ia32.efi] Error 1
make[2]: Leaving directory '/storage/linux/src/efifs/src'
make[1]: *** [Makefile:18: btrfs] Error 2
make[1]: Leaving directory '/storage/linux/src/efifs/src'
make: *** [Makefile:16: all] Error 2

For arm:

arm-none-eabi-gcc -I/storage/linux/src/efifs/gnu-efi//gnuefi -I/storage/linux/src/efifs/gnu-efi//gnuefi/../inc -I/storage/linux/src/efifs/gnu-efi//gnuefi/../inc/arm -I/storage/linux/src/efifs/gnu-efi//gnuefi/../inc/protocol -Wno-error=pragmas -marm -fpic  -g -O2 -Wall -Wextra -Werror -fshort-wchar -fno-strict-aliasing -ffreestanding -fno-stack-protector -fno-stack-check -fno-stack-check -fno-merge-all-constants -DCONFIG_arm -c /storage/linux/src/efifs/gnu-efi//gnuefi/reloc_arm.c -o reloc_arm.o
/storage/linux/src/efifs/gnu-efi//gnuefi/reloc_arm.c:40:10: fatal error: elf.h: No such file or directory
   40 | #include <elf.h>
      |          ^~~~~~~
compilation terminated.
make[2]: *** [/storage/linux/src/efifs/gnu-efi//gnuefi/../Make.rules:52: reloc_arm.o] Error 1
make[2]: Leaving directory '/storage/linux/src/efifs/gnu-efi/arm/gnuefi'
make[1]: *** [Makefile:80: gnuefi] Error 2
make[1]: Leaving directory '/storage/linux/src/efifs/gnu-efi'
make: *** [Make.common:158: gnu-efi/arm/lib/libefi.a] Error 2

It builds fine for aa64.

Commands used to build:

$ git clone --recursive https://github.com/pbatard/efifs.git
$ cd efifs
$ patch -d grub -Np1 -i ../0001-GRUB-fixes.patch
$ unset -v CFLAGS
$ make -j1 ARCH='x64'
$ # (or make -j1 ARCH='ia32')
$ # (or make -j1 ARCH='arm' CROSS_COMPILE='arm-none-eabi-')

System information:

• OS: Arch Linux x86_64
• mingw-w64-gcc: 10.2.0
• arm-none-eabi-gcc: 10.2.0

Per pbatard/rufus#1213, the ia32 and aarch64 versions of the EDK2 drivers compiled with VS2019 don't populate the following fields from the PE Header:

• cpu
• file-type
• subsystem

The gnu-efi version for all archs, or EDK2 version for x64 and arm don't have that issue (and the signature field is missing then, which is probably related):

We definitely want to have cpu and subsystem filled out, as we suspect that some UEFI firmwares may refuse to load a driver that doesn't have those. At first glance, it would look like some of the post processing that is meant to happen to convert a DLL to an EFI binary is not being applied to the AARCH64 and IA32 targets...

While trying to make systemd-boot use these drivers to load initrd and kernel from custom XBOOTLDR partition, I get "Buffer Too Small" error when I try using ext2 with efifs driver instead of vfat for it. Is there some trick I'm missing for using these drivers?

You can reproduce my error by running

docker run --device /dev/kvm --rm -it yoriksar/nixos-qemu-vm:3ifn9pacv6wqv1r49j002p01cz7w4ama

It's a NixOS system wrapped in QEMU VM in Docker image. Note that similar system that uses FAT boots just fine, even though it also loads ext2_64.efi driver:

docker run --device /dev/kvm --rm -it yoriksar/nixos-qemu-vm:7nbbvwpjwa292ws2k58vr98vmlq7pgvc

(you may omit --device /dev/kvm if you don't want containers to get access to it, but it will be slow)

Both examples use the same version of everything, only the format of the boot drive differs.

In my previous attempts I managed to get more debug from systemd-boot:

OpenVolume
OpenVolume
Open(3E7F2998 <ROOT>, "\EFI\nixos\775xip76m7ipmad91aqg4qmzv11ag5f7-linux-5.15.55-bzImage.efi")
  RET: 3EE78E18
Close(3E7F2998|'/') <ROOT>
GetInfo(3EE78E18|'/EFI/nixos/775xip76m7ipmad91aqg4qmzv11ag5f7-linux-5.15.55-bzImage.efi', 0)
Get regular file information
GetInfo(3EE78E18|'/EFI/nixos/775xip76m7ipmad91aqg4qmzv11ag5f7-linux-5.15.55-bzImage.efi', 600)
Get regular file information
Read(3EE78E18|'/EFI/nixos/775xip76m7ipmad91aqg4qmzv11ag5f7-linux-5.15.55-bzImage.efi', 7821408)
Close(3EE78E18|'/EFI/nixos/775xip76m7ipmad91aqg4qmzv11ag5f7-linux-5.15.55-bzImage.efi')
OpenVolume
Open(3E7F2998 <ROOT>, "EFI\nixos\688xmj1rc311djm1ql9c80kr4gmcc3va-initrd-linux-5.15.55-initrd.efi")
  RET: 3E7DB018
GetInfo(3E7DB018|'/EFI/nixos/688xmj1rc311djm1ql9c80kr4gmcc3va-initrd-linux-5.15.55-initrd.efi', 592)
Get regular file information
EFI stub: ERROR: Failed to get file info
Close(3E7DB018|'/EFI/nixos/688xmj1rc311djm1ql9c80kr4gmcc3va-initrd-linux-5.15.55-initrd.efi')
Close(3E7F2998|'/') <ROOT>
EFI stub: ERROR: Failed to load initrd!
EFI stub: ERROR: efi_main() failed!
Close(3E7F2998|'/') <ROOT>
Failed to execute NixOS (\EFI\nixos\775xip76m7ipmad91aqg4qmzv11ag5f7-linux-5.15.55-bzImage.efi): Buffer Too Small

it seems like it fails to get file information using this driver first, so "Buffer Too Small" might not be the root issue.

When using QEMU.efi from https://snapshots.linaro.org/components/kernel/leg-virt-tianocore-edk2-upstream/3852/QEMU-AARCH64/RELEASE_GCC5/ you get the following when trying to load the driver:

UEFI Interactive Shell v2.2
EDK II
UEFI v2.70 (EDK II, 0x00010000)
Mapping table
      FS0: Alias(s):HD0b:;BLK1:
          PciRoot(0x0)/Pci(0x1,0x0)/HD(1,MBR,0xBE1AFDFA,0x3F,0xFBFC1)
     BLK4: Alias(s):
          VenHw(93E34C7E-B50E-11DF-9223-2443DFD72085,00)
     BLK0: Alias(s):
          PciRoot(0x0)/Pci(0x1,0x0)
     BLK2: Alias(s):
          PciRoot(0x0)/Pci(0x2,0x0)
     BLK3: Alias(s):
          PciRoot(0x0)/Pci(0x2,0x0)/HD(1,MBR,0x0059785B,0x800,0x3800)
Shell> set FS_LOGGING 4
Shell> load fs0:\exfat_aa64.efi
FS driver installed.
Image 'FS0:\exfat_aa64.efi' loaded at 43913000 - Success
FSBindingSupported
FSBindingStart
error: not a FAT filesystem.
FSBindingSupported
FSBindingStart
FSInstall: PciRoot(0x0)/Pci(0x2,0x0)/HD(1,MBR,0x0059785B,0x800,0x3800)


Synchronous Exception at 0x0000000043919BD0


Synchronous Exception at 0x0000000043919BD0

This does not happen with older versions of Linaro QEMU, such as ones from 2017 which is the one we provide for testing on the website and also doesn't happen on real hardware with up to date UEFI and Shell, such as with the currebt Raspberry Pi 4 UEFI firmware.

This is also not a regression from 1.4, as version 1.3 of the drivers exhibit the same issue...

I seem to have an odd issue where recent versions of the EFI Shell are unable to switch to an ext4 filesystem:

The logging above the "fs0:" command is the output of a "dir fs0:" command, so the file system is working correctly.

With an earlier version of the shell (under VirtualBox, rather than KVM/Qemu) it can switch to the file system with no issue. I've also run the new version of shell under VirtualBox, and it exhibits the same issue. However, only the new version prints out those GetInfo lines, older versions print nothing when switching file systems, so it's clearly looking for something and not finding it.

I've tried tracing through where the EFI Shell source code, but I can't seem to find any obvious cause of this issue (I'm not familiar with the EFI source code).

Is it possible to port also LVM drivers from GRUB ?

I've been testing out v1.4 with the various versions of the EFI shell I've accumulated, and while two of them (the newest versions) work perfectly, one of them manages to cause a machine fault. I'm not entirely sure this is the drivers fault, as I would expect that on all the versions, but it may be the case some other field hasn't been initialised just right.

It's claiming it's version edk2-stable201905, and it's one that came with the OVMF firmware that's on Fedora, not one of the versions I've downloaded directly from their github page. Since it works with one of the other shells, it's not an urgent issue at all.

UEFI Interactive Shell v2.2
EDK II
UEFI v2.70 (EDK II, 0x00010000)
Mapping table
      FS0: Alias(s):HD0b:;BLK1:
          PciRoot(0x0)/Pci(0x9,0x0)/HD(1,GPT,95EE65AB-C835-4836-85F7-96EC40FE1AFB,0x100800,0x18FF000)
      FS1: Alias(s):HD0c:;BLK2:
          PciRoot(0x0)/Pci(0x9,0x0)/HD(2,GPT,5A066E88-433A-4141-AC41-5DB43836F215,0x800,0x100000)
     BLK0: Alias(s):
          PciRoot(0x0)/Pci(0x9,0x0)

Press ESC in 4 seconds to skip startup.nsh or any other key to continue.
Shell> fs0:
OpenVolume
GetInfo(BECCDD18|'/', 0) <DIR>
Get regular file information
GetInfo(BECCDD18|'/', 600) <DIR>
Get regular file information
Close(BECCDD18|'/') <ROOT>
OpenVolume
Open(BECCDD18 <ROOT>, "\")
  Reopening <ROOT>
  RET: BECCDD18
Close(BECCDD18|'/') <ROOT>
Close(BECCDD18|'/') <ROOT>
FS0:\> ls
OpenVolume
Open(BECCDD18 <ROOT>, ".")
  Reopening <ROOT>
  RET: BECCDD18
GetInfo(BECCDD18|'/', 0) <DIR>
Get regular file information
GetInfo(BECCDD18|'/', 600) <DIR>
Get regular file information
Close(BECCDD18|'/') <ROOT>
GetInfo(BECCDD18|'/', 0) <DIR>
Get regular file information
GetInfo(BECCDD18|'/', 600) <DIR>
Get regular file information
SetPosition(BECCDD18|'/', 0) <DIR>
Read(BECCDD18|'/', 602) <DIR>
Read(BECCDD18|'/', 602) <DIR>
Read(BECCDD18|'/', 602) <DIR>
Read(BECCDD18|'/', 602) <DIR>
Read(BECCDD18|'/', 602) <DIR>
Read(BECCDD18|'/', 602) <DIR>
Read(BECCDD18|'/', 602) <DIR>
Read(BECCDD18|'/', 602) <DIR>
Read(BECCDD18|'/', 602) <DIR>
Read(BECCDD18|'/', 602) <DIR>
Read(BECCDD18|'/', 602) <DIR>
Read(BECCDD18|'/', 602) <DIR>
Read(BECCDD18|'/', 602) <DIR>
error: not a regular file.
Unable to obtain the size of 'bin': [17]
Read(BECCDD18|'/', 602) <DIR>
error: not a regular file.
Unable to obtain the size of 'sbin': [17]
Read(BECCDD18|'/', 602) <DIR>
Read(BECCDD18|'/', 602) <DIR>
Read(BECCDD18|'/', 602) <DIR>
Read(BECCDD18|'/', 602) <DIR>
Read(BECCDD18|'/', 602) <DIR>
Read(BECCDD18|'/', 602) <DIR>
Read(BECCDD18|'/', 602) <DIR>
Read(BECCDD18|'/', 602) <DIR>
Read(BECCDD18|'/', 602) <DIR>
Read(BECCDD18|'/', 602) <DIR>
Close(BECCDD18|'/') <ROOT>
OpenVolume
Open(BECCDD18 <ROOT>, "\lost+found")
  RET: BEB2F998
Close(BECCDD18|'/') <ROOT>
OpenVolume
Open(BECCDD18 <ROOT>, "\.viminfo")
  RET: BEB31018
Close(BECCDD18|'/') <ROOT>
OpenVolume
Open(BECCDD18 <ROOT>, "\.ash_history")
  RET: BEB5F298
Close(BECCDD18|'/') <ROOT>
OpenVolume
Open(BECCDD18 <ROOT>, "\usr")
  RET: BEB5F518
Close(BECCDD18|'/') <ROOT>
OpenVolume
Open(BECCDD18 <ROOT>, "\sys")
  RET: BEB5F018
Close(BECCDD18|'/') <ROOT>
OpenVolume
Open(BECCDD18 <ROOT>, "\etc")
  RET: BEB60598
Close(BECCDD18|'/') <ROOT>
OpenVolume
Open(BECCDD18 <ROOT>, "\lib")
  RET: BEB60D18
Close(BECCDD18|'/') <ROOT>
OpenVolume
Open(BECCDD18 <ROOT>, "\proc")
  RET: BEB60018
Close(BECCDD18|'/') <ROOT>
OpenVolume
Open(BECCDD18 <ROOT>, "\dev")
  RET: BEB61498
Close(BECCDD18|'/') <ROOT>
OpenVolume
Open(BECCDD18 <ROOT>, "\boot")
  RET: BEB61E18
Close(BECCDD18|'/') <ROOT>
OpenVolume
Open(BECCDD18 <ROOT>, "\run")
  RET: BEB61018
Close(BECCDD18|'/') <ROOT>
OpenVolume
Open(BECCDD18 <ROOT>, "\pkgs")
  RET: BEC57E98
Close(BECCDD18|'/') <ROOT>
OpenVolume
Open(BECCDD18 <ROOT>, "\bin")
error: not a regular file.
Could not open file '\bin': [17]
Close(BECCDD18|'/') <ROOT>
OpenVolume
Open(BECCDD18 <ROOT>, "\sbin")
error: not a regular file.
Could not open file '\sbin': [17]
Close(BECCDD18|'/') <ROOT>
OpenVolume
Open(BECCDD18 <ROOT>, "\lib64")
  RET: BEB2EC18
Close(BECCDD18|'/') <ROOT>
OpenVolume
Open(BECCDD18 <ROOT>, "\var")
  RET: BEB2F598
Close(BECCDD18|'/') <ROOT>
OpenVolume
Open(BECCDD18 <ROOT>, "\root")
  RET: BEB2ED18
Close(BECCDD18|'/') <ROOT>
OpenVolume
Open(BECCDD18 <ROOT>, "\.bash_history")
  RET: BEB2E718
Close(BECCDD18|'/') <ROOT>
OpenVolume
Open(BECCDD18 <ROOT>, "\tmp")
  RET: BEB2DB98
Close(BECCDD18|'/') <ROOT>
OpenVolume
Open(BECCDD18 <ROOT>, "\system")
  RET: BEB2D918
Close(BECCDD18|'/') <ROOT>
OpenVolume
Open(BECCDD18 <ROOT>, "\mnt")
  RET: BEB2D298
Close(BECCDD18|'/') <ROOT>
OpenVolume
Open(BECCDD18 <ROOT>, "\home")
  RET: BEB2D518
Close(BECCDD18|'/') <ROOT>
OpenVolume
Open(BECCDD18 <ROOT>, "\srv")
  RET: BEB2D618
Close(BECCDD18|'/') <ROOT>
!!!! X64 Exception Type - 03(#BP - Breakpoint)  CPU Apic ID - 00000000 !!!!
RIP  - 00000000BE05CEB7, CS  - 0000000000000038, RFLAGS - 0000000000000246
RAX  - 0000000000000000, RCX - 0000000000000000, RDX - 0000000000000402
RBX  - 00000000BFF6FC70, RSP - 00000000BFF6FC40, RBP - 00000000000007FF
RSI  - 00000000000007FF, RDI - 00000000BEB31E30
R8   - 0000000000000001, R9  - 000000000000009F, R10 - 0000000000000000
R11  - 0000000000000000, R12 - 00000000BEC58E18, R13 - 00000000BFF6FF40
R14  - 0000000000000000, R15 - 00000000BF09F818
DS   - 0000000000000030, ES  - 0000000000000030, FS  - 0000000000000030
GS   - 0000000000000030, SS  - 0000000000000030
CR0  - 0000000080010033, CR2 - 0000000000000000, CR3 - 00000000BFC01000
CR4  - 0000000000000668, CR8 - 0000000000000000
DR0  - 0000000000000000, DR1 - 0000000000000000, DR2 - 0000000000000000
DR3  - 0000000000000000, DR6 - 00000000FFFF0FF0, DR7 - 0000000000000400
GDTR - 00000000BFBEE698 0000000000000047, LDTR - 0000000000000000
IDTR - 00000000BF5AF018 0000000000000FFF,   TR - 0000000000000000
FXSAVE_STATE - 00000000BFF6F8A0
!!!! Find image based on IP(0xBE05CEB7) /builddir/build/BUILD/edk2-edk2-stable201905/Build/OvmfX64/DEBUG_GCC5/X64/ShellPkg/Application/Shell/Shell/DEBUG/Shell.dll (ImageBase=00000000BDFFA000, EntryPoint=00000000BE051258) !!!!

I want to try and use the btrfs efi module (replacing the factory fat module with this custom btrfs module in a psychical motherboard's firmware) to boot an efistub linux kernel from a "whole-disk" type btrfs (no partitions but "mkfs.btrfs /dev/sda").

Is it even possible if the system root is a non-default subvolume? Does this module automatically load all sub-volumes as directories?

Can I use efibootmgr to create an efi boot entry for this?
The only problem I see is efibootmgr assuming a partition (preferably an EFI System type partition, I guess) rather than a disk (there is a --part option but I think it defaults to 1, thus excluding it doesn't mean it points to the disk instead of a partition).

A slight extra: it would be a RAID-1 profile btrfs but it should not matter as long as it's a true read-only mount...

This way everything could be kept on check-summed and redundant storage while getting rid of all the "legacy" tools such as disk partitions, bios boot loaders, and old filesystems (FAT).

Any plans to add the ability to decrypt encrypted /boot partitions? It seems like full disk encryption for linux installations is becoming more common, and this would allow for tighter control of one's boot partition and/or bootloader.

Thoughts?

This may be an inappropriate place to ask, and please excuse me, if so. But it may be related the the driver code, not just a particular shell, so here goes.

I have the latest versions of your wonderful library of drivers and have compiled them using both VS2019 Enterprise and EDK2 (2020-08-10 chain) targeting =x64. Everything works well in QEMU with OVMF but in VMWare Workstation Pro's shell (version 2.31 - the latest), although loading the ntfs_x64.efi driver returns success, most commands that query ANY disk i/o (not just ntfs or the device it's on) cause the shell to hang. Certainly map -r or reconnect -r cause a hang.

I also noticed a similar issue with QEMU and OVMF when the virtual disk image was created with various tools or configurations. Things as simple as creating and initializing a raw image in Disk Management as GPT, then partitioning it with a protective partition, an ESP (FAT32) partition, and an NTFS partition. QEMU boots the shell but hangs after loading the ntfs_x64.efi driver and trying to connect the 3rd (NTFS) partition. The ESP partition was fine.

Thanks for the project and thanks for any help you might suggest.

I'm unable to boot recent (> 5.7) kernels with your xfs (probably f2fs too) driver.
Refind output is: ERROR: buffer too small
If I try to load from EFI shell, then I got:

ERROR: Unable to load file info
ERROR: Unable to load initramfs

5.4.77 kernel boots via both Refind and EFI Shell. Both 5.4.77 and 5.9.8 boot via GRUB 2.04.
I don't know how to get any debug logging for this, set FS_LOGGING 4 doesn't apply to this.

xfs driver v1.5
Archlinux, kernel 5.9.8
MoBo MSI Z390 MPG Gaming Edge

Using a Dell Latitude 5285, rEFInd bootloader, Arch Linux and 1.7 efifs drivers I have tried to boot into ZFS in a try to automate some kind of auto snapshotting.

First rEFInd boots, try to boot the entry configured with ZFS and this logs pops:

EFI stub: ERROR: filed to get file info
Error: Buffer Too Small returned from vmlinuz-linux

These logs looks seems to change randomly to some like these

error: compression algorithm 114 not supported
error: compression algorithm 32 not supported
error: compression algorithm 32 not supported
error: compression algorithm 32 not supported
error: compression algorithm 32 not supported
error: compression algorithm 114 not supported
error: compression algorithm 32 not supported
error: compression algorithm 32 not supported
error: compression algorithm 32 not supported
error: compression algorithm 32 not supported
error: compression algorithm 114 not supported
error: compression algorithm 32 not supported
error: compression algorithm 32 not supported
error: compression algorithm 32 not supported
error: compression algorithm 32 not supported
EFI stub: ERROR: filed to get file info
Error: Buffer Too Small returned from vmlinuz-linux

error: unknown device -103311030
error: unknown device -103311030
error: unknown device -103311030
error: unknown device -103311030
error: unknown device -103311030
error: unknown device -103311030
error: unknown device -103311030
error: unknown device -103311030
error: unknown device -103311030
error: unknown device -103311030
error: unknown device -103311030
error: unknown device -103311030

error: compression algorithm inherit not supported
error: unsupported embedded BP (type=47)
error: unsupported embedded BP (type=47)
error: unsupported embedded BP (type=47)
error: unsupported embedded BP (type=47)
error: compression algorithm inherit not supported
error: unsupported embedded BP (type=47)
error: unsupported embedded BP (type=47)
error: unsupported embedded BP (type=47)
error: unsupported embedded BP (type=47)
error: compression algorithm inherit not supported
error: unsupported embedded BP (type=47)
error: unsupported embedded BP (type=47)
error: unsupported embedded BP (type=47)
error: unsupported embedded BP (type=47)
EFI stub: ERROR: filed to get file info
Error: Buffer Too Small returned from vmlinuz-linux

error: compression algorithm inherit not supported
error: compression algorithm 115 not supported
error: compression algorithm 115 not supported
error: compression algorithm 115 not supported
error: compression algorithm 115 not supported
EFI stub: ERROR: filed to get file info
EFI stub: ERROR: Filed to load initrd!
EFI stub: ERROR: efi_main() failed!
Error: Buffer Too Small returned from vmlinuz-linux

This installation of Arch I have used a Kernel from the arch archive (5.7.12) to avoid bug #26 after finding these error I tryed to update to the lastest version (5.9) and logs looks the same.

I am aware that this projects uses GRUB fs and GRUB fs has limitations with zfs features: https://elixir.bootlin.com/grub/latest/source/grub-core/fs/zfs/zfs.c#L276
I created a pool that grub opens correctly.

Building in VS2019 errors:

Severity	Code	Description	Project	File	Line	Suppression State
Error	NETSDK1013	The TargetFramework value '' was not recognized. It may be misspelled. If not, then the TargetFrameworkIdentifier and/or TargetFrameworkVersion properties must be specified explicitly.	ntfs	C:\Program Files\dotnet\sdk\3.1.300\Sdks\Microsoft.NET.Sdk\targets\Microsoft.NET.TargetFrameworkInference.targets	93	

In my environment, the log output is messy after I set the FS_LOGGING efi variable.
After doing some research I found some clues.
It seems that Print_t is defined as follows:
typedef UINTN (*Print_t) (IN CONST CHAR16 *fmt, ... );

In function SetLogging the log function will be assigned with Print if log level is suitable.
But in EDK2 Print is defined with EFIAPI so that may be the problem.

I would like to use the drivers on my Mac but unfortunately they don't load.

I can boot up UEFT Shell v1 (v2 gives me a black screen) using Refind, then call load f2fs_x64.efi but it tell me the version is incompatible.

Could there be a way to make them compatible with Macs?

Hi! I was wondering if you know whether it's possible to use the UFS drivers from here with the rEFInd booloader. I tried downloading the latest ones and dropping them into rEFInd's drivers directory, but when I boot into refind, it shows the message "Load error returned from ufs(1|2)_x64.efi" for each of them.

Using refind 0.12.0-1 to boot debian bullseye. Refind does not even start when using the 1.6 version of f2fs efi driver. No problem with 1.5.

env

arch => x86_64
/efi => ESP partion
root partition => XFS
mkfs.xfs version 6.5.0 in archlinux livecd 2024.02.01

question

I format root partition with command mkfs.xfs /dev/sda2
install refind and put efifs diver xfs_x64.efi in /efi/EFI/refind/drivers_x86
but after boot into refind menu, it can't autoly show linux kernel boot option

I tried to set off mkfs.xfs -m bigtime=0 /dev/sda2 mentioned in #33 but it doesn't work
then set off -m inobtcount=0 -m finobt=0 -m rmapbt=0 and also doesn't work

I set off crc with mkfs.xfs -m crc=0 /dev/sda2 and finally linux kernel shows on refind, boot into linux.

In mkfs.xfs man page

Formatting a filesystem without CRCs selects the V4 format, which is deprecated and will be removed from upstream in September 2030. Distributors may choose to withdraw support for the V4 format earlier than this date. Several other options, noted below, are only tunable on V4 formats, and will be removed along with the V4 format itself.

Is xfs_x64.efi doesn't support xfs v5 with crc=1 which mkfs.xfs default parameter yet?

Trying to compile your Efifs driver in VS2017 and copied latest gnu-efi to the gnu-efi folder, copied grub v2.02 to the grub folder (also did a git clone with: git clone git://git.savannah.gnu.org/grub.git ) and when I compile I get a bunch of type conversion errors. Must because I need to apply those patches? On my system TortoiseSvn opens those patch files and when I apply and direct it to the grub folder it errors saying 'non working directory'. I've even tried the grub-core and fs folder without luck. Must not be correct way to apply the patches? Efin driving me crazy. Please help. Thanks

Pardon me for my ignorance on UEFI, but I was wondering if it would be at all possible via the iso9660.efi driver to mount an .iso file.