Windows 10 upgrade led to grub rescue

Question

I was dual-booting Windows 7 and Linux Ubuntu on my desktop, and today is the day they gave out free Windows 10 upgrades. How exciting! I got the update, and it was installing, and I left to go take a 30 minute nap. However, when I came back to my computer, it led me to the grub rescue prompt.

error: no such partition.
Entering rescue mode...
grub rescue>

I get the following when I type ls:

grub rescue> ls
(hd0) (hd0,msdos5) (hd0,msdos3) (hd0,msdos2) (hd0,msdos1)

After a quick look through of people who encountered the grub rescue prompt, I typed set and got the following

grub rescue> set
cmdpath=(hd0)
prefix=(hd0,msdos6)/boot/grub
root=hd0,msdos6

I was still kind of lost after finding that certain commands like normal didn't work, and then I found a video tutorial where you boot from a Linux image cd and run some commands on the terminal. Luckily, I had my CD with me, and booted from there. When I typed sudo fdisk -l into the terminal however, this is what I got:

ubuntu@ubuntu:~$ sudo fdisk -l

Disk /dev/sda: 1000.2 GB, 1000204886016 bytes
255 heads, 63 sectors/track, 121601 cylinders, total 1953525168 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
Disk identifier: 0xc03ede74

   Device Boot      Start         End      Blocks   Id  System
/dev/sda1   *        2048      206847      102400    7  HPFS/NTFS/exFAT
/dev/sda2          206848  1547022335   773407744    7  HPFS/NTFS/exFAT
/dev/sda3      1547022336  1547943935      460800   27  Hidden NTFS WinRE
/dev/sda4      1547945982  1953521663   202787841    f  W95 Ext'd (LBA)
/dev/sda5      1915731968  1953521663    18894848    7  HPFS/NTFS/exFAT

Says here none of my devices has the Linux system in them! And I couldn't follow the video tutorial any more than that...

I teased my brain a little and determined that sda2 contained my Windows system (since I remember my C: drive has around 700-ish GB of space). After thinking a little bit more, I remember assigning around 200-ish GB of my hard disk space to something that's Ubuntu related when installing Ubuntu. I don't exactly remember which, but I think it was basically Ubuntu "hard disk space", and it didn't have any boot files in them. I assigned two other things for linux, but they were very small in size (not breaking the 1 GB mark yet).

So, can anyone here help me out get my upgrade back on track? I won't mind if I end up having to completely remove the partitions that have Linux in them.

Solution 1

My computer came with Windows 8 pre-installed so I shrunk the Windows partition to make room for Ubuntu. That is how it worked for the last year. After the second reboot in Windows 10 upgrade the computer did not boot any more. GRUB only displayed a grub rescue command prompt. I found out later that the problem occurred because Windows somehow changed the partition scheme. The boot partition (containing normal GRUB data) was no longer where GRUB expected it. I don't know how and why this happened.

The first thing that you can do in the rescue mode is to see the partitions with the ls command. Mine were:

• (hd0,gpt1),
• (hd0,gpt2),
• etc.

Try to find out which partition is your boot partition. There is no Tab completion, you have to type it out completely. I tried the following commands until I found the right partition:

ls (hd0,gpt1)/
ls (hd0,gpt1)/boot
ls (hd0,gpt2)/

etc.

Then type set in the same prompt. It will display where GRUB looks for its files. In my case (hd0,gpt6) has moved to (hd0,gpt7). The set command displayed:

prefix=(hd0,gpt6)/boot/grub
root=hd0,gpt6

To get back into normal GRUB, start by changing the prefix setting to point to the right partition. In my case the command was:

set prefix=(hd0,gpt7)/boot/grub

Then you can switch from rescue to normal mode:

insmod normal
normal

One could also have fixed the root setting with:

set root=(hd0,gpt7)

But this is not strictly necessary, as it doesn't matter for Windows chain-load entries. Once in the normal GRUB menu, you can boot Windows and finish your Windows upgrade. The problem is that you have to tell grub rescue about the right partitions on every reboot. That is how I did it. I left the problem of GRUB for later because I was not sure whether Windows would do some more changes to the partitions or boot.

When Windows finished I started to solve GRUB problems. Press e to edit boot options for Ubuntu. I changed all (hd0,gpt6) to (hd0,gpt7) and Ubuntu booted.

However, I use encrypted partition and cryptswap. At the boot Ubuntu asked me for the passphrase. Fortunately I saved it at the installation of Ubuntu and entered it at the boot. Ubuntu booted without problems.

I then corrected the /boot/grub/grub.cfg file where I replaced (hd0,gpt6) with (hd0,gpt7) and performed:

sudo grub-install

