While that is true in this case, it is also true that the amount of space from drive to drive will be different. What they're trying to guarantee is that you should get a minimum of 32G of space, but they can give you more.

All same sized flash drives are not exactly the same size. Some have slightly more blocks than another, so as a result using dd, it will copy as many blocks as it sees on the source drive and if there is just one more block on that source drive, it will copy it and then not be able to place it on the target.

If you specify fewer blocks than the source disk has, you risk not copying all information.

dd is a block copy and does not pay attention to partitioning, therefore if you reduce the size of the copy, you risk not getting all required information.

There are postings out there where people have copied all to a file, for instance on their main drive which has sufficient space and then they manipulate that file to make it smaller, by using gparted to ensure that the upper range of the file can be truncated without losing data. Their result makes it smaller than possible for any target device rated for that size so their copy out will always succeed, providing the target gives the full advertised space.

Yousa, this finally WORKED!!
Wow, what a little ordeal!

The warranty replacement was THE SAME THING- 31GB. STILL TOO SMALL!! Back to square one.

So, my intuition told me that dd must only copy as much as the size of the partition, and therefore if I wanted to have success with it, I must make that source 32GB flash drive's partitions 1GB+ smaller.
The other complication was that I had an encrypted volume group as part of this source drive.
So any procedure would have to:
1) Boot on a recovery or accessory kernel & attach the source drive
2) open this drive's vg with a cryptographic utility
3) make its volume group, pv and lv available to the kernel
4) Reduce root filesystem associated with the vg using resize2fs
5) Reduce the associated lv with lvreduce
6) Reduce the associated pv with pvresize
7) Reduce crypt with cryptsetup
8) Reduce the partition storing the crypt with fdisk.

I wrote the author of the tutorial I used to build the encrypted Ubuntu installation.
So he shared a procedure that worked really well.

https://help.ubuntu.com/community/Re...ptedPartitions

Still tricky in spots. Had to go down and up in size on the lv, pv and partitions (2 and 5) a few times.
I was amazed that I didn't corrupt the original filesystem, but I did have like 5GB space left according to df -m
I suspect that as long as you don't make lv, pv or partitions smaller than the original filesystem's occupied space even once, you could resize all day long, reboot, and still get back to sizes that let you open and mount your data.

When I dd'd the final time, it still gave one final complaint about "no space on device".
I wonder if dd gets this from the disk label or the header section of fdisk -l /dev/sdb, which always shows the 32GB.

I decided to boot it anyways and Voila!!

Now have 2 identical keys!

Yousa, this worked!! Wow, what a mini-ordeal!!

The warranty drive replacement was the sane 31GB- TOO SMALL!

So, I gravitated back to my original idea that I must resize the source flash drive.
To complicate things, the source is an encrypted installation of ubuntu linux with a lv,pv and volume group.

I wrote person who authored the tutorial on how to make the flash drive bootable encrypted ubuntu installation to see if he had anything or encountered the need to resize.

He sent along the following:
https://help.ubuntu.com/community/Re...ptedPartitions

This did ultimately work. Still a bit tricky in spots.

Basically any procedure would have to:

1) Boot another ubuntu kernel and attach the USB drive. Install & configure the tools (lvm2 and cryptsetup).

2) Open the encrypted filesystem and make kernel aware of lv,pv and vg.

3) Reduce the (root) file system with resize2fs.

4) Reduce the (root) (LVM) Logical Volume with lvreduce.

5) Reduce the (LVM) Physical Volume with pvresize.

6) Reduce the Crypt with cryptsetup.

7) Reduce the Partition storing the crypt with fdisk.

It took several attempts to get the partition sizing matched to the new pv and lv.
I was amazed that I did not corrupt the original filesystem.
It did have about 5-6GB of unallocated space as seen with df -m when it was booted.
I suspect that as long as one dosen't cut into the space of the original filesystem in downsizing the lv,pv and partitions, they can do it all day long until that get it right.

There was still one last nuisance "no space left on device". dd must get this from the disklabel or header seen in fdisk -l /dev/sdb
But for sure, if the partition is <= target drive, it will work.

So booted and working!!