Slow boot time after update to Mojave - External SSD

I use Akitio Thunder SATA Go (eSata to Thunderbolt v1) adapter. This seems to be the cheapest Thunderbolt option with two eSata ports (for two external HDDs). You can hook your SSD directly using the included SATA -> eSata cable. In my case I connected my Startech USB/eSata enclosure with its eSata cable. Akitio adapter is powered by the Thunderbolt cable which is very short but you don't have to pay for it. Included SATA -> eSata cable is powered by a USB Type-A port of your Mac.

Delock 42510 requires Thunderbolt cable (sold separately) and a power adapter (included). What is interesting is that Delock cuts the power when machine goes to sleep, which increases "Unsafe shutdown count" SMART parameter of my SSD. I didn't notice any problem with the SSD though (it cools down to the ambient temperature on sleep and then heats up to 39-40 C after each wake up).

OK, I opened the iMac and I replaced the internal HDD with the SSD. It is working even faster than before. It is still on HFS+ so I don’t know if this fixes the issue. I will reformat at some point and do a clean install again.

One thing I read recently is that Samsung are offering tools for updating the SSD firmware. For anyone having this issue – it will be worth it to try and update your SSD firmware to see if this fixes it.

Great finds and advice for the solutions. It's not like I don't have the money, I can buy these at a whim, but I think it's incredibly ridiculous that Apple is not going to fix this. We now have to spend money to fix an Apple Mac OS BUG.

I think the AKITIO Thunderbolt solution is not as good for stationary use as the Delock/LaCie enclosures - simply because it's not an enclosure. You still need to occupy a USB port, meaning you need two cable connections to your Mac (USB and TB) - apart from the cable between between the adapter and the SSD. Also, you have two devices, the adapter AND the ("naked") SSD lying around on the table at the rear side of your Mac. Plus, the Thunderbolt cable is very short, it's 10cm of which only 6cm are flexible, so the adapter will literally be hanging on the TB connector of an iMac.

I think so far, the LaCie solution desribed a few posts above is the most practical one so far, and it comes at approx. the same cost as the Akitio adapter (at least here in Germany). Only one single cable connection is used (the included TB cable) without the need for an additional power supply USB cable connection. The downside here is the big "rugged" orange enclosure design which might look a a bit stupid connected to an otherwise quite elegant iMac.

The Delock solution looks quite good on the iMac, but here the major disadvantage is the need for an additional power supply (which is included though), meaning another cable connection. If there was a combination of LaCie/Delock, meaning a nice and small more "Mac style" enclosure (like the Delock) that doesn't need a power supply (like the LaCie), then that would be something I'd seriously consider.

Indeed, the Akitio Thunderbolt cable is very short, but it's not looking that bad behind my Macmini (it's aluminium with white cable). For an iMac you will need a stand (i.e. a book) to put in on. The advantage of Akitio is lower price (~91 USD) and that I you can connect two HDDs to a single Thunderbolt port (I just hooked two of my existing USB/eSata enclosures with their long eSata cables).

The Rugged LaCie costs (~130 USD) and has a little longer, but orange Thunderbolt cable. May be you can manage to put the drive on your desktop below your iMac, but not too far from it. You must trow the included 1TB HDD and connect only one HDD to a Thunderbolt port.

Can anyone with LaCie Rugged confirm if your SSD SMART parameters are OK especially when machine goes to sleep (look for changes of "Unsafe shutdown count" and "UDMA CRC Error count")?

I dont know where to look for unsafe shutdown count and udma. i cant find them in mac system report window.

but in sata field where lacie stays i checked and saw this:

TRIM Support: Yes

SMART status: Verified

To read SMART parameters of your SSD you need a third party app as DriveDx or SMARTReporter. They provide trial versions. Or you may use the free "smartctl" which is only a command line tool, but actually all other utilities use it.

Unfortunately macOS DiskUtility shows only a summary as "S.M.A.R.T. status: Verified" (when It's able to read SMART data).

in trial version of drivedx i found only CRC Error Count

here is what it says

id - 199

name - CRC Error Count

Type: life-span indicator, online

Raw Value - 0

Value - Current:100 Worst:100 Treshold:0

Status - 100% OK

i cant see anything else in that crc report window

Same problem here.

I have an 2017 iMac (Retina 4K, 21.5-inch, 2017) with an Samsung 850 EVO 2TB in an 2,5" Event EW7070 USB 3.1 enclosure.

Connected with an usb-c > usb-c cable.

Tried it also with an usb-c > usb-a cable, but the same problem.

After boot I have to wait 2~4 minutes for the Apple logo, after that it is starting normal.

I'm sorry but the "solution" provided by the OP is not a solution. It is not acceptable that an OS update causes normal external SSDs to essentially stop working. This is nearly the last straw for me with Apple. They simply have no consideration for their customers and their products are no longer superior enough to justify such poor behavior. Apple was once the brand that "just works" -- that is no longer the case.

Mac OS Mojave doesn't support anymore HFS+ in a boot Drive.

So you can't update your OS if it detects that you're using a HFS+ formatted drive. You need to use your original drive to update the OS and clone again to the external SSD.

I am on same situation, Fusion Drive 1tb inside, boot on Fusion Drive is fast, boot on Samsung T5 takes 1-2 minutes until Apple logo. On High Sierra with Samsung T5 in HFS+ everything was smooth.

Perhaps this got nothing to do with the problem discussed here, but I just found out by accident my iMac doesn't swap memory at all when starting from my external T5 (iMac late 2013, USB3, 32GB). Is it possible this is the reason, does the OS fail to set up VM at startup? Would you check whether your swap is working?

I just came across this as I was running a huge batch of photos and the whole system eventually crashed with no memory left and no swap used.

Sorry if this is not of any help, I was just wondering ...

You're right.

I've found int my IMac that the VM partition on the external disk wasn't mounted. You can check it running the diskutil command on a terminal: diskutil ap list

I've found the solution in this url: https://apple.stackexchange.com/questions/318266/mac-os-x-is-not-creating-a-swap -file

But this problem has no relation with the slow boot. Once solved (the VM), the boot time before logo is the same.

I use external Thunderbolt SSD (which boots < 1 sec. to the Apple logo), but my VM volume was not mounted as well ("diskutil apfs list"). This seems to be another bug that Apple have to fix. I mounted VM volume manually and tested with "memory_pressure -l critical". The swap is working properly, now. Thanks for letting us know.

I've been experimenting with the slow boot issue. First my setup - I have a 2017 27" iMac with an internal fusion drive, which boots with no issues. I have three external enclosures - two identical Mercury Elite USB-C Raid 0 arrays, with Samsung EVO 860 SSD drives, two drives in each enclosure. These attach to the two USB-C/Thunderbolt ports. I have a third enclosure with my backup drive and a 2.5" drive attached via USB 3.0.

My iMac was booting fine, until I attached the second Raid array, yesterday. Adding the second array made the bootstrap portion of the boot as long as 5 minutes. Performing various actions (NVRAM, PRAM resets, etc.) brought down boot times to about 3:10. The only way I could get a sub-minute boot was to remove the second Raid array. I used SuperDuper to clone the Mercury Raid array to the second, larger Raid drive. I thought maybe the disk arrays being clones had some impact, so I erased the smaller array and then rebooted. 3:10 on the reboot.

In my case, it seems to be caused by the second Raid array being attached via USB-C.