Hey all, I'm interested in trying to enable support for boot-time modification of the grubenv file on ZFS and other non-standard filesystems that don't necessarily work today. I have a proposed design, and I was wondering if you all would be interested in it. I'd be implementing it and testing it myself, my main goal was to try to make sure that after doing so, the community would be interested in integrating it. This has the dual advantage of allowing everyone using ZFS and other filesystems to benefit from it, and also making it so I don't have to maintain a fork indefinitely.
The proposal is that rather than always opening the grubenv file and reading it using the normal file API, we can add a function (or functions) to the fs struct that allows a filesystem to advertise that it needs to use special logic to handle writable files. Then the grubenv file can be stored in a special location (probably one of that padding areas in the label, which is where the FreeBSD loader stores some boot data in zfs) where it can be written safely by the bootloader without harming the checksum tree in ZFS. The GRUB code would need to change to invoke the special "Please let the fs handle this writable file" logic (which would have open, read, and write functions) for filesystems that have them available, but this should be extensible to other CoW or sparse filesystems like BTRFS. If a filesystem doesn't advertise that logic, GRUB would fall back to using the currently file-based logic. An alternative proposal that I found slightly less elegant but would involve fewer invasive changes is to just modify the zfs grub logic to check if it's opening the grubenv file, and if so divert to special read and open logic that would access this padding area. This would involve hardcoding the grubenv file name in the ZFS code, but I figured I would mention it as a possibility in case it was preferred for other reasons. Do people have thoughts or opinions about this concept and this design? I would greatly appreciate any feedback or thoughts on alternative approaches. Thank you for your time and attention! -- Paul Dagnelie
_______________________________________________ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
