ZFS Drivers does not seems to work

[kang-makes]

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.

[pbatard]

Please try to access the same file as the kernel accesses from a UEFI shell (e.g. copy from the ZFS partition to a removable FAT drive) after issuing set FS_LOGGING 4 in the shell and see the output you get there. Or just try to issue a dir from the shell, since kernel reports that it can't get file info and dir will access file info.

I'm afraid I'm not planning to experiment with Linux kernels (especially as I want to isolate that the issue isn't with the software that loads kernel/initrd), so I will need your help providing enough troubleshooting details from the shell.

If this is an issue with EfiFs, then you should be able to replicate it from the shell by simply trying to access the same files.

[rharmonson]

@kangco-de did you resolve your issue? I may be having the same or similar issue.

[rharmonson]

@pbatard, this is new to me, but I thought I give the EFI shell a go as you asked the OP.

I used rEFInd's EFI internal shell and loaded the zfs_x64.efi (1.7), map -r, and walked through the file structure. Using zpool bpool and sys/BOOT/default/@, I get a bunch of the compression algorithm errors when entering or ls the @ dir then it displays the expected vmlinux and initramfs files. My suspicion is the errors break rEFInd, for I see the error flash then return to rEFInd menu options when attempting to load using the rEFInd stanza.

Googling, I found a question that may be related.
https://unix.stackexchange.com/questions/447960/how-to-create-a-zfs-zpool-that-grub-can-read#450516

As described in the link, my bpool and sys/BOOT/default work fine as long as I use grub 2.04-10 from Arch's repo.

I am using Artix (Arch) Linux, and the archzfs repo; linux-lts and zfs-dkms. I used OpenZFS Arch installation steps, mostly. I am using Artix with runit, so..

The steps I took to test your zfs drivers from the EFI shell.

Using rEFInd, copying zfs_x64.efi 1.7 to the esp, and EFI internal shell, it displays FS0, BLK0, BLK1, BLK3, and BLK4.

FS0:
load zfs_x64.efi

Results

Image 'FS0:\zfs_x64.efi' loaded at DDCEC000 - Success

map -r

Results with the addition of FS1:

FS1: Alias(s):HD1a65535a2:;BLK3:
PciRoot(0x0)/Pci(0xD,0x0)/Sata(0x0,0xFFFF,0x0)/HD(2,GPT,93739539-8C5F-47F4-A881-06E5320EE6BA,0x200800,0x800000)

Using ls shows the expected ESP.

03/16/2021  20:02 <DIR>  4,096 EFI
03/16/2021  08:17             90,848 zfs_x64.efi
                 1 File(s)    90,848 bytes
                 1 Dir(s)

Moving to FS1: and using ls.

Directory of: FS1:\
03/14/2021  16:21 <DIR> r               0  @
03/14/2021  16:21 <DIR> r               0 sys

My boot zpool and dataset are bpool/sys/BOOT/default

cd to sys, BOOT, then default works fine. However, when I ls "@," I get the following a bunch of times

error: compression algorithm inherit not supported

then lists the expected files including vmlinux and initramfs.

[kang-makes]

My computer broke and I am having problems with some tooling which I had no backup.

I will not test this in a month or so because this is also for a personal project I do in my spare time.

You have describe exactly the same problem I found that made me open this issue.

[rharmonson]

@kang-makes

Sorry to hear about your computer.

Using the EFI Shell and executing

vmlinuz-linux-lts root=ZFS=rpool/sys/ROOT/default rw initrd=/initramfs-linux-lts.img

results with the algorithm and other errors similar but not exactly the same as your own. Unclear if we are having the same problem, but something is wrong be it my implementation or a bug.

grub works, but I am not interested in using it. I am going to spend a couple more hours ensuring the ZFS pool is configured to meet (grub's) requirements and check my tasks and configuration against OpenZFS Quick Start guide for the nth time. If I do not find the problem, I am going to find a palatable if not ideal solution that doesn't require zfs_x64.efi.

[rharmonson]

@kang-makes

I have a solution that doesn't use the zfs driver and I am very happy with it. It uses an EFI stub, mkinitcpio, and a hook.

I hope to have instructions publish at https://techore.gitlab.io/ in the next week or two. It's really about making time. You can get my attention using "Issues" for the repository if you are looking for it and cannot find it. Again, give me a couple weeks.

[pbatard]

See #38#issuecomment-1236164699

This is basically a kernel issue with the fixed size structure they are using to retrieve the initrd/initramfs data.
Now, we could work around this in EfiFs by reducing the default size of our own structure, and we probably will do that, but ultimately, the kernel should not expect that the Info buffer's MAX_FILE_NAME_LEN will be less than 512 bytes, especially as there are counter examples of this in the UEFI code...