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 :
Windows Boot Manager (on /dev/sda2)
I get :
error: invalid signature.
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.
bootrec.exe /fixmbr
bootrec.exe /fixboot
bootrec.exe /scanos
bootrec.exe /rebuildbcd
The very last command gave the following error:
The requested system device cannot be found
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 :
menuentry 'Windows 10 on /dev/sda2 MANUAL' {
insmod part_msdos
insmod ntfs
set root=(hd0,2)
chainloader +1
}
Selecting this entry in grub gives:
BOOTMGR missing
Press Ctrl+Alt+Del
Here's my boot-info : http://paste.ubuntu.com/24947042/
boot dual-boot grub2 uefi
add a comment |
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 :
Windows Boot Manager (on /dev/sda2)
I get :
error: invalid signature.
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.
bootrec.exe /fixmbr
bootrec.exe /fixboot
bootrec.exe /scanos
bootrec.exe /rebuildbcd
The very last command gave the following error:
The requested system device cannot be found
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 :
menuentry 'Windows 10 on /dev/sda2 MANUAL' {
insmod part_msdos
insmod ntfs
set root=(hd0,2)
chainloader +1
}
Selecting this entry in grub gives:
BOOTMGR missing
Press Ctrl+Alt+Del
Here's my boot-info : http://paste.ubuntu.com/24947042/
boot dual-boot grub2 uefi
add a comment |
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 :
Windows Boot Manager (on /dev/sda2)
I get :
error: invalid signature.
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.
bootrec.exe /fixmbr
bootrec.exe /fixboot
bootrec.exe /scanos
bootrec.exe /rebuildbcd
The very last command gave the following error:
The requested system device cannot be found
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 :
menuentry 'Windows 10 on /dev/sda2 MANUAL' {
insmod part_msdos
insmod ntfs
set root=(hd0,2)
chainloader +1
}
Selecting this entry in grub gives:
BOOTMGR missing
Press Ctrl+Alt+Del
Here's my boot-info : http://paste.ubuntu.com/24947042/
boot dual-boot grub2 uefi
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 :
Windows Boot Manager (on /dev/sda2)
I get :
error: invalid signature.
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.
bootrec.exe /fixmbr
bootrec.exe /fixboot
bootrec.exe /scanos
bootrec.exe /rebuildbcd
The very last command gave the following error:
The requested system device cannot be found
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 :
menuentry 'Windows 10 on /dev/sda2 MANUAL' {
insmod part_msdos
insmod ntfs
set root=(hd0,2)
chainloader +1
}
Selecting this entry in grub gives:
BOOTMGR missing
Press Ctrl+Alt+Del
Here's my boot-info : http://paste.ubuntu.com/24947042/
boot dual-boot grub2 uefi
boot dual-boot grub2 uefi
edited Jun 26 '17 at 7:45
Zanna
50.2k13133241
50.2k13133241
asked Jun 25 '17 at 8:48
Brummbaer
3116
3116
add a comment |
add a comment |
2 Answers
2
active
oldest
votes
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.
A very instructive answer ! Indeed, Hibernate and Fast Boot were disabled in Windows because I already had problems with those features, when trying to access my NTFS partitions from Ubuntu. You're right, I have an ESP partition on my small SSD that boots (usually) both Windows (on /dev/sda) and Ubuntu (on /dev/sdf). I'll keep using rEFInd, since I found it very convenient. Install the .deb package file and there you go, everything was fixed. Thank you for all the information about EFI and BIOS modes, my lack of knowledge about these caused me many troubles.
– Brummbaer
Jun 26 '17 at 16:07
add a comment |
Problem solved, I installed rEFInd using the .deb package file. Now everything works fine!
add a comment |
Your Answer
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "89"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2faskubuntu.com%2fquestions%2f928952%2fgrub-windows-10-wont-boot-invalid-signature%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
2 Answers
2
active
oldest
votes
2 Answers
2
active
oldest
votes
active
oldest
votes
active
oldest
votes
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.
A very instructive answer ! Indeed, Hibernate and Fast Boot were disabled in Windows because I already had problems with those features, when trying to access my NTFS partitions from Ubuntu. You're right, I have an ESP partition on my small SSD that boots (usually) both Windows (on /dev/sda) and Ubuntu (on /dev/sdf). I'll keep using rEFInd, since I found it very convenient. Install the .deb package file and there you go, everything was fixed. Thank you for all the information about EFI and BIOS modes, my lack of knowledge about these caused me many troubles.
– Brummbaer
Jun 26 '17 at 16:07
add a comment |
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.
A very instructive answer ! Indeed, Hibernate and Fast Boot were disabled in Windows because I already had problems with those features, when trying to access my NTFS partitions from Ubuntu. You're right, I have an ESP partition on my small SSD that boots (usually) both Windows (on /dev/sda) and Ubuntu (on /dev/sdf). I'll keep using rEFInd, since I found it very convenient. Install the .deb package file and there you go, everything was fixed. Thank you for all the information about EFI and BIOS modes, my lack of knowledge about these caused me many troubles.
– Brummbaer
Jun 26 '17 at 16:07
add a comment |
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.
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.
answered Jun 25 '17 at 15:12
Rod Smith
35.1k43870
35.1k43870
A very instructive answer ! Indeed, Hibernate and Fast Boot were disabled in Windows because I already had problems with those features, when trying to access my NTFS partitions from Ubuntu. You're right, I have an ESP partition on my small SSD that boots (usually) both Windows (on /dev/sda) and Ubuntu (on /dev/sdf). I'll keep using rEFInd, since I found it very convenient. Install the .deb package file and there you go, everything was fixed. Thank you for all the information about EFI and BIOS modes, my lack of knowledge about these caused me many troubles.
– Brummbaer
Jun 26 '17 at 16:07
add a comment |
A very instructive answer ! Indeed, Hibernate and Fast Boot were disabled in Windows because I already had problems with those features, when trying to access my NTFS partitions from Ubuntu. You're right, I have an ESP partition on my small SSD that boots (usually) both Windows (on /dev/sda) and Ubuntu (on /dev/sdf). I'll keep using rEFInd, since I found it very convenient. Install the .deb package file and there you go, everything was fixed. Thank you for all the information about EFI and BIOS modes, my lack of knowledge about these caused me many troubles.
– Brummbaer
Jun 26 '17 at 16:07
A very instructive answer ! Indeed, Hibernate and Fast Boot were disabled in Windows because I already had problems with those features, when trying to access my NTFS partitions from Ubuntu. You're right, I have an ESP partition on my small SSD that boots (usually) both Windows (on /dev/sda) and Ubuntu (on /dev/sdf). I'll keep using rEFInd, since I found it very convenient. Install the .deb package file and there you go, everything was fixed. Thank you for all the information about EFI and BIOS modes, my lack of knowledge about these caused me many troubles.
– Brummbaer
Jun 26 '17 at 16:07
A very instructive answer ! Indeed, Hibernate and Fast Boot were disabled in Windows because I already had problems with those features, when trying to access my NTFS partitions from Ubuntu. You're right, I have an ESP partition on my small SSD that boots (usually) both Windows (on /dev/sda) and Ubuntu (on /dev/sdf). I'll keep using rEFInd, since I found it very convenient. Install the .deb package file and there you go, everything was fixed. Thank you for all the information about EFI and BIOS modes, my lack of knowledge about these caused me many troubles.
– Brummbaer
Jun 26 '17 at 16:07
add a comment |
Problem solved, I installed rEFInd using the .deb package file. Now everything works fine!
add a comment |
Problem solved, I installed rEFInd using the .deb package file. Now everything works fine!
add a comment |
Problem solved, I installed rEFInd using the .deb package file. Now everything works fine!
Problem solved, I installed rEFInd using the .deb package file. Now everything works fine!
answered Jun 25 '17 at 10:22
Brummbaer
3116
3116
add a comment |
add a comment |
Thanks for contributing an answer to Ask Ubuntu!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Some of your past answers have not been well-received, and you're in danger of being blocked from answering.
Please pay close attention to the following guidance:
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2faskubuntu.com%2fquestions%2f928952%2fgrub-windows-10-wont-boot-invalid-signature%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown