I recently upgraded my home desktop's hard drive, because the old one was getting a bit full. Googling for instructions about how to transfer an existing system onto a new drive, many posts suggest using the cpio command, and that's what I tried. While this command does the job for the most part, there is one caveat which I encountered that makes cpio not the ideal tool to use.
Using cpio will end up a little screwy in some edge cases because of this. The particular case I ran into involved folders in /media that are managed by udisks2. udisks2 creates personal mount folders under /media with tailored ACLs to help properly manage permissions for permission-capable filesystems mounted by regular users. If you already have one of these personal mount folders, cpio will break it, and you'll lose permission to view any filesystems that you mount under it henceforth.
A better solution than cpio: rsync -caHAX src/ dest/
(Edit: Add -v to also see progress.)
As a side-note: if applicable, don't forget to run sudo dpkg-reconfigure grub-pc and set the appropriate device to install the Grub bootloader onto. I attempted a manual grub-install so that the new hard drive would boot, but forgot to dpkg-reconfigure. A couple of weeks later, a Grub package update changed files on the filesystem but updated the Grub boot image on the wrong hard drive, leaving the system unbootable (until I fixed it with a rescue image on a USB stick). Don't let it happen to you!
Update 2014-12-01: Alternatively, and this is probably a better idea, if you're transferring your system from one device to another as I was doing, why not just use tune2fs (or reiserfstune, or equivalent for the filesystem in question) to set the partition UUIDs? I haven't tried it, but I suspect this ought to avoid the issue with Grub, and also issues with any other program (e.g. Amarok) that records the drive's UUID.
Comment to add? Send me a message: <email@example.com>