Let's say you did a hard disk clone and it won't boot. This outlines specific steps to fix a cloned hard drive on /dev/sda that did not boot after cloning. The main issue was a different UUID for the hard drive. If you have the option during cloning to preserve the UUID, all this would not be necessary. So this is a duplicated drive that does not have the UUID of the original. When the system tried to boot, it did not, and this was shown:
Gave up waiting for root device
ALERT! /dev/disk/by-uuid/[UUID] does not exist!
So this is a problem with /etc/fstab and/or GRUB - here are some steps to resolve the problem:
NOTE: All examples assume single hard drive device as /dev/sda and booting rescue from USB or Disc
Get to a Shell with root/superuser prompt
Plug in handy Debian Complete Collection on USB (or suitable boot media with shell access)
Select Live Standard (Shell prompt)
Type sudo su[Enter] to get to root/superuser prompt
Figure out new UUIDs (main boot partition/swap/etc.)
You can use blkid (/sbin/blkid[Enter]) to view current UUID for drives
To save off for use in editing, you can do something like this:
lsblk -l -o +UUID | grep sda1 | cut -b 80-115 > newuuid.txt[Enter]
(List 36 characters for UUID into file)
Now we want to actually make changes to the boot drive (not our USB drive), so mount the root partition (be sure you know correct partition/layout of drive for this step!)
mount /dev/sda1 /mnt[Enter]
In nano, use insert key, then enter /home/user/newuuid.txt to insert text for new hard drive UUID - edit as appropriate to replace/update the UUID. Note old UUID that you are updating/replacing, as this may be used in grub.cfg, and also need an update.
You will also need to do a similar process for the swap partition
EXAMPLE FSTAB FOR REFERENCE/WHAT UUID ENTRY LOOKS LIKE
# /etc/fstab: static file system information.
# Use 'blkid' to print the universally unique identifier for a
# device; this may be used with UUID= as a more robust way to name devices
# that works even if disks are added and removed. See fstab(5).
# / was on /dev/sda1 during installation
UUID=c3447a5c-d4d9-4327-af71-393723761edd / ext4 errors=remount-ro 0 1
# swap was on /dev/sda5 during installation
UUID=75eef9cf-24c1-4b1a-9a3e-8a3c625bd62a none swap sw 0 0
/dev/sr0 /media/cdrom0 udf,iso9660 user,noauto 0 0
At this point, you should remove USB / DVD boot media, and reboot system to boot hard drive. You should at least get to the grub menu (startup menu)
Ideally you will be able to boot the default item or get into the advanced options (if available) and get a rescue mode/option to boot
If this does not work, or there is still boot issue (and you can't use rescue option to boot to hard drive), then, you will have to get to same spot as updating fstab and then update a grub.cfg menu item (change root UUID from original/old UUID to new hard drive UUID (e.g. what was saved in newuuid.txt)) e.g. nano /boot/grub/grub.cfg[Enter] - you will want to find the old/original UUID and replace with new current hard drive UUID - you can do the whole file, but easiest to do the main boot option or use edit option from grub menu. The reason we suggest editing grub.cfg is because you can use newuuid.txt vs. recording/manually entering new UUID.
EXAMPLE LINE IN GRUB.CFG WHERE UUID WOULD NEED TO CHANGE
echo 'Loading Linux 4.19.0-14-amd64 ...'
linux /boot/vmlinuz-4.19.0-14-amd64 root=UUID=c3447a5c-d4d9-4327-af71-393723761edd ro quiet
If you still can't get booted on the actual hard drive (never see GRUB errors or just reboot without starting GRUB), then you may have to do some work to run / fix grub - here is one (simple) approach:
After booting to the rescue prompt:
#>mount /dev/sda1 /mnt
(Now map rescue system to critical mount points proc/sys/dev on /mnt to prep for chroot)
#>mount -t proc /proc proc/
(if that fails, try rbind), e.g. mount --rbind /proc proc/
#>mount --rbind /sys sys/
#>mount --rbind /dev dev/
(Now chroot to make this root folder)
(Now fall into fix below, e.g. run update-grub then grub-install /dev/sda)
Once booted, you will want to formally update grub/fix all references to hard drive
get to root/superuser prompt and run
Then reboot, and your system now is reconfigured for cloned drive!
Delay/Warning: Gave up waiting for suspend/resume device
This can happen if the original drive had a device configured for suspend/resume with a UUID - now that the UUID has changed, it will cause a delay are reboot. Here are some quick notes on where to find / how to resolve this situation.
Once you have your correct UUID, as root/superuser, go to /etc/initramfs-tools/conf.d/ and edit the file resume. Use RESUME=UUID=75eef9cf-24c1-4b1a-9a3e-8a3c625bd62a (where UUID matches correct device). Alternatively, use RESUME=none if this capability is not needed/wanted.
Make sure your root user has /sbin in the path, e.g. PATH=$PATH:/sbin, then run update-initramfs -u to update correct files. Now reboot and this should remove & resolve delay, warning display.