Skip to contentSkip to conversation

grub-install for EFI

PATCH In review Robert Millan 2 participants 18 messages May 11, 2007 – May 20, 2007

lore
Share & tools
lore

Robert Millan

author
#0 lore raw

PATCH 1/1 grub-install for EFI

Hi,

Please have a look at this patch that adds grub-install for EFI and tell me what you think. I have some doubts/comments myself, and I'll reply to my own message to use the patch context.

Signature · 4 lines
Robert Millan

My spam trap is [email protected].  Note: this address is only intended
for spam harvesters.  Writing to it will get you added to my black list.
conf/i386-efi.rmk +9 -8
diff -Nur grub2-1.95+20070507.old/conf/i386-efi.rmk grub2-1.95+20070507/conf/i386-efi.rmk
@@ -6,7 +6,7 @@
 
 # Utilities.
 bin_UTILITIES = grub-mkimage
-#sbin_UTILITIES = grub-setup grub-mkdevicemap grub-probe
+sbin_UTILITIES = grub-mkdevicemap grub-probe
 #ifeq ($(enable_grub_emu), yes)
 #sbin_UTILITIES += grub-emu
 #endif

@@ -24,15 +24,16 @@
 #	kern/fs.c kern/env.c fs/fshelp.c
 
 # For grub-mkdevicemap.
-#grub_mkdevicemap_SOURCES = util/i386/pc/grub-mkdevicemap.c util/misc.c
+grub_mkdevicemap_SOURCES = util/i386/pc/grub-mkdevicemap.c util/misc.c
 
 # For grub-probe.
-#grub_probe_SOURCES = util/i386/pc/grub-probe.c	\
-#	util/i386/pc/biosdisk.c	util/misc.c util/i386/pc/getroot.c	\
-#	kern/device.c kern/disk.c kern/err.c kern/misc.c fs/fat.c	\
-#	fs/ext2.c kern/parser.c kern/partition.c partmap/pc.c fs/ufs.c 	\
-#	fs/minix.c fs/hfs.c fs/jfs.c kern/fs.c kern/env.c fs/fshelp.c 	\
-#	fs/xfs.c fs/affs.c fs/sfs.c fs/hfsplus.c
+grub_probe_SOURCES = util/i386/pc/grub-probe.c	\
+	util/i386/pc/biosdisk.c	util/misc.c util/i386/pc/getroot.c	\
+	kern/device.c kern/disk.c kern/err.c kern/misc.c fs/fat.c	\
+	fs/ext2.c kern/parser.c kern/partition.c partmap/pc.c		\
+	partmap/gpt.c fs/ufs.c fs/minix.c fs/hfs.c fs/jfs.c kern/fs.c	\
+	kern/env.c fs/fshelp.c fs/xfs.c fs/affs.c fs/sfs.c fs/hfsplus.c	\
+	disk/lvm.c disk/raid.c
 
 # For grub-emu.
 grub_emu_DEPENDENCIES = grub_script.tab.c grub_script.tab.h		\
util/i386/efi/grub-install.in +206 -0

206 lines not on this page · raw message

util/i386/pc/biosdisk.c +1 -1
diff -Nur grub2-1.95+20070507.old/util/i386/pc/biosdisk.c grub2-1.95+20070507/util/i386/pc/biosdisk.c
@@ -18,7 +18,7 @@
  *  Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
  */
 
-#include <grub/machine/biosdisk.h>
+#include <grub/i386/pc/biosdisk.h>
 #include <grub/disk.h>
 #include <grub/partition.h>
 #include <grub/pc_partition.h>
util/i386/pc/grub-probe.c +1 -1
diff -Nur grub2-1.95+20070507.old/util/i386/pc/grub-probe.c grub2-1.95+20070507/util/i386/pc/grub-probe.c
@@ -26,7 +26,7 @@
 #include <grub/fs.h>
 #include <grub/partition.h>
 #include <grub/pc_partition.h>
-#include <grub/machine/util/biosdisk.h>
+#include <grub/i386/pc/util/biosdisk.h>
 #include <grub/util/getroot.h>
 #include <grub/term.h>
author
#1 lore raw

conf/i386-efi.rmk line 9

Quoted 9 lines · Robert Millan

diff -Nur grub2-1.95+20070507.old/conf/i386-efi.rmk grub2-1.95+20070507/conf/i386-efi.rmk

