Unable to create a MemTest86 bootable USB Flash drive for macOS Catalina

[rperchonok]

This is a repost of information I provided in another posting on this forum entitled “cant create usb with catalina macOS”. I believe I addressed all issues raised by PassMark administrator David in that posting. My hope is that a new posting may attract additional technical eyes and perhaps help me to resolve my inability to create a bootable USB Flash drive for my iMac (2020) running macOS Catalina.

I have followed the steps provided in the posting at https://www.memtest86.com/tech_creating-linux-mac.html with the following observations:

• Steps 1 & 2. Completed without a problem.

• Step 3. My flash drive is USB 3.1 128GB.
• Step 4. The terminal command "diskutil list” clearly shows my flash drive is assigned "/dev/disk4”.
• Step 5. I am able to successfully unmount my flash drive. My terminal session confirms this and the drive no longer appears in Finder.
• Step 6.
  • I first cd to the directory where memtest86-usb.zip was unzipped.
  • I confirm with the ls command that the directory contains the file memtest86-usb.img.
  • I issue the command "sudo dd if=memtest86-usb.img of=/dev/disk4"
  • When prompted for a password, I provide that associated with the administrator privileged account that I am logged into.
  • After a 14 minute wait, the copy appears to succeed with the following terminal message:
    • 1024000+0 records in
    • 1024000+0 records out
    • 524288000 bytes transferred in 592.901005 secs (884276 bytes/sec)
  • Note that my 128GB flash drive was formatted as a 260.8 MB MS-DOS (FAT16) drive as a result of the “sudo dd” command. Of that space, only 7.9 MB is in use. However, the message provided in Terminal in response to the “sudo dd” command indicated that 524 MB were transferred. What is the expected size and content of the USB flash drive after executing the "sudo dd" command?
  • In order to confirm the typical transfer speeds to my USB flash drive, I later reformatted it as Mac OS Extended and copied a 1GB file to it from my iMac. The copy required 14sec, i.e. an estimated speed of 71MB / sec. I do not understand why the sudo command above required an excessively long time to complete its apparently incomplete data transfer.
• Step 7. When booting my iMac while holding the Option key down, I now see two additional boot devices both labeled “EFI Boot”. I separately tried booting from each, but in both cases receive the error message: "Unable to verify startup disk. Try again or select another startup disk.”
  • I have confirmed that I had previously set the External Boot option (in Startup Security Utility) to Allow booting from external media. I know this works in that I’ve previously booted from a bootableThunderbolt 3 drive created by SuperDuper.

[David (PassMark)]

After a 14 minute wait, the copy appears to succeed

Most flash drives don't like small read and writes. And dd on the Mac seems to default to just 512 byte blocks. Which means lots of I/O and overhead.

Try this instead, to force the block size to be 4MB (80x less I/O)
sudo dd if=memtest86-usb.img of=/dev/disk4 bs=4m
(after checking that /disk4 is still your target destination drive)
It should be a lot quicker.

Note that my 128GB flash drive was formatted as a 260.8 MB MS-DOS (FAT16) drive.... Of that space, only 7.9 MB is in use. However, the “sudo dd” command indicated that 524 MB were transferred

Yes. 128GB is much larger than required. So most of the drive won't be used. 524MB is the size of the disk image we provide and that 524MB is also mostly empty as some free space is required for log files & reports, etc... So all that sounds about right.

I receive the error message: "Unable to verify startup disk. Try again or select another startup disk.”

This is probably a result of the Apple T2 Security Chip in newer Mac's See this post.
https://forums.passmark.com/memtest8...9110#post49110

We'll also update the article you linked to with a few more details.

[rperchonok]

Thanks for the suggestion. Unfortunately, it generates the error "dd: bs: illegal numeric value”. Looking at the man page for the dd command indicates the bs argument should be numerical, i.e. without the ‘M’. Should I set the value to 4000000 or 4194304 (i.e. 4*1024^2)? I noticed that the bs switch sets both the input and output block size to this value. Is that your intent?

I totally understand that 128GB is MUCH larger than the space required for the MemTest86 bootable drive. My comment was intended to highlight that only 7.9MB was in use.

[Ivg]

I am having the exact same issue... did u figure out how to make it work?

[Ivg]

After some Google-foo, i discovered a solution to the "illegal numeric value" - if you use "m" instead of "M" it will work...

[Ivg]

In addition I then double checked that I also have bot the external device boot and "no security" option selected (see the post linked above) - this made it boot into MemTest.

but it still was getting stuck on "getting memory controller details" so I am trying the solution from this post

[David (PassMark)]

Glad you got it to the point of (almost) booting. Unfortunately there is a bug in Apple UEFI BIOS that they added about a month ago.
There is a work around however. As per the link above.
We've reported the issue to Apple. But no response as yet from them.

Update 21/Dec/2020: We received a response from Apple saying that they found and addressed the BIOS issue. It should roll out in early 2021 (maybe as part of their 11.2 release).

[Ivg]

So I have had it boot successfully using the workaround you have suggested and for better or for worse (I'll explain in a sec) after 15 hours of testing (2 passes) my ram came back clean... On one hand I have good ram sticks but on the other, I have no idea what to do next to diagnose my intermittent kernel panics on the mac - i have done a clean install and tested the ram... so now I am clueless as to what I should try to figure it out. That being said Memtest gave my ram a clean bill of health!

[David (PassMark)]

While not a Mac expert I believe crash logs are keep for Kernel Panics. I would hope they contain some information about a issue. e.g. maybe the name of the device driver that caused the problem.

1. Library.
2. Select Logs > DiagnosticsReports.