In light of memtest86+ not working with UEFI, is there an open source alternative or something I can use from grub to test memory?

  • You might use memory stressers that work inside an OS (e.g. inside Linux, as a userland program & process) Apr 24 '18 at 8:26
  • BTW, ten years ago I had a (MSI S270 Turion) laptop with faulty memory: memtest did not detect anything, but kernel compilation failed very often. Replacing the memory modules fixed the issue Apr 24 '18 at 8:29
  • 2
    Is this a statement of principle ("must be open source") or a statement of financial necessity ("must be free")?
    – roaima
    Apr 24 '18 at 9:00
  • 1
    @roaima the closed-source memtest86 is available for gratis (mentioned in the linked AU post), so I'd say it's a statement of principle (or other necessity such as validating source code)
    – muru
    Apr 24 '18 at 15:01
  • It's a fair request for clarification, but yes libre. Apr 24 '18 at 15:08

Yes, there is, in the Linux kernel itself: the memtest option will run a memory check with up to 17 patterns (currently). If you add memtest to your kernel boot parameters, it will run all tests at boot, and reserve any failing addresses so that they’re not used. If you want fewer tests, you can specify the number of patterns (memtest=8 for example).

This isn’t as extensive as Memtest86+’s tests, but it still gives pretty good results.

Some distribution kernels don’t include this feature; you can check whether it’s available by looking for CONFIG_MEMTEST in your kernel configuration (try /boot/config-$(uname -r)). The kernel won’t complain if you specify memtest but it doesn’t support it; when it does run, you should see output like

[    0.000000] early_memtest: # of tests: 17
[    0.000000]   0x0000000000010000 - 0x0000000000099000 pattern 4c494e5558726c7a
[    0.000000]   0x0000000000100000 - 0x0000000003800000 pattern 4c494e5558726c7a
[    0.000000]   0x000000000500d000 - 0x0000000007fe0000 pattern 4c494e5558726c7a
[    0.000000]   0x0000000000010000 - 0x0000000000099000 pattern eeeeeeeeeeeeeeee
[    0.000000]   0x0000000000100000 - 0x0000000003800000 pattern eeeeeeeeeeeeeeee
[    0.000000]   0x000000000500d000 - 0x0000000007fe0000 pattern eeeeeeeeeeeeeeee
[    0.000000]   0x0000000000010000 - 0x0000000000099000 pattern dddddddddddddddd
[    0.000000]   0x0000000000100000 - 0x0000000003800000 pattern dddddddddddddddd
[    0.000000]   0x000000000500d000 - 0x0000000007fe0000 pattern dddddddddddddddd
[    0.000000]   0x0000000000010000 - 0x0000000000099000 pattern bbbbbbbbbbbbbbbb
[    0.000000]   0x0000000000100000 - 0x0000000003800000 pattern bbbbbbbbbbbbbbbb

while the kernel boots (or in its boot logs, later).

You can use QEMU to get a feel for this:

qemu-system-x86_64 -kernel /boot/vmlinuz-$(uname -r) -append "memtest console=ttyS0" -nographic

(or whichever qemu-system-... is appropriate for your architecture), and look for “early_memtest”. To exit QEMU after the kernel panics, press Ctrla, c, q, Enter.


You can add the freeware (free beer) version of the latest memtest86 into UEFI Grub2 on Ubuntu.

Based on a tutorial, I took the following steps on a remote Ubuntu 16.04 server to add memtest86 to UEFI Grub2:

  1. Firstly, note that grub2 does not show memtest86 nor memtest86+: GRUB boot menu This is despite the fact my boot folder clearly has memtest86+. See image below. listing of /boot directory

  2. Download memtest86-usb.zip to laptop

  3. Send the zip file to the remote machine, then unzip it somewhere (e.g. /home/<username>/memtest86-usb/)

  4. We need to analyze memtest86-usb.img using fdisk -lu memtest86-usb.img to see it's mount offset. fdisk -lu memtest86-usb.img We want to mount the second device listed in the above output, memtest86-usb.img2. The above image shows each sector is 512 Bytes, and memtest86-usb.img2 starts at sector 514048. Therefore it starts at 514048*512 Bytes=263192576 Bytes.

  5. Create a folder (e.g. /home/<username/memtest-tmp) and mount it:

    mkdir /home/<username>/memtest-tmp
    sudo mount -o loop,offset=263192576 /home/<username>/memtest86-usb/memtest86-usb.img
  6. Use lsblk to check details about the EFI partition as well as your mounted .img file lsblk output In the above picture, we note the following:

    1. Where the EFI partition is mounted, here it's at /boot/efi.
      • Note, in my server, I have the option of choosing the boot mode to be legacy or UEFI in the BIOS setup. I had previously set it to legacy and thus the /boot/efi folder did not exist. Changing the boot mode to UEFI allowed me to see the /boot/efi folder and verify that the EFI partition is mounted there.
    2. The device number. Device name is sda1; thus it's the letter a. This is important later.
    3. The partition number. Device name is sda1; thus it's partition 1. This is important for later
    4. As a sanity check, we also note that memtest86-usb.img2 was mounted to /home/<username>/memtest-tmp.
  7. Next, we verify that the mount point contains an EFI/BOOT folder` and view its contents: enter image description here

  8. Next, we simultaneously copy and rename /home/<username>/memtest-tmp/EFI/BOOT to /boot/efi/EFI/memtest86 (assuming the target folder /boot/efit/EFI/memtest86): enter image description here

  9. Next we create a GRUB chainloader entry. Create a file /etc/grub.d/42_memtest, with contents similar to the following:

    exec tail -n +3 $0
    # This file provides an easy way to add custom menu entries.  Simply type the
    # menu entries you want to add after this comment.  Be careful not to change
    # the 'exec tail' line above.
    menuentry 'memtest86' {
    insmod part_gpt
    insmod fat
    set root='hd0,gpt1'
    if [ x$feature_platform_search_hint = xy ]; then
        search --no-floppy --fs-uuid --set=root --hint-bios=hd0,gpt1 --hint-efi=hd0,gpt1 --hint-baremetal=ahci0,gpt1 4418-37D3
        search --no-floppy --fs-uuid --set=root 4418-37D3
    chainloader /EFI/memtest86/BOOTX64.efi}

    In the above picture, we did set root='hd0,gtp1, because our EFI partion was noted as device name = sda1. According to the grub2 convention...

    1. The a in sda corresponds to the 0 in hd0
    2. The 1 in sda1 corresponds to the 1 in gtp1.
    3. We can use the gpt* format to specify partition 1 of device sda because we did insmod part_gpt. We can recognize the disk label type as gpt using the fdisk -l command, and also from looking at the /boot/grub/grub.cfg file.

    Also note that we used the EFI partition's UUID, which can be obtained from the blkid command which shows the UUID of all partitions on your machine.

  10. We update grub2 with update-grub2.

  11. Restart and you should see memtest86 in grub2 GRUB boot menu with memtest86

  • 1
    Please outline the complete steps described in the tutorial. Keep the tutorial link as reference. You do not need to include the screenshots.
    – Nils
    Feb 4 at 21:02
  • 1
    Note that the OP was already aware of memtest86, but was asking for a FLOSS solution. Feb 4 at 21:20

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.