2

I have a dual boot system with ubuntu 20.04 and windows 10. Because of being low on space I am upgrading my ssd to 512 gigs. I have booted into live ubuntu drive, and backed up each partition ubuntu, windows, efi as well as microsoft reserved from the previous 256 ssd via dd as follows

dd if=/dev/nvme0n1p6 of=/path/to/linux.img

and so on for each of the 4 partitions

After backup I have restored each partition now onto the new ssd as follows

dd if=/path/to/linux.img of=/dev/nvme0n1p4

Note the nvme0n1p4 here compared to the nvme0n1p6 before (partition names have been changed that might have messed up entries in my ubuntu bootloader grub)

I am less knowledgeable in this domain of bootloader and grub entries, and how it works, Any help would be HUGELY APPRECIATED.

Now when trying to reboot my system, it shows an error of windows OS saying it doesnt find the windows boot file rather than load the ubuntu grub at bootup, which was the default behavious previosuly, which i am thinking is due to the changed partition names now compared to before.

I should have dd'ed the entire ssd rather than individual partitions but some other SO post mentions it can cause problems if you are backing up to another hard drive than the one from where restore was taken from.

I have also tried to update grub and install grub via live cd but it says unable to find efi partitions.

All my work related stuff is there in that ssd and I really dont want to install linux again because it has all the configurations, packages, projects and everything. I have been trying to resolve this for 2 days straight but am unable to do so.

Any help would be really really appreciated!:)

gparted description

Improve this question
1
  • You typically cannot easily copy gpt partitions. The GUID is in the primary partition table, the partition, and the backup partition table. A dd does not update the partition table entries. And you cannot have duplicate GUIDs nor UUIDs when you reboot. Often just easier to do a new install & restore from backups. Becomes good test that backup includes everything. Commented Aug 16, 2023 at 22:28

1 Answer 1

Reset to default
0

From the presence of the msftdata "flag" on the NTFS partition and the existence of /boot/efi FAT32 partition, I see you are using GPT partitioning and are booting in native UEFI mode, instead of legacy MBR and BIOS, respectively. These two nuggets of information have a major effect on the actions you must do.

If your BIOS settings include the option to configure the system to either boot in UEFI mode only or at least prefer UEFI over legacy mode, I would strongly suggest using those settings. They should minimize the hassle of accidentally booting in the wrong mode, as part of recovery operations or otherwise.

First, your /boot/efi partition is not appropriately marked as an EFI System Partition (ESP for short). Since you seem to be using gparted, this means setting the esp flag on that partition; the boot flag will also get set automatically.

(With GPT partitioning, esp and msftdata are not really "flags", but various GPT partition type UUIDs. gparted just presents them as flags, which can be a bit confusing, as a partition can have only one type UUID, and so most of the "flags" will actually be mutually exclusive. With GPT, the boot flag is essentially just an alias for esp for compatibility reasons.)

The position, size and the label "nothing" for /dev/nvme0n1p2 suggests this might be the partition you intended for microsoft reserved. If so, you should set the msftres flag for it: it is just a reservoir of empty space just ahead of the Windows partition, to allow future filesystem conversions and upgrades.

Your only remaining Linux partition would seem to be /dev/nvme0n1p4, but it is marked with a mount point of /home - is that correct? If so, where's your actual Ubuntu root filesystem?

Next issue will be that since you imaged each partition separately and apparently rebuilt the partition table, the unique PARTUUIDs stored in the GPT partition table for each partition will be different.

Linux and GRUB normally use filesystem-level UUIDs instead, so they should be more or less immune to this change. But the UEFI firmware is likely to use the PARTUUID as the primary identifier of the EFI System Partition. This means the UEFI NVRAM boot entries (viewable with sudo efibootmgr -v when booted in UEFI mode) will be stale.

Because Windows has installed a second copy of its boot manager at /boot/efi/EFI/boot/bootx64.efi (the removable media/fallback boot path), it is now the only bootloader the UEFI firmware can find without further input from you. But apparently it either cannot find its configuration file /boot/efi/EFI/Microsoft/Boot/BCD, or the information it contains is invalidated by your changes.

You might try booting in UEFI mode from a Windows 10 installation media and using its "Repair Windows" option. It is probably the simplest way to fix the Windows bootloader, if it works - and you should do it before trying to fix the Linux bootloader, as Windows repair procedure will automatically place Windows as the first OS in the boot order (and may overwrite/delete the Linux NVRAM boot variable). By fixing Windows first, you'll only have to undo that once.

You probably could fix this with just the efibootmgr command. First ensure that /dev/nvme0n1p1 is mounted at /boot/efi, then run (e.g. from a Live CD):

sudo efibootmgr -c -L UbuntuNew -d /dev/nvme0n1 -l \\EFI\\ubuntu\\shimx64.efi

(If you have disabled Secure Boot and /boot/efi/EFI/ubuntu/shimx64.efi does not exist, replace shimx64.efi in the command with grubx64.efi.)

This creates a new UEFI boot variable which will appear in BIOS boot settings with the name "UbuntuNew". You can change that name to anything you want, but reinstalling GRUB may restore the old name, which is likely just "Ubuntu".

Improve this answer
5
  • Thank you so much for such a detailed answer. I am pretty less knowledgeable about some of the terminologies, let me research and wrap my head around and get back but lemme clarify one thing Abt the screenshot. I edited the mount point of fat32 to /boot/efi from disks utility, and also for the Linux partition to /home, but upon reboot to live cd it reverted back to original. About your question, That /home partition is my Ubuntu root partition where os resides, I didn't create /home in the first place. Let me try the steps that you mentioned Commented Aug 17, 2023 at 8:11
  • Creating a new boot entry for ubuntuNew did the trick(tysm), afterwards it gave filesystem inconsistency errors which were resolved by fsck and were probably caused by doing dd in two steps, i.e it was interrupted mid way and I had to use seek and skip flag to continue from there onwards, please correct me if I am wrong Abt the inconsistency part? Commented Aug 17, 2023 at 10:56
  • Ideally you should only image unmounted filesystems, but in practice, it is often possible to image active filesystems if the filesystem is quiescent (specifically, no changes are made) during the imaging. Doing the dd in two steps increases the chance that some write event slipped through between the two dd operations, so you are probably essentially correct. Commented Aug 17, 2023 at 13:04
  • Although I did the two way dd in a fail safe way(I assume), cuz for the second dd I started 1 gigs of blocks behind but I got your point. Secondly now after entering ubuntu, can i update the boot records and update the windows bootloader to point to the new partition table rather than using a windows live cd? Commented Aug 17, 2023 at 14:09
  • Recovering the Windows bootloader is off topic for Unix&Linux.SE. You might want to make a new question about it on SuperUser.SE instead. Commented Aug 17, 2023 at 17:44

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.