I've not been able to boot to Windows 10 after an Ubuntu Update that appeared to upgrade Grub. I was initially getting the error invalid signature when trying to boot to Windows. In the past when I had this problem I booted to the Ubuntu live CD, ran boot-repair and this fixed the Windows boot entry in Grub. Now however I've tried boot-repair a number of times trying different options. I have a /boot/EFI partition. In UEFI I re-enabled CSM and disabled secure boot. I have rEFInd installed although I can't remember installing it. I think Ubuntu and Windows 10 were installed in UEFI mode. When I select the Windows option in Grub it goes to the rEFInd boot loader where there is no option to boot to windows. The options in rEFInd are below and they both boot to Ubuntu:

EFI/ubuntu/grubx64.efi boot/vmlinuz-4.4.0-97-generic.efi

Ubuntu and Windows are installed on the same NVME drive on separate partitions. The EFI partition is there also. Here the the result of the last boot-repair.


Windows is installed on /dev/nvme0n1p4 and the Ubuntu root partition is on /dev/nvme0n1p5.

Can anyone help with this?

  • I am not an expert in interpreting boot-repair results but it is showing three memory devices; sda, sdb and sdd. You are saying you have Windows 10 installed. Yes, it is on sdb3 but it is also showing windows 7 on sda1. Also there is not boot-loader for Windows 10 on sdb as mentioned in the boot-repair file. Oct 14, 2017 at 2:42
  • sda1 is an ntfs partition used for storage only. sdd is the usb key with Ubuntu live. I have Windows 10 installed separately in sdb3 and nvme0n1p4. I mainly want it to boot Windows on nvme0n1p4 along with Ubuntu on nvme0n1p5
    – will76
    Oct 14, 2017 at 5:13

2 Answers 2


I resolved this by booting from my Windows 10 USB key and performing a boot repair. I made sure I could boot to Windows ok. Then I rebooted and booted from my Ubuntu 16.04 live USB key, installed and ran boot-repair and rebooted. Then the Grub2 menu appeared and I can now dual boot Ubuntu and Windows. To prevent this from recurring I ran this command to stop grub2 from updating which started the problem.

sudo apt-mark hold grub* grub*:i386

I realize you've found a solution; but I have some speculation about what may have caused it and some suggestions on how to avoid it in the future:

  • DO NOT ENABLE THE CSM! The Compatibility Support Module (CSM) provides a BIOS-mode boot option to the firmware. If both your OSes were installed in EFI mode, the CSM is unnecessary at best and a door into a world of pain at worst. See my page on the subject for all the gory details. To be sure, nothing you've mentioned makes me think that the CSM was involved in your problems, but you could have created a new set of problems on top of those you already experienced by enabling the CSM. I recommend you go into the firmware and disable the CSM. Secure Boot also was most likely not the cause of your problems, and it provides at least theoretical security benefits, so you may want to re-enable it.
  • You say that launching the "Windows" option in GRUB instead launched rEFInd. This suggests that rEFInd was installed in a way that caused it to take the place of the Windows boot loader. When this happens, the rEFInd installer copies the Windows boot loader to another location, so it should remain accessible; but GRUB's scripts might not detect it at that location. (rEFInd should, though.) In any event, I think that something went badly wrong with this -- for instance, you or some tool you ran might have decided to delete the "duplicate" Windows boot loader from its non-standard location, which would have been a bad mistake, and resulted in exactly the symptoms you experienced.
  • The "invalid signature" message from GRUB when you tried to launch Windows was probably because rEFInd (which seems to have replaced the Windows boot loader) was not signed by any Secure Boot key in the firmware or in your MOK list. This is just another clue that rEFInd replaced the Windows boot manager. After you disabled Secure Boot, rEFInd would then launch from GRUB when you selected Windows, since the Secure Boot key check was not being done.
  • Unfortunately, Boot Repair does a poor job with NVMe disks, so it seems to be missing critical data on your NVMe disk, including the EFI System Partition (ESP), on which all your boot loaders are stored. If you hadn't fixed your problem, I'd ask you to post a complete file listing from the ESP, or at least a complete listing of all *.efi files on it; but given that you've successfully repaired it, I don't think there's much point to doing this. You should just keep in mind that Boot Repair doesn't yet properly support NVMe disks, though. With any luck this flaw will be fixed soon.
  • By repairing the boot process in Windows, you wiped rEFInd (or at least the rEFInd binary) from EFI/Microsoft/Boot, which fixed things; HOWEVER, if you installed rEFInd via the Ubuntu PPA, it might auto-update, which in turn might cause a recurrence of the problem. Type dpkg -s refind. If you get a message to the effect that refind is not installed, you're good (you probably installed rEFInd in another OS or via the .zip file). If you get package information on rEFInd, typing sudo dpkg -P refind should remove the package and eliminate any chance of an accidental upgrade of rEFInd. Typing sudo add-apt-repository -r ppa:rodsmith/refind will remove the rEFInd PPA from your system, which is another way to safeguard against an accidental future update of rEFInd. If you want to be really thorough, you could delete rEFInd files from /boot/efi/EFI/Microsoft/Boot. These include the refind.conf and BOOT.CSV files and the drivers_x64, keys, and icons subdirectories. (There might also be backups: icons-backup and refind.conf-sample.) Be careful, though! If you don't know what you're doing, or if you're careless, messing with files on the ESP can be dangerous! It's best to back up the entire ESP before you try. (A file-level backup, as in sudo tar cvfz /root/esp-backup.tgz /boot/efi, should be sufficient. Copy the /root/esp-backup.tgz file to a USB flash drive for safekeeping before you reboot.)
  • A GRUB update should not cause this problem to recur. In fact, GRUB updates can be important, since they can include security fixes or other improvements you might want or need. Thus, you might want to un-mark GRUB from being held.

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.