Attempting a grub rescue boot, encountering very unexpected behaviour
A friend has a system dualbooting Debian (I installed a small recovery script there that flashes back a stored Windows partition) and Windows 10.
Apparently Windows did a really large update (possibly the anniversary update, though I don't know why it only did it now if that's the case) and the next boot got stuck at the grub rescue prompt. After determining which partition was the one with Debian using ls, I attempted to make him follow the following procedure: Code:
grub rescue> set root=(hd0,4) Windows is installed in sda1, with user data in sda2. sda3 used to contain Debian, but that's now in sda4. As for what's in sda3 now, my guess is that the installer recreated there the Windows boot data partition that I usually forego (I prefer everything to be placed in the main Windows root), upsetting the partition order and creating this whole mess. |
I've seen a lot of posts with people whose booting was messed up by major windows updates. Did you have both windows 10 and Debian installed using UEFI. If you have a Linux DVD/flash drive, you can boot it and mount sda3 to see what is on it. To get more info, you can download the boot repair software and burn it to a CD and boot it. When you do that there will be an option to "Create Bootinfo Summary". After it runs, you will get a link where the output is posted which you can past here. That will provide more details and someone should be able to advise you.
https://help.ubuntu.com/community/Boot-Repair I don't use UEFI myself so maybe someone else who does will see your post and have a solution. |
what happens if you skip the insmod normal and normal lines?
|
All guesswork until we get that bootinfo data requested in post #2.
|
All times are GMT -5. The time now is 07:13 AM. |