I have the following setup:

  • UEFI Asus Motherboard
  • GPT TABLE and Ubuntu on /dev/sdb
  • MS-DOS TABLE, Windows 7 and Linux Mint on /dev/sda

I try to boot the Windows 7 partitions with grub2 from Ubuntu 11.10.

My Windows "System Reserved" is /dev/sda3.

The GRUB windows entry is (standard):

menuentry "Windows 7 (loader) (on /dev/sda3)" --class windows --class os {
        insmod part_msdos
        insmod ntfs
        set root='(hd0,msdos3)'
        search --no-floppy --fs-uuid --set=root 644C5AC04C5A8CA4
        chainloader +1

Parted output:

Disk /dev/sda: 500GB
Sector size (logical/physical): 512B/512B
Partition Table: msdos

Number  Start   End     Size    Type      File system  Flags
 1      32.3kB  296MB   296MB   primary   ext2
 2      296MB   423GB   423GB   extended
 5      296MB   20.3GB  20.0GB  logical   ext4
 6      20.3GB  363GB   342GB   logical   ext4
 7      363GB   423GB   60.1GB  logical   ntfs
 3      423GB   423GB   105MB   primary   ntfs         boot
 4      423GB   500GB   77.2GB  primary   ntfs

Disk /dev/sdb: 1500GB
Sector size (logical/physical): 512B/512B
Partition Table: gpt

Number  Start   End     Size    File system     Name  Flags
 1      17.4kB  20.0MB  20.0MB  fat16                 boot
 2      20.0MB  50.9GB  50.9GB  ext4
 4      50.9GB  1103GB  1052GB  btrfs
 5      1103GB  1156GB  52.7GB  ext4
 6      1156GB  1233GB  77.2GB  ntfs
 7      1233GB  1233GB  105MB   ntfs
 3      1496GB  1500GB  4271MB  linux-swap(v1)

After trying to boot Windows from grub2 I get the message:

error: invalid EFI file path

migrated from stackoverflow.com Jan 2 '12 at 6:22

This question came from our site for professional and enthusiast programmers.


You cannot do that.

It should be glaringly obvious that any pre-boot application, such as the boot loader program for an operating system, is tightly coupled to the machine firmware; just as an ordinary applications program is tied to the operating system whose services it employs. An EFI boot loader program cannot be run on a machine unless that machine provides EFI firmware services. An old PC/AT style bootstrap loader program cannot be run on a machine unless that machine provides the old PC/AT firmware services.

The chainloader verb in GRUB embodies this. It's not documented, but it does different things depending from how GRUB is hosted — i.e. what machine firmware GRUB is (expecting to be) running on. On the version of GRUB hosted on old PC/AT systems, it expects to be given a disc block set or a file, and loads and runs (the first sector of) what it is given in the manner of an old PC/AT VBR bootstrap program. On the EFI-hosted version of GRUB, it expects to be given filenames, and loads and runs the files as ordinary EFI applications.

You have the EFI-hosted version of GRUB. You've passed +1 to chainloader as the filename, but that simply isn't a valid path to a pre-boot EFI application image file. GRUB has been unable to construct the EFI device path for the image file, because you've given it a syntactically incorrect path. Hence the error message.

A correct use of chainloader in the EFI-hosted GRUB names a file. For Microsoft Windows NT 6.1, this will be the EFI version of Microsoft's Boot Manager that lives alongside the BCD store on the EFI System Partition:

chainload (hd1,gpt1)/EFI/Microsoft/Boot/bootmgfw.efi

Of course, this will not work for you, because you either didn't install Windows NT 6.1 on this machine — but on some other machine and transferred the hard disc to this one — or didn't install the EFI-bootstrappable version of it, somehow persuading Windows NT 6.1 to run the non-EFI version of its installation utility on your EFI machine. How do I know? Because Microsoft wouldn't have let you install it to a non-EFI-partitioned hard disc on an EFI machine as you have done, and because you have both a proper EFI System Partition (the FAT partition on your second hard disc) and its Poor Man's equivalent when you would have only needed the former otherwise.

As such, Windows NT 6.1 hasn't been installed with the EFI-hosted version of Microsoft's Boot Manager, the BCD store is in the wrong place, and there will be several other problems — relating to Windows NT expecting one hardware/firmware combination and having been configured with the appropriate drivers and settings for that, and suddenly being bootstrapped on another hardware/firmware combination — in store for you later.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.