At that point the only remaining issue was the encryption. Since the root Ubuntu partition number was increased by one (7 instead of 6), the swap partition suffered a similar change. I had to change the /etc/crypttab file to point to /dev/sda8 instead of /dev/sda7.

I am using only two partitions for Ubuntu (root and swap). If other operating systems coexisting with Windows use more partitions there might be more changes required. Especially if partitions are mounted according to their numbers and not by their UUIDs. Take a look at your /etc/fstab. If the partitions are identified by UUID there should be no problems. But if there are /dev/... lines the number should be corrected if these partitions had been renumbered.

Solution 2

Before changing partitions, make a backup and save to another device. If not sda change to correct drive. Then you can start over if you restore incorrect set with testdisk. You just want all current plus missing Logical when restoring with testdisk.

sudo sfdisk -d /dev/sda > parts.txt

Your missing partition is here or between start of extended partition at 1547... & first partition shown at 1915...:

/dev/sda4      1547945982  1953521663   202787841    f  W95 Ext'd (LBA)
/dev/sda5      1915731968  1953521663    18894848    7  HPFS/NTFS/exFAT

You can use testdisk, but it uses CHS. You have to choose all existing partitions and the missing partition as logical. It may show many versions depending on how many times you changed partitions around. So choose the size that matches the missing without overlapping any other current partitions. Some that have correctly restore were just able to boot, others has to reinstall grub. And some could not correct restore partition.

http://www.cgsecurity.org/wiki/TestDisk_Step_By_Step

Another restore tool is parted rescue. It uses sectors, but range you give must be just outside the missing partition with no overlap to current partitions. Best if you know exact start & end. See man parted

http://www.gnu.org/software/parted/manual/html_node/rescue.html

User who used parted rescue:

http://ubuntuforums.org/showthread.php?t=1775331&p=10905969#post10905969

Solution 3

It's a nasty bug in the Windows partitioner, and not Linux specific. It ironically deleted an NTFS partition in my case.

The Windows 10 installer creates a new partition (your /dev/sda3) carved off the end of the main Windows partition sda2 if the Windows boot partition sda1 is too small to contain the Windows 10 Recovery Environment.

When it rewrites the partition table to do this, for every logical partition in the extended partition table sda4, if it is located on the disk before the previous partition number, it gives up.

In your case your Linux partitions were located on your disk before your new sda5, but had higher partition numbers than sda5 had before the repartitioning.

If you look through the huge Windows 10 upgrade logs, you will see a message something like "6 before 5, Nothing to do", along with the old and new partition tables.

Windows does not overwrite the contents of the partitions it deletes, so it is possible to recover them if you can find where they are. In my case I had backups of the partition table, but using testdisk as explained in oldfred's answer has an excellent chance of finding them all. Parted rescue will be hard to use as more than one partition was deleted in your case.

To use testdisk from your Ubuntu Live CD, in a terminal type sudo apt-get install testdisk to install it, and sudo testdisk to run.

After repairing the partition table, the Linux partition containing GRUB may now have a different number to before, so you might still end up at the GRUB rescue prompt. If so, Boot Repair will now be able to fix GRUB.

Again, using your Ubuntu Live CD, type:

sudo add-apt-repository ppa:yannubuntu/boot-repair
sudo apt-get update
sudo apt-get install -y boot-repair && boot-repair

to install and run it.

Now Windows can complete its upgrade.

Solution 4

To use boot-repair you need to set in BIOS:

• Enable UEFI (in my BIOS it is:)

  Legacy support DISABLE

• Disable Secure Boot

Probably you have Secure Boot enabled, so you get "incorrectly signed file" error.

View more solutions

Comments

[Admin]

If LInux partition is a logical Windows does not rewrite partition table with it. Use testdisk. Some have used testdisk to restore it and reinstalled grub to MBR and had everything back to normal. But you must include all partitions correctly as Primary & logical for it to work. cgsecurity.org/wiki/TestDisk_Step_By_Step

[Admin]

In the layout above, it looks like there's only 3505 sectors left at the end of the disk after the new /dev/sda5 or (hd0,msdos5) partition, which would amount to only 1.7 MB, so the Linux partition could hardly be hiding in there. My best guess would be that the Linux partition entry somehow got shifted into that place (#5 instead of #6) and that its type was inexplicably changed. The first thing to try would be ls (hd0,msdos5)/ on the GRUB rescue prompt.

[Admin]

one more reason not to use windows, such an ignorant OS

[Admin]

Hi! Thanks for taking the time to help! I'm actually not too sure which partition it is! But I'll fiddle around a bit to see if it works.

[Admin]

No problem! Always glad to help.

[Admin]

