Closed kang-makes closed 1 year ago
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.
@kangco-de did you resolve your issue? I may be having the same or similar issue.
@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.
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.
@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.
@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.
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...
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:
These logs looks seems to change randomly to some like these
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.