Hi,

I recently moved from grub-pc/GPT to grub-efi/GPT (dual boot with Win 8).
After successfully installing Grub to the ESP and getting the UEFI to run
grubx64.efi Grub (after welcomming me) complained:

| error: invalid arch independent ELF magic.
| grub rescue>

At this prompt I could list the available partitions but I couldn't access
their content via "ls (hdx,gpty)". Commands other than "ls" weren't
accessible either, so the system was "user-unbootable". I assume Grub could
not access it's grub.cfg or remaining modules.

This happend when running grubx64.efi from an EFI-shell (v1) and with the
normal UEFI boot sequence. However, when I used the previously installed
rEFInd boot manager to launch grubx64.efi, Grub worked just fine.

AFAIK rEFInd contains some file system drivers. So I installed Grub under a
second label and added

| --modules="part_gpt ext2"

to the grub-install invocation. This produced a different grubx64.efi but
with the same size as the first one.

Accidently running the FIRST grubx64.efi, it now worked using either UEFI
boot or EFI-shell!

Does grub-efi use the GPT boot partition similar to grub-pc? If so, did
grub-install add the ext2.mod there so that both Grub instances can now
access the remaining modules on the (separate) ext3 /boot partition?

If more information is needed I'll try to help but I tried an awful lot of
things to get the UEFI/Win8/GPT/Linux/Grub thingy working, may not remember
/all/ of it and am loth to do anything disruptive at this point.

Regards
Jens

This probably means that it's trying to load modules from /boot/grub/
and they're actually for grub-pc rather than grub-efi-amd64.  What is
$prefix set to?  (You can inspect it in the rescue shell using 'set'.)

That's a little mysterious.

I doubt this was necessary.  grub-install autodetects the necessary
modules already, and this is confirmed by the fact that your core image
was the same size both times round.  GRUB does not know about or use
rEFInd's file system drivers.

grub-install copies modules into /boot/grub/, which probably explains
the change in behaviour.  Perhaps you constructed the first grubx64.efi
using some mechanism other than grub-install, or perhaps grub-pc is
still installed and some bit of packaging called grub-install for the
BIOS platform without you noticing?

grub-pc and grub-efi-amd64 both use /boot/grub/.  (In GRUB 2.00 this is
clarified by moving the modules to /boot/grub/i386-pc/ and
/boot/grub/x86_64-efi/ respectively; but in 1.99 they shared a single
/boot/grub/ directory.)

The GRUB core image (which typically resides in the BIOS Boot Partition
with grub-pc on GPT, or in the EFI System Partition with grub-efi-amd64)
is required to contain all the modules that are necessary to access
/boot/grub/, much as a Linux kernel + initramfs are together required to
contain all modules necessary to access /.  Once the core image has
started up to roughly the point where it could execute a rescue shell,
it does not normally access the BIOS Boot Partition / EFI System
Partition any further.

Just for reference, what is your partition layout (e.g. 'parted -l')?

The evidence suggests that, on your first attempt, the GRUB core image
and the modules it found were built for different platforms, but that
your second attempt installed the correct set of modules.
Unfortunately, if you didn't take detailed notes, we may not be able to
progress this bug any further because it's pretty hard to guess at what
point things went wrong.

Cheers,

Hi!

sorry for taking so long to respond.

My starting point was a working grub-pc (squeeze, amd64) setup. I then
installed grub-efi version 1.99-26 (wheezy, amd64) via aptitude/synaptic
so grub-pc probably was uninstalled but not purged (it is purged
now).

I used hints gleaned from bug report #623297 to avoid pitfalls.

|at this prompt I could list the available partitions but I
|couldn't access their content via "ls (hdx,gpty)". Commands
|other than "ls" weren't accessible either,

Therefor, I assume that grubx64.efi was unable to find or load
it's modules.

I checked the *.mod files from the grub-pc AMD64 and grub-efi*
AMD64 packages: 'file' reports grub-pc's are 32bit ELF binaries while
grub-efi's are 64bit binaries. Taking grubx64.efi's error message into
account I theorize that it was finding and trying to use grub-pc's 32bit
modules and failed, resulting in an absolutly bare rescue shell.

Bug report #680718 seems to be about a similar or identical
problem with regard to the *.mod files

Then
| I installed Grub under a second label and added --modules="part_gpt ext2"
with two consequences:

1. Both grubx64.efi binaries have the same size but different
   MD5sums.
2. IIRC the 1st grubx64.efi suddenly worked (I switched to the
   2nd now)

This looks like grub-install does not move *.mod and/or other files
to their right place at least some of the time. Maybe the --modules
option forces an overwrite of existing files because you wrote

In my quest to get this to work I relied heavily on
 <https://wiki.archlinux.org/index.php/GRUB2>
and guessed educatedly which command line options exist/to use in this
version.

Unless newer packages work differently it would be very helpful
to include a small README with a list of low level commands to
build necesary files and move files to the right places
manually. This old Grub 1.x way to install by hand was cumbersome
but would provide a safety net until an automated install works
reliably.

Cheers
Jens

p.s.

No news on

I may contact Rod Smith, the author of rEFInd. BTW he has some
IMHO helpful documentation on UEFI/Linux as well at
 <http://www.rodsbooks.com/efi-bootloaders/>

[image: Inline images 1]