I actually did this earlier today! My laptop that I did this on uses legacy MBR-based BIOS boot (ThinkPad X201 Tablet), but most of these steps should be the same between (u)EFI and 'legacy' BIOSes. I have done similar on an EFI-based macintosh in the past.
1. Give partitions on the new drive new UUID's so they can be distinguished.
To update the UUID's of the new disk, boot from the old disk and run (for an ext* type partition):
tune2fs -U `uuidgen` /dev/sdb1
…if /dev/sdb1
is your new disk's partiton-to-re-UUID and you're booted in /dev/sda
.
If it gives you an error, then it's probably going to ask you to run a filesystem check prior to renaming. Run the command tune2fs
tells you to, and then run tune2fs again.
For other filesystems, you will need to figure out how you are able to change the UUID. Here are two more common ones:
- btrfs uses
btrfstune -U `uuidgen` /dev/sdb1
.
- I think XFS uses
xfs_admin -U `uuidgen` /dev/sdb1
, but I am not
100% sure on that since I have never used XFS personally.
Repeat that for all the partitions on the new disk.
2. edit new drive's /etc/fstab
.
Mount the root partition of the new disk and edit /etc/fstab
to replace the old disk's UUID's with the new UUID's. You can check what your new UUID's are by running blkid
.
3. Boot to the new drive (with a temporary, stopgap solution) before continuing
At this point, for a temporary, one-time boot to the new drive, you can specify root=/dev/sdb1
(if /dev/sdb1
is your new disk's root partition) in the kernel parameters. In GRUB2, this is as easy as pressing 'e' on the linux boot entry and tacking it to the end of the line starting with linux
. If your entire linux install was on one partition (no separate home partition, etc.), then you can do this from the beginning (before changing UUID's).
4. Update the ramdisk with your new fstab for future boots to use the right drive.
Next, we need to actually update the booted ramdisk. For the next step, I highly recommend just removing the original disk, if possible. If you can do that, then upon updating grub you can easily avoid adding the old disk to the available entries in your new disk's boot menu.
In any case, as root, you should run (on debian and derivates; I believe the command is update-initrd
on some others):
update-initramfs -u
4.5 update GRUB menu entries (maybe not strictly necessary)
I am not sure if this is actually required, I am ashamed to admit. I did it because "it couldn't hurt," and it didn't on my laptop.
grub-install /dev/sdX
(where /dev/sdX is the drive you want the grub bootloader reinstalled on. Do not specify a partition, such as /dev/sdX1, etc. – only specify the device name).
This got my cloned disk booting without any issues on my first attempt. I've done this process more or less the same way in the past, when I last migrated to a larger drive.
You may have to change the boot priority of your disks in your BIOS/(U)EFI setup, too, to make it automatically use your disk if it's still giving you trouble.
/boot/efi
) – Philip Couling Mar 12 '19 at 12:15cat /etc/fstab |grep -v '#'|grep .; sudo parted /dev/sda print
What device label does target external disk get? (e.g. /dev/sdb?) – Manwe Mar 12 '19 at 12:24grub.cfg
to/etc/grub.d/40_custom
then change--root=/dev/sdaX
to--root=/dev/sdbX
in the40_custom
file, update grub. – GAD3R Mar 12 '19 at 13:29dd
is almost certainly the wrong tool for the job. It copies everything, included blank space. You'd better simply use cp, rsync or rdiff-backup; it will be much faster (and in the case of rdiff-backup, will provide incremental backups). – wazoox Mar 14 '19 at 16:13