Andrew Lutomirski wrote:
> 2 .If I want to edit boot options, grubby makes it unnecessarily
> painful, and the directions are simply wrong. For example, my
> /etc/grub2-efi.cfg says:
>
> #
> # DO NOT EDIT THIS FILE
> #
> # It is automatically generated by grub2-mkconfig using templates
> # from /etc/grub.d and settings from /etc/default/grub
> #
>
> That's grossly misleading. It *was* automatically generated, but it
> is certainly not automatically generated on an ongoing basis. If I
> change settings in /etc/default/grub, nothing happens. If I actually
> want to change boot options, I have to either manually edit every
> instance (or somehow, magically, the correct subset of copies) in
> /etc/grub2-efi.cfg, which is a real pain and easy to screw up. Or I
> can cross my fingers any try to figure out the right invocation to
> just regenerate the whole thing (grub2-mkconfig >/etc/grub2-efi.cfg,
> presumably). Assuming that such an incantation exists (which it does
> these days!), one wonders why it's not happening automatically on
> kernel upgrades.
There are several issues with the current approach:
* Our approach to updating grub.cfg differs from the approach recommended
and documented by upstream.
* As you pointed out, even the documentation IN the file we ship
misleadingly documents the upstream approach and not the one we are
actually using. (At least that part would be easily fixable though, by
patching the boilerplate grub.cfg header in grub2-mkconfig.)
* Any third-party configuration tools such as kcm_grub2 expect the upstream
mechanisms, because we are pretty much the only distro that bypasses them.
Thus, they WILL rerun grub2-mkconfig, and any changes you or grubby
manually made to the file will be overwritten.
Now our approach does have the advantage that you have more detailed control
over the contents of the file than with grub2-mkconfig (though you have to
be careful not to confuse grubby). I am torn as to whether this is enough
justification for continuing to ignore upstream's recommended configuration
system.
Kevin Kofler
--
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
http://lists.fedoraproject.org/admin/lists/devel@xxxxxxxxxxxxxxxxxxxxxxx