conf/i386-efi.rmk +1 -1
@@ -6,7 +6,7 @@
 
 # Utilities.
 bin_UTILITIES = grub-mkimage
-#sbin_UTILITIES = grub-setup grub-mkdevicemap grub-probe
+sbin_UTILITIES = grub-mkdevicemap grub-probe

grub-probe is needed to check partmap (so we don't have to assume gpt).

grub-mkdevicemap is needed to create device.map, without which grub-probe won't work.

util/i386/efi/grub-install.in

Quoted 3 lines

diff -Nur grub2-1.95+20070507.old/util/i386/efi/grub-install.in grub2-1.95+20070507/util/i386/efi/grub-install.in

util/i386/efi/grub-install.in +0 -0

Note: this grub-install.in is based on the i386/pc version. I tried to keep changes minimal, so if you diff them it'll produce readable output.

One thing that I'm not sure about is the CLI inconsistency. Perhaps it shouldn't take the directory as a standalone parameter, and instead use --root-directory?

Quoted 16 lines

diff -Nur grub2-1.95+20070507.old/util/i386/pc/biosdisk.c grub2-1.95+20070507/util/i386/pc/biosdisk.c

util/i386/pc/biosdisk.c +1 -1
@@ -18,7 +18,7 @@
  *  Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
  */
 
-#include <grub/machine/biosdisk.h>
+#include <grub/i386/pc/biosdisk.h>
 #include <grub/disk.h>
 #include <grub/partition.h>
 #include <grub/pc_partition.h>

diff -Nur grub2-1.95+20070507.old/util/i386/pc/grub-probe.c grub2-1.95+20070507/util/i386/pc/grub-probe.c

util/i386/pc/grub-probe.c line 31

Quoted 7 lines
util/i386/pc/grub-probe.c +1 -1
@@ -26,7 +26,7 @@
 #include <grub/fs.h>
 #include <grub/partition.h>
 #include <grub/pc_partition.h>
-#include <grub/machine/util/biosdisk.h>
+#include <grub/i386/pc/util/biosdisk.h>
 #include <grub/util/getroot.h>
 #include <grub/term.h>

Not really sure about these. Seems ugly, but biosdisk.h has the grub_util_biosdisk_get_grub_dev definition, which is not really i386/pc-specific. Also, note that powerpc needs them as well if we want update-grub to work there (haven't submitted this part, because it grub-probe on powerpc has other issues that I cannot debug).

Signature · 4 lines
Robert Millan

My spam trap is [email protected].  Note: this address is only intended
for spam harvesters.  Writing to it will get you added to my black list.
author
#2 lore raw
Quoted 4 lines · Robert Millan

One thing that I'm not sure about is the CLI inconsistency. Perhaps it shouldn't take the directory as a standalone parameter, and instead use --root-directory?

Or perhaps it should do like powerpc and check that /boot/grub is a mount point?

# Find the partition at the right mount point. install_device=awk '$2 == '"\"$grubdir\""' { print $1 }' < /proc/mounts if test "x$install_device" = x; then
echo "$grubdir must be a mount point."
exit 1
fi

Signature · 4 lines
Robert Millan

My spam trap is [email protected].  Note: this address is only intended
for spam harvesters.  Writing to it will get you added to my black list.
author
#3 lore raw

new patch

New patch. Fixed a few errors, enabled grub-install in sbin_SCRIPTS, and made the CLI consistent with the other grub-installs.

The patch works in my qemu environment [1], so I've added it in Debian already. If nobody objects, or reports that the patch is wrong whatsoever, I'll add it to CVS in a few days.

Btw, since my new grub-install is based on the PC version and they're very similar, I've also attached a diff between both versions so you can't check more easily.

[1] Still, grub boots but can't access my filesystems. But this seems completely unrelated to grub-install, and probably caused by firmware bugs.

Signature · 4 lines
Robert Millan

My spam trap is [email protected].  Note: this address is only intended
for spam harvesters.  Writing to it will get you added to my black list.
conf/i386-efi.rmk +11 -10
diff -Nur grub2-1.95+20070507.old/conf/i386-efi.rmk grub2-1.95+20070507/conf/i386-efi.rmk
@@ -6,7 +6,7 @@
 
 # Utilities.
 bin_UTILITIES = grub-mkimage
-#sbin_UTILITIES = grub-setup grub-mkdevicemap grub-probe
+sbin_UTILITIES = grub-mkdevicemap grub-probe
 #ifeq ($(enable_grub_emu), yes)
 #sbin_UTILITIES += grub-emu
 #endif

@@ -24,15 +24,16 @@
 #	kern/fs.c kern/env.c fs/fshelp.c
 
 # For grub-mkdevicemap.
-#grub_mkdevicemap_SOURCES = util/i386/pc/grub-mkdevicemap.c util/misc.c
+grub_mkdevicemap_SOURCES = util/i386/pc/grub-mkdevicemap.c util/misc.c
 
 # For grub-probe.
-#grub_probe_SOURCES = util/i386/pc/grub-probe.c	\
-#	util/i386/pc/biosdisk.c	util/misc.c util/i386/pc/getroot.c	\
-#	kern/device.c kern/disk.c kern/err.c kern/misc.c fs/fat.c	\
-#	fs/ext2.c kern/parser.c kern/partition.c partmap/pc.c fs/ufs.c 	\
-#	fs/minix.c fs/hfs.c fs/jfs.c kern/fs.c kern/env.c fs/fshelp.c 	\
-#	fs/xfs.c fs/affs.c fs/sfs.c fs/hfsplus.c
+grub_probe_SOURCES = util/i386/pc/grub-probe.c	\
+	util/i386/pc/biosdisk.c	util/misc.c util/i386/pc/getroot.c	\
+	kern/device.c kern/disk.c kern/err.c kern/misc.c fs/fat.c	\
+	fs/ext2.c kern/parser.c kern/partition.c partmap/pc.c		\
+	partmap/gpt.c fs/ufs.c fs/minix.c fs/hfs.c fs/jfs.c kern/fs.c	\
+	kern/env.c fs/fshelp.c fs/xfs.c fs/affs.c fs/sfs.c fs/hfsplus.c	\
+	disk/lvm.c disk/raid.c
 
 # For grub-emu.
 grub_emu_DEPENDENCIES = grub_script.tab.c grub_script.tab.h		\

@@ -63,10 +64,10 @@
 grub_emu_LDFLAGS = $(LIBCURSES)
 
 # Scripts.
-#sbin_SCRIPTS = grub-install
+sbin_SCRIPTS = grub-install
 
 # For grub-install.
-#grub_install_SOURCES = util/efi/pc/grub-install.in
+grub_install_SOURCES = util/i386/efi/grub-install.in
 
 # Modules.
 pkgdata_MODULES = kernel.mod normal.mod _chain.mod chain.mod \
util/i386/efi/grub-install.in +212 -0

212 lines not on this page · raw message

util/i386/pc/biosdisk.c +1 -1
diff -Nur grub2-1.95+20070507.old/util/i386/pc/biosdisk.c grub2-1.95+20070507/util/i386/pc/biosdisk.c
@@ -18,7 +18,7 @@
  *  Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
  */
 
-#include <grub/machine/biosdisk.h>
+#include <grub/i386/pc/biosdisk.h>
 #include <grub/disk.h>
 #include <grub/partition.h>
 #include <grub/pc_partition.h>
util/i386/pc/grub-probe.c +1 -1
diff -Nur grub2-1.95+20070507.old/util/i386/pc/grub-probe.c grub2-1.95+20070507/util/i386/pc/grub-probe.c
@@ -26,7 +26,7 @@
 #include <grub/fs.h>
 #include <grub/partition.h>
 #include <grub/pc_partition.h>
-#include <grub/machine/util/biosdisk.h>
+#include <grub/i386/pc/util/biosdisk.h>
 #include <grub/util/getroot.h>
 #include <grub/term.h>
i386/efi/grub-install.in renamed from i386/pc/grub-install.in +10 -44

136 lines not on this page · raw message

#4 lore raw
In reply to Robert Millan
Quoted 8 lines · Robert Millan
Quoted 3 lines · Robert Millan

One thing that I'm not sure about is the CLI inconsistency. Perhaps it shouldn't take the directory as a standalone parameter, and instead use --root-directory?

Or perhaps it should do like powerpc and check that /boot/grub is a mount point?

Quoted 6 lines

# Find the partition at the right mount point. install_device=awk '$2 == '"\"$grubdir\""' { print $1 }' < /proc/mounts if test "x$install_device" = x; then
echo "$grubdir must be a mount point."
exit 1
fi

It is a bad idea to use /proc, at least without checking the operating system. This makes the script unportable among host operating systems.

Okuji

author
#5 lore raw
Quoted 10 lines · Yoshinori K. Okuji
Quoted 9 lines

Or perhaps it should do like powerpc and check that /boot/grub is a mount point?

# Find the partition at the right mount point. install_device=awk '$2 == '"\"$grubdir\""' { print $1 }' < /proc/mounts if test "x$install_device" = x; then
echo "$grubdir must be a mount point."
exit 1
fi

Quoted 2 lines

It is a bad idea to use /proc, at least without checking the operating system. This makes the script unportable among host operating systems.

Note that this code is in powerpc/../grub-install.in already, and in my version of i386/efi/grub-install.in it didn't made in. Instead, sanity check there is:

  fs_module=`$grub_probe --target=fs --device-map=${device_map} ${grubdir}`
  if test "x$fs_module" = xfat; then :; else
      echo "${grubdir} doesn't look like an EFI partition." 1>&2
      exit 1
  fi
Signature · 4 lines
Robert Millan

My spam trap is [email protected].  Note: this address is only intended
for spam harvesters.  Writing to it will get you added to my black list.
#6 lore raw
Quoted 3 lines · Robert Millan

Note that this code is in powerpc/../grub-install.in already, and in my version of i386/efi/grub-install.in it didn't made in. Instead, sanity check there is:

This means that I was not careful enough to review the powerpc-specific code. This must be fixed.

Okuji

#7 lore raw
In reply to Robert Millan
Quoted 1 line · Robert Millan

grub-probe is needed to check partmap (so we don't have to assume gpt).

Yes.

Quoted 2 lines

grub-mkdevicemap is needed to create device.map, without which grub-probe won't work.

Right.

Quoted 6 lines

Note: this grub-install.in is based on the i386/pc version. I tried to keep changes minimal, so if you diff them it'll produce readable output.

One thing that I'm not sure about is the CLI inconsistency. Perhaps it shouldn't take the directory as a standalone parameter, and instead use --root-directory?

Consistency is important, but it is not a must, as long as the user can easily guess the difference. In principle, you should respect consistency, but should not blindly believe in it. So if you think it is reasonable to make difference, you can. Otherwise, don't.

Quoted 5 lines

Not really sure about these. Seems ugly, but biosdisk.h has the grub_util_biosdisk_get_grub_dev definition, which is not really i386/pc-specific. Also, note that powerpc needs them as well if we want update-grub to work there (haven't submitted this part, because it grub-probe on powerpc has other issues that I cannot debug).

If it is not specific to i386-pc, it should be moved to somewhere else.

Okuji

author
#8 lore raw
Quoted 9 lines · Yoshinori K. Okuji
Quoted 4 lines

One thing that I'm not sure about is the CLI inconsistency. Perhaps it shouldn't take the directory as a standalone parameter, and instead use --root-directory?

Consistency is important, but it is not a must, as long as the user can easily guess the difference. In principle, you should respect consistency, but should not blindly believe in it. So if you think it is reasonable to make difference, you can. Otherwise, don't.

Ok. My last version is mostly consistent (/boot/grub path is a default, and can be overriden the same way), the difference being that it doesn't take any non-flag argument. But I think this difference is reasonable, specially considering that i386/pc/grub-install and powerpc/grub-install already differ on this part.

Quoted 7 lines
Quoted 5 lines

Not really sure about these. Seems ugly, but biosdisk.h has the grub_util_biosdisk_get_grub_dev definition, which is not really i386/pc-specific. Also, note that powerpc needs them as well if we want update-grub to work there (haven't submitted this part, because it grub-probe on powerpc has other issues that I cannot debug).

If it is not specific to i386-pc, it should be moved to somewhere else.

Will do.

Thanks,

Signature · 4 lines
Robert Millan

My spam trap is [email protected].  Note: this address is only intended
for spam harvesters.  Writing to it will get you added to my black list.
author
#9 lore raw

grub-install for EFI (please test)

My grub-install for EFI is in CVS now. I would appreciate if someone can test it on real hardware, since it's only known to work in qemu. :-)

Signature · 4 lines
Robert Millan

My spam trap is [email protected].  Note: this address is only intended
for spam harvesters.  Writing to it will get you added to my black list.
#10 lore raw
In reply to Robert Millan
Quoted 3 lines · Robert Millan

Please have a look at this patch that adds grub-install for EFI and tell me what you think. I have some doubts/comments myself, and I'll reply to my own message to use the patch context.

In my opinion, grub-install is not very useful without grub-setup. As I haven't reverse-engineered "bless" yet, I don't know how to implement it. I guess it just modifies some bytes in a superblock or somewhere, though.

Okuji

author
#11 lore raw
Quoted 6 lines · Yoshinori K. Okuji
Quoted 3 lines · Robert Millan

Please have a look at this patch that adds grub-install for EFI and tell me what you think. I have some doubts/comments myself, and I'll reply to my own message to use the patch context.

In my opinion, grub-install is not very useful without grub-setup.

It saves a pair of things to the user (figuring out which modules are needed, and what to do with the resulting grub.efi image). From Debian POV, it's very important so that grub installs can be automated from debian-installer (without duplicating code, that is).

Quoted 3 lines

As I
haven't reverse-engineered "bless" yet, I don't know how to implement it. I guess it just modifies some bytes in a superblock or somewhere, though.

What is bless needed for? In my environment (Debian GNU/Linux on a qemu sandbox with EFI firmware), it was not necessary to get grub.efi booting (although later it had issues accessing filesystems other than the EFI partition, but I suppose this might be a qemu/firmware bug).

Signature · 4 lines
Robert Millan

My spam trap is [email protected].  Note: this address is only intended
for spam harvesters.  Writing to it will get you added to my black list.
#12 lore raw
Quoted 6 lines · Robert Millan
Quoted 5 lines · Yoshinori K. Okuji
Quoted 3 lines · Robert Millan

Please have a look at this patch that adds grub-install for EFI and tell me what you think. I have some doubts/comments myself, and I'll reply to my own message to use the patch context.

Quoted 6 lines
Quoted 1 line

In my opinion, grub-install is not very useful without grub-setup.

It saves a pair of things to the user (figuring out which modules are needed, and what to do with the resulting grub.efi image). From Debian POV, it's very important so that grub installs can be automated from debian-installer (without duplicating code, that is).

Providing a rudimentary tool rather harms the user.

Quoted 9 lines
Quoted 4 lines

As I
haven't reverse-engineered "bless" yet, I don't know how to implement it. I guess it just modifies some bytes in a superblock or somewhere, though.

What is bless needed for? In my environment (Debian GNU/Linux on a qemu sandbox with EFI firmware), it was not necessary to get grub.efi booting (although later it had issues accessing filesystems other than the EFI partition, but I suppose this might be a qemu/firmware bug).

http://www.hmug.org/man/8/bless.php

Okuji

author
#13 lore raw
Quoted 7 lines · Yoshinori K. Okuji
Quoted 6 lines · Robert Millan
Quoted 5 lines · Yoshinori K. Okuji
Quoted 3 lines · Robert Millan

Please have a look at this patch that adds grub-install for EFI and tell me what you think. I have some doubts/comments myself, and I'll reply to my own message to use the patch context.

Quoted 8 lines
Quoted 6 lines
Quoted 1 line

In my opinion, grub-install is not very useful without grub-setup.

It saves a pair of things to the user (figuring out which modules are needed, and what to do with the resulting grub.efi image). From Debian POV, it's very important so that grub installs can be automated from debian-installer (without duplicating code, that is).

Providing a rudimentary tool rather harms the user.

What do you mean? It's almost the same that the powerpc version does.

Quoted 10 lines
Quoted 8 lines
Quoted 3 lines

As I
haven't reverse-engineered "bless" yet, I don't know how to implement it. I guess it just modifies some bytes in a superblock or somewhere, though.

What is bless needed for? In my environment (Debian GNU/Linux on a qemu sandbox with EFI firmware), it was not necessary to get grub.efi booting (although later it had issues accessing filesystems other than the EFI partition, but I suppose this might be a qemu/firmware bug).

http://www.hmug.org/man/8/bless.php

I see.. but user still can boot grub.efi manualy via EFI shell, right?

Signature · 4 lines
Robert Millan

My spam trap is [email protected].  Note: this address is only intended
for spam harvesters.  Writing to it will get you added to my black list.
#14 lore raw
Quoted 3 lines · Robert Millan
Quoted 1 line

Providing a rudimentary tool rather harms the user.

What do you mean? It's almost the same that the powerpc version does.

The powerpc version is not a good reference. From my point of view, it is far from user-friendly. When the user invokes grub-install, she expects that she can "install" GRUB, as the name stands for.

The best reference in GRUB is still the i386-pc version. The others should follow it as much as possible.

Quoted 3 lines
Quoted 1 line

http://www.hmug.org/man/8/bless.php

I see.. but user still can boot grub.efi manualy via EFI shell, right?

If an EFI shell is available, yes. On Intel Mac, the shell is not available by default, because of the graphics mode. For now, the only way to boot GRUB is to start Mac OS X and bless a boot image, or use a small program to switch to text mode and boot GRUB from a shell.

Okuji

author
#15 lore raw
Quoted 11 lines · Yoshinori K. Okuji
Quoted 3 lines · Robert Millan
Quoted 1 line

Providing a rudimentary tool rather harms the user.

What do you mean? It's almost the same that the powerpc version does.

The powerpc version is not a good reference. From my point of view, it is far from user-friendly. When the user invokes grub-install, she expects that she can "install" GRUB, as the name stands for.

The best reference in GRUB is still the i386-pc version. The others should follow it as much as possible.

Ok. So, what interface we should provide to the user? I've been told that the files shouldn't be in the root of EFI partition, but in a subdirectory like /efi/grub. Should this directory be specified by the user? We could make it something like:

  $ sudo grub-install /something/efi/grub
  doesn't look like an EFI partition.
  $ mount /dev/sda1 /something
  $ sudo grub-install /something/efi/grub

OTOH, making it like:

  $ sudo grub-install "(hd0)"
  # /efi/grub being implicit here

forces us to mount/umount and opens a can of worms wrt portability.

What do you think?

Quoted 8 lines
Quoted 3 lines
Quoted 1 line

http://www.hmug.org/man/8/bless.php

I see.. but user still can boot grub.efi manualy via EFI shell, right?

If an EFI shell is available, yes. On Intel Mac, the shell is not available by default, because of the graphics mode. For now, the only way to boot GRUB is to start Mac OS X and bless a boot image, or use a small program to switch to text mode and boot GRUB from a shell.

Perhaps we should look at the refit source and see how bless-like functionality is implemented?

Signature · 4 lines
Robert Millan

My spam trap is [email protected].  Note: this address is only intended
for spam harvesters.  Writing to it will get you added to my black list.
#16 lore raw
Quoted 10 lines · Robert Millan

Ok. So, what interface we should provide to the user? I've been told that the files shouldn't be in the root of EFI partition, but in a subdirectory like /efi/grub. Should this directory be specified by the user? We could make it something like:

  $ sudo grub-install /something/efi/grub
  doesn't look like an EFI partition.
  $ mount /dev/sda1 /something
  $ sudo grub-install /something/efi/grub
Quoted 8 lines

OTOH, making it like:

  $ sudo grub-install "(hd0)"
  # /efi/grub being implicit here

forces us to mount/umount and opens a can of worms wrt portability.

What do you think?

Not bad. The prefix can be anything. It can be even /boot/grub. On EFI, the prefix is dynamically passed to GRUB, so the decision is very flexible.

Quoted 2 lines

Perhaps we should look at the refit source and see how bless-like functionality is implemented?

When I looked at it at the last time, the documentation only said that you would write it to somewhere, and execute bless on Mac OS X. Things might have changed, but I don't know.

Okuji

author
#17 lore raw
Quoted 16 lines · Yoshinori K. Okuji
Quoted 15 lines · Robert Millan

Ok. So, what interface we should provide to the user? I've been told that the files shouldn't be in the root of EFI partition, but in a subdirectory like /efi/grub. Should this directory be specified by the user? We could make it something like:

  $ sudo grub-install /something/efi/grub
  doesn't look like an EFI partition.
  $ mount /dev/sda1 /something
  $ sudo grub-install /something/efi/grub

OTOH, making it like:

  $ sudo grub-install "(hd0)"
  # /efi/grub being implicit here
Quoted 6 lines
Quoted 3 lines

forces us to mount/umount and opens a can of worms wrt portability.

What do you think?

Not bad. The prefix can be anything. It can be even /boot/grub. On EFI, the prefix is dynamically passed to GRUB, so the decision is very flexible.

You mean the first one? Note that in the current version (i.e. no arguments), --root-directory still works, so it's still possible to override this path.

Quoted 6 lines
Quoted 2 lines

Perhaps we should look at the refit source and see how bless-like functionality is implemented?

When I looked at it at the last time, the documentation only said that you would write it to somewhere, and execute bless on Mac OS X. Things might have changed, but I don't know.

I'll have a look later..

Signature · 4 lines
Robert Millan

My spam trap is [email protected].  Note: this address is only intended
for spam harvesters.  Writing to it will get you added to my black list.