Bug#699038: grub-efi-amd64-bin: Transition grub-pc - grub-efi fails due to missing FS driver module
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. On Mon, Jan 28, 2013 at 11:58:00AM +, Colin Watson wrote: On Sat, Jan 26, 2013 at 05:56:02PM +0100, Jens G wrote: 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 As I wrote in my original bug report: |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 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'.) 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 I doubt this was necessary. grub-install autodetects the necessary modules already, 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 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. That's a little mysterious. 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/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#699038: grub-efi-amd64-bin: Transition grub-pc - grub-efi fails due to missing FS driver module
On Sat, Jan 26, 2013 at 05:56:02PM +0100, Jens G wrote: 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 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'.) 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. That's a little mysterious. 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. 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. Accidently running the FIRST grubx64.efi, it now worked using either UEFI boot or EFI-shell! 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? 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? 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')? 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. 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, -- Colin Watson [cjwat...@debian.org] -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#699038: grub-efi-amd64-bin: Transition grub-pc - grub-efi fails due to missing FS driver module
Package: grub-efi-amd64-bin Version: 1.99-26 Severity: important 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 -- System Information: Mainboard: Asus M5A99X EVO, BIOS:1604 Debian Release: 6.0.6 APT prefers stable APT policy: (990, 'stable'), (500, 'stable-updates'), (500, 'proposed-updates'), (181, 'testing'), (180, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 3.2.0-0.bpo.4-amd64 (SMP w/6 CPU cores) Locale: LANG=de_DE, LC_CTYPE=de_DE (charmap=UTF-8) (ignored: LC_ALL set to de_DE.utf8) Shell: /bin/sh linked to /bin/dash Versions of packages grub-efi-amd64-bin depends on: ii efibootmgr0.5.4-2Interact with the EFI Boot Manager ii grub-common 1.99-26GRand Unified Bootloader (common f grub-efi-amd64-bin recommends no packages. grub-efi-amd64-bin suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
