can 'dd' be used to clone to a smaller HDD, knowing that partitions will need editing?

The physical drive should not start smoking, at least, but chances are very good that your filesystem will not work anymore (I mean, the target filesystem; if you just copied and did not touch anything in the source, the source itself should be fine). Data inside a partition is not necessarily allocated in increasing order. Some of it may be at the end of the partition even if the partition is not full (actually, I think that this happens deterministically with some filesystem, but I do not know enough to get in the details). The data there may be essential to the integrity of the filesystem. So I strongly advise you not to rely on such a copy.

If you want to do this copy, you first have to shrink the partition with some tool that is aware of its internal structure and is able to remap everything in good order into a smaller partition. Then you can do the copy. gparted is a good GUI interface to do this kind of things.

For the bs value, usually the best idea is to have a couple of tests before starting the real copy. There are some tools that help you automating this check, but I do not remember the name. In my experience, the best range is usually between 4M and 16M. Higher than that you do not earn much anymore. But it depends on many things, including the disks themselves. For example, I rarely worked with real high-end disks, which may be suitable for higher values due to bigger speed and cache size.

EDIT If a partition is wholly copied, then you can use it without problems. However, as others have underlined, you also have to be sure that the partition table is intact (at least, the relevant entries). With MBR's four primary partitions there are no problems, since they are described in the first 512 bytes of the disk. Logic partitions are described throughout the extended partition, so entries may be lost (but they would described partitions that would be lost anyway). With GPT there is a copy of the partition table both at the beginning and at the end of the disk. You lose the second one, but you can rebuilt it from the first one. Of course it is advisable to do that as soon as possible; other answers were more precise with respect to that.

Although at first the proposed "challenge" may seem difficult, not feasible or sound naive as some have commented, it isn't. The main idea behind using dd to migrate from a bigger to a smaller disk is perfectly fine and have benefits for migrating the data. Of course, having enough free space so that the occupied data fits in the destination disk is a necessary requirement.

The idea is to think in dd'ing each partition individually and not the entire disk at once as initially proposed. Even more can be accomplished: The partition(s) that would be truncated can also be safely migrated with a little help of filesystem re-sizing tools. Indeed, such kind of migration is interesting in order to preserve filesystem matadata and extended file attributes that cannot be easily copied with tools like cp, rsync, pax, ... which operate in the filesystem layer and not block device layer. Using dd elliminates the need of re-installing the OS or having to relabel the FS in order to avoid issues with SELinux.

Below is what I usually do to accomplish similar tasks:

1) First you have reduce the filesystem(s) within the affected partitions that would be truncated. For this, use the resize2fs tool (assuming we are talking about an ext2/ext3/ext4 fs - other modern FSs also have resizing tools for the same purpose). Note that although -- for obvious reasons -- a filesystem cannot be bigger than the partition it resides within, it can safely be smaller. The safety trick here is to reduce "more than needed". For example: imagine you have a filesystem of 1TB that you want to migrate to a 500 Gig drive. In this case, I suggest reducing the fs to, let's say, 450 Gig (you have to have enough free space for this, of course, i.e., the currently occupied space in this filesystem cannot exceed 450 Gig). The apparent wasted 50 Gig of space will be fixed after the data migration.

2) Partition the destination disk with the appropriate geometry considering its space constraints;

3) dd the data using the partition device(s) and not the disk device (i.e., use dd if=/dev/sda# of=/dev/sdb# for each partition instead of using if=/dev/sda of=/dev/sdb). NOTE: sda and sdb here are just examples; IMPORTANT NOTE: When dd'ing from a bigger to a smaller partition device, dd will complain about attempting to write post to the end of the block device, that's ok since the filesystem data would have been entirely copied before reaching that point. To avoid such error message you can specify the size of the copy using bs= and count= parameters to match the shrunk filesystem size, but this will require some (simple) calculation, but if done wrongly can risk your data.

4) After dd'ing the data, resize the respective filesystem(s) within the destination partition(s) again using resize2fs. This time do not specify the new filesystem size. When ran without a size specification, resize2fs grows the filesystem so that it occupies the maximum allowed size, so, in this case, the 450 Gig filesystem will grow again to occupy the entire 500 Gig partition and no byte will be wasted. (The "reduce more than needed" approach avoids you to accidentally specify sizes wrongly and risk your data. Note that GB vs GiB units can be tricky).

Note for more complex operations: If you have a boot manager that you intend to copy along, which is very likely to be the case, you can dd the first few KBs of the disk using the disk device instead of the partition devices (like dd if=/dev/sda of=/dev/sdb bs=4096 count=5), and then reconfigure the geometry in /dev/sdb (which will temporarily contain an invalid geometry for the new drive but an intact and valid boot manager). Finally proceed using the partition devices as described above for dd'ing a partition at a time. I did operations like this many times. Quite recently, I successfully performed a complex migration when upgrading from a HDD containing a mix of MacOSX & Linux installations to a smaller SDD in my MacMini6,2. In this case, I had to boot Linux from an external drive, dd'ed the bootmanager, ran gdisk to fix the GPT in the new disk and finally dd'ed each partition containing the just shrunk filesystes. (Note that the GPT partition scheme keeps two copies of the partition table, one in the beginning and another in the end of the disk. gdisk complains a lot because it cannot find the second copy of the PT and because the partitions exceed the disk size, but it correctly fixes the PT copy issue after you redefine the disk geometry). This was a much more complex case, but worth mentioning because illustrates that this kind of operation is also perfectly feasible.

Good luck! ...and most importantly remember to backup all important data before such kind of operation. A mistake and you can surely damage your data irrecoverably.

And just in case I didn't emphasize enough: back up your data before the migration! :)

As others have mentioned here using just dd won't work due to the copy of the GPT table placed at the end of the disk.

I have managed to perform a migration to a smaller drive using the following method:

First - boot into liveCD distro of your choice.

Resize the source drive partitions to indeed fit within the smaller drive's constraints (using gparted for example). Then, assuming sda is the source disk, using sgdisk, first create a backup of GPT table from the source drive to be on the safe side: `

    sgdisk -b=gpt.bak.bin /dev/sda

Assuming sdb is the target, replicate the table from the source drive to the target:

    sgdisk -R=/dev/sdb /dev/sda

sgdisk will now complain that it tried placing the header copy out of the bounds of the target disk, but then will fallback and place the header correctly at the upper bound of the target disk.

Verify that a correct clone of the partition table has been created on the target drive using the tool of your choice (gparted for example).

Using dd, copy each partition from the source drive to the target:

dd if=/dev/sda1 of=/dev/sdb1 bs=1M
dd if=/dev/sda2 of=/dev/sdb2 bs=1M
dd if=/dev/sda3 of=/dev/sdb3 bs=1M
etc...

Obviously, if you mix up the names of the drives when replicating the GPT partition table without a backup or when dding the content you can kiss your content goodbye :)