I recently ran into a classic problem on my long-running Fedora installation: my /boot partition was full. Back when I set up the system (around Fedora 20), 400MiB was more than enough. Now, with modern kernels, it can barely hold two versions, let alone the default three that Fedora manages. This meant I couldn’t run system updates.

The challenge was that my disk was partitioned with /dev/sda1 for /boot and /dev/sda2 as a single large LVM physical volume for my /root and /home filesystems. This setup prevents a simple resize of /dev/sda1.

After some research, I decided the safest approach was to migrate my entire system to a new SSD of the same size, but with a larger /boot partition. This post documents the steps I took to successfully complete this migration. All operations were performed on a spare Linux computer.

The Setup

  • Original Drive (250GiB SSD): Connected as /dev/sdb.
  • New Drive (250GiB SSD): Connected as /dev/sdc.

Step 1: Partitioning the New Drive

First, I needed to create a new partition layout on the new drive (/dev/sdc). I used fdisk to match the MBR partition table of the original drive.

  1. Create a 4GiB boot partition: This will be /dev/sdc1.
  2. Create a second partition for LVM: This partition, /dev/sdc2, will use the remaining ~225GiB of space.

Step 2: Copying the Boot Partition and Resizing the Filesystem

With the new partitions created, the next step is to copy the data.

  1. Copy the boot partition data: I used dd for a block-level copy from the old boot partition to the new one.

    # dd if=/dev/sdb1 of=/dev/sdc1 bs=4M status=progress

  2. Resize the filesystem: The dd command copies everything, including the original filesystem size (400MiB). To make the filesystem use the full 4GiB of the new partition, I ran e2fsck and resize2fs.

    # e2fsck -f /dev/sdc1
# resize2fs /dev/sdc1

Step 3: Migrating the LVM Volumes

This was a more complex part. I needed to recreate the LVM structure on the new drive and copy the data.

  1. Create a new Physical Volume (PV) and Volume Group (VG):

    To avoid conflicts, I named the new Volume Group watamem (the original was fedora_watamem).

    # pvcreate /dev/sdc2
# vgcreate watamem /dev/sdc2

  2. Create the Logical Volumes (LVs):

    I created home and root logical volumes with the same (or slightly larger) size as the originals.

    # lvcreate -L 54G -n home watamem
# lvcreate -L 90G -n root watamem

  3. Copy the LV data:

    Again, I used dd to copy the data from the old logical volumes to the new ones.

    # dd if=/dev/fedora_watamem/home of=/dev/watamem/home bs=4M status=progress
# dd if=/dev/fedora_watamem/root of=/dev/watamem/root bs=4M status=progress

Step 4: Making the New Drive Bootable

At this point, all the data was on the new drive, but it wouldn’t boot. I needed to chroot into the new system to update the bootloader configuration.

  1. Mount the filesystems:

    # mount /dev/watamem/root /mnt
# mount /dev/sdc1 /mnt/boot
# mount --bind /dev /mnt/dev
# mount --bind /sys /mnt/sys
# mount --bind /proc /mnt/proc

  2. Enter the chroot environment:

    # chroot /mnt

  3. Update GRUB configuration:

    Inside the chroot, I updated the GRUB configuration to point to the new watamem volume group, regenerated the config file, and reinstalled GRUB to the MBR of the new drive.

    # sed -i 's/fedora_watamem/watamem/g' /etc/default/grub
# grub2-mkconfig -o /boot/grub2/grub.cfg
# grub2-install --target=i386-pc /dev/sdc

  4. Exit and Unmount:

    # exit
# umount /mnt/{dev,sys,proc,boot}
# umount /mnt

The Final Step

With the migration complete, the only thing left was to swap the drives. I plugged the new SSD into my workstation, held my breath, and powered it on.

Success! The system booted up perfectly from the new drive, and I now have a spacious 4GiB /boot partition. I’m even writing this blog post from the newly migrated system.