Below is my research with description of trying to copy Ubuntu 20.04
with enabled hibernation on separate swap partition on Thinkpad T420
to new SSD drive based on answers in the current question. Eventually I had success but encountered many problems (nuances) while trying this recommendations.
Below SSD and HDD will be considered as interchangeable terms.
Firstly I tried the most simpler and straightforward way (as I thought) which is described in the Pilot6's answer - copying files from source partition to destination partition
For copying I used rsync
command.
The problem was that my new SSD drive did not boot Ubuntu without old SSD drive (both SSD drives must be connected). The only recommendations about this situation I found was to install or update or recover Grub
configuration. But this was not helpful.
Setting UUID of new root to grub config and updating grub as recommended here:
/etc/default/grub
GRUB_DEVICE_UUID=40dbf2e4-e0c5-4f75-83bc-3176dc06d164
also did not work.
The problem was not in Grub
but in UUID of swap partition which was pointing to old drive.
If you do this for Ubuntu with enabled hibernation on separate swap partition you also have to update UUID of swap partition in /etc/uswsusp.conf
and run command for updating initramfs
to apply the change:
update-initramfs -u -k all
Otherwise at boot time there will be black screen with no diagnostic message.
Happily by accident one time I left this black screen on about 5 minutes to hang. Then the following diagnostic message appeared:
resume: Could not stat the resume device file '/dev/disk/by-uuid/8e8927aa-eca7-43d6-b7cd-66cfda70a242
Please type in the full path name to try again or press ENTER to boot the system:
stat
, not start
- probably typo in the message.
Related question: Could not stat the resume device file
Later I found out that '8e8927aa-eca7-43d6-b7cd-66cfda70a242' - is UUID of my swap partition on old hdd drive.
I was able to boot in new system by specifying root location on new drive by simple partition name, not UUID: "/dev/sdx1" and hitting Enter
.
Interestingly that I specify new root location, not new swap location. It seems that Ubuntu somehow figured things out.
I run command for updating initramfs
after booting to new copy of Ubuntu.
In the command log there was the following:
update-initramfs: Generating /boot/initrd.img-5.13.0-27-generic
I: The initramfs will attempt to resume from /dev/sda4
I: (UUID=0253f7b6-8e26-4d19-b262-6d8923911752)
I: Set the RESUME variable to override this.
which means that swap UUID was successfully changed.
Also I tried to run update for initramfs
from chroot
(from the old copy of Ubuntu or Live version of Ubuntu):
sudo mount /dev/sdx1 /mnt
sudo mount /dev/sdx5 /mnt/boot/efi
for i in /sys /proc /run /dev /dev/pts; do sudo mount --bind "$i" "/mnt$i"; done
sudo chroot /mnt
initramfs
command was executed from chroot
but there was no message about updating resume UUID
as in previous log - do not know if it works properly.
At that moment I already updated Grub
from chroot
by the following commands:
sudo grub-install /dev/sdx
sudo update-grub
After that I was able to boot from new SSD drive without old SSD drive.
Under this answer in comments there is comment from andrybak:
Currently trying to use this answer to migrate my install from old HDD to new HDD. I'm failing at the step "Install grub to the new drive". Grub keeps pointing/finding the install on the old HDD and I don't know how to convince Grub to look at the new HDD.
This may be the similar problem as I described above.
Ubuntu copied in such a way is loading normally but I noticed some problem with security system:
When I mount other drive's partitions by gnome-disks
I cannot open them in nautilus
(clicking their links in gnome-disks
will do nothing). This is due to error: Permission denied
.
The solution was the following:
- I normally installed new Ubuntu (minimum version without office and updates) on new SSD drive.
- Copied files of old Ubuntu to partition with new Ubuntu installation.
In this case there was no problem with
Permission denied
.
( Update. Later I found out that problem with Permission denied
was due to bad files copying. Command rsync -a
does not copy all properties of files and cannot be used for copying system files. Need to use command like rsync -axHAWXS --numeric-ids --info=progress2
in case of rsync
but better to use cp -a
because cp
works faster than rsync
for local copying - Copy entire file system hierarchy from one drive to another )
By such approach I copied my Ubuntu from MBR disk to new GPT disk. (Before installing the minimum version of Ubuntu I formatted new SSD as GPT.)
Related questions:
Copying files under working source OS is not working:
I tried copying files under current working system (not Live version) as discussed in comments under the Pilot6's answer by the following commands:
sudo rsync -a / /mnt/dest/ --exclude sys --exclude proc --exclude dev --exclude tmp --exclude media --exclude mnt --exclude run
sudo mkdir sys proc dev tmp media mnt run
sudo mkdir /var/tmp
And updating Grub
from chroot
.
In this case new copy of Ubuntu booted but the resolution of screen was lower. Probably some monitor-specific drivers was not copied or copied with errors due to currently working system.
Also tested ljrk's answer - using dd comand
sudo dd if=/dev/sda of=/dev/sdb bs=64K conv=noerror,sync status=progress
127945670656 bytes (128 GB, 119 GiB) copied, 818 s, 156 MB/s
dd: error writing '/dev/sdb': No space left on device
1953669+1 records in
1953669+0 records out
128035676160 bytes (128 GB, 119 GiB) copied, 829,897 s, 154 MB/s
By using USB SSD with installed Ubuntu and dd
command I copied bit by bit source SSD to the target SSD. In result target SSD had the same partitions, same UUIDs, same PARTUUID.
Below is about making Live USB SSD and changing UUIDs, PARTUUIDs to new ones.
For more high speed it is better to insert source and destination SSD drives inside notebook (the second SSD drive by optibay / caddy adapter), and will run dd
command from Bootable USB stick or USB SSD / USB HDD.
I found two programs for Ubuntu to make bootable USB stick or USB HDD. I wanted to make USB HDD (SSD) and this was quite challenging.
WoeUSB
program also can be used for creating bootable HDD, not only USB stick but this is not specified in the program description.
The command below creates bootable HDD from Windows 10 Pro image (by UI it is not possible to specify USB Hard drive, only USB stick):
sudo woeusb --device "/home/username/Downloads/Win10_21H2_Russian_x64.iso" /dev/sdx --target-filesystem ntfs
How to create a bootable Windows 10 USB on Linux with the new WoeUSB
Also tried UNetbootin
tool (for Ubuntu) but it cannot use NTFS
, only FAT32 - this is not appropriate in case image of Win 10 pro since it has file with about 4,5 Gb in size (FAT32 does not support files with the size more than 4 Gb). Ubuntu 20.04 installation image must be able to be installed on FAT32 partition (the most biggest file in ubuntu-20.04.3-desktop-amd64.iso
image is casper/filesystem.squashfs
with the size of 2,1Gb
). I used already installed Ubuntu connected via USB SSD.
The following command writes image to USB SSD with FAT32 FS:
sudo unetbootin installtype=HDD targetdrive=/media/username/winds/ method=diskimage isofile="/home/username/Downloads/Win10_21H2_Russian_x64.iso"
By UI it is not possible to specify target as USB Hard drive, only as USB stick. In targetdrive
parameter path must be specified to the mounted USB drive. And at the end there must be slash sign /
otherwise command will fail with error:
unetbootin /dev/sdx1sources is out of space
Or maybe not fail but will write files not to the destination drive.
dd
is useful if you want just move your system to another drive - even Dropbox works on target SSD without requiring re-linking. Old drive can be formatted. And you are done.
But if you want both HDD disks to work in the same notebook UUIDs and PARTUUIDs of the new HDD must be changed to unique. Below information about this.
How to Change UUID of Partition in Linux Filesystem
blkid | grep sdb1
/dev/sdb1: UUID="0c0f5bf5-4e0f-4f4e-85df-896c88e14ba0"
umount /dev/sdb1
sudo e2fsck -f /dev/sdb1 #required by tune2fs before changing UUID
sudo tune2fs -U 0c0f5bf5-4e0f-4f4e-85df-896c88e14ba5 /dev/sdb1
sudo blkid | grep sdb1
/dev/sdb1: UUID="0c0f5bf5-4e0f-4f4e-85df-896c88e14ba5"
Source: How to Change UUID of Partition in Linux Filesystem
How to change PARTUUID?
sudo blkid | grep sdb1
/dev/sdb1: PARTUUID="a41c501b-1800-41ed-968b-b7bbfe4ef5ef"
sudo gdisk /dev/sdb
x # enter x to change to experts menu
c # enter c to change PARTUUID
1 # enter the number of the partition you want to change
a41c501b-1800-41ed-968b-b7bbfe4ef6ef
m # enter m to go back to main menu
w # enter w to write the change to disk
q # enter q to exit gdisk
OK; writing new GUID partition table (GPT) to /dev/sdb.
Warning: The kernel is still using the old partition table.
The new table will be used at the next reboot or after you
run partprobe(8) or kpartx(8)
The operation has completed successfully.
sudo blkid | grep sdb1
/dev/sdb1: PARTUUID="a41c501b-1800-41ed-968b-b7bbfe4ef6ef"
Source: How to change PARTUUID?
Severus Tux'answer - about using Clonezella
This is also good way to go but will take more time in preparation and set up in comparison to using dd
command - Clonezella Live USB stick must be prepared, booted, and many menus of Clonezella UI must be went through before starting the process of cloning or saving an image of the system.
Clonezella works in the similar way as dd
- UUIDs, PARTUUIDs will be copied to target SSD drive also.
Discussion about UUIDs, PARTUUIDs on Clonezilla page:
/home
instead of the entire system. It should be an easier change (just move everything over and add a single line to /etcs/fstab), and most large files are likely to go into your home directory (and so onto the larger disk).