12

I am migrating my Ubuntu EFI boot system to a larger hdd. I used the command

dd if=/dev/sdb of=/dev/sda

I did not dismount the input file before copying and the output file was fresh unpartitioned space. I have successfully booted from the new larger hdd.

  • fdisk -l reports:

    GPT PMBR size mismatch

  • gdisk reports the old drive size (200GB) and

  • PMBR is reporting the new hard drive size (2TB).

The error states gdisk w (write) command will work, however gdisk help recommends command xe (relocate backup to end of disk).

My goal is to remove the old drive and use the new drive as a primary boot disk with my old grub install intact.

Shall I just go ahead an expand the partitions or should I use one of these commands?

10

Do as the gdisk prompt suggests: Use the e option on the experts' (x) menu to relocate the data structures to the end of the disk. You can accomplish the same thing in parted or GParted if you prefer. IIRC, they do it semi-automatically, although they ask for confirmation.

Once you've moved the GPT backup data structures, you can resize your partition(s) using GParted.

  • 4
    You should believe this guy - he wrote gdisk. – mikeserv Mar 10 '15 at 1:50
  • I wound up using gparted from a live usb. I removed the partitions and rewrote the partition table on the new drive. From there, I wrote robot steps: gparted copied the partition structure of the old disk, and meanwhile also resized the partitions and copied data for the new disk. It did everything while I slept. – Zakri Kneebone Mar 10 '15 at 12:32
  • 1
    @ZakriKneebone: As I don't see the "why your should do this" explained here: because the GPT gets stored on the first and last sector of the disk just in case the one on the first sector fails, it still has a back-up... (and an upvote!) – Fabby Mar 12 '15 at 22:28
  • 1
    @RodSmith An alternative non interactive solution would be welcome too. After cloning using dd to a larger drive this issue always comes back. Handy if the clone script can fix the incorrect "backup GPT". I can't find a relocate option in GPT fdisk (sgdisk) version 1.0.3. Never mind superuser.com/questions/905756/… tells that -e|--move-second-header is the sgdisk option. – Pro Backup Jul 28 '18 at 21:49
1

I want to post an expanded explanation of my trials and error for those trying the same since documentation is rather fragmented and points to several different techniques. I wound up using gparted from a live usb. I removed the partitions and rewrote the partition table on the new drive. Gparted has a step sequencer: it copied the partition structure of the old disk, and meanwhile also resized the partitions and copied data for the new disk. It did everything while I slept. Using dd also required a manual update of fstab file which I skipped. I then tried ddrescue (from the Universe package via Synaptic, not Software Center) from live usb which reported it did not work with gpt. It referred me to gparted.

  • Good one too! Lots of people will be learning from this Q&A... – Fabby Mar 12 '15 at 22:29
0

Just another datum, I ran into this today resizing an EBS volume on my EC2 instance. I solved it by running growpart /dev/nvme0n1 1, which resized my partition correctly.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.