Transfering an OS from HD to SSD

Micronaut · 2025-06-30 00:08:26

When you use one of those 'whole partition' transfer utilities to copy a system from an old HD to an SSD, does the OS notice the change in hardware? I seem to recall there are differences in how an OS should behave on one vs the other, but I don't know if that is something fixed at install time, or if it should be manually changed, or if it's automatically recognized.

Eeqmcsq · 2025-06-30 00:33:26

I don't have any experience with "partition transfer utilities", but I have done these at one time or another:

- Whole disk cloning. Something like "dd if=/dev/sdx of=/dev/sdy".
- Copy the OS files from one partition to another. I think it was something like "cp -ax /path/to/old_drive_partition/* /path/to/new_drive_partition". This required either changing the new partition's UUID to match the old one, or modifying /etc/fstab to match the new partition UUID.
- Copy the OS files from a single disk to a RAID array. A RAID array is multiple storage drives working together to behave like a single giant storage drive. This required modifying some files so that the RAID array started first on boot, then it could be mounted to the file system.

In all cases, Linux didn't care about the change in the storage drive. I think all Linux cares about is finding the file system's UUID, and successfully mounting it based on the file system type (example: ext4).

One reason I can think of why the OS might behave differently is if an SSD loaded files so quickly during boot, it exposes some race condition, as some apps have dependencies that haven't been fully initialized yet. A a slower HDD would hide these issues because the apps are loaded more slowly, giving the dependencies more time to initialize properly.

The only time I can remember seeing a problem with cloning hard drives is on my Win7 work laptop. That's because one of the software licensing apps used the storage drive name or whatever to generate its license key. When I replaced the laptop HDD with a cloned SSD, the license app said my license was no longer valid. I just requested and installed a new license, and that was all.

Micronaut · 2025-06-30 02:29:32

Well, my first thought was logging, which is supposed to be different on Windows when using an SSD compared to an HD. There is supposed to be much less, to reduce the wear on SSDs. Logging of everything has been so automatic in *nix for so long I wondered if there was any concession to hardware wear. And then there is the automatic disk optimization in Windows, but Linux doesn't do that at all. There may be other operational differences, though, so I was just wondering.

Eeqmcsq · 2025-06-30 05:51:25

I don't know anything about the logging system. But your post reminded me of back in the early 2010s when SSDs were getting cheap enough for not-so-rich computer geeks to buy. I remember there were Linux tweaks for reducing unnecessary disk writes by specifying "relatime" or "noatime" or something like that to reduce or stop updating a file's "access time" every time it's read. Back then, those tweaks had to be done manually.

If I had to speculate about today, I would suspect you'd still have to do those tweaks manually. My reasoning is that whatever the logging system an app or Linux is using would have no idea what type of storage device the log files are being written to. It could be an HDD, SSD, a RAID array that's a MIX of HDD+SSD (weird, but possible), a RAM disk, even a network shared folder on another PC. Since there's no way to know (or at least, no EASY way to know), I conclude that it's up to the sys admin to make those disk optimization tweaks manually.

Of course, a real sys admin can tell us for sure.

rolfie · 2025-06-30 06:48:24

Don't worry about wear on a modern SSD. They have such a large TWB that normal use on a workstation does not kill or even limit the lifetime. More than a decade ago when SSDs were new I used to put /var and /tmp onto a HDD. I have stopped that along time ago.

Last edited by rolfie (2025-07-01 08:02:32)

stargate-sg1-cheyenne-mtn · 2025-07-01 07:42:07

regardless of what you do, when you do it, and/or how you do it.

do a fresh and complete backup and if it is at all important, have a backup backup.

it isn't a question of IF, it is a question of WHEN you will have some kind of problem(failure/fire/flood/theft/tornado/etc).

as always, ymmv.

greenjeans · 2025-07-01 14:48:38

^^Good advice, I regularly backup my stuff using Refracta Snapshot, that way I have a complete simple turnkey way of re-installing everything.

yurimodin · 2025-07-01 20:12:13

Just be sure your /etc/fstab is listed by UUID and not drive path. I would also turn off swap for the move.

RedGreen925 · Yesterday 00:43:31

When you use one of those 'whole partition' transfer utilities to copy a system from an old HD to an SSD, does the OS notice the change in hardware?

I do not use them utilities. Here is my method on booted live usb using rsync. First you create the new partitions on the drive to be copied to. below is example of the cloning operationing on one of my machines for EFI booting I have no clue on MBR drive.

et to a second cloning to the Samsung NVMe 128GB external enclosure drive the
extra one I have a duplicate.

root@9600k:~# gdisk /dev/sdb
GPT fdisk (gdisk) version 1.0.10

Partition table scan:
  MBR: protective
  BSD: not present
  APM: not present
  GPT: present

Found valid GPT with protective MBR; using GPT.

Command (? for help): o
This option deletes all partitions and creates a new protective MBR.
Proceed? (Y/N): y

Command (? for help): n
Partition number (1-128, default 1):
First sector (34-250069646, default = 2048) or {+-}size{KMGTP}:
Last sector (2048-250069646, default = 250068991) or {+-}size{KMGTP}: 500MB
Current type is 8300 (Linux filesystem)
Hex code or GUID (L to show codes, Enter = 8300): ef00
Changed type of partition to 'EFI system partition'

Command (? for help): n
Partition number (2-128, default 2):
First sector (34-250069646, default = 1026048) or {+-}size{KMGTP}:
Last sector (1026048-250069646, default = 250068991) or {+-}size{KMGTP}:
Current type is 8300 (Linux filesystem)
Hex code or GUID (L to show codes, Enter = 8300):
Changed type of partition to 'Linux filesystem'

