[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Sending Information to GRUB from a (U)EFI Program
From: |
Jordan Uggla |
Subject: |
Re: Sending Information to GRUB from a (U)EFI Program |
Date: |
Sun, 10 Nov 2013 19:51:56 -0800 |
On Sun, Nov 10, 2013 at 1:10 PM, SevenBits <address@hidden> wrote:
> Hello everyone,
>
> It's my first time posting here, and I don't know if this should really be
> in grub-devel or here, so please correct me if I emailed this to the wrong
> list.
I'd say that the first place you should ask such questions is here, as
for all you know all of the needed functionality already exists in
grub, and questions about how to use existing functionality are
(usually) not appropriate for grub-devel. As far as I know there is no
way, in current upstream grub source, to pass information from another
bootloader to grub, and it seems like a useful thing to be able to do,
but I'm not convinced that what you are doing requires this. My
recommendation would be to try to flesh out your plan more, given the
information below, and then start a grub-devel thread about desired
additional functionality.
>
> I'm a developer of Mac Linux USB Loader and Enterprise, a two-piece software
> program to help boot GNU/Linux on Apple Macintosh computers with (U)EFI.
> Macs have a slightly off (U)EFI firmware implementation that makes it
> largely futile to boot even the simplest of distributions on Mac. The
I was using Ubuntu via EFI on a macbook pro years ago, and I was under
the impression that (aside from hardware drivers being more likely to
be a problem than with other x86 machines) both Ubuntu and Fedora
handle Macs just fine. I haven't had much personal experience with it
lately though.
> program consists of two parts, both open source: the front end Mac Linux USB
> Loader, a Mac application, and Enterprise, a (U)EFI application.
What functionality is grub missing that makes you want to use two UEFI
applications rather than just one (grub)?
>
> The firmware I am currently using consists wholly of a compiled (U)EFI GRUB
"Firmware" generally refers to the code loaded from storage on the
motherboard itself, using the word "firmware" to describe a UEFI
application is at best odd, and could lead to confusion.
> image I found on the Internet. I believe it is using a patched copy of GRUB,
> and, in violation of the GPL, the author never provided the source code.
This is something that would be good to bring up on grub-devel, so
that the project can decide if they want to try to take action in
response to this GPL violation.
> Since attempts to contact him or her were in vain, I decided to code my own
> solution. And here we are.
>
> My (U)EFI boot manager program, Enterprise, which you can find on GitHub,
> allows the user to specify which Linux kernel options they wish to use to
> boot Linux. My goal is to pass these options to a pre-compiled GRUB image
> that I distribute with Enterprise, which will load the GNU/Linux
> distribution from a supplied ISO file using GRUB's loopback and iso9660 file
> system support (you can view some more info on this here on my blog). My
> struggle is how to modify GRUB to enable this to happen.
>
> I can already create a pre-compiled GRUB image with an embedded
> configuration file. Trouble is, I must hard-code the locations to the Linux
> kernel image and the initial RAM disc in the ISO file, which in effect locks
> it in to one distribution.
Another solution to this is to load that distribution's loopback.cfg,
http://www.supergrubdisk.org/wiki/Loopback.cfg and I'd personally much
rather see that at least supported than depending on the user to know
the proper distribution specific paths and kernel parameters, or
trying to do distro detection and hard coding static values (I tried
to do this with Super GRUB2 Disk, and with how distributions change,
and with how many there are, it's not manageable).
> It also doesn't allow the user to specify their
> own kernel parameters. I'd like to change this.
While the looopback.cfg "protocol" doesn't explicitly specify a way
for passing additional custom kernel parameters, grml's looback.cfg
does support this, and I'd be willing to look at trying to standardize
that as well.
>
> If anyone has any ideas regarding how I could implement a solution like
> this, I would be grateful. I'm fluent in C and understand the (U)EFI system
> call framework and can modify GRUB's source code, so the actual
> implementation of your suggestions won't be an issue. I'd just like to know
> the most efficient way to transfer small amounts of data from Enterprise to
> GRUB.
This sounds like a cool project, thank you for working on it and I
think that you'll find that Vladimir Serbinenko (phcoder), the lead
developer of GRUB, is very responsive to requests for features to
support projects like yours, where they make sense. He and other
developers have implemented many new features that I've asked for as
part of my work on Super GRUB2 Disk, and often in working with the
GRUB developers I end up with something fairly different than what I
originally thought I wanted, but much cleaner in the end.
--
Jordan Uggla (Jordan_U on irc.freenode.net)