Can't resize partition after cloning the disk to the bigger disk

Question

I cloned my entire disk to the new disk with dd if=/dev/sdb of=/dev/nvme0n1 . It was a long process so I don't want to repeat it again. I booted from the new disk but there is a problem: the new disk is twice bigger than the old one. When I try to resize my /home partition from live-cd with gnome disks and gparted I get errors.

This is what sudo fsck.ext4 -v /dev/nvme0n1p6 says:

e2fsck 1.46.5 (30-Dec-2021)
The filesystem size (according to the superblock) is 67138671 blocks
The physical size of the device is 67138560 blocks
Either the superblock or the partition table is likely to be corrupt!

My partitons look like this:

/dev/nvme0n1p1   (/)
/dev/nvme0n1p2
    /dev/nvme0n1p6    (home)
    /dev/nvme0n1p7    (boot)
    /dev/nvme0n1p5    (swap)

So, I want to resize nvme0n1p6. How can I do it?

fdisk -l /dev/nvme0n1 result:

Disk /dev/nvme0n1: 476.94 GiB, 512110190592 bytes, 1000215216 sectors
Disk model: KINGSTON SKC3000S512G                   
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x39739d02

Device         Boot     Start       End   Sectors   Size Id Type
/dev/nvme0n1p1 *         2048  78127047  78125000  37.3G 83 Linux
/dev/nvme0n1p2       78127102 625141759 547014658 260.8G  5 Extended
/dev/nvme0n1p5      616755200 625141759   8386560     4G 82 Linux swap / Solaris
/dev/nvme0n1p6       78127104 615235583 537108480 256.1G 83 Linux
/dev/nvme0n1p7      615237632 616751103   1513472   739M 83 Linux

P.S. With gparted I extended /dev/nvme0n1p2 to 439GB but I still have 178 unallocated GB. They are just in this union partition now.

New fdisk info:

Device         Boot     Start        End   Sectors   Size Id Type
/dev/nvme0n1p1 *         2048   78127047  78125000  37.3G 83 Linux
/dev/nvme0n1p2       78127102 1000214527 922087426 439.7G  5 Extended
/dev/nvme0n1p5      616755200  625141759   8386560     4G 82 Linux swap / Solaris
/dev/nvme0n1p6       78127104  615235583 537108480 256.1G 83 Linux
/dev/nvme0n1p7      615237632  616751103   1513472   739M 83 Linux

Answer 1

It would appear that your filesystems are already “corrupted”, for whatever reason. While you may shy away from cloning it again, I strongly recommend you do it anyway. This is a great opportunity you will not get again!

You apparently are still using CSM/BIOS booting. To get ready for the future (well, present, really), my suggestion is as follows:

• Do not use block-based cloning, instead sync over files.
• Use GPT on the new drive—with Linux, you can use either CSM/BIOS booting or UEFI with GPT!
• Maybe also rearrange partitions so that you can more easily clone/resize relevant partitions in the future.

First, a caveat: Not block-cloning the entire drive means you will have to reinstall your bootloader! You cannot skip this, otherwise the cloned drive will not boot.

The abstract steps are easy. All need to be done as root:

1. Create fresh GPT partition layout on destination drive.
   • If you want to continue using CSM/BIOS booting, you must start with a 1 MiB “BIOS boot partition” (type ef02 in gdisk, bios_grub in parted, 21686148-6449-6E6F-744E-656564454649).
2. Create filesystems (and swap) on the newly created partitions. Maybe something different than ext4 nowadays? You decide!
   • Instead of a Linux-formatted /boot partition, consider using a FAT32 EFI System Partition to be more future-proof. Make sure to consult your distribution’s documentation whether this partition should be at /boot/efi or whatever afterwards! This will work even with CSM/BIOS.
3. Clone each partition. Create /mnt/old and /mnt/new. In turn, mount each pair of partitions and then do rsync -axHAWXS --numeric-ids --info=progress2 /mnt/old /mnt/new.
   • If (and only if) the new boot partition won’t be at /boot, clone the old /boot partition to the new / partition: rsync -axHAWXS --numeric-ids --info=progress2 /mnt/old /mnt/new/boot
4. One the new / partition, update /etc/fstab (/mnt/new/etc/fstab) with the new device names. (And possibly change /boot to /boot/efi.)
   • While you’re at it, why not use UUIDs?
5. Reinstall your boot loader. I’ll assume GRUB 2. (Commands like arch-chroot let you do skip the bind mounts.)
   1. Mount your new root partition at /mnt/new.
   2. Mount the new boot partition at /mnt/new/boot or /mnt/new/boot/efi. (Check documentation!!)
   3. Mount /dev: mount --rbind /dev /mnt/new/dev
   4. Mount /sys: mount --rbind /sys /mnt/new/sys
   5. Enter the target environment: chroot /mnt/new
   6. Install GRUB to the new drive: grub-install /dev/nvme0n1—GRUB should auto-detect the rest.
   7. Create new GRUB config: grub-mkconfig -o /boot/grub/grub.cfg (Make sure to adapt paths as needed.)

In the future, if you go UEFI, you’ll have more boot loader options. GRUB 2 is still perfectly good of course!

If you do want to switch to UEFI booting, you have a bit of an chicken-or-egg problem: You will need to UEFI-boot to properly install your bespoke UEFI boot loader, then reinstall the boot loader again. I’m sure there’s guides on the net.

---

Warning: I haven’t actually tested any of this yet. As it doesn’t touch your old drive, you should be quite safe. Make sure not to bodge any commands so as not to accidentally overwrite the old drive!