Migrating Fedora to an SSD

Operating Systems & Open Source Linux
1

I'm currently using Fedora 25 on an older computer. It's currently installed on a 500GB HDD, but this HDD is old, slow and loud so I'm looking to upgrade to an SSD for the OS. I could easily do a fresh installation on the SSD but I was wondering if there's a healthy way to migrate my current installation to the SSD without having to do a fresh install and re-apply all of those settings. However if such a procedure would for any reason cause the OS to run less than ideal on the new disk, then I would do a fresh install.
What's the best practice in this case?

Thanks.

2

You can do a fresh install, then just migrate your /home folder. You keep all your settings and files, however you lose all your programs. (in a perfect world)

2 Likes
3

Resizing your partitions and then cloning them onto your new drive can work as well. Of course things can go wrong.
Also make sure to update the UUIDs in your /etc/fstab and your /etc/crypttab file. Otherwise Fedora won't mount your partitions.

4 Likes
4

This is exactly what I did when switching my SSD for a new one. Worked like a charm.

5

First step: compare the actual disk size you use with the size of the SSD.

If it will fit as-is, you can boot a LiveUSB of your choice, and resize and move the partitions as needed with gparted.
Then, you can use MD to migrate on the fly, or clone everything offline.

Beware: you still need to install a bootloader on the SSD!

You can also "just" prepare the partitions on the SSD, rsync all files into them from a LiveUSB, chroot and make it bootable.

If you provide more info, we can give better advice.

1 Like
6

dd if=/dev/sda of=/dev/sdb bs=10M will work just fine. You can even keep a compressed copy for keepsies ! like this dd if=/dev/sda | gzip -c > /image.img and restore your image with gunzip -c image.img.gz | dd of=/dev/sdb at a later date.

1 Like
7

What info would be best to provide? My current HDD's total size is 500GB, but the SSD's total size will be 256GB.

Here's some info, maybe it will help:

[xsahajax@localhost ~]$ sudo fdisk -l
Disk /dev/sda: 465.8 GiB, 500107862016 bytes, 976773168 sectors
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: 0x466f129c

Device     Boot   Start       End   Sectors   Size Id Type
/dev/sda1  *       2048   2099199   2097152     1G 83 Linux
/dev/sda2       2099200 976773119 974673920 464.8G 8e Linux LVM


Disk /dev/sdb: 1.8 TiB, 2000398934016 bytes, 3907029168 sectors
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: gpt
Disk identifier: 28CD50EC-5646-4901-BA4F-4FE48A859325

Device      Start        End    Sectors  Size Type
/dev/sdb1      34     262177     262144  128M Microsoft reserved
/dev/sdb2  264192 3907028991 3906764800  1.8T Microsoft basic data


Disk /dev/mapper/fedora-root: 50 GiB, 53687091200 bytes, 104857600 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes


Disk /dev/mapper/fedora-swap: 7.9 GiB, 8480882688 bytes, 16564224 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes


Disk /dev/mapper/fedora-home: 406.9 GiB, 436861927424 bytes, 853245952 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes

sdb is a secondary hard drive that is irrelevant. sda will be upgraded.

8

(probably) where that information came from:

https://wiki.archlinux.org/index.php/disk_cloning

Step-by-step how-to for cloning a drive. You can do partitions instead after resizing them. Easy-mode stuff. The /etc/fstab is the only thing to change after cloning but before swapping the drives.

2 Likes
9

yeah I've never cloned or helped clone/repartition/ back up drives before... :stuck_out_tongue_winking_eye:

1 Like
10

So if I interpret that correctly you are using MBR booting and LVM. I assume you use /dev/sda1 for /boot. Is that correct?

You can always provide the output of "df -h" and "mount", then I'll gladly provide you with recipe to upgrade.

11

@sam_vde

df -h:

[xsahajax@localhost ~]$ df -h
Filesystem               Size  Used Avail Use% Mounted on
devtmpfs                 7.6G     0  7.6G   0% /dev
tmpfs                    7.6G     0  7.6G   0% /dev/shm
tmpfs                    7.6G  1.4M  7.6G   1% /run
tmpfs                    7.6G     0  7.6G   0% /sys/fs/cgroup
/dev/mapper/fedora-root   50G   14G   33G  30% /
tmpfs                    7.6G  636K  7.6G   1% /tmp
/dev/sda1                976M  180M  729M  20% /boot
/dev/sdb2                1.9T  1.1T  773G  59% /mnt/Data
/dev/mapper/fedora-home  401G  2.2G  378G   1% /home
tmpfs                    1.6G   16K  1.6G   1% /run/user/42
tmpfs                    1.6G   16K  1.6G   1% /run/user/1000

Mount:

[xsahajax@localhost ~]$ mount
sysfs on /sys type sysfs (rw,nosuid,nodev,noexec,relatime)
proc on /proc type proc (rw,nosuid,nodev,noexec,relatime)
devtmpfs on /dev type devtmpfs (rw,nosuid,size=7943772k,nr_inodes=1985943,mode=755)
securityfs on /sys/kernel/security type securityfs (rw,nosuid,nodev,noexec,relatime)
tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev)
devpts on /dev/pts type devpts (rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000)
tmpfs on /run type tmpfs (rw,nosuid,nodev,mode=755)
tmpfs on /sys/fs/cgroup type tmpfs (ro,nosuid,nodev,noexec,mode=755)
cgroup on /sys/fs/cgroup/systemd type cgroup (rw,nosuid,nodev,noexec,relatime,xattr,release_agent=/usr/lib/systemd/systemd-cgroups-agent,name=systemd)
pstore on /sys/fs/pstore type pstore (rw,nosuid,nodev,noexec,relatime)
cgroup on /sys/fs/cgroup/cpu,cpuacct type cgroup (rw,nosuid,nodev,noexec,relatime,cpu,cpuacct)
cgroup on /sys/fs/cgroup/freezer type cgroup (rw,nosuid,nodev,noexec,relatime,freezer)
cgroup on /sys/fs/cgroup/perf_event type cgroup (rw,nosuid,nodev,noexec,relatime,perf_event)
cgroup on /sys/fs/cgroup/cpuset type cgroup (rw,nosuid,nodev,noexec,relatime,cpuset)
cgroup on /sys/fs/cgroup/pids type cgroup (rw,nosuid,nodev,noexec,relatime,pids)
cgroup on /sys/fs/cgroup/memory type cgroup (rw,nosuid,nodev,noexec,relatime,memory)
cgroup on /sys/fs/cgroup/hugetlb type cgroup (rw,nosuid,nodev,noexec,relatime,hugetlb)
cgroup on /sys/fs/cgroup/net_cls,net_prio type cgroup (rw,nosuid,nodev,noexec,relatime,net_cls,net_prio)
cgroup on /sys/fs/cgroup/blkio type cgroup (rw,nosuid,nodev,noexec,relatime,blkio)
cgroup on /sys/fs/cgroup/devices type cgroup (rw,nosuid,nodev,noexec,relatime,devices)
configfs on /sys/kernel/config type configfs (rw,relatime)
/dev/mapper/fedora-root on / type ext4 (rw,relatime,data=ordered)
systemd-1 on /proc/sys/fs/binfmt_misc type autofs (rw,relatime,fd=39,pgrp=1,timeout=0,minproto=5,maxproto=5,direct,pipe_ino=14168)
hugetlbfs on /dev/hugepages type hugetlbfs (rw,relatime)
mqueue on /dev/mqueue type mqueue (rw,relatime)
debugfs on /sys/kernel/debug type debugfs (rw,relatime)
binfmt_misc on /proc/sys/fs/binfmt_misc type binfmt_misc (rw,relatime)
tmpfs on /tmp type tmpfs (rw,nosuid,nodev)
fusectl on /sys/fs/fuse/connections type fusectl (rw,relatime)
/dev/sda1 on /boot type ext4 (rw,relatime,data=ordered)
/dev/sdb2 on /mnt/Data type fuseblk (rw,relatime,user_id=0,group_id=0,allow_other,blksize=4096)
/dev/mapper/fedora-home on /home type ext4 (rw,relatime,data=ordered)
sunrpc on /var/lib/nfs/rpc_pipefs type rpc_pipefs (rw,relatime)
tmpfs on /run/user/42 type tmpfs (rw,nosuid,nodev,relatime,size=1591320k,mode=700,uid=42,gid=42)
tmpfs on /run/user/1000 type tmpfs (rw,nosuid,nodev,relatime,size=1591320k,mode=700,uid=1000,gid=1000)
gvfsd-fuse on /run/user/1000/gvfs type fuse.gvfsd-fuse (rw,nosuid,nodev,relatime,user_id=1000,group_id=1000)
12

I'm going to start with a disclaimer. I haven't used LVM for some time so I write this to my best recollection. It is your data, and your computer. Do research, validate the steps. I offer no guarantees, this is provided "as-is".

Ok, this aside: this is what I think is important for you:

  • you are using "classic" pc bios MBR booting
  • you have /boot on /dev/sda1, this holds the files needed for your computer to boot linux
  • you are using LVM for the root filesystem and /home, with /dev/sda2 as the partition LVM uses to store the data

Migration is technically not that difficult, but you need to understand what you are doing (MBR booting is not very forgiving) and it does require the terminal and root rights. Said this: you don't need to touch your HDD until the actual LVM migration starts, so that will be a nice fallback scenario until then.

I forgot to ask if you have swap on your computer. If you have it has to a an LVM volume as well, so these steps will still work. You can check this using "cat /proc/swaps".

Step 1: boot your system from SSD

  • connect the SSD to your computer, and boot it
  • determine the SSD device name (e.g. /dev/sdh, replace with the actual name where needed)

Step 2: copy /boot from HDD to SSD using gparted

  • open gparted
  • select /dev/sda
  • umount /boot (/dev/sda1)
  • copy sda1 to sdh
  • give sdh1 a new UUID
  • give sdh1 a new filesystem label
  • set the boot flag for sdh1

Step 3: prepare fstab and remount /boot

  • check "ls -l /dev/disk/by-uuid" and "ls -l /dev/disk/by-label" for the UUID and Label of sdh1
  • open /etc/fstab for editing: you will need to change the relevant entry for /boot: either UUID=yournewuuidseenabovefor sdh1 or LABEL=thelabelyougavetosdh1
  • when done, run "mount -a" followed by "mount"
  • if this succeeded, you will see /dev/sdh1 is now mounted on /boot, sda1 should not be mounted at all

Step 4: prepare grub and reboot from SSD

  • run "update-grub" to make new configuration files in /boot that take into account your new configuration
  • run "grub-install /dev/sdh", which will make the SSD bootable
  • power off the pc, and swap HDD and SSD
  • reboot the computer
  • if all went well, the computer now boots from SSD, and it will have /boot on SSD
  • if it does not work, you can reseat the HDD

BEWARE: when you reboot, DEVICE NAMES CHANGE. sda is now the SSD !!! Determine the new device name for the HDD before continuing.

Your HDD is 500GB, your SSD is smaller. But that's not a big deal, since you are only using 14G on fedora-root, and 2,2GB on fedora-home. You can shrink fedora-root, but it's not a must. You must however, shrink fedora-home. I only have experience doing this in 2 steps. First you shrink the filesystem itself, then the volume that holds it. I usually keep the volume slightly bigger, and grow the filesystem when I'm done to fill it completely.

Step 5: shrink filesystems to fit onto the new SSD

  • use "resize2fs" to shrink fedora-home (for example to 8GB)
  • use "lvresize" to shrink fedora-home (BE VERY VERY CAREFUL WHEN DOING THIS, MAKE SURE YOU UNDERSTAND THE SYNTAX)

If you choose to do so, you can shrink fedora-root repeating this step.

Step 6: Prepare the SSD for LVM

  • run "vgdisplay" to see how much data is in use on your volume group
  • open gparted
  • create a new LVM partition on the SSD to add to your LVM group. It has to be large enough to hold all data as shown by vgdisplay. You can use all available space as well, or you just set it to something else (e.g. 128GB) for now, as you don't need the full SSD space at this moment

Step 7: Add the SSD to the volume group and migrate the data to it

Step 8: Verify and remove the HDD

  • run "vgdisplay": it should have the size of the new SSD partition
  • run "pvdisplay": it should only show the SSD partition
  • run "mount": there should be no active mounts using partitions on the HDD
  • Power off the machine. Remove HDD. Reboot.

Step 9 (optional): finalize LVM

  • if you want, you can give fedora-home a final size using lvresize BUT DON'T SHRINK IT UNLESS YOU RUN RESIZE2FS FIRST
  • run "resize2fs" and make it occupy all available space in the volume

So if all went well you now have a system running 100% on SSD. And neglecting a few reboots, you migrated everything online. That's the beauty of Linux.

Good luck!

2 Likes
13

Wow, what an awesome guide!
Thank you for the effort. I will try it next weekend and will report back.

P.S.
Would this procedure result in slower performance as opposed to a fresh install?

1 Like
14

One last thing: if you partition the SSD GPT, you need a bios grub partition. Stick with MBR if that's what you know.

I see no reason for it to be slower than a fresh install, unless Fedora does some magic detecting SSDs during installation. Even then, I think your workflow would need to be very specific to actually notice the difference.

You could experiment with schedulers or the blk mq driver. I don't know if that's a thing on Fedora.

Any takers?