Grub windows invalid signature

Ошибка grub не видит Windows 10

Многие новички и опытные пользователи Linux держат также установленной на своем компьютере операционную систему Windows, например, последней, десятой версии. Новичкам это нужно чтобы иметь запасную операционную систему, к которой они смогут вернуться, если их Linux сломается. А для опытных пользователей важно программное обеспечение, которое не поддерживается ни в Linux, ни даже с помощью эмулятора Wine, а таких программ достаточно много.

Но временами случается такая ситуация, что загрузчик Grub не распознает установленную Windows и не отображает ее в списке для систем для загрузки. В этой статье мы рассмотрим почему возникает ошибка grub не видит Windows 10 и как ее решить.

Ошибка Grub не видит Windows 10

Причин такой ошибки может быть несколько, начиная от того, что система установлена на другом жестком диске, и заканчивая неизвестными глюками пакета os-prober, который и занимается определением операционных систем в Linux. Также, если у вас есть несколько версий Windows на компьютере, то программа может видеть только одну из них.

Сначала можно попытаться сделать наш с Windows раздел более видимым для программы. Для этого примонтируйте его в какую-либо папку. Например, в /mnt/:

sudo mount -t ntfs-3g -o ro /dev/sda1

Я предполагаю, что система Windows установлена на разделе, который определяется в Linux, как /dev/sda1. Дальше запустите утилиту os-prober:

Если программа обнаружит Windows, то вам останется обновить конфигурацию загрузчика Grub:

sudo grub2-mkconfig -o /boot/grub/grub.cfg

Если же этот способ не сработает, а он, скорее всего, не сработает, то вам останется только вручную добавить пункт меню для Windows. Это не самое простое, но зато эффективное решение. Сначала нам нужно узнать UUID раздела диска, на который установлена Windows, например, /dev/sda1:

Затем откройте файл /etc/grub.d/40_custom и добавьте туда такой код:

menuentry “Windows 10”

Если кратко, то здесь мы устанавливаем в качестве корня первый раздел первого диска, а затем указываем загрузчику, что нужно найти раздел с нужным нам UUID. Затем передаем управление загрузчику на этом разделе с помощью chainloader. Дальше осталось обновить конфигурацию Grub:

Мы использовали такой метод потому что теперь настройка не собьется после обновления ядра или другого процесса, инициализирующего обновление конфигурации. Потому что если бы мы добавили эти строки в /boot/grub/grub.cfg, то они были бы перезаписаны если не при первом, то при одном из следующих обновлений системы.

Когда конфигурация обновлена вы можете перезагрузить компьютер и загружать Windows с помощью нового пункта. Таким образом, можно добавить несколько пунктов, только для разных разделов нужно указывать их UUID.

Выводы

В этой небольшой статье мы разобрали что делать когда у вас возникнет ошибка grub не видит windows 10 и какими способами ее можно исправить. На самом деле решение очень простое, если вы не используете систему с UEFI. В варианте с EFI загрузка Windows управляется не Grub, а загрузчиком UEFI, но при использовании Linux рекомендуется отключить эту технологию.

Grub : Windows 10 won’t boot (invalid signature)

I’ve been using Ubuntu for a couple of days (work), and this morning I noticed that my Windows 10 wouldn’t boot anymore. When I choose :

My dual boot setup worked fine for months, and I have no idea of how it broke. As of now, only Ubuntu boots fine.

I tried many things, like running the usual boot fixing commands from a Windows installation medium.

The very last command gave the following error:

So I followed these instructions, but still no luck.

I also tried to use grub-customizer to create a manual entry for Windows 10, containing the following lines :

Selecting this entry in grub gives:

2 Answers 2

I see you’ve found a solution, and it’s one of several I was going to suggest. (Disclaimer: I maintain rEFInd, so I’m not unbiased.) I do want to provide an analysis to suggest what may have gone wrong, though. Also, I have an important suggestion that may help you avoid future problems.

Based on your Boot Repair output, your first disk ( /dev/sda , a 112 GiB disk) uses GPT, has an EFI System Partition (ESP), and has both Windows and Ubuntu (GRUB) EFI-mode boot loaders on its ESP. It looks like Windows is installed on this disk. You also have a second disk, /dev/sdf , a 932 GiB disk that uses MBR partitioning and has both Windows and Ubuntu partitions. It looks like Ubuntu is installed on this disk.

