On Tue, Feb 12, 2019, 7:10 AM Javier Martinez Canillas <javier@dowhile0.org wrote:

I see, I would had thought that the advice would had been to use
grub-editenv create instead. But still grub2-editenv create will only
prevent removing the symlink, it won't help with the issue of the
kernelopts variable not being set.

We should make editing the grubenv more reliable to avoid these issues.


There is another complication with writing to grubenv from the pre-boot environment. It was designed for simple filesystems like FAT and ext2. It can't work on software/firmware RAID and Btrfs - because modifications outside kernel code immediately makes those volumes invalid. GRUB disallows writes to Btrfs volumes, and perhaps also mdadm and LVM (but I haven't tested them). GRUB permits writes to XFS but XFS upstream devs consider it proscribed to write to an XFS volume outside xfs-progs or kernel code. The ext4 developers are more tolerant, but my take is that they'd really prefer GRUB write to the reserve areas for the bootloader instead. These reserve areas for bootloaders are in different locations and are of different sizes depending on the file system.

In the short term it means any features depending on writing to grubenv from pre-boot GRUB (as opposed to Linux user space GRUB tools), can only be expected on UEFI (grubenv is always on FAT), or if on BIOS only with default (automatic) partitioning. That might be an acceptable limitation.

---
Chris Murphy