7
August
2022
Setting up booting Linux from another drive after cloning an HDD-SSD
2:05

Setting up booting Linux from another drive after cloning an HDD-SSD

7 August 2022 2:05

After cloning the disk, you need to configure the OS so that it boots from the new, faster SSD disk.

Background

An SSD drive from WEIJINTO, purchased on AliExpress for a home computer, arrived.
WEIJINTO SSD 120GB, 240GB, 128GB, 256GB, 512GB, 480GB, 960GB, 360GB, 2.5 inch at WEIJINTO Store
For a volume of 120 GB I paid 800 rubles (about $11). Despite the price, this company produces high quality data storage devices. So, the disk of this company has been working for more than 1 year, under harsh conditions, without any comments.

Physical connection of an SSD drive

In the system unit, both drives are connected to the motherboard using SATA cables:

  • The first HDD contains all the partitions of the old disk.
  • The second SSD drive will only contain the primary partition (mounted at "/").

Disk cloning

First of all, you need to make sure that the disk is present in the system, even if it is not yet partitioned.

sudo apt-get install gnome-disk-utility

Now launch the "Disks" utility through the "Start" menu - "Accessories" - "Disks"
or run the command (does the same thing):

gnome-disks

First, let's find out the layout type of the source disk (old HDD) - I have a GPT layout type.
I decided to partition the new disk also with the GPT type.
gpt

In the left part of the window, select the SSD disk, we see that it is working, but is not yet partitioned (and does not contain information).
disks
Close the graphical utility "Disks", it will not be needed yet.

Disk partitioning

Launch fdisk from the command line and execute the commands

sudo fdisk /dev/sdb
g
n
p
w

The g command creates a GPT partition, n creates a new partition of the "Linux" type, p - displays partitions (check), w - writes and exits.

Cloning the main partition from HDD to SSD

Let's find out on which partition the "root" of the file (/) is located.

 lsblk

NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT

sda 8:0 0 465,8G 0 disk

├─sda1 8:1 0 300M 0 part /boot/efi

├─sda2 8:2 0 73,9G 0 part /

├─sda3 8:3 0 7,8G 0 part [SWAP]

├─sda4 8:4 0 90,8G 0 part /var

└─sda5 8:5 0 293G 0 part /home

It can be seen that the “root” corresponds to sda2(others may have sda1).

Second drive, destination drive sdb is also visible, and the volume we created is visible in it sdb1

sdb 8:16 0 111,8G 0 disk

└─sdb1 8:17 0 111,8G 0 part

The destination disk must be larger than the source partition (111G > 73.9G).

I'm starting to clone from partition to partition between the sda ​​and sdb disks.
Source disk sda2 is copied to destination disk sdb1, buffer size 2 MB:

sudo dd if=/dev/sda2 of=/dev/sdb1 bs=2M

Cloning took me about 30 minutes.

Assigning a new UUID to an SSD disk partition

To prevent duplicates, as well as to make it easier to distinguish between disks, I decided to change the UUID of the volume on the destination disk, i.e. write down a new uuid,

generate uuid;

uuidgen

The resulting value was copied to the clipboard and substituted as a command parameter,
thereby replacing the uuid of the /dev/sdb1 partition with a new uuid:

sudo tune2fs /dev/sdb1 -U новый_uuid

The command takes 5 seconds to complete.

Checking the file system of the new disk after cloning

We are convinced, that the new SSD disk sdb, more precisely the volume "/dev/sdb1" not mounted:

sudo umount /dev/sdb1

Run a file system check:

sudo e2fsck -f /dev/sdb1

The main thing: ensuring the operating system starts from the new partition

We know the uuid identifier of the new boot and main partition on the SSD, but you can find it out in another way (if you forgot):

ls -l /dev/disk/by-uuid

or

 lsblk -f

There are 2 simple steps left to do:

1) Add a command GRUB_DEVICE_UUID(to indicate the drive from which the next boot will be performed),
to the configuration file /etc/default/grub,

sudo nano /etc/default/grub

The /etc/default/grub file is still located on the old partition /dev/sda2, but at the next boot, the GRUB2 boot loader will select the volume with the UUID that we specify to it.

The configuration file line /etc/default/grub is as follows (enter without asterisks):

GRUB_DEVICE_UUID=**вставьте здесь uuid нового загрузочного раздела (том sdb1 на SSD диске)**

Ctrl+O, Ctrl+X

We update the GRUB configuration:

 sudo update-grub

2) In the new section, edit the FSTAB file

To do this, in the "Disks" utility, mount a new SSD disk with 1 partition (button with a triangle ▶).

In Explorer, look for the path /media/user/uuid and open the file in a text editor /etc/fstab:

Edit "/media/user/long_uuid/etc/fstab".

We replace the old uuid for /dev/sda2 with a new one, which is known for /dev/sdb1
fstab
Save the fstab file and reboot the PC.

Now grub will use the new uuid to boot, and fstab from the new disk will also use the uuid of the new SSD disk.

Check

In addition to reducing the loading time of the operating system (in my case, from 1 minute 3 seconds, the time decreased to 34 seconds), current connections can be viewed in the same utility "Discs". Old partition No. 2 on the HDD disk not mounted, and the new one on the SSD is mounted as "root volume".

tom

Note

The user partition /home and the system settings partition /var on my old disk were separated into separate volumes. They remained the same separate sections in the same places. PC acceleration will occur in this case when loading the OS and launching programs. In this example, the user profile is saved on the old HDD. If the source disk was partitioned differently, and the entire disk was allocated to the “root” (/), including /home, then you need to buy an SSD of a larger capacity than the original HDD disk (for example, 1 TB).


Links:
How to change UUID in the /boot/grub/grub.cfg
How to change disk partition UUID in Linux



Related publications