Score:0

Dual boot with Windows 10, Grub no longer working

ec flag

I had dual boot working for the last few months on my PC, with Windows 10 and the EFI partition on a NVMe drive and Ubuntu on a SATA SSD. Both the Windows Boot Loader and Grub are installed on the NVMe drive, while the Grub config is on the SATA SSD.

Unfortunately, the last time I used Windows it did not shut down properly (I had to power cycle the PC) and now grub only displays the grub> prompt. Selecting the Windows Boot Manager from the motherboard's EFI does boot Windows correctly.

So I booted from a live USB, installed boot-repair and ran the utility. Whether I used the recommended repair or selected Purge GRUB before reinstalling it and Upgrade GRUB to its most recent version I had the same result as before.

Though when I unselected SecureBoot I had another result, grub is now showing error: no such device: b5d41058-ecac-4877-895d-2f9206cef3d2.

I have been looking into this issue for five hours, so I am now enlisting your help.

I generated a boot info using boot-repair, it should contain everything needed. Note that sdb is the live USB.

Also noteworthy, I'm using an AMD B550 chipset, which required me to update grub when I first moved my disks to my current PC.

Thank you very much!

user10489 avatar
in flag
This sounds like you might have a hard drive failure. This could cause both the windows and linux failures. From the linux live disk, can you open a shell and run some commands? `lsblk` to list disks, and `smartctl -a /dev/XXX` on the disk likely to contain your linux partition... (Also possible is that your disk is fine but your linux partition is gone.)
oldfred avatar
cn flag
Not seeing much in report, but it does show both systems without errors. Windows updates may also update UEFI (which can be a good thing). But UEFI updates may reset some settings and you have to redo those. I keep a list to check after UEFI updates. AMD often needs IOMMU setting. And very new systems work better with 21.04 to have newest kernel & drivers. https://askubuntu.com/questions/1265397/unable-to-install-ubuntu-20-04-via-live-usb-ryzen-5-3600
Captain H. avatar
ec flag
Hello, sorry for the delayed response, I unfortunately had more pressing issues to attend to. @user10489 SMART is OK, as well as fsck, so the disk seems fine. I'm also able to mount it from the live session.
Captain H. avatar
ec flag
@oldfred I'm not sure to understand what you mean by UEFI settings that Windows 10 may update, can you explain further?
oldfred avatar
cn flag
UEFI can get updated, and typically should be updated if updates available. But updates usually reset settings to defaults. I multiple settings, some required & some optional that I have to regularly redo after an update. Drives need to be AHCI and AMD systems usually need IOMMU setting, not sure what else on your system.
Captain H. avatar
ec flag
@oldfred I checked my BIOS settings, SATA drives are still in AHCI, but I could not find any mention of IOMMU. The board is an [MSI MPG B550I Gaming Edge Wi-Fi](https://www.msi.com/Motherboard/MPG-B550I-GAMING-EDGE-WIFI) with BIOS 7C92v15.
oldfred avatar
cn flag
It does show two new UEFI/BIOS plus an additional beta version. Updates may include other things not listed.
Captain H. avatar
ec flag
Hello, so today I updated the BIOS to the latest stable version then retried reinstalling Grub from a 20.04.3 live USB (which as the latest HWE). It ended up installing `grub-efi` [2.04-1ubuntu45](https://packages.ubuntu.com/hirsute/grub-efi) but it did not fix the issue: I get the same error as before.
Score:2
ec flag

So, I tried reinstalling Ubuntu onto the SATA SSD with no luck: grub was still broken. What I ended up doing was switching to a NVMe SSD (Samsung 980), which fixed my issue.

I'm not sure whether my 860 was dead (though SMART is OK and Ubuntu seemed fine to install on it) or if it's a weird behavior caused by a mix and match of SATA and NVMe drives (and probably the AMD chipset).

I hope this will somehow help anybody with a similar issue, I wished I knew what was the exact issue with my PC.

Score:0
cn flag

I don't know why that happens, but i wanna suggest a solution.

First, boot windows 10.

Second, Install Grub2Win. Installation link-->https://sourceforge.net/projects/grub2win/

After Installing Grub2Win ,set everything properly.

Every time you boot, Grub2Win will be displayed then you can choose OSes.

Here is a reason why i suggest this solution.

I dont know the detail but when your computer boot windows 10, your windows default bootloader just pick windows 10 OS and that's it.

Grub is installed in sda, the SATA SSD device. However when you pick nvme, which has windows 10 installed, there is no grub. Windows 10 has only default bootloader.

Therefore, whenever you choose that nvme, that windows 10 always pick Win10 only.

So my plan is make your nvme device has a non-default bootloader so that new bootloader can pick another OSes.

Captain H. avatar
ec flag
Hello, I'm not sure if you understood my issue. Grub is installed on my NVMe drive, but the grub configuration is on the SATA SSD. I'm going to edit my question to make it clearer.
Score:0
in flag

Since you say that you can mount your linux filesystem manually from the live disk, and fsck on it returns no errors, and you can get to the grub> prompt, then it sounds like either the UUID of your linux filesystem has changed, or grub's idea of what that should be has been damaged.

The solution to this is to get into the system on your disk by one of the methods below, and then run update-grub to recreate the second stage grub boot loader information.

There are several ways to get there:

  • boot a livedisk of the same version you installed on your disk and chroot into the OS on the disk. This is well covered here.
  • use the grub> prompt to find your root disk manually and then load the kernel and initrd ; This is easy if you know what you are doing, and very hard if you don't, but sometimes, once you've found the root disk, you can take a short cut by loading the broken grub config file and then edit it in memory to correct the root disk. Some of that is covered here.
  • use refind (booted from a usb?) to directly boot a kernel and initrd from the filesystem, bypassing grub (this is easiest when it works, but frequently it can't read your filesystem to find a kernel)

Once you've used one of the methods above, update-grub should fix it. It might also help to run grub-install, but if you are getting the grub> prompt, this probably isn't necessary.

Captain H. avatar
ec flag
I just double-checked and the UUIDs matches. One hypothesis I had was that either grub boots before the SATA drive has time to be initialized or that somehow grub cannot access it, but I have no idea how I can check this.
Captain H. avatar
ec flag
Well, since you apparently can't make `pre`s in the comments, here's a [pastebin](https://paste.ubuntu.com/p/5JYkQgVZCf/) of the two commands I ran to check that the UUIDs are correct.
user10489 avatar
in flag
If the uuid matches, you are probably right about the other two alternatives. Perhaps the drive isn't spun up in time for grub to look for it. If this is the case, you should be able to power up, fail the boot, hit ctrl-alt-del and retry the boot. If that works, look for a way to delay grub before it tries to boot.
Captain H. avatar
ec flag
Ctrl-alt-del seems to restart the PC as after I hit the keys I see the motherboard logo then grub boots again. You said "Perhaps the drive isn't spun up in time", just to clear any ambiguity, its a SATA SSD, not HDD. I'll see how to delay grub during the weekend to see if it fixes the issue.
user10489 avatar
in flag
Yes, if it's not a spinning disk then this won't help. But I can't think why an SSD would show the matching UUID but not be found by grub. Maybe a driver issue? Maybe it doesn't actually match (or something you are not looking at mismatches), and rerunning update-grub would still help.
mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.