Windows 8 changes GRUB2 in every boot!

I've installed Windows 8 and Ubuntu 12.10 both UEFI style (win8 first then ubuntu). GRUB2 shows me both Ubuntu and Win8 entries.

If I boot into Ubuntu is fine. I could reboot anytime I will see GRUB2 unchanged.

The story changes when I Boot into Win8. When I boot to Win8 using GRUB2 it takes me to the Windows Boot manager (which only has the Windows 8 entry). I hit Windows and it boots fine. When I reboot, there's no GRUB2 nor Win loader. It has no boot loader.

I booted a LiveCD and downloaded boot-repair and everything is back. It's a never ending cycle.

Is GRUB2 supposed to load the Win boot loader? What can I do to fix it?

More information:

USER@MACHINE:~$ ls -l `find /boot/efi -iname "*\.efi"`

-rwxr-xr-x 1 root root 1357480 Dec  9 21:41 /boot/efi/EFI/Boot/bootx64.efi
-rwxr-xr-x 1 root root 1357480 Dec  9 21:41 /boot/efi/EFI/Microsoft/Boot/bootmgfw.efi
-rwxr-xr-x 1 root root 1350896 Jul 25 20:57 /boot/efi/EFI/Microsoft/Boot/bootmgr.efi
-rwxr-xr-x 1 root root 1357480 Dec  9 21:41 /boot/efi/EFI/Microsoft/Boot/bootx64.efi
-rwxr-xr-x 1 root root 1263856 Jul 25 20:57 /boot/efi/EFI/Microsoft/Boot/memtest.efi
-rwxr-xr-x 1 root root  897400 Dec  9 21:41 /boot/efi/EFI/ubuntu/grubx64.efi
-rwxr-xr-x 1 root root 1357480 Dec  9 21:41 /boot/efi/EFI/ubuntu/shimx64.efi

USER@MACHINE:~$ ls -l `find /boot/efi -iname "*\.bkp"`

-rwxr-xr-x 1 root root 1354480 Jul 25 20:57 /boot/efi/EFI/Boot/bootx64.efi.bkp
-rwxr-xr-x 1 root root 1354480 Jul 25 20:57 /boot/efi/EFI/Microsoft/Boot/bootmgfw.efi.bkp

USER@MACHINE:~$ sudo parted /dev/sda print

Model: ATA ST31000524AS (scsi)
Disk /dev/sda: 1000GB
Sector size (logical/physical): 512B/512B
Partition Table: gpt

Number  Start   End     Size    File system     Name                          Flags
 1      1049kB  316MB   315MB   ntfs            Basic data partition          hidden, diag
 2      316MB   420MB   105MB   fat32           EFI system partition          boot
 3      420MB   555MB   134MB                   Microsoft reserved partition  msftres
 4      555MB   751GB   750GB   ntfs            Basic data partition
 5      751GB   998GB   248GB   ext4
 6      998GB   1000GB  2000MB  linux-swap(v1)

Solution 1:

Boot into Linux, type the following three commands in a shell, and post the output here:

ls -l `find /boot/efi -iname "*\.efi"`
ls -l `find /boot/efi -iname "*\.bkp"`
sudo parted /dev/sda print

Note that those are back-ticks (to the left of the "1" key on most keyboards) around the find commands.

The result should be a list of all the boot loaders on your ESP, including both the regular names and the renamed versions created by Boot Repair; and a list of all the partitions on your disk.

Also, what sort of computer are you using? (Brand and model.) Did it come with Windows 8 or did you install it yourself?

Unfortunately, some manufacturers are playing very annoying games with their boot loaders on pre-loaded Windows 8 computers. IMHO, blowing those installations away and starting from scratch is looking more and more like a good solution.

Edit/answer given new information:

There's nothing in your output that's weird or unexpected, so it looks as if something in Windows is "repairing" what it sees as its own "broken" boot loader. This requires some elaboration, which will help you understand what's going on:

An EFI (or UEFI, which is just EFI 2.x) implementation is supposed to check NVRAM entries to decide which boot loader (a file with a .efi extension) to run when it boots. Some implementations are broken, though, and will only boot the EFI/BOOT/bootx64.efi or EFI/Microsoft/Boot/bootmgfw.efi boot loader. Others will boot other boot loaders, but only if they've got the name "Windows Boot Manager" or "Red Hat Enterprise Linux".

To work around this type of bug, the Ubuntu Boot Repair tool implements a fix that's at least as ugly and confusing as the bug it bypasses: It renames those two default boot loaders with .bkp extensions, places copies of GRUB in their place, and adjusts GRUB so that it will launch the Windows boot loaders using their new names. This gets GRUB booting, but in a way that Windows doesn't understand and might try to "fix" itself. I think that this is what's happening -- when Windows boots, it's seeing that its boot loader has been overwritten by another one and so it tries to correct the problem.

I recommend you try the following:

1. Check your manufacturer's Web site to see if there's a firmware update. If there is, update your firmware to the latest version, just in case there's a bug fix for this type of boot bug.
2. Boot Windows and reboot to verify that when you reboot you go straight into Windows. You want to start from this point because it's more standard than the way that Boot Repair sets up.
3. Boot a Linux emergency disc in EFI mode. (The Ubuntu install disc should work fine for this.)
4. Install the efibootmgr utility, if necessary. In the Ubuntu live CD, you'd do this by typing sudo apt-get install efibootmgr.
5. Type sudo efibootmgr -c -l \\EFI\\ubuntu\\shimx64.efi -L "Windows Boot Manager" -p 2. Be careful to type this command exactly as specified, including the doubled-up backslashes as directory path separators. This should set up GRUB to launch as the default boot loader, giving it the firmware label "Windows Boot Manager" in case you've got that bug. (You could try with a less deceptive name, and on most systems that will work, but maybe not for you.) If you're not using Secure Boot, you could substitute grubx64.efi for shimx64.efi in this command, but given that shimx64.efi is present on your system, my suspicion is that you are using Secure Boot.
6. Reboot and test it.

If it works at this point, then great. If it boots to GRUB but GRUB can't launch Windows, you may need to adjust your GRUB configuration so that it references EFI/Microsoft/Boot/bootmgfw.efi rather than EFI/Microsoft/Boot/bootmgfw.efi.bkp.

If you can't get your system to launch GRUB in this way, then you may have a very brain-damaged firmware combined with something in Windows that's automatically "fixing" a "damaged" boot loader on every boot, closing off your best (albeit ugly) avenue of repair. In that case, I have several further suggestions:

• If the computer is new enough, return it to the store and get a new one. Make it very clear, both to the store and to the manufacturer, why you're returning it.
• Look for whatever in Windows is checking and "repairing" its boot loader and disable that. You should then be able to use Ubuntu's Boot Repair, or do something similar manually, to get it all working.
• Create a second ESP and install GRUB (or another Linux boot loader) to it using the Microsoft names. By juggling partition ID numbers (using gdisk, for example -- use the t option on the experts' menu), you might be able to get the firmware to use your desired boot loader while getting Windows to look at its own boot loader. This is highly speculative, though; it might not work at all.
• Create a USB flash drive with my rEFInd boot manager. You'll then be able to insert it into the computer and boot from the USB device to get rEFInd, which should then detect both Windows and GRUB and give you the option of booting either. With a little extra reconfiguration, you could get it to boot Linux directly. If you can set your firmware to boot from the USB device by default, you could leave the USB drive plugged in permanently for a permanent solution.
• Install rEFInd or GRUB from Windows. I'm far from positive of this, but if you install a boot loader from Windows (as described on rEFInd's Web site), it might bypass whatever in Windows is juggling the boot loaders, thus enabling your preferred boot loader to run by default.

Note that, if you use any solution that involves rEFInd, you may need to set it up with Secure Boot, with involves jumping through some extra hoops. (This situation will improve in time, but for now it's still a bit awkward.) Alternatively, you could disable Secure Boot in your firmware.

I hope this helps!