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.


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.

  • Boot the system in a virtual machine first to see if it work at all, or if there is an issue with incompatibly hardware in your setup, or if there's an issue with the disk image on the USB stick. – Kusalananda Oct 1 '17 at 6:08
  • Done, I've got it going on a 50 gb virtual drive. No anomalies to speak of. – Michael Eric Oberlin Oct 1 '17 at 18:48
  • TrueOS Installer is unable to write onto USB but IMG instead. – randmc macion Jul 27 '18 at 1:35

Interestingly enough, it is booting now. Apparently the advised method of burning to USB is not always effective, to the point of crippling the installer -- but it is repairable with something as simple as GParted.

| improve this answer | |

I would try the ISO file instead of the .img file.

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.