The memtest86+ tool supplied with Unraid will only work correctly if you are booting in non-UEFI (legacy) mode. If you want a version that can be run when booting in UEFI mode then you need to download your own copy from the memtest86+ web site.
Old thread, I know. But I forgot about this and ran into the same problem after upgrading my memory yesterday. I wanted to test my new memory properly before booting UnRaid completely. For the life of me, I couldn't figure out why the PC kept rebooting when I chose the memtest option on the UnRaid boot menu. I thought to myself "Maybe that's an old entry in the menu and doesn't work anymore?" and just downloaded the new version from the website and tested from that. This brings up the point of my reply... Is there any particular reason why the UnRaid dev's haven't included the newer UEFI version of memtest onto the OS image? Unless it's a licensing thing, I don't see the harm. I would even argue that you could include BOTH versions, the UEFI and the CSM versions, unless it's a matter of storage space on the UnRaid image on the drive. Just curious. Seems like an unnecessary hurdle to have to change your BIOS over to an older legacy boot mode for RAM testing. If I recall, when you first create your ISO image for the flash drive, don't you have to pick the UEFI option? If that's the case, have it install the UEFI version of memtest if you select that option.
The change I think would be worth making at the Unraid level is to change the boot menu when in UEFI mode to not include the memtest option since it does not work in that mode. Perhaps a different entry that points out a version from memtest86.com is needed?
That's not a bad idea. If it's not able to work don't offer it. But if the boot menu is capable of detecting UEFI vs Legacy, a simple "Not available for UEFI, please download from memtest86.com" flag that displays only in UEFI would be nice. It would at least remind you that it's not going to work and you won't waste your time trying to figure out why the PC keeps rebooting.
Is the Unraid Boot menu code available anywhere? I am interested in making the changes that would make the Unraid Boot Menu UEFI aware and handle memtest entry accordingly. Most of the work appears to be in the GUI code for maintaining the syslinux entries, but some small changes need to be made to the Boot Menu in UEFI and Legacy mode to handle the memtest part of it differently in the two cases.
So i'm trying to run a memtest, first I tried selecting the memtest boot option in the flash drive setting through unraid, that would just make the system go in to a reboot cycle. It would output the boot select option to the display and try to automatically run the memtest after 5 seconds as it should but then would just reboot straight away. Was able to boot back in to the OS as standard from this boot selection screen.
Then tried creating a memtest bootable usb using the latest memtest download from When I tried to boot from the UEFI option the system would just go straight back in to the bios. Tried the previous version of memtest (from 2013) and it would do the same thing.
I've been having all sorts of issues with my system that I think originate from my cache drive dying and copying the cache files over the the new drive (possible something corrupt in these files). But realistically this shouldn't affect my system's ability to run a memtest if i'm trying to run it direct from a bootable usb drive created using the official memtest boot drive creator, right?
I am using it in a MSI X399 Gaming Pro Carbon AC motherboard, with a AMD Ryzen Threadripper 1950x CPU. I have two kits, and populated both kits in the slots specified by the motherboard manual (A2/B2/C2/D2). I initially used the A-XMP profile for 3000MHz. When running Passmark memtest86 v7.4, I would notice about four errors on Test #10. I kept dropping frequency, thinking a Ryzen compatibility issue, but even at default 2133MHz, I would get a handful of errors on Test #10. I then decide to test the two kits separately, installing in slots B2/D2, and running at default 2133MHz. One kit fails on Test #10 as above, while the other passes. So it looks like this one kit is bad. I would like a replacement, so I can run in quad-channel. Would like to setup advanced RMA.
Essentially, it sounds like Corsair will not honor warranty on RAM that fails "synthetic" benchmarks like Prime95 and memtest86. I would like to see this posted on the warranty page or some FAQ, as it will certainly affect me as a future buyer, and perhaps others.
Whenever I build a system, I run a standard suite of tests to insure stability. This includes memtest86 (note the use of *test* not *benchmark*), Prime95, IntelBurnTest, Intel Processor Diagnostic Test (assuming Intel system), Valley, Heaven, Cinebench, etc. Prime95 is puzzling. This is running a bunch of FFTs, which is pure math. If this fails with one set of RAM at stock / non-overclocked speeds, but not another, how is this not a memory error? I recently built several systems for a client with 64GB of RAM each. He was running complex math solvers, which max'd out the use of RAM. I don't want him to get bad results for his applications! A memory failure wouldn't crash the system, but provide inaccurate results, which he would probably never detect.
Using your explanation of these "synthetic" tests, if I am building a system for a customer using Corsair RAM, and encounter errors in memtest86, then I would not give that system to a customer. I am not going to tell him/her: "Oh, it fails some synthetic tests, but those are not real...don't worry!". Then when I get the system back in a few weeks/months, I will have to spend the time debugging, replacing RAM and re-testing. Meanwhile, I will have lost credibility with the customer, thus potentially losing future sales and referrals.
You just said the magic set of words. Case by case basis. I would like to see other users here on the forums give their input as well, as I just find that failing memtest and Prime95 not a benchmark, but a stress test. If your RAM cannot pass stress test, it is not very robust. I have subsequently moved the same RAM to a totally different platorm, an ASRock X399 Taichi / AMD Ryzen 7 1700X, set the speed to 2933MHz via A-XMP. I ran memtest86, and sure enough Test #10 fails. Set the speed to 2133MHz and Test #10 fails. Put in an identical kit (CMK16GX4M2B3000C15W), set speed to 2933MHz via A-XMP and it passes.
Actually Debian made this pretty easy. Just install the memtest86 or memtest86+ package. I think I will make memtest86+ a dependency of the kernel plugin so it gets installed automatically when the plugin does. Both packages add an entry to grub.
I installed the memtest86+ package. First time I tried booting to it I got no output in my ipmi console. Looking into it I saw that ttyS0 was specified for the serial console in the grub entry. I changed that to the required for my use case ttyS1 and tried again. This time I got output but when the memtest started it got 34% into test #1 and hung. I could not escape out of it. I tried a few more times but it failed the same way.
One test would be analogous to the DRAM memtest program, which would check all the NAND chips for "errors" or faults. I assume that would be at the byte level, not at the MLC or SLC cell level. Or would the block level be appropriate?
If you're talking about memtest86/memtest86+, as in the bootable programs, sure. Interrupting it won't do anything, since it never writes any persistent data. In fact, the tests are intentionally endless - it'll just keep running passes until you stop it.
memtest is structured as a number of tests, each of a specific pattern. A single completed run through all selected tests is known as a pass. As mentioned before, you can safely abort at any time, simply by switching off the machine.
Looking for similar filenames on my system I find only files with quite old dates which is telling me they may have nothing to do with the recent installation of memtest86+ but may be leftovers from something in the past:
PassMark suggests that this is a firmware issue, and further recommends purchasing the configurable version of memtest86+ to remediate it. If it really is a firmware issue, it may be worth pursuing a fix on the Framework side.
I used a microsft tool to create a bootable Window 10 install USB.The key contains memtest at:"H:\boot\memtest.exe"When I boot off the USB it goes into Windows 10 install - how can I run the memtest.exe?I know there lots of ways to make a bootable memtest USB but I want to know how to use memtest on the existing bootable Windows 10 USB that I have.
Booting into Qubes OS installer, which has a memtest built into it. Librem 14 failed to boot to the memtest:
Loading the new kernel:
kexec -l /media/isolinux/memtest --append="intel_iommu=igfx_off "
Cannot determine the file type of /media/isolinux/memtest
Failed to load the new kernel
!!! Failed to boot w/ options: Run a memory testelfkernel /isolinux/memtest
!!! Something failed during USB boot