Grub2 starts in commanline after restart and can't find /boot or /grub

Question

Note: read question before marking it as duplicate. It is different. I would't find answer to the question anywhere.

I have windows 10 preloaded and dual booted it with ubuntu 18.04. I needed to increase space in c drive in windows 10. So I followed process given in bellow link https://www.diskpart.com/articles/increase-c-drive-space-5740.html

At the end it required my laptop to restart. After Restart it show me grub screen. It seems normal problem. In fact I found many answers in unix.stackexchange.com and askubuntu.com. I followed the process but I stuck in between.

GRUB starts in command line after reboot

As given answer and many other I need to find grub/ or boot/ I am not able to find that. Neither I was able to find vmlinuz-4.4.0-38-generic or initrd.img-4.4.0-38-generic with respective version by following process

I also followed https://www.linux.com/training-tutorials/how-rescue-non-booting-grub-2-linux/ which also provide good information

It seems my system is in (hd0,gpt1).

Directory structure shown to me in grub is as bellow

(hd0,gpt1)/efi
Boot/ Microsoft/ ubutnu/

Boot/
bootx64.efi fbx64.efi

ubuntu/
grubx64.efi grub.cfg shimx64.efi mmx64.efi bootx64.csv

So I can't see grub/ or boot/ as required by most of the answers instead what I see is different

Edit1: output of cat (hd0,gpt1)/efi/ubuntu/grub.cfg and ls (hd0 are shown below

Edit2: Thank to telcoM. I prepared Ubuntu installation USB and try Ubuntu functionality. I installed testdisk too. But it show me only one harddrive partition which is of my USB 32 GB.

Answer 1

Unfortunately, it looks like you may have destroyed your Ubuntu root filesystem while using the AOMEI Partition Assistant. Perhaps it could not identify Linux partitions, and showed them as unknown/empty partitions with no drive letter.

The fact that the Debian-style mini grub.cfg on the ESP says the prefix setting was

set prefix=($root)'/boot/grub'

indicates /boot was not a separate filesystem; if it was, the prefix would have been set to $(root)'/grub' instead.

Before the partition modification, at this point GRUB would have been able to find a filesystem with the UUID specified in the mini grub.cfg file. Since it cannot be found now, I'm afraid that filesystem may been overwritten or otherwise corrupted.

Your existing partitions seem to be:

• (hd0,gpt1) - this is the EFI System Partition that is used to load GRUB from.
• (hd0,gpt2) - by the size (only 16M), this seems to be the "Microsoft reserved" partition that is normally generated by Windows 10.
• (hd0,gpt3) - size approximately 67 GB / 64 GiB, your Windows C: drive according to your comments
• (hd0,gpt4) - size approximately 200GB / 191 GiB, your Windows D: drive according to your comments
• (hd0,gpt5) - size approximately 870M, contents unknown. Maybe a Windows recovery partition?

According to the partition sizes and start locations, there is a gap of about 220 GiB in between (hd0,gpt3) and (hd0,gpt4). This is probably where the Linux partition used to be located.

So the Linux partition seems to be lost. You should find yourself a Linux Live CD (or other suitable boot media) that contains a partition recovery utility like testdisk, and see if the Linux partition or any parts of it can be recovered.

Here's a link to a list of Live CDs that contain testdisk: https://www.cgsecurity.org/wiki/TestDisk_Livecd

---

You should be able to get into Windows by typing this into the GRUB prompt:

chainloader /efi/Microsoft/boot/bootmgfw.efi

But if you need to rescue any files from the Linux partition, you should not do that right now. In fact, you should avoid any operations that might write to the disk until you've either successfully rescued all the important files from the lost Linux partition, or are satisfied that further rescue attempts will not be worth the effort.

If you want to give up trying to recover Linux, going to BIOS settings and moving "Windows Boot Manager" to the first place in the boot order should also persistently restore the ability to boot Windows (only).

---

You should use another computer to prepare a bootable Live CD (or other live boot media, such as a pendrive) with testdisk or some other rescue utility available.

If you are familiar with Ubuntu, you could use Ubuntu Live functionality - you might prepare a Ubuntu installation USB and use its "Try Ubuntu" functionality, and then just use the usual package management tools to automatically download & install testdisk to a RAM-based installation. In this case, you'll need to do that again each time you boot from the USB in order to have the tool available.

Or you might use a longer procedure to set up a live USB with persistence or make a complete USB-based installation of Ubuntu; both of these options should allow you to use the standard package management tools to add testdisk and/or other recovery tools to the USB before coming back to the computer with the damaged Linux partition, booting it from the pendrive and making a recovery attempt.

You'll also need a second pendrive or other media you can use to save any recovered files into; although you might be able to mount the Windows D: drive and use it to store the recovered files, as it seems to be not overlapping the missing partition.

Once you can boot the computer from a pendrive and run testdisk on the computer's HDD (e.g. just sudo testdisk /dev/sda or whatever the device name of the HDD ends up being), the next steps depend on what it will report. In the best case, it might be able to simply undo what AOMEI did and restore the missing partition.

AOMEI Partition Assistant seems to be aimed for Windows users only, as it does not seem to support any non-Windows partition types. In the future, you may wish to use gparted instead for modifying the partitioning of any computer that has Linux installed.