Hi! So I booted the boot-repair-disk and used recommended repair. I did so and restarted my computer, but it takes me to windows boot manager, and tells me that a recent hardware or software change might have installed a file that is signed incorrectly or damaged. The file is \Windows\system32\winload.exe, status 0xc0000428. Pressing enter takes me to the boot manager to choose which OS to start, showing only Windows 7. Pressing enter on Windows 7 takes me back to the same error screen, resulting in a loop.

[Admin]

After doing some research, it sounds like the error code (0xc000428) is associated with winload.exe not being verified by some digital signature. Do it say anything about that?

[Admin]

Any update on the situation @LChaos2 ?

[speedogoo]

I met the exact same problem and parted shows "free space" where there was Linux. Run rescue with from/to of the "free space" and ext4 is back!

[Amedee Van Gasse]

Just want to chime in to say that gparted showed free space where ext4 used to be. Ran parted, set to sectors, print partitions, rescue with the from/to of the "free space" (don't forget to add an s for sectors to your values) and ext4 was back, exactly the same as @speedogoo. No need at all to fiddle with grub.

[Admin]

Yes, any update?

[bheeshmar]

Thanks for this breadcrumb. I was able to recover my wife's lost Linux partition using parted rescue. A grub-install later, we were back in action.

[dibs]

This was a great answer for me. I had no disc of Ubuntu and was upgrading my Windows from 8.1 to 10 and had the same problem. So this answer gets extra credit from me as I was able to just enter it and carry on until the update was done. Thanks for saving my bacon.

[toby]

Thanks for the clear explanation of what the problem is, this helped me a lot. I was in the same situation as described in the question. However testdisk wasn't able to find the deleted linux partition. For me Parted rescue did the trick and I was able to continue the windows 10 upgrade afterwards

[Jacques MALAPRADE]

Tried the ls (hd0,msdos1)/ ls (hd0,msdos1)/boot ls (hd0,msdos2)/ etc. for all entries from ls command, and every time it comes up with error: unkown filesystem.

[Nikita R.]

Thank you, that helped. One thing that wasn't clear for me (because I'm new to both Ubuntu and Grub) was that editing the grub config needed to be done after booting into Ubuntu (and not in the mini Emacs, which doesn't support saving the file apparently.) So I booted, then edited the config sudo nano /boot/grub/grub.cfg and then ran sudo grub-install /dev/sda (for some reason, the call without the parameter failed for me). And only then the permanent changes worked.

[Greg Bell]

"Windows does not overwrite the contents of the partitions it deletes" How can this be? The new partition it made for me (after killing my linux partitions) took up the whole disk. So doesn't this mean that writes could go anywhere.

[Camford]

Tried ls (hdo,msdos1) etc for all entries. Get error unknown file system

[nobody]

@Ash G Did you try hdo or hd0?

[dfrankow]

I think this happened to me because the Windows 10 upgrade added another small (1G) partition with the "diag" flag, meaning it's a diagnostic or recovery partition.

[a.j. tawleed]

So now even a Windows Update does this. I am using Windows for a while now

[laurent]

Like other comments here i got the unknown file system error, because i was typing 'hdO' instead of 'hd0'.

[aviggiano]

I can't express how much I love you

[WLKB]

This worked for me except editing the grub config in the end. You mention that you replaced (hd0,gpt6) with (hd0,gpt7), but I have no such lines in my grub config. I am using Arch and it seems that the config is generated from a .d folder. How does that line look like exactly? I assume it is missing in my case.

[nobody]

@exhuma, I am sorry I do not know how the grub and its files are organized in Arch. You will have to figure that one out. I think you will find the answers here: wiki.archlinux.org/index.php/GRUB#Configuration

[WLKB]

@nobody it's not really about the fine structure, but about the actual line that you needed to modify. What does that line look like? What's the name of the setting you needed to modify?

[nobody]

@exhuma I have done this a long time ago and I have now newer Ubuntu 19.10 on that computer. However, I have found some backup, which says that I changed set root=... and search... lines in grub.cfg. Now it seems that grub.cfg is generated from some advanced scripts, for which I do not know how they determine partition numbers, which are generated and written into grub.cfg.

[WLKB]

Ah shucks. Thanks anyway for going through the trouble and digging it out. I will continue my search.

[Dan]

I have just been through this process for a routine Windows 10 update in April 2020. My grub.cfg is autogenerated from various files in /etc (for an ancient Debian Jessy install) but I ignored all that and just did a search-replace in the autogenerated grub.cfg file to switch out every instance of the string "gpt5" with "gpt6". There were 20. It worked. This may not be Correct but could help someone get back into Windows...

[spirit]

This thread is many years old, but this just happened to me in June 2020 after a Win 10 update, so apparently MS hasn't fixed this bug in all the years. Is there any way I can prevent this from happening again next time? Your 2nd sentence seems to imply that having a large enough sda1 partition may help. But how large is large enough?