I've a ASUS N56VZ with Intel Core i7 – 3610QM, with Win 7 Home Premium x64 pre-installed. This computer come with EFI instead of the traditional BIOS.
When I bought it, I had 3 visible partitions. C (System) – with windows and programs; D (Data) – in blank, I store my personal data and movies; E (Recovery) – software from ASUS to recovery computer.
So, as I'm at a Master's Degree in Computer Science, I needed to install Ubuntu. I made a partition from Win 7, reserving around 35 GB for Ubuntu 12.04.
It went fine, and the install was sucessful. I rebooted and I could get into Ubuntu.
The boot showed 4 entries: 2 for Ubuntu, and one for Windows and one, for Windows Recover.
When I tried to enter Windows 7, "Windows 7 (loader)", I got this message:
error: Invalid EFI file path.
Press any key to continue...
The one for recovery couldn't boot either.
So I get in Ubuntu again, and use repair-tool, which insert new entries on GRUB. Now I have 11 entries!
One of the new entries is called "Windows UEFI loader". The old entry "Windows 7 (loader)" continued to not work. This new one, "Windows UEFI loader", got me into Windows. And I stooped here.
I want a single boot manager with just the two needed options.
I think that this isn't perfect, but I don't know how to solve it.
More, if I'm on Windows 7 and I put it to hibernate, when I turn on the computer, I get a black screen and the message saying that it couldn't restaure the session. (I'm not sure about the exact words. – I was oblied to reboot and start the windows again.)
And this is a major concern. I would like to solve this too.
Here is the link after running the boot-repair:
This one I made it today, with boot-repair and asking for Boot info summary:
Best Answer
The Boot Repair tool is increasingly making a hash of things by creating too many backup copies of too many boot loader files. There are numerous ways to solve this problem. Here's one of them:
/dev/sda1
in your case and is mounted at/boot/efi
. A file-based backup (usingtar
orcp
, for example) should do fine. This will enable you to recover should things go badly./boot/efi
directory, which is the EFI System Partition (ESP), where boot loaders are stored./boot/efi/backups
). Do likewise with duplicates -- if two boot loaders both launched GRUB, for instance, you can delete or move one of them./boot/efi/EFI/Microsoft/Boot/bootmgfw.efi
. This is where it's supposed to belong. Boot Repair copied it to another filename, so you're just copying it back.vmlinuz-3.5.0-23-generic
entry, you can probably delete GRUB, or uncomment thedont_scan_files
line in/boot/efi/EFI/refind/refind.conf
and addgrubx64.efi
to its list.If all goes well, you should now be booting via rEFInd, which should present you with a much smaller list of boot options. If there are still too many, you can try to track down the errant files and delete them, if you think that's appropriate, or use the
dont_scan_files
,dont_scan_dirs
, ordont_scan_volumes
options in/boot/efi/EFI/refind/refind.conf
to keep the remaining items out of the boot list. Such "blacklisting" might be helpful to keep links from/vmlinuz
to/boot/vmlinuz-3.5.0-23-generic
out of the boot list, if your system has such a symbolic link.Note that rEFInd scans for boot loaders on every boot, so it will automatically pick up new kernels when you install them.
If you prefer to keep using GRUB, you can do something conceptually similar to my procedure, but you'll need to peruse the
/boot/grub/grub.cfg
file and cross-reference this to your notes on which boot loader entries work and which don't work to discover which files to delete. You'll then need to useupdate-grub
to re-write yourgrub.cfg
file. Your currentgrub.cfg
file also has BIOS-mode entries for launching Windows, which are useless, and I'm not sure how to keepupdate-grub
from picking them up, if indeed that's how they got in there.Good luck!