How I transferred the working Ubuntu MATE 14.04 system to a new SSD disk
Somehow, while working, I noticed that my personal laptop on the i5, with 8 gigabytes of RAM on Linux, is inferior to the service, less powerful, "horse."
It was decided to make a “knight's move”: instead of the old SATA HDD, a new SSD was purchased. Admins are essentially lazy creatures, and I was no exception. Remembering everything that was done anew, building up your working environment, did not want to say anything at all, and transferring the operating system was the least trouble-free option in my case. So let's get started.
In the laptop, through the adapter controller in the DVD-drive slot, a second new 60 GB SSD-drive was installed, defined in the system as / dev / sdb.
On the old 320 GB HDD / dev / sda disk there were three sections: / dev / sda1 (swap - previously disabled), / dev / sda2 (/ root partition), / dev / sda3 (/ home). The total volume of all data on all sections occupied about 50 GB.
')
Booted into LiveUSB mode, on Ubuntu MATE 14.04 with usb-stick. Gparted created the sdb1 partition on the SSD disk. Flags are not set. Enter privileged root mode:
Check if there is support for TRIM:
* Data Set Management TRIM supported (limit 1 block).
The listing output means that TRIM support is and is active.
Check the alignment of sections:
If 1 is aligned or 1 aligned, then everything is fine.
Create mount point directories:
We mount the necessary sections:
We transfer, synchronizing data from the root partition:
Where:
-q - reduce the level of details
-a - archive mode
-H - keep hard links
-E - save file executables
-A - save ACLs
-X - save extended attributes
-h - output numbers in an easily perceived format
Mount the partition with the user directory and also transfer data from it:
For greater safety from random errors, unmount the partitions of the original HDD disk:
Mount the file systems of the native OS to which the data was transferred:
Use the chroot operation to change the working root directory to the one into which we transfer data:
Back up one of the configuration files with information about file systems:
Add the current UUID of the sdb1 partition to fstab:
Editing fstab:
And we bring it to an approximate form:
# / was on / dev / sdb1 during installation
UUID = c45939b4-3a58-4873-aa6e-247746hgftb5 / ext4 errors = remount-ro 0 1
where UUID = sdb1 value
Update the Linux bootloader configuration file:
Check whether the UUID values of the section are set correctly in the grub.cfg configuration file:
where instead of “uuid sda2” substitute your uuid partition value. I still have the old values, therefore:
Exit the chroot:
Unmount the file systems:
In grub.cfg, we change all the old uuid values of the sda2 partition to the new uuid values of the sdb1 partition. It was easier for me to do this. You can do it your way.
We put the mysql server, in which there is the replace utility (any password, the same one, is not useful):
Change UUIDs:
where old_uuid and new_uuid, old and new values respectively.
Check if the values have changed in grub.cfg:
Re-mount file systems and chroot-name:
Install the bootloader on sdb itself:
Exit the chroot:
Unmount everything mounted:
Exit from root privileged mode:
Reboot to the new system. When rebooting into the BIOS, do not forget to select and install the boot from the new device.
It was decided to make a “knight's move”: instead of the old SATA HDD, a new SSD was purchased. Admins are essentially lazy creatures, and I was no exception. Remembering everything that was done anew, building up your working environment, did not want to say anything at all, and transferring the operating system was the least trouble-free option in my case. So let's get started.
In the laptop, through the adapter controller in the DVD-drive slot, a second new 60 GB SSD-drive was installed, defined in the system as / dev / sdb.
On the old 320 GB HDD / dev / sda disk there were three sections: / dev / sda1 (swap - previously disabled), / dev / sda2 (/ root partition), / dev / sda3 (/ home). The total volume of all data on all sections occupied about 50 GB.
')
Booted into LiveUSB mode, on Ubuntu MATE 14.04 with usb-stick. Gparted created the sdb1 partition on the SSD disk. Flags are not set. Enter privileged root mode:
sudo -i Check if there is support for TRIM:
hdparm -I /dev/sdb | grep -i trim * Data Set Management TRIM supported (limit 1 block).
The listing output means that TRIM support is and is active.
Check the alignment of sections:
parted /dev/sdb align-check opt 1 If 1 is aligned or 1 aligned, then everything is fine.
Create mount point directories:
mkdir /mnt/{sda2,sda3,sdb1} We mount the necessary sections:
mount /dev/sdb1 /mnt/sdb1 mount /dev/sda2 /mnt/sda2 We transfer, synchronizing data from the root partition:
rsync -qaHEAXh /mnt/sda2/* /mnt/sdb1 Where:
-q - reduce the level of details
-a - archive mode
-H - keep hard links
-E - save file executables
-A - save ACLs
-X - save extended attributes
-h - output numbers in an easily perceived format
Mount the partition with the user directory and also transfer data from it:
mount /dev/sda3 /mnt/sda3 rsync -qaHEAXh /mnt/sda3/* /mnt/sdb1/home For greater safety from random errors, unmount the partitions of the original HDD disk:
umount /mnt/sda2 umount /mnt/sda3 Mount the file systems of the native OS to which the data was transferred:
mount --bind /proc /mnt/sdb1/proc mount --bind /dev /mnt/sdb1/dev mount --bind /sys /mnt/sdb1/sys Use the chroot operation to change the working root directory to the one into which we transfer data:
chroot /mnt/sdb1 Back up one of the configuration files with information about file systems:
cp /etc/fstab{,.bak} Add the current UUID of the sdb1 partition to fstab:
ls -l /dev/disk/by-uuid |grep sdb >> /etc/fstab Editing fstab:
nano /etc/fstab And we bring it to an approximate form:
# / was on / dev / sdb1 during installation
UUID = c45939b4-3a58-4873-aa6e-247746hgftb5 / ext4 errors = remount-ro 0 1
where UUID = sdb1 value
Update the Linux bootloader configuration file:
update-grub Check whether the UUID values of the section are set correctly in the grub.cfg configuration file:
cat /boot/grub/grub.cfg | grep «uuid sda2» where instead of “uuid sda2” substitute your uuid partition value. I still have the old values, therefore:
Exit the chroot:
exit Unmount the file systems:
umount /mnt/sdb1/sys umount /mnt/sdb1/dev umount /mnt/sdb1/proc In grub.cfg, we change all the old uuid values of the sda2 partition to the new uuid values of the sdb1 partition. It was easier for me to do this. You can do it your way.
We put the mysql server, in which there is the replace utility (any password, the same one, is not useful):
apt-get install mysql-server-5.5 Change UUIDs:
replace 'old_uuid' 'new_uuid' -- /mnt/sdb1/boot/grub/grub.cfg where old_uuid and new_uuid, old and new values respectively.
Check if the values have changed in grub.cfg:
cat /mnt/sdb1/boot/grub/grub.cfg | grep «uuid sdb1» Re-mount file systems and chroot-name:
mount --bind /proc /mnt/sdb1/proc mount --bind /dev /mnt/sdb1/dev mount --bind /sys /mnt/sdb1/sys chroot /mnt/sdb1 Install the bootloader on sdb itself:
grub-install /dev/sdb Exit the chroot:
exit Unmount everything mounted:
umount /mnt/sdb1/sys umount /mnt/sdb1/dev umount /mnt/sdb1/proc umount /mnt/sdb1 Exit from root privileged mode:
exit Reboot to the new system. When rebooting into the BIOS, do not forget to select and install the boot from the new device.
Source: https://habr.com/ru/post/277517/
All Articles