Win10 NVMe Image Restore Causes GRUB2 to Disappear

Question

So I have GRUB2 (v2.02 beta 3.6ubuntu3.9)working on a dual boot (each os has own hdd) Win10/Ubuntu 16.04 UEFI PC. A Macrium Reflect ("MR") backup image is created of all Win10 C:\ partitions (3; 221GB GPT, 99MB FAT32, 451 Unallocated).

Upon restoration of C drive (disk3) image GRUB2 menu disappears. Because it is a NVMe (e.g., instead of GRUB2 on sda1 it is on nvmeOn1p1) posted solutions will not work. Likewise, a "bare metal" restoration of N:\ drive (disk0;ssd) that has home and root partitions (SWAP on hdd) for Linux will not bring GRUB2 back.

A re-installation of Linux is required to get GRUB2 back. This happens with Reflect, Acronis, and Lazesoft imaging software. Tried backing up via EasyUEFI but this failed as well. Is there a better way to get GRUB2 back after an image restore?

Clarification:

I backup all partitions on a ssd via imaging software -- e.g., Macrium Reflect. When I need to restore an OS I boot from a WinPE usb or USBLinux and install an image from an image (MR) file in order to restore the drive to a previous condition.

Since I installed Ubuntu 16.04 I began dual booting. Despite reinstalling images for BOTH OS images (Win10 on NVMe C:\ (disk3) and Ubuntu on N:\ (disk0) GRUB2 cannot be restored. GRUB2 (and Linux) is installed on disk0 (MBR) but, my understanding, is that part of GRUB2 is also on disk3's EFI System Partition.

So either GRUB2 is hidden somewhere such that the imaging software can't copy it or it needs something like command "grub-update" to reactivate it, idk. The only way I can get the original GRUB2 is to reinstall Linux from a live Linux usb onto disk0 ssd. This is the problem -- GRUB2 disappears whenever I have to restore a backup os image. I'd like to either capture GRUB2 in the disk image (and be able to reinstall it via image) or find another way to backup GRUB2 so I don't have to reinstall Linux every time I have to restore a backup image of Win10 or Linux.

Apologies for the lengthy post. I had hoped to describe the problem in three short paragraphs but hopefully the above Clarification provides the details Android Dev requested.

Thanks!

System Info:

**Secure Boot & Fast Boot:  Disabled**

Summary
        Operating Systems:
            Windows 10 Pro 64-bit/Ubuntu 16.04 64-bit
        CPU
            Intel Core i7 4790 @ 3.60GHz    38 °C
            Haswell 22nm Technology
        RAM
            16.0GB Dual-Channel DDR3 @ 780MHz (9-9-9-24)
        Motherboard
            ASUSTeK COMPUTER INC. Z97-A (SOCKET 1150)   28 °C
        Graphics
            ASUS VE278 (1920x1080@59Hz)
            Dell E193FP (1280x1024@60Hz)
            2048MB ATI AMD Radeon HD 7800 Series (Sapphire/PCPartner)   43 °C
        Storage
            119GB Samsung SSD 840 PRO Series (SSD)  29 °C
            1863GB Seagate ST32000641AS (SATA)  36 °C
            3726GB TOSHIBA HDWQ140 (SATA)   34 °C
            232GB Samsung SSD 960 EVO 250GB (Unknown)
            3GB Samsung SSD 840 PRO Series (SSD)    29 °C

Hi, oldfred, your assistance is GREATLY appreciated. Here is the result of efibootmgr:

BootCurrent: 0000
Timeout: 1 seconds
BootOrder: 0000,0002,0001,003B,003E,0044,0045,0046
Boot0000* ubuntu    HD(1,GPT,2087d7-5dc8-4038-a9c1-90939c232,0xe1800,0x31800)/File(\EFI\UBUNTU\SHIMX64.EFI)
Boot0001* Windows Boot Manager  HD(1,GPT,287d7-5dc8-4038-a9c1-9d969c232,0xe1800,0x31800)/File(\EFI\MICROSOFT\BOOT\BOOTMGFW.EFI)WINDOWS.........x...B.C.D.O.B.J.E.C.T.=.{.9.d.e.a.8.6.2.c.-.5.c.d.d.-.4.e.7.0.-.a.c.c.1.-.f.3.2.b.3.4.4.d.4.7.9.5.}...d................
Boot0002* Windows Boot Manager  HD(1,GPT,20887dc7-5dc8-4038-a9c1-9d09639c2322,0xe1800,0x31800)/File(\EFI\MICROSOFT\BOOT\BOOTMGFW.EFI)WINDOWS.........x...B.C.D.O.B.J.E.C.T.=.{.9.d.e.a.8.6.2.c.-.5.c.d.d.-.4.e.7.0.-.a.c.c.1.-.f.3.2.b.3.4.4.d.4.7.9.5.}...d................
Boot003B* UEFI: (NTFS) Lexar USB Flash Drive    PciRoot(0x0)/Pci(0x14,0x0)/USB(21,0)/HD(1,MBR,0x104,0x800,0x3b9e800)..BO
Boot003E* Windows Boot Manager  PciRoot(0x0)/Pci(0x1,0x1)/Pci(0x0,0x0)/NVMe(0x1,00-25-38-57-71-B0-F8-84)/HD(1,GPT,20887dc7-5dc8-4038-a9c1-9d09639c2322,0xe1800,0x31800)..BO
Boot0044* Windows Boot Manager  PciRoot(0x0)/Pci(0x1,0x1)/Pci(0x0,0x0)/NVMe(0x1,00-25-38-57-71-B0-F8-84)/HD(1,GPT,2087c7-5dc8-4038-a9c1-90969c2322,0xe1800,0x31800)..BO
Boot0045* ubuntu    PciRoot(0x0)/Pci(0x1,0x1)/Pci(0x0,0x0)/NVMe(0x1,00-25-38-57-71-B0-F8-84)/HD(1,GPT,20887dc7-5dc8-4038-a9c1-9d0939c232,0xe1800,0x31800)..BO
Boot0046* ubuntu    HD(1,GPT,2087dc7-5dc8-4038-a9c1-9d06392322,0xe1800,0x31800)/File(\EFI\UBUNTU\GRUBX64.EFI)..BO

and from blkid:

device     fs_type label    mount point    UUID
-------------------------------------------------------------------------------
/dev/nvme0n1
                        (in use)       
/dev/nvme0n1p1
       vfat             /boot/efi      2A4B-F383
/dev/nvme0n1p2
       ntfs    960NVMe  (not mounted)  EE60D3E6040F31
/dev/sda1  ext4             (not mounted)  08bd78-3292-473f-a132-8b62dc7b1
/dev/sda2  ntfs    QA       /media/gks/QA 64DA7D8DA5C8
/dev/sda3  ext4             /              1ca465-6375-402c-be7d-4c7eb840e
/dev/sda4  ext4             /home          b467e3d-a581-4335-981b-bb7c0d23e
/dev/sdb1  ntfs    WindowsPAGE (not mounted) 6EEAFF83EA8B
/dev/sdb2  ntfs    BackUp   (not mounted)  E862507262504788
/dev/sdb4  swap             [SWAP]         cbd8ffa2-1c86-42c4-bead-64d6ab7bf82a
/dev/sdb5  ntfs    ASUSHDD2E (not mounted) 01CCE805006500
/dev/sdb6  ntfs    ASUSHDD2D (not mounted) 01CCE687CD6DC0
/dev/sdc1                   (not mounted)  
/dev/sdc2  ntfs    Toshiba4 (not mounted)  26E4D4EED61FBB
/dev/sdd1  ntfs

I'm a bit confused by your question. Can you edit to clarify? — You'reAGitForNotUsingGit, Sep 04 '17 at 14:15
Worst case may be reinstall of grub. But you may just need to re-add entry into UEFI. Post these above. sudo efibootmgr -v & sudo blkid -c /dev/null -o list UEFI's NVRAM forgets entries if a drive is disconnected. Or if ESP - efi system partition is recreated with new UUID/GUID as UEFI looks for GUID. PartUUID in blkid should match GUID in efibootmgr list of ubuntu entry. Also good idea to separately backup ESP/FAT32 partition(s). I do like to have an ESP on every drive with copies of boot files, but UEFI generally only uses one of them. And Ubuntu/grub only wants to install to sda. — oldfred, Sep 04 '17 at 15:39
n.b., oldfred. I changed some of the numbers which looked like serial numbers. After re-reading your reply I'm guessing that these are UUID/GUIDs. I'm not trying to be difficult but it seemed as though it might be imprudent to publicly disclose this info. Clearly, I'm in over my head here. — Ted Harold, Sep 04 '17 at 16:44
Please format output & need to see GUIDs. Ubuntu entries use GUID 2087d7-5dc8-4038-a9c1-90939c232 and one Windows entry also does, but another Windows entry 0001 does not. Sorry gave wrong command to show PartUUID, use this for each drive lsblk -o +PARTUUID /dev/sda Do not have NVME, so not sure of exact command, but expect something like this for it. lsblk -o +PARTUUID /dev/nvme0n1 You want partUUID of nvme0n1p1 to match entry in UEFI. Should be either 2087d7-5dc8-4038-a9c1-90939c232 or 287d7-5dc8-4038-a9c1-9d969c232,0xe1800,0x31800. — oldfred, Sep 04 '17 at 17:52

score 1 · Answer 1 · answered Sep 06 '17 at 13:49

You should be able to boot on a temporary basis by using my rEFInd boot manager on a USB flash drive or CD-R. (The link provides downloadable images for both types of media.) There is one caveat: The images I provide don't support Secure Boot, so you may need to disable that feature (temporarily, if you like). With rEFInd booting into your regular installation, your recovery options become easier, and of course you can use your system for real work while you figure out a long-term solution.

Chances are one or both of two things has happened:

Incomplete backup/restore of the ESP -- On an EFI-based system, the EFI System Partition (ESP) holds EFI boot loaders. If the ESP was not backed up, was not restored, or was incompletely backed up or restored, then the system will be rendered unbootable. It sounds like Windows is still booting, so I doubt if this is what's happening to you, but it's conceivable that the Windows backup software didn't bother to back up or restore GRUB. You can check this by looking for GRUB on the ESP. On an Ubuntu installation, it should be EFI/ubuntu/grubx64.efi on the ESP (with at least two other support files, shimx64.efi and grub.cfg, in the same directory).
Damaged or invalid NVRAM entry -- The efibootmgr output that oldfred requested shows the NVRAM entries that control the boot process. You've got three entries for ubuntu, one of which refers to shimx64.efi, another of which refers to grubx64.efi, and the third of which explicitly references neither file. The entry that refers to shimx64.efi (Boot0000) is first in the boot order, which means that it should be working; however, it's still possible that the NVRAM entry is damaged. In particular, your output refers to a partition with a GUID value of 2087d7-5dc8-4038-a9c1-90939c232 for that entry, with two other GUID values for your two other ubuntu entries. You said you changed what looked like serial numbers, so I'm guessing you altered these values. (That was unnecessary and makes it harder for us to diagnose your problem. These GUID values are not sensitive from a security point of view.) In any event, the backup/restore operation might have changed the partition GUID values. If so, those entries might be invalid, and you'll need to either change the partition's GUID value to match what's in NVRAM (which you can do with sgdisk, as in sudo sgdisk -u 1:2087d7-5dc8-4038-a9c1-90939c232 /dev/nvme0n1 to change the GUID of partition 1 of /dev/nvme0n1 to 2087d7-5dc8-4038-a9c1-90939c232) or create a new NVRAM entry (which you can do by typing sudo efibootmgr -c -d /dev/nvme0n1 -l \\EFI\\ubuntu\\shimx64.efi -L ubuntu). Depending on your process, you might prefer to do this from Windows using bcdedit or EasyUEFI, as described here. Other and more subtle types of NVRAM damage or NVRAM going out of sync with reality are possible, too.

In addition to fixing the problem in one of the above-specified ways, there's always the "brute force" approach of re-installing GRUB (or some other boot loader). The most common way to do this in Ubuntu is with Boot Repair, but there are other approaches, such as a manual re-install with sudo grub-install followed by sudo update-grub or installing rEFInd's Debian package or PPA.

One more point: Your question is phrased in such a way that it sounds as if you're doing this restore operation repeatedly. Normally, this would not be the case; you might (and should) create backups regularly, but restoring them would be done infrequently. One reason to do such restores frequently is if you're doing a mass deployment, as for a bunch of computers for an office or classroom. If this is the case, be aware that any target system on which Ubuntu's never been installed will not have an NVRAM entry for booting Ubuntu. Thus, the "damaged or invalid NVRAM entry" bullet point will always apply on such systems, even if it isn't the cause of the problem on your test system.

Finally, if you want to better understand the EFI boot process and how to handle it, I recommend the following reading list:

Adam Williamson's blog entry on how EFI works -- This page describes the theory behind EFI-mode booting.
A question and answers on the differences between BIOS and EFI booting on Superuser.com -- This provides the basics of the preceding, but is more concise.
My page on installing Linux on EFI systems -- This page is a more practical introduction to EFI-mode booting than Adam Williamson's blog.
My page on EFI boot loaders for Linux -- This page describes EFI boot loader choices for Linux systems.

score 0 · Answer 2 · answered Sep 17 '17 at 06:16

Apologies for the delay in follow up. An uninvited guest, Hurricane Irma, paid a visit.

Thanks to all for your comments. Rod, I'll certainly check out your solution and reading list.

Just a quick summary for anyone who faces the above problem. I've worked out a method which, so far, solves the problem.

Let's begin with the software used. Currently, I'm using Lazesoft Recovery Suite Professional for image backups of both Win10 and Ubuntu.

Upon making an image, Lazesoft will allow the imaging of some or all partitions. I image all available partitions. Importantly, when/if I need to restore an image I DO NOT restore the partition Lazesoft refers to as MBR (even though both drives are GPT). GRUB2 will most likely continue to present boot options if this restore selection is not checked.

If GRUB2 fails to appear despite the above action make sure that the UEFI boot priority has not changed. Specifically, the first item in the boot sequence should be something like nameofyourNVMe ubuntu. Occasionally, this option will be relegated to ubuntu, Windows Boot Loader, etc.

As an aside, my ASUS has an entry for boot device of UEFI only or UEFI and OPROM (or something like this that refers to a legacy device). Since Lazesoft formats as FAT32 it must have the latter option in order to boot from the usb drive.

Win10 NVMe Image Restore Causes GRUB2 to Disappear

2 Answers2