Ordinarily, the partition table type (GPT vs. MBR) is tied to the way the computer boots — EFI/UEFI mode with GPT and BIOS/CSM/legacy mode with MBR. There are exceptions to this rule, but it’s a useful starting point, especially for Windows. Because your computer has both GPT and MBR disks, this creates some ambiguity; but it looks like Windows originally booted in EFI mode from the GPT disk. Since everything used to work, I’d further hypothesize that Ubuntu was installed in EFI mode, too; but the Ubuntu installation booted from the ESP on /dev/sda to the actual installation on the MBR /dev/sdf . This is perfectly legal; however, it probably led to problems because of an assumption in a script somewhere. This is where I begin to move beyond fairly safe inferences into the realm of sheer speculation. In particular, my guess is that you did a software update in Ubuntu that ended up either breaking GRUB’s ability to boot Windows. This can happen sometimes, especially if the Windows Fast Startup and/or Hibernate features are active. These features can cause filesystem damage, which can make the Windows boot loader seem to disappear or malfunction, either temporarily or permanently. Thus, it’s imperative that these features be disabled, and I suggest you do so. See here and here for instructions on doing so.

You then exacerbated the problem by performing recovery actions that were designed for BIOS-mode Windows installations. This put a BIOS-mode Windows boot loader on the first sector of /dev/sda , among other things. Given that rEFInd worked, at least these attempts didn’t damage anything further, just added useless cruft.

In any event, installing rEFInd bypassed the hash that is now the GRUB configuration, thus getting things working. If you’re happy with rEFInd, you might as well keep using it. An alternative would be to try to fix the EFI-mode GRUB installation. Boot Repair can often do this, although your computer’s odd mix of MBR and GPT, as well as traces of both EFI-mode and BIOS-mode GRUB installations, might confuse that tool. Thus, unless you’re seriously unhappy with rEFInd, it’s probably best to follow the adage “if it ain’t broke, don’t fix it.” I do strongly advise you to disable Fast Startup and Hibernate in Windows, though; even if rEFInd can launch both Ubuntu and Windows now, if those features are active they could cause new problems in the future.

“Error: Invalid signature” when configuring dual boot Ubuntu 14.04 and Windows 10

After installing the Windows 10 upgrade on my laptop, it ruined the grub boot manager, and I could only boot in windows 10. I fixed the boot manager using a live cd with the boot-repair tool, but it only recognized the Ubuntu partition, and not the Windows one.

So I edited the /etc/grub.d/40_custom file and added the following contents:

After running sudo update-grub2 , I got an entry in the boot menu, but the partition does not load. It gives the following error:

Does anybody know how one can overcome this error?

My most recent boot-repair dump is here: http://paste.ubuntu.com/11965327/, and the partition I want to boot is this one:

3 Answers 3

There are some peculiarities about your installation:

• Your computer has two Windows Recovery Environment partitions, /dev/sda1 and /dev/sda5 . My guess is one is from your previous Windows installation and the other is for the new installation, but I can’t be positive of that. I doubt if this duplication is causing you any problems per se; I mention it simply because it’s a sign of a history of changes to the machine, and such changes may be both the cause of problems and make it difficult to figure out what’s wrong.
• Your EFI System Partition (ESP) is /dev/sda4 . This is perfectly legal, but is unusual; the ESP is normally /dev/sda1 or /dev/sda2 . The ESP holds EFI-mode boot loaders and related files. My hunch is that the ESP was created late in the machine’s history — perhaps it was Ubuntu-only at one point and then you installed Windows, which created the ESP in this unusual location.
• The Boot Info Script output doesn’t identify any EFI boot loaders on the ESP. My suspicion is that they do exist, but the script has omitted these entries. (I’ve seen this happen from time to time.) OTOH, if those files are missing, then it means that Windows has failed to install its boot loader. The same may be true of Ubuntu, too; but see below.
• Your disk uses the GUID Partition Table (GPT), which means that Windows will install to and boot from this disk only in EFI mode; but there’s evidence of a BIOS-mode installation of GRUB, the standard Ubuntu boot loader. Such a mish-mash means that you’d not be able to boot Windows from a BIOS-mode GRUB on this computer. It could be you’ve also got an EFI-mode GRUB and had been booting that way; or maybe you had been switching between OSes by using the computer’s built-in boot manager (typically accessed by hitting Esc, Enter, or a function key at start time).

At this point, your best bet is to install an EFI-mode boot loader for Linux. There are two ways to do this that are relatively safe and easy. Both work best if you first enter your firmware and completely disable any option to boot using BIOS, CSM, or legacy mode. (Those are three terms for the same thing.) Sometimes these options are phrased the other way — you must enable EFI or UEFI support. With that done, do one of two things:

• Method 1: Boot your Ubuntu install disk, ensure you’ve booted in EFI mode by looking for the /sys/firmware/efi directory (if it’s present, you’ve booted in EFI mode), install the boot-repair package, and run it. This should repair your installation by installing an EFI version of GRUB. This usually works, but occasionally it doesn’t. I realize you’ve already run Boot Repair, but my suspicion is that you ran it in BIOS mode, which of course means it would install the BIOS-mode GRUB, which will be useless for booting Windows.
• Method 2: If you haven’t done so already, disable Secure Boot in your firmware. You can then download and prepare a boot medium from the CD-R or USB flash drive version of my rEFInd boot manager. Boot to it; it should show you a menu with at least one option for each of Windows and Ubuntu. Test these to be sure you can boot both OSes, then boot Ubuntu. At this point, you can install the rEFInd Debian package or PPA. (Alternatively, you could install the EFI version of GRUB.) You may be able to re-enable Secure Boot at this point, but you may need to jump through some extra hoops to get it to work.

There should be no need to re-install Ubuntu, and probably not to re-install Windows. BIOS-mode and EFI-mode installations of Ubuntu are identical except for the boot loader (and related partitions — but you’ve got the partitions to handle both modes).

“Error: Invalid signature” when configuring dual boot Ubuntu 14.04 and Windows 10

After installing the Windows 10 upgrade on my laptop, it ruined the grub boot manager, and I could only boot in windows 10. I fixed the boot manager using a live cd with the boot-repair tool, but it only recognized the Ubuntu partition, and not the Windows one.

So I edited the /etc/grub.d/40_custom file and added the following contents:

After running sudo update-grub2 , I got an entry in the boot menu, but the partition does not load. It gives the following error:

Does anybody know how one can overcome this error?

My most recent boot-repair dump is here: http://paste.ubuntu.com/11965327/, and the partition I want to boot is this one:

3 Answers 3

There are some peculiarities about your installation:

• Your computer has two Windows Recovery Environment partitions, /dev/sda1 and /dev/sda5 . My guess is one is from your previous Windows installation and the other is for the new installation, but I can’t be positive of that. I doubt if this duplication is causing you any problems per se; I mention it simply because it’s a sign of a history of changes to the machine, and such changes may be both the cause of problems and make it difficult to figure out what’s wrong.
• Your EFI System Partition (ESP) is /dev/sda4 . This is perfectly legal, but is unusual; the ESP is normally /dev/sda1 or /dev/sda2 . The ESP holds EFI-mode boot loaders and related files. My hunch is that the ESP was created late in the machine’s history — perhaps it was Ubuntu-only at one point and then you installed Windows, which created the ESP in this unusual location.
• The Boot Info Script output doesn’t identify any EFI boot loaders on the ESP. My suspicion is that they do exist, but the script has omitted these entries. (I’ve seen this happen from time to time.) OTOH, if those files are missing, then it means that Windows has failed to install its boot loader. The same may be true of Ubuntu, too; but see below.
• Your disk uses the GUID Partition Table (GPT), which means that Windows will install to and boot from this disk only in EFI mode; but there’s evidence of a BIOS-mode installation of GRUB, the standard Ubuntu boot loader. Such a mish-mash means that you’d not be able to boot Windows from a BIOS-mode GRUB on this computer. It could be you’ve also got an EFI-mode GRUB and had been booting that way; or maybe you had been switching between OSes by using the computer’s built-in boot manager (typically accessed by hitting Esc, Enter, or a function key at start time).

At this point, your best bet is to install an EFI-mode boot loader for Linux. There are two ways to do this that are relatively safe and easy. Both work best if you first enter your firmware and completely disable any option to boot using BIOS, CSM, or legacy mode. (Those are three terms for the same thing.) Sometimes these options are phrased the other way — you must enable EFI or UEFI support. With that done, do one of two things:

• Method 1: Boot your Ubuntu install disk, ensure you’ve booted in EFI mode by looking for the /sys/firmware/efi directory (if it’s present, you’ve booted in EFI mode), install the boot-repair package, and run it. This should repair your installation by installing an EFI version of GRUB. This usually works, but occasionally it doesn’t. I realize you’ve already run Boot Repair, but my suspicion is that you ran it in BIOS mode, which of course means it would install the BIOS-mode GRUB, which will be useless for booting Windows.
• Method 2: If you haven’t done so already, disable Secure Boot in your firmware. You can then download and prepare a boot medium from the CD-R or USB flash drive version of my rEFInd boot manager. Boot to it; it should show you a menu with at least one option for each of Windows and Ubuntu. Test these to be sure you can boot both OSes, then boot Ubuntu. At this point, you can install the rEFInd Debian package or PPA. (Alternatively, you could install the EFI version of GRUB.) You may be able to re-enable Secure Boot at this point, but you may need to jump through some extra hoops to get it to work.

There should be no need to re-install Ubuntu, and probably not to re-install Windows. BIOS-mode and EFI-mode installations of Ubuntu are identical except for the boot loader (and related partitions — but you’ve got the partitions to handle both modes).