Command (? for help): w

Final checks complete. About to write GPT data. THIS WILL OVERWRITE EXISTING
PARTITIONS!!

Do you want to proceed? (Y/N): y
OK; writing new GUID partition table (GPT) to /dev/sdb.
The operation has completed successfully.

The formatting of the drive I go first partitiion EFI system which needs to be fat32, ext4 for second and third partition, the /root and /home partitions.

root@9600k:~# mkfs.vfat -F 32 /dev/sdb1

root@9600k:~# mkfs.vfat -F 32 /dev/sdb1
root@9600k:~# fatlabel /dev/sdb1 DRIVEEFI
root@9600k:~# mkfs.ext4 -m 0 -L DRIVEROOT /dev/sdb2
root@9600k:~# mkfs.ext4 -m 0 -L DRIVEHOME /dev/sdb3

The -m 0 reserves not space on the partitions the default without is 5% and the -L gives you partition label.

Now the actual copying/cloning from booted usb. Open terminal from desktop environment use these commands.

sudo mkdir /tmp/oldroot
sudo mkdir /tmp/newroot
sudo mkdir /tmp/oldhome
sudo mkdir /tmp/newhome
sudo mkdir /tmp/oldefi
sudo mkdir /tmp/newefi

Then mount the partitions using sudo fdisk -l to determine the actual drive letter number of the partition to be cloned.

sudo mount /dev/sda1 /tmp/oldefi
sudo mount /dev/sdb1 /tmp/newefi
sudo mount /dev/sda2 /tmp/oldroot
sudo mount /dev/sdb2 /tmp/newroot
sudo mount /dev/sda3 /tmp/oldhome
sudo mount /dev/sdb3 /tmp/newhome

Now clone.

sudo scp -r  /tmp/oldefi/* /tmp/newefi/
sudo rsync -avP /tmp/oldroot/* /tmp/newroot/
sudo rsync -avP /tmp/oldhome/* /tmp/newhome/

Once the cloning is done you need to edit some files for the new UUIDs on the cloned to drive so it will boot. To get the required information use the sudo blkid command an example of its output below.

Mushkin 480GB SSD
/dev/sda1: LABEL_FATBOOT="MUSHKINEFI" LABEL="MUSHKINEFI" UUID="6465-9332" BLOCK_SIZE="512" TYPE="vfat" PARTLABEL="EFI system partition" PARTUUID="d2a1b57d-794c-4ed8-9c76-1c6d12108f6b"
/dev/sda2: LABEL="MushkinRoot" UUID="03fec226-03dd-40de-8728-1bf7ae86239d" BLOCK_SIZE="4096" TYPE="ext4" PARTLABEL="Linux filesystem" PARTUUID="4e0572c1-cac9-4319-bd7f-90c9806d0a26"
/dev/sda3: LABEL="MushkinHome" UUID="6db5ea58-64bd-45db-aa1c-004c6b782f04" BLOCK_SIZE="4096" TYPE="ext4" PARTLABEL="Linux filesystem" PARTUUID="319d59c2-0efe-4d3b-a37e-8c1e517ee813"

There you can see where to get them from. Now three files need to be edited on a Devuan EFI system. The first.

root@9600k:~# cat /boot/efi/EFI/debian/grub.cfg 
search.fs_uuid 766dcfc3-a1e4-495f-86e2-570205723fef root 
set prefix=($root)'/boot/grub'
configfile $prefix/grub.cfg

On the cloned drive this file would be /tmp/newefi/EFI/debian/grub.cfg you edit with your favourite editor to change to new UUID for the new / from the blkid command earlier. The second is the /tmp/newroot/etc/fstab where you edit all three the old EFI, / and /home to the new UUIDs for them. Lastly

Here I show example from script I have that does all of this part on live running system.

# My Mushkin 8500t intenal
sed -i "s/6977106c-69db-4634-b33f-9a03da4b46ed/03fec226-03dd-40de-8728-1bf7ae86239d/g" /root/bin/boot_mushkin_8500t_grub.cfg

So the command to do it on cloned drive would be.

sed -i "s/oldrootUUID/newrootUUID/g" /tmp/newroot/boot/grub/grub.cfg

Then you can reboot and when the new drive is selected from the one time EFI boot menu it should just fire up. Now I look back this shows two partition drive in the gdisk step just continue on with next partition if desired. I have done this hundreds of times and it works every time unless I forget to edit a UUID when manually, my scripts run it flawless to back and restore to my various machines and drives. Good luck if you use this method it should just work unless I have stupid typo I missed when checking it over..

The officially official Devuan Forum!

#1 2025-06-30 00:08:26

Transfering an OS from HD to SSD

#2 2025-06-30 00:33:26

Re: Transfering an OS from HD to SSD

#3 2025-06-30 02:29:32

Re: Transfering an OS from HD to SSD

#4 2025-06-30 05:51:25

Re: Transfering an OS from HD to SSD

#5 2025-06-30 06:48:24

Re: Transfering an OS from HD to SSD

#6 2025-07-01 07:42:07

Re: Transfering an OS from HD to SSD

#7 2025-07-01 14:48:38

Re: Transfering an OS from HD to SSD

#8 2025-07-01 20:12:13

Re: Transfering an OS from HD to SSD

#9 Yesterday 00:43:31

Re: Transfering an OS from HD to SSD

Board footer