Grub Rescue after windows 10 1803 update

this method works! thank you!

Now please check at ‘sudo parted -l’ if p6 partition is flagged ‘boot,esp’?
Print please.

Oh, good to hear and you’re welcome.

I reboot it, and it now gives me the normal grub.

But this is the output of ‘parted -l’:
6 120GB 120GB 210MB fat32 msftdata
not sure why it is still this, i am not sure which partition the current new manjaro grub is placed at now.

Here are two problems I have now:

  1. How do I remove the old manjaro entry directory from bios, since it will just keep saying grub rescue.
  2. I want to avoid having this problem again from updating windows 10 in the future, how do I stop letting Windows 10 to automatically download and install update? I tried stopping the windows update service, but it turns itself back on after reboot. ( I would like solve this from using the windows 10 os)

thank u for reading

Good that it works now. Just for my own education can you please post the output of

fdisk -l

/dev/nvme0n1p1 2048 24578047 24576000 11.7G Windows recovery environment
/dev/nvme0n1p2 24578048 24782847 204800 100M EFI System
/dev/nvme0n1p3 24782848 24815615 32768 16M Microsoft reserved
/dev/nvme0n1p4 24815616 232851932 208036317 99.2G Microsoft basic data
/dev/nvme0n1p5 232853504 234528767 1675264 818M Windows recovery environment
/dev/nvme0n1p6 234530816 234940415 409600 200M Microsoft basic data
/dev/nvme0n1p7 234940416 339388415 104448000 49.8G Linux filesystem
/dev/nvme0n1p8 339388416 423274495 83886080 40G Microsoft basic data
/dev/nvme0n1p9 423274496 549103615 125829120 60G Microsoft basic data
/dev/nvme0n1p10 549103616 624713727 75610112 36.1G Microsoft basic data
/dev/nvme0n1p11 624715776 998164479 373448704 178.1G Microsoft basic data
/dev/nvme0n1p12 998166528 1000214527 2048000 1000M Windows recovery environment

All of it pls.

oh sorry, sort of a busy day while having this computer issue, haha.

Disk /dev/nvme0n1: 477 GiB, 512110190592 bytes, 1000215216 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: 4509B168-0E35-4CCA-A24F-A85A3C31C25D

Device Start End Sectors Size Type
/dev/nvme0n1p1 2048 24578047 24576000 11.7G Windows recovery environment
/dev/nvme0n1p2 24578048 24782847 204800 100M EFI System
/dev/nvme0n1p3 24782848 24815615 32768 16M Microsoft reserved
/dev/nvme0n1p4 24815616 232851932 208036317 99.2G Microsoft basic data
/dev/nvme0n1p5 232853504 234528767 1675264 818M Windows recovery environment
/dev/nvme0n1p6 234530816 234940415 409600 200M Microsoft basic data
/dev/nvme0n1p7 234940416 339388415 104448000 49.8G Linux filesystem
/dev/nvme0n1p8 339388416 423274495 83886080 40G Microsoft basic data
/dev/nvme0n1p9 423274496 549103615 125829120 60G Microsoft basic data
/dev/nvme0n1p10 549103616 624713727 75610112 36.1G Microsoft basic data
/dev/nvme0n1p11 624715776 998164479 373448704 178.1G Microsoft basic data
/dev/nvme0n1p12 998166528 1000214527 2048000 1000M Windows recovery environment

G… Why is that so fragmented? How many Versions of Windows have you running? I see 3 recovery partitions.

Okay. Don’t worry about this.
I have myself ‘unflagged’ $esp and it still boots very well.
Some here have needed the $esp to be flagged as boot and then it boots.
I guess that their disk are not setup well (as in setting msdos or gpt) before use.
Linux generally do not care so much about boot flags while windows must have the boot flags for windows bootloader. Don’t worry about this flag thing here. I was wondering if this lack of flag (like in some here) is causing you the same problem. It wasn’t.

I am not clear where you see this entry. At system bios-setup (F2) ?
And when you boot normally (without going to bios-setup), isn’t that working as you said it is (without grub-rescue)? If that is the case, just leave it alone. I have an idea but I’m afraid I might have understood you wrongly and give a bad advice.

As you mention, you can stop updates in windows itself (or find a way without turning it back on). But not all windows update messes it up, only the major ones. And since you now know how to handle this when it messes up, you might want to rethink if you want to stop windows update. That’s entirely up to you. Oh, we cant stop windows updates from the linux side, if you’re wondering.

Cheers. Take care.

i know right? the windows 10 updated twice, so the recoveries are generated. that is why i want to stop the windows 10 update

I ment no offence. You sure have your reasons to partition your system like this.

Oh, no no, sorry if I offend you as well. To be honest, I dont know how the recoveries came up, but since I updated twice for the two major updates, now i have three recoveries. I think I will just leave it.

Anyway, Thank you for helping!

No worries. I thought it was on my side :smile:
I would consider the “fresh start” MS offers. I did that once and it turned out well. Rid me of a lot of problems.

will the next Windows 10 18XX update distroy grub again?

I don’t know. This somehow depends on how Win10 treats different hardware. It did not happen with my setup on the surface pro after updating to 1803. It can happen with the next update. But sharply said, if it happens, it could be considered computer sabotage.

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.

Forum kindly sponsored by Bytemark