How to dd a TrueOS installer to USB, on Linux

Forgive my ignorance, I've used a dozen distros of Linux (Debian and Fedora derivatives) but haven't yet wet my feet with BSD. I'm attempting to write the current TrueOS installer to a USB, through the Debian derivative Mint, v. 18.2. However, I'm not having much luck. I've cleared all partitions off of the thumb drive, and then launched the command:

sudo dd if=./latest.img of=/dev/sdf bs=1M

Where sdf is the thumb drive, and latest.img is the disk image. After some time, it completes, and I have a formatted drive which has a partition on it, which, as anticipated, Linux does not recognize (as Linux has zero or next-to-zero support for UFS in most cases). I boot to it, through UEFI of course, and it begins to start, then tells me that there is no bootable system on the chip. This is not an EFI/BIOS message, as the installer starts a self-check briefly before telling me this. I restarted to Mint and looked at it in GParted, and found multiple complaints about the structure of the drive. (I would love to quote this to you directly, but I reformatted the thumb drive earlier today and am currently unable to retrieve it.) As gung-ho as I usually am about installing an OS on a spare drive, I am not willing to goof around further until I've got this problem figured out. I thought disk dump would copy the image byte-for-byte? Does anyone see anything overtly wrong with my method here? I'm attempting to follow the handbook as closely as I can. If I don't get an immediate solution I'll try it again in a couple of days and grab the log verbatim. --ADDENDUM-- I just finished dd-ing the image to the disk again, and opened it in GParted. The two messages were: The backup GPT table is not at the end of the disk, as it should be. Fix, by moving the backup to the end (and removing the old backup)? (Clicked Fix) Not all of the space available to /dev/sdf appears to be used, you can fix the GPT to use all of the space (an extra 10004782 blocks) or continue with the current setting? (Clicked Fix) Afterward, the final partition sizes on /dev/sdf were:

/dev/sdf1 800.0 KiB (boot, esp)
/dev/sdf2 63.00 KiB
/dev/sdf3 2.68 GiB
/dev/sdf4 1.00 MiB
unallocated 4.77 GiB

It's late, but after I try this again I'll either report back with any error messages or submit an answer to my question.