GNOME Bugzilla – Bug 762220
Allow for more flexibility in generating grub.cfg
Last modified: 2016-04-13 12:55:31 UTC
Created attachment 321540 [details] [review] Patch to disable grub2-mkconfig usage Hard-coding grub settings in _ostree_bootloader_grub2_generate_config() is not an optimal solution. Comment from "grub2-15_ostree": # Pick up stuff from grub's helper that we want to inject into our # generated bootloader configuration. Yes, this is pretty awful, but # it's a lot better than reimplementing the config-generating bits of # OSTree in shell script. I tried reimplementing this logic in shell and it results in more flexible approach in my experience, see the attached patch with sample 'ostree-grub-generator' configuration. This custom ostree-grub-generate script can call grub2-mkconfig if desired. The attached sample file simply converts boot loader entries into grub.cfg and adds custom header. Yocto scripts for example do not attempt to chroot sysroot, it simply runs python script to generate grub.cfg where some values can be altered via exposed variables, so similar to ostree-grub-generator. The attached patch is a sample to demonstrate the approach, a final patch would need to keep a backward compatibility with grub2-mkconfig approach. if (OSTREE_NO_GRUB2_MKCONFIG) procctx = gs_subprocess_context_newv ("ostree-grub-generator", "-o", else procctx = gs_subprocess_context_newv ("grub2-mkconfig", "-o", This case relates to: https://bugzilla.gnome.org/show_bug.cgi?id=761180
Created attachment 321541 [details] sample configuration generator
Review of attachment 321540 [details] [review]: A compile time option like --with-grub2-generator=/usr/libexec/myos-grub2-generate would be pretty simple, right? Then it'd just default to grub2-generate. And if provided we'd not install 15_ostree. I'm a little uncertain about encouraging people to parse the loader snippets as well. But, they're intentionally simple, so eh.
It seems like what you're avoiding wrt performance is the grub2-probe stuff right? Certainly on an embedded system it makes no sense to try to look for Windows (or other distributions, etc.) installations every time a kernel is installed... I'm totally open to making this area of code flexible - my high level concern is that we avoid *too* many special cases and try to drive standardization across distributions as much as possible.
I was thinking of having a new argument "--with-grub2-mkconfig" (this would be dafault), and if it is explicitly disabled --with-grub2-mkconfig=no, then use some other name for a script to execute, like "ostree-grub-generator". ostree-grub-generator should be name that does not change, it is OS installer task to do something like: cp ostree-grub-generator-intel-nuc /usr/sbin/ostree-grub-generator Then it would be easier to find this script on a device, as it has one defined name. And thinking from build system side of view (for example yocto), it is simpler to write one recipe that has --with-grub2-mkconfig=no then adjusting: --with-grub2-generator=/usr/libexec/my_os-grub2-generate --with-grub2-generator=/usr/libexec/my_other_os-grub2-generate for different device builds. > It seems like what you're avoiding wrt performance is the grub2-probe stuff right? That is one reason. Other is that I would prefer not to install grub package on a device. > my high level concern is that we avoid *too* many special cases and try to drive standardization across distributions as much as possible. Embedded often is a special case. I think this approach adds reasonable level of flexibility and does not brake backward compatibility.
(In reply to gatis.paeglis@theqtcompany.com from comment #4) > I was thinking of having a new argument "--with-grub2-mkconfig" (this would > be dafault), and if it is explicitly disabled --with-grub2-mkconfig=no, then > use some other name for a script to execute, like "ostree-grub-generator". > ostree-grub-generator should be name that does not change, it is OS > installer task to do something like: That sounds fine to me, although I'd put it outside of $PATH i.e. /usr/libexec to avoid an extra character of typing in bash completion. > That is one reason. Other is that I would prefer not to install grub package > on a device. Ah yes, true. Indeed, grub2 has way too much internal static linking between the tools > Embedded often is a special case. I think this approach adds reasonable > level of flexibility and does not brake backward compatibility. Agreed, it's OK by me. Are you going to do an updated patch?
> i.e. /usr/libexec to avoid an extra character of typing in bash completion. This path does not exists on Ubuntu, or as it seems any debian based distribution. Not sure if there are other standard path with a similar purpose. Maybe that script should have a check, if it was called from interactive shell then it prints warning and exits. But that does not solve typing extra character issue. > Are you going to do an updated patch? Yes, I can make a patch and push it on github, end of this week or next week.
(In reply to gatis.paeglis@theqtcompany.com from comment #6) > > i.e. /usr/libexec to avoid an extra character of typing in bash completion. > > This path does not exists on Ubuntu, or as it seems any debian based > distribution. Yeah, https://www.google.com/search?q=debian+libexec&ie=utf-8&oe=utf-8 Using $libdir/$(PACKAGE) is also fine. (I've been meaning to move the switch-root binaries there for the same reason)
Pull request in https://github.com/GNOME/ostree/pull/216 :)
This has been fixed.