On Mon, Mar 07, 2016 at 07:57:21PM +0000, Vladimir 'phcoder' Serbinenko wrote: > > > > Well, I have a bunch of patches that need to be clean up (or even > > > > re-examined), and I've also got the secure-boot branch here: > > > > > > > > https://github.com/vathpela/grub2-fedora/tree/sb > > > > > > > > Which is all the patches distros should be carrying to work with Secure > > > > Boot correctly. This branch is also recently rebased against master, > > > > though I'm not sure what the current thinking is regarding their path > > > > upstream. > > > > > > > > > > Personally I'd rather include support for it. I'm tired of linux vs. > > > linuxefi nightmare, and patches have been in the wild long enough. > > > > So what's the path forward, then? Just make all efi use linuxefi, like > > linux vs linux16? That's pretty close to what I've got already, except > > on arm where it's just "linux" in EFI mode as well. But we could make > > those aliases for the same thing on that platform easily enough. Or do > > you have something else in mind? > > RedHat/Fedora config is too platform-dependent and platform is detected at > mkconfig time rather than at runtime. This is a problem as runtime and > mkconfig can be different. Case that I see often is coreboot failing due to > use of Linux16 (which is a valid protocol for coreboot and is used for > memtest but Linux crashes with it) but other cases exist, like enabling or > disabling of SCM or moving disk to another computer. Can we fix this by > introducing some helper to detect it on runtime? It can either be a > function or a real command
Yeah, we can do something in the config file based on a platform variable, and then setting the actual commands that way. I'm curious as to why you think "linux16" doesn't work for Linux, though. We use it 100% of the time in Fedora and RHEL, and upstream x86 kernel maintainers have expressed a preference for it. Using "linux" instead seems to break much more, for example EDD often does not ever get exposed to the kernel when it's used. -- Peter _______________________________________________ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel