Skip to content

Instantly share code, notes, and snippets.

@gerarldlee
Last active March 19, 2024 21:45
Show Gist options
  • Save gerarldlee/7c888d8da9389d255dd9a08da1b0ab04 to your computer and use it in GitHub Desktop.
Save gerarldlee/7c888d8da9389d255dd9a08da1b0ab04 to your computer and use it in GitHub Desktop.
Story:
My hdd is 1tb but i bought a 256gb ssd. I partitioned it accordingly:
140gb windows
50gb ubuntu
50gb fedora
1gb linux boot
250mb efi system
I want to move operating system files to ssd to make my development env faster, and my documents to hdd.
Move Windows 10 onto new SSD:
this is better than cloning, so as to prevent alignment problems, time-consuming backup operations, and time consuming uninstallation of apps since you are moving into a smaller ssd.
- operating system, applications
hdd:
- documents, pictures, videos, music, etc
step 1: download windows 10 media creator from ms website
step 2: create win 10 install image by dvd or usb or hdd
this will copy to iso, your digital license, etc, but not your drivers if you are installing from a win 10 branded laptop
setp 3: install from the media you created, specifying the new SSD partition created for windows
Moving Ubuntu onto new SSD:
- operating system, /boot i.e. initrd.img, vmlinuz
- /bin, lib, usr, var, etc
- applications that i use i.e. firefox, vbox, images
hdd:
- swap
- documents, images, encrypted folders
rsync - fast method of file transfering with folder structure, ownerships and permissions. it will also continue where you left, had your transfer been interrupted.
options: -a archive
-P -partial (continue where left off) and -progress (show progress)
step 0: login as root
step 1: mount ssd, format to ext4
find the ssd device name
dmesg | grep sd[a-z]
check if ATA trim is enabled in the ssd
sudo hdparm -I /dev/sdc | grep TRIM
* Data Set Management TRIM supported (limit 16 blocks)
* Deterministic read ZEROs after TRIM
format the ssd, use ext4
sudo gparted /dev/sdX
mount the ssd
sudo mkdir /mnt/ssd
sudo mount /dev/sdc1 /mnt/ssd
step 2: use rsync to copy files to the ssd
sudo rsync --exclude="mnt" --exclude="lost+found" --exclude="sys" --exclude="proc" --exclude="cdrom" --exclude="media" -aP / /mnt/ssd/
-or- to ignore the home folder:
sudo rsync --exclude="home" --exclude="mnt" --exclude="lost+found" --exclude="sys" --exclude="proc" --exclude="cdrom" --exclude="media" -aP / /mnt/ssd/
-and- if you just want to exclude specific folders in the home directory, type this after the command above:
sudo rsync --exclude="Pictures" --exclude="Downloads" --exclude="Documents" --exclude=".PlayOnLinux" --exclude=".wine" --exclude="Virtual*" -aP /home/user/ /mnt/ssd/home/user
mkdir /mnt/ssd/{mnt,proc,sys}
change the /mnt/ssd/etc/fstab to set uuid to the ssd partition
find the uuid of the partition of ssd:
sudo blkid /dev/sdX1
sudo blkid /dev/sdX2
fstab should look like this (you should see the "discard" option, means TRIM is enabled):
# file system mount point type options dump pass
proc /proc proc nodev,noexec,nosuid 0 0
UUID=5d8[...]abe / ext4 discard,noatime,nodiratime,errors=remount-ro 0 1
UUID=a01[...]4cc none swap sw
sudo mount -o bind /dev /mnt/ssd/dev
sudo mount -o bind /sys /mnt/ssd/sys
sudo mount -t proc /proc /mnt/ssd/proc
sudo cp /proc/mounts /mnt/ssd/etc/mtab
sudo chroot /mnt/ssd/ /bin/bash
mount /dev/sda2 # My new EFI system in SSD
step 4: reinstall grub
grub-install /dev/sdc
grub-install --recheck /dev/sdc # only in case of errors in the step before
# on Fedora, do this instead of grub-install
dnf install grub2-efi shim
-or-
dnf reinstall grub2-efi shim
update-grub # grub2-mkconfig -o /boot/efi/EFI/fedora/grub.cfg on Fedora with EFI
# else, grub2-mkconfig -o /boot/grub2/grub.cfg
reboot
Moving Fedora to SSD
see the layout
lsblk
fdisk -l
Copied from: https://forum.level1techs.com/t/migrating-fedora-to-an-ssd/116502/11
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
see http://www.tldp.org/HOWTO/LVM-HOWTO/removeadisk.html, section 13.5.2
you'll need to run pvcreate and vgextend using the new SSD partition
the pvmove command's first argument is the HDD partition, the second the SSD. Use "pvdisplay" to verify.
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.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment