Package Details: memtest86-efi 1:9.4build1000-4

Git Clone URL: (read-only, click to copy)
Package Base: memtest86-efi
Description: A free, thorough, stand alone memory test as an EFI application
Upstream URL:
Licenses: GPL2, custom:PassMark
Submitter: Xorg
Maintainer: Xorg
Last Packager: Xorg
Votes: 107
Popularity: 0.71
First Submitted: 2013-10-29 10:25 (UTC)
Last Updated: 2022-02-05 11:42 (UTC)

Pinned Comments

Xorg commented on 2019-06-08 08:52 (UTC) (edited on 2019-06-08 08:53 (UTC) by Xorg)

As you probably know, the <> URL is likely to cause problems, like this error:

==> Validating source files with sha512sums... ... FAILED

To avoid this problem, I prefer to reupload archive somewhere else, where this kind of breakage will not appear.

I can't upload this archive on AUR directly (archive is 8 MB but AUR accepts 250 KiB maximum), so I decide to put this archive on my Git repository to avoid future breakages.

I hope it suits you.

Latest Comments

Gadgethm commented on 2022-02-06 05:22 (UTC)

@Xorg: Thank you for the fast update! I was still having issues due to the fact that I don't set entries in grub or in efibootmgr (I use refind), and option 1 was hardcoding the path to the root of the esp instead of the user specified path.

I went ahead and made some local changes to add an option to install without adding entries, but to the user specified location; let me know your thoughts.

Here's the diff:

diff --git a/memtest86-efi b/memtest86-efi
index 0e4c54b..ff6f42b 100755
--- a/memtest86-efi
+++ b/memtest86-efi
@@ -154,7 +154,8 @@ install() {
    echo -e "${CB}2${CR}: Add a new EFI boot entry (more safe)"
    echo -e "${CB}3${CR}: Add a boot entry for GRUB2 menu"
    echo -e "${CB}4${CR}: Add a boot entry for systemd-boot menu"
-   echo -e "${CB}5${CR}: Cancel"
+   echo -e "${CB}5${CR}: Copy shellx64.efi file on ESP to user specified directory (bit safe)"
+   echo -e "${CB}6${CR}: Cancel"
    while [[ $choice -lt 1 ]] || [[ $choice -gt 5 ]]; do
        read -r choice
@@ -211,6 +212,11 @@ install() {
            bootctl --path="$esp_mount_path" update

+                5) # Install MemTest86 in ${esp_mount_path}${memtest86_esp_path}/
+                        memtest86_esp_bin="shell$ARCH.efi"
+                        _common_install "${esp_mount_path}${memtest86_esp_path}" "$memtest86_esp_bin"
+                ;;
        *) # Do nothing and quit
            echo -e "Canceled. MemTest86 will not be installed."
            exit $CODE_OK
@@ -242,7 +248,7 @@ update() {
            _common_install "$esp_mount_path" "$memtest86_esp_bin"

-       2|3|4) # Update files in ${esp_mount_path}${memtest86_esp_path}/
+       2|3|4|5) # Update files in ${esp_mount_path}${memtest86_esp_path}/
            _common_install "${esp_mount_path}${memtest86_esp_path}" "$memtest86_esp_bin"
@@ -298,6 +304,12 @@ remove() {
            rm -v "$esp_mount_path/loader/entries/memtest86-efi.conf"
            bootctl --path="$esp_mount_path" update
+                5) # Remove files in ${esp_mount_path}${memtest86_esp_path}
+                        echo -e "MemTest86 will be removed from ${CB}${esp_mount_path}${memtest86_esp_path}/${CR}."
+                        rm -rfv "${esp_mount_path:?}${memtest86_esp_path:?}"
+                ;;

    echo "Writting configuration..."

Xorg commented on 2022-02-05 11:49 (UTC)

@Gadgethm: Fixed in 0933d59e69d9. I improved a bit _mount_esp() function. Please note it is up to user to update configuration file if ESP mount point change after installation. In your case, I recommend a memtest86-efi -r, then update package to 1:9.4build1000-4, then reinstall like you want with memtest86-efi -i.

Gadgethm commented on 2022-02-04 04:40 (UTC) (edited on 2022-02-04 05:06 (UTC) by Gadgethm)

The latest update 600ab3bcaead broke my install setup. The auto mount feature is not really implemented well; it just blindly mounts and installs memtest to a hardcoded location, but my setup is to have my esp mounted at /boot/efi, and memtest installed at /boot/efi/EFI/tools/memtest86. As a result, the install script instead mounts my EFI directory to itself at /boot/efi/EFI/tools/memtest86, and then installs to the ESP root (since that's hardcoded in)

A better solution would be to have an option to have the script install to a specific, user specified directory. This way you're not auto mounting to whatever directory the user specified and resulting in nested mounts.

My config for reference:

# /etc/memtest86-efi.conf


Here's an example config of a better way to implement:

# /etc/memtest86-efi.conf


[EDIT] Another note: On further testing and investigation, the _mount_esp() function does not correctly detect that my EFI partition is already mounted at /boot/efi when I change the esp directory to be /boot/efi. As a result, the mount fails due to already being mounted and the script bombs out. The issue is with the way the not character is processed.

Relevant lines in the script:

if ! mount | grep "$partition" | grep -q "$esp"; then
        echo -e "ESP ${CB}$partition${CR} is not mounted, mounting..."

Should be changed to

if [! mount | grep "$partition" | grep -q "$esp"]; then
        echo -e "ESP ${CB}$partition${CR} is not mounted, mounting..."

Xorg commented on 2022-02-01 19:06 (UTC)

@mokkurkalve: Please manually edit /etc/memtest86-efi/memtest86-efi.conf configuration file to fix the issue.

mokkurkalve commented on 2022-01-31 23:40 (UTC) (edited on 2022-01-31 23:47 (UTC) by mokkurkalve)

The change in 1:9.4build1000-2 makes my update fail:

sudo memtest86-efi -s
Default MemTest86 directories:
Configuration directory: /etc/memtest86-efi/
Data directory: /usr/share/memtest86-efi/

MemTest86 is installed on your system with following parameters:
ESP device name: /dev/sdb1
ESP mount point: /boot
Type of installation: 3

sudo memtest86-efi -u 
ESP /dev/sdb1 is not mounted, mounting...
mount: /boot: special device /dev/sdb1 does not exist.
Fail to mount /dev/sdb1 on /boot. Aborted.

The EFI partition is not on /dev/sdb1, it's on /dev/nvme0n1p1. I have migrated this system (with dd, and reinstall Grub) from an older machine on which the EFI partition was on /dev/sdb1. I have however not noticed any problems with this before, and "sudo memtest86-efi -u" worked fine before this change. (Updating Grub has also worked flawlessly. Booting. And anything else.) EDIT: Can I just replace "partition=/dev/sdb1" with "partition=/dev/nvme0n1p1" in /etc/memtest86-efi/memtest86-efi.conf to solve this?

Xorg commented on 2022-01-31 18:46 (UTC)

@hamelg: Added in 600ab3bcaead, thanks.

hamelg commented on 2022-01-30 16:58 (UTC) (edited on 2022-01-30 17:00 (UTC) by hamelg)

the update hook doesn't work here because my efi partition is not permanently mounted. A check could be added in the memtest86-efi script.

diff --git a/memtest86-efi b/memtest86-efi
index 45a7fb7..4080189 100644
--- a/memtest86-efi
+++ b/memtest86-efi
@@ -211,6 +211,14 @@ update() {

                2|3|4) # Update files in $esp/EFI/memtest86/
+            ## Check if efi partition is mounted, if not mount it
+               if ! mount | grep "$partition" | grep -q "$esp"; then
+                       echo -e "ESP ${CB}$partition${CR} is not mounted, mounting..."
+                       if ! mount "$partition" "$esp"; then
+                               echo -e "${CE}Fail to mount $partition on $esp. Aborted.${CR}" > /dev/stderr
+                               exit $CODE_FATAL
+                       fi
+               fi
                        _common_install "$esp/EFI/memtest86" "memtest$ARCH.efi"

francoism90 commented on 2021-04-25 12:24 (UTC)

Just saying thanks, helped me a lot to identify faulty memory. :)

Rhinoceros commented on 2021-03-13 08:29 (UTC)

Hi, the latest pkgver bump is actually less than the previous one. You can test with vercmp.

$ vercmp 9.0 9.0build2000

This should give -1. You might have to bump epoch if you want to change your PKGBUILD versioning.

Xorg commented on 2021-02-21 20:41 (UTC)

@leuko: Thanks for your comment. I improved this behavior in 3d058842b163. It is a shame I never run shellcheck on this script before. :)

leuko commented on 2021-02-21 14:37 (UTC)

I had the following error after invoking memtest86-efi --install with EFI entry addition (2. option):

Add a new EFI boot entry...                                                                                          
invalid numeric value -w

The problem was that I provided the path for my md array. Providing the real device name (/dev/sda instead of /dev/md/mycomp:boot) fixed the issue.

Thank you for this package Xorg!

Xorg commented on 2020-05-17 10:38 (UTC)

@buzo: My bad, I forgot to push my commits...

Xorg commented on 2020-01-29 14:50 (UTC) (edited on 2020-01-29 14:50 (UTC) by Xorg)

@jakub: Ok. BTW, the script tries to mount the partition on the given mount point if the partition is not mounted.
The script has been improved thanks to your feedback.

jakub commented on 2020-01-26 19:25 (UTC)

@Xorg: it seems it's not mounted, which is quite strange as I've set mount point during installation. Anyway, I'll have to sort it out. Thx for hint!

Xorg commented on 2020-01-26 19:10 (UTC)

@jakub: No, it is not correct. Are you sure /dev/sda1 is mounted? You can check with mount | grep /dev/sda1.
Otherwise, you can enter the mount point manually.

jakub commented on 2020-01-26 19:02 (UTC) (edited on 2020-01-26 19:02 (UTC) by jakub)

➜  ~ sudo memtest86-efi --install
This script is unofficial, written by an AUR (Arch User Repository) user. Use it at YOUR OWN RISK.
Press Enter if /dev/sda1 is your ESP partition, else enter device path manually (like /dev/sdXY): 
Press Enter if  is your mount point, else enter mount point manually (like /boot/efi):

As you see script did not show anything as "mount point". Is this correct?

Xorg commented on 2019-09-11 07:00 (UTC)

@capoeira: then run memtest86-efi --install...

capoeira commented on 2019-09-10 23:00 (UTC)


the option doesn't apear for me:

"[studio@bahiahost ~]$ memtest86-efi Usage: memtest86-efi ACTION

Available ACTION: -i, --install Install MemTest86 in ESP -u, --update Update an existing installation of MemTest86 -r, --remove Remove MemTest86 from ESP -s, --status Print and return status -h, --help Print this help and exit -a, --about Print informations about memtest86-efi and exit "

Xorg commented on 2019-09-10 17:27 (UTC)

@capoeira: run the memtest86-efi command and follow instructions. You need to choose 3: Add a boot entry for GRUB2 menu in your case.

capoeira commented on 2019-09-10 09:47 (UTC)

So how can I add this to Grub?

Xorg commented on 2019-07-05 16:06 (UTC)

@nTia89: Ok, it is done.

nTia89 commented on 2019-07-05 10:22 (UTC)

Hi, you can update the URL field to use HTTPS protocol

Xorg commented on 2019-06-08 08:52 (UTC) (edited on 2019-06-08 08:53 (UTC) by Xorg)

As you probably know, the <> URL is likely to cause problems, like this error:

==> Validating source files with sha512sums... ... FAILED

To avoid this problem, I prefer to reupload archive somewhere else, where this kind of breakage will not appear.

I can't upload this archive on AUR directly (archive is 8 MB but AUR accepts 250 KiB maximum), so I decide to put this archive on my Git repository to avoid future breakages.

I hope it suits you.

darkbasic commented on 2019-06-08 07:30 (UTC)

==> Validating source files with sha512sums... ... FAILED memtest86-efi ... Passed memtest86-efi.conf ... Passed memtest86-efi-update.hook ... Passed memtest86-efi-remove.hook ... Passed ==> ERROR: One or more files did not pass the validity check! Error downloading sources: memtest86-efi

Did it break once again?

Xorg commented on 2019-06-03 15:22 (UTC)

@maxbla: Yes, it is due an upstream update. Fixed, thanks.

maxbla commented on 2019-06-03 06:37 (UTC) (edited on 2019-06-03 06:37 (UTC) by maxbla)

Package doesn't build. Presumably upstream shipped an update. I made it work in the meantime with makepkg --skipchecksums -si

==> Validating source files with sha512sums... ... FAILED
    memtest86-efi ... Passed
    memtest86-efi.conf ... Passed
    memtest86-efi-update.hook ... Passed
    memtest86-efi-remove.hook ... Passed
==> ERROR: One or more files did not pass the validity check!

Xorg commented on 2019-03-13 05:34 (UTC) (edited on 2019-03-13 05:37 (UTC) by Xorg)

@Sven: memtest86+ and memtest86-efi are not the same things.
The memtest86-efi script can produce a /etc/grub.d/86_memtest file (option 2: "Add a boot entry for GRUB2 menu").

So why does this one skip that?

memtest86+ is put under /boot and is not an EFI application.
memtest86-efi is put under $esp/EFI/memtest86/, where $esp is a variable that cannot be determined in a programmatic way (i.e. when you use bind).

This package is unofficial and produced by AUR community. If you have ideas to improve this package, feel free to share them with us.

Sven commented on 2019-03-12 22:56 (UTC)

This package should install a file to /etc/grub.d/ so that grub-mkconfig picks it up automatically. The memtest86+ package does that. So why does this one skip that?

zerophase commented on 2019-02-28 18:26 (UTC) (edited on 2019-02-28 18:27 (UTC) by zerophase)

@xiretza That issue is the responsibility of you. The package manager is not responsible for the maintenance of your system. Now, the package manager could have a version check that causes the PKGBUILD to fail, if the zip extracted does not have the right version of memtest86.

The proper solution in the cached package directory is:

makepkg -sric
rm -rf

Xorg commented on 2019-02-28 17:51 (UTC)

Ok, that's fixed (again).

xiretza commented on 2019-02-28 16:16 (UTC)

It's certainly not the best way, in fact I would say it's a lot worse than failing checksums.

As long as the PKGBUILD doesn't save the .zip with a versioned name, manual intervention (i.e. deleting the file from the package directory) is always required. The only difference is that if there's a checksum, you know you have to do this. If it's set to SKIP, the old file is simply used without even a warning, and the resulting package never changes. This is arguably more broken than a package that doesn't build because of a wrongly cached file.

The best solution would be to leave the checksum and download the file to a name that contains $pkgver, i.e.


This way, a checksum is always bound to a local file name (since they update at the same time in the PKGBUILD), and a broken checksum means both $pkgver and the checksum need to be updated.

buzo commented on 2019-02-27 14:34 (UTC)

Correct, but it is the best way to deal with the broken upstream. Someone should contact them to fix it.

Besides, there is memtest86+ in the community repo as an alternative.

ortango commented on 2019-02-27 14:30 (UTC)


isn't it the case that this pkgbuild will not download a new if it exists in the srcdest since the file isn't versioned?

so it will use the last version and extract from there. since you are now skipping the hash check it won't even fail. people will install the old version as the new version and never even know.

Xorg commented on 2019-02-27 12:19 (UTC)

@dude and @Popkornium18: Ok, done. Thank you for your advice.

Popkornium18 commented on 2019-02-27 10:46 (UTC)

@Xorg Checksum should definitely be 'SKIP' in that case. There is no point in having a checksum verification if it is always failing anyways.

dude commented on 2019-02-27 08:06 (UTC)

@Xorg maybe the sha512sum should be changed to 'SKIP' in that case, if it can't be reliably verified.

Xorg commented on 2019-02-26 23:29 (UTC) (edited on 2019-02-26 23:30 (UTC) by Xorg)

@ortango: It will not solve problem with sha512sums. Problem is upstream file is not versioned (, so it breaks sha512sums every time the file is changed (e.g. when a new version is available).
In my opinion, it is an upstream issue. I miss the old URL like <>$_pkgbasename-usb-$pkgver.$

ortango commented on 2019-02-26 20:25 (UTC) (edited on 2019-02-26 20:27 (UTC) by ortango)


do you have the zip cached in your SRCDEST folder? if so, delete it and try again.

maybe this package should name the source file like "" to avoid this.

Popkornium18 commented on 2019-02-26 19:49 (UTC) checksum still fails.

Xorg commented on 2019-02-26 12:02 (UTC)

@intartso: Ok, fixed, thanks.

BoostCookie commented on 2019-02-26 08:43 (UTC)

For me the sha512sum for fails.

Xorg commented on 2019-02-17 12:42 (UTC)

@ron2138: Mounting the loopback device requires to be root, but makepkg should never be run as root. From wiki:

Running makepkg itself as root is disallowed. Besides how a PKGBUILD may contain arbitrary commands, building as root is generally considered unsafe. Users who have no access to a regular user account should run makepkg as the nobody user.

So, no, sorry, I will not do changes in the PKGBUILD to allow to build this package as root.
If you have an alternative way to extract the .img file as regular user, why not.

ron2138 commented on 2019-02-17 12:17 (UTC) (edited on 2019-02-17 12:20 (UTC) by ron2138)

When there are root privileges, can the p7zip dependency eliminated with losetup, as in

Xorg commented on 2018-12-07 13:21 (UTC)

@feral_hedgehog: Fixed, thanks.

feral_hedgehog commented on 2018-12-07 13:05 (UTC)

I've been having issues with the grub entry install option after the latest update. The 86_memtest file that gets created under /etc/grub.d isn't executable and is missing a backslash before the '$' in the if-statement, which prevents the entry from being added to grub.

Xorg commented on 2018-07-05 19:14 (UTC) (edited on 2018-12-07 09:41 (UTC) by Xorg)

@park0kyung0wo: I would say no. Software cannot damage hardware, but overheat and brutal shutdowns can.

park0kyung0won commented on 2018-07-04 20:53 (UTC)

Oh I see thanks for the reply

I'm asking for I do not know much about low level efi things, Can efi firmwares like memtest damage my hardware?... I hope not :(

Xorg commented on 2018-07-04 16:12 (UTC) (edited on 2018-07-04 16:12 (UTC) by Xorg)

@park0kyung0won: I'm sorry, I can't help you: it's not a packaging issue.

If you shutdown your computer safely under MemTest86, it may be an upstream bug.

I suggest you to contact PassMark Support[3] or try MemTest86 forum[4].



park0kyung0won commented on 2018-07-04 12:02 (UTC)


I have encountered a problem while using this package. I installed this memtest86-efi package, with option of adding entry to systemd-boot list. I aborted memtest in the middle(no particular reason, I couldn't wait), and booted back to Arch Linux. Then I got an error from S.M.A.R.T that my nvme SSD device has been degraded, which Arch Linux is installed. I had one "Media and Data Integrity Errors" on S.M.A.R.T record of that nvme SSD drive.

I was curious so I've conducted tests. Everytime I do memtest, that "Media and Data Integrity Errors" count increased by one, and that integrity error made status of my nvme SSD degraded. So I highly suspect this memtest was a cause...

buzo commented on 2018-02-27 19:33 (UTC)

Looks good, thanks for the quick fix!

Xorg commented on 2018-02-27 19:09 (UTC) (edited on 2018-02-27 19:10 (UTC) by Xorg)

Ok, done in following commit: a1c4551125f1

Tell me if you encounter issue. And if you have a better idea than p7zip to extract .img file...

Xorg commented on 2018-02-27 18:16 (UTC)

@buzo: Try to delete the ISO file by yourself.

Ok, switched from md5sums to sha512sums. I found an upstream FTP, but that is the USB version, ISO seems not present: I'll investigate.

buzo commented on 2018-02-27 13:49 (UTC)

Now I get a validity check error because memtest86-efi-7.5-1-x86_64.pkg.tar.xz is still there, so makepkg does not download the new version. This is broken. I think the file should be renamed after download. (And upstream should add a version number to the file name.)

And I agree, MD5 is outdated and not secure. Please switch to a modern hash (sha256sum for instance) while you are at it.

Xorg commented on 2018-02-27 12:12 (UTC)

@xiretza: Thank for your report. It would be the same issue with sha512sums... md5sums updated.

xiretza commented on 2018-02-27 11:15 (UTC)

There's been another build with the exact same version number and no separate download (great release system...), which invalidates the md5sum (you might want to change that to something cryptographically secure like sha512sums).

Xorg commented on 2017-12-15 07:12 (UTC)

@yi22588: Not exactly. You can't run .efi file on Arch (or on any OS). The memtest86-efi script provides a way to run this .efi file by your UEFI or your bootloader (GRUB2 and systemd-boot are supported).

For instance, I've chosen to add a new boot entry in my UEFI to launch MemTest86. Screenshot:

Your ESP is /dev/sda1. What's wrong with it?

yi22588 commented on 2017-12-05 01:09 (UTC)

@Xorg: Thanks for reply. So this package provides people to run .efi file right?

The command output: /dev/sda1 1 15567 125034839+ ee EFI GPT

Xorg commented on 2017-11-30 17:01 (UTC)

@yi22588: This package doesn't allow you to run MemTest86 on Arch. This package provides an EFI executable. If you want to run this executable, it must be placed in ESP in order to be usable by UEFI. memtest86-efi is an interactive script written by myself to help people do to this stuff. Can you paste 'fdisk -l | grep EFI' command output please?

yi22588 commented on 2017-11-30 08:09 (UTC)

@moll I type ./memtest86-efi -i Is it a right move? and if I can't mount ESP, I can't use this package right?

moll commented on 2017-11-30 07:47 (UTC)

@yi22588: Ensure the bootx64.efi file this package installs somewhere (I think it was /usr...) is copied to /boot and boot to it with your favorite bootloader. Arch's Wiki may help configuring your bootloader and where exactly to put it.

yi22588 commented on 2017-11-30 05:38 (UTC)

Can someone tell me how to use this package?

Xorg commented on 2017-09-04 09:29 (UTC)

@moll: Only tested for my SATA device... Stupid naming convention for NVMe devices. With the last patch, seems good for both SCSI and NVMe naming.

moll commented on 2017-09-04 08:30 (UTC)

Yay. However, have you tested it? I haven't yet, but a quick glace at hints it uses a replacement pattern to strip out non-numbers which will fail for, let's say, the 3rd partition on the first NVMe disk on the first controller: $ partition=/dev/nvme0n1p3; echo ${partition//[^0-9]/} 013 Also the latter `${partition//$partnumber}` is not a reliable approach if the controller and disk numbers happen to match. I think the right way would be to pattern match from the right and assume only the last numeric component is the partition.

Xorg commented on 2017-09-04 08:18 (UTC)

@moll: Sorry for delay, it's fixed now.

moll commented on 2017-08-24 17:49 (UTC) (edited on 2017-08-24 17:49 (UTC) by moll)

Xorg: I don't remember the exact error at the moment, but if you look at the install script, it uses Bash string indexing that assumes the disk name is always 8 characters. for example. You can immediately see that the disk name `/dev/nvme0n1` gets cut off at `/dev/nvm` which is not right. ;)

Xorg commented on 2017-08-17 13:11 (UTC)

@moll: Install script is provided by myself. Can you paste your error, please?

moll commented on 2017-08-14 13:49 (UTC)

Hey, Thanks for the package. I'm not sure where to report this, but the install script fails for non 8-character disks like NVMe, whose 1st partition gets assigned /dev/nvme0n1p1.

zerophase commented on 2017-02-28 04:07 (UTC)

The latest update fixes booting from EFI boot into memtest86, on Asus mobos.

zerophase commented on 2017-01-03 10:35 (UTC)

This is what I use. [Trigger] Operation = Install Operation = Upgrade Type = Package Target = memtest86-efi [Action] Depends = coreutils When = PostTransaction Exec = /usr/bin/cp /usr/share/memtest86-efi/bootx64.efi /boot/EFI/tools/memtest86.efi It needs that name, and needs to be in that folder for rEFInd to detect memtest86.

Xorg commented on 2017-01-03 06:29 (UTC)

Sorry for delay. I have added hooks. Please tell me if you see something wrong.

nTia89 commented on 2016-12-17 09:52 (UTC)

@Xorg, your work is amazing and yes in this case will bring "only" a simplified and more ordered file anyhow, it would be a proof of concept and it will bring this package into the new pacman's hook era

Xorg commented on 2016-12-16 08:09 (UTC)

What is the problem with .install file? :( Ok, I'll try to write a hook, but I'm not sure it will change anything.

zerophase commented on 2016-12-14 15:00 (UTC)

I have a pacman hook I can toss up. Been using it so refind can find the binary.

nTia89 commented on 2016-12-14 10:38 (UTC)

do you plan to switch from .install script to a pacman hook?

Maniaxx commented on 2016-10-03 18:50 (UTC)

Yes, that should work as well but only affects one substitution per backslash whereas single quotes disable it globally (whole cat). I'm not sure why you choose that more error prone way (especially as you don't need substitution at all in the cat process) but its your decision. See Example 19-7. Parameter substitution turned off:

Xorg commented on 2016-10-03 15:23 (UTC)

Yes, I understand that, that's why I think using [ "\$grub_platform" = "efi" ] should fix this problem. [ "x" = xefi ] is a nonsense, it should be always false.

Maniaxx commented on 2016-10-02 20:36 (UTC)

What i wanted to tell you is that this exactly happened here. Your script just copied this line: [ "x" = xefi ] and thus broke the condition completely in grub.cfg so the entry could never appear. I'm aware how that x comparison works. It started working properly once the single quotes around EOF were set.

Xorg commented on 2016-10-02 16:01 (UTC) (edited on 2016-10-02 16:02 (UTC) by Xorg)

@Maniaxx: Ok, after looking files in /etc/grub.d, I've added missing shebang. cat <<EOF is used is these scripts (I've removed training space before EOF). 'EOF' is not used. In "x${grub_platform}", 'x' is useless. Should be "\$grub_platform" according to other scripts. Changes are pushed. I don't increase pkgrel, due to memtest86-efi script doesn't update configuration.

Maniaxx commented on 2016-09-30 01:31 (UTC) (edited on 2016-09-30 20:02 (UTC) by Maniaxx)

The '86_memtest' script probably should start with #!/bin/sh like all the other scripts in /etc/grub.d (it works anyway though) and there's a bug in the first line (missing single quotes): cat << EOF should be: cat << 'EOF' Otherwise [ "x${grub_platform}" = xefi ] results in [ "x" = xefi ] as ${grub_platform} gets expanded at cat runtime from local environment (that is not set). The single quotes make sure that the text gets copied literally.

zerophase commented on 2016-08-08 16:16 (UTC)

This issue applies to Haswell E chips as well.

Xorg commented on 2016-08-08 13:01 (UTC)

Fixed. Bump to 7.1 and use HTTP instead HTTPS.

gableroux commented on 2016-08-08 03:07 (UTC) (edited on 2016-08-08 03:13 (UTC) by gableroux)

Following commit added https: According to jamesan comment, I'd revert the commit to use the working http method until it gets fixed on their server. I tried to play around and see if it works, but makepkg fails (md5 changed). When extracting memtest86-7.0.iso.tar.gz, I get Memtest86-7.1.iso. md5 for memtest86-7.0.iso.tar.gz is the same as memtest86-7.1.iso.tar.gz I managed to fix it by upgrading to 7.1 at the same time: git revert 705fb5c1c1769fd0d53aa097dde36c3fc83449c9 + following patch: diff --git a/.SRCINFO b/.SRCINFO index 9668a77..5caeb36 100644 --- a/.SRCINFO +++ b/.SRCINFO @@ -1,8 +1,6 @@ -# Generated by mksrcinfo v8 -# Wed Jul 27 18:04:51 UTC 2016 pkgbase = memtest86-efi pkgdesc = A free, thorough, stand alone memory test as an EFI application - pkgver = 7.0 + pkgver = 7.1 pkgrel = 1 url = install = memtest86-efi.install @@ -14,12 +12,12 @@ pkgbase = memtest86-efi optdepends = efibootmgr: to add a new EFI boot entry optdepends = grub: to add MemTest86 entry in GRUB2 menu backup = etc/memtest86-efi/memtest86-efi.conf - source = memtest86-7.0.iso.tar.gz:: + source = memtest86-7.1.iso.tar.gz:: source = memtest86-efi source = memtest86-efi.conf source = grub.conf source = systemd-boot.conf - md5sums = c709d3147295defc50e3f2b0e779a88e + md5sums = ed0ffd04d2d9ce72fc2a9fd871ebdd98 md5sums = 6d78d97e54e9feb75e3b1f835297ffd8 md5sums = 6c096df3f55baf3e27c3bd605a418aa2 md5sums = f848ecf41edb2d95f469ff2251bcfa4a diff --git a/PKGBUILD b/PKGBUILD index 4fce194..407fb13 100644 --- a/PKGBUILD +++ b/PKGBUILD @@ -2,7 +2,7 @@ _pkgbasename=memtest86 pkgname=$_pkgbasename-efi -pkgver=7.0 +pkgver=7.1 pkgrel=1 pkgdesc="A free, thorough, stand alone memory test as an EFI application" arch=('i686' 'x86_64') @@ -18,7 +18,7 @@ source=("$_pkgbasename-$pkgver.iso.tar.gz::$_ "memtest86-efi.conf" "grub.conf" "systemd-boot.conf") -md5sums=('c709d3147295defc50e3f2b0e779a88e' +md5sums=('ed0ffd04d2d9ce72fc2a9fd871ebdd98' '6d78d97e54e9feb75e3b1f835297ffd8' '6c096df3f55baf3e27c3bd605a418aa2' 'f848ecf41edb2d95f469ff2251bcfa4a'

jamesan commented on 2016-07-28 16:48 (UTC)

The HTTPS URL to the ISO tarball no longer works. The non-secure HTTP URL works though:

zerophase commented on 2016-07-27 22:13 (UTC)

Odd, I'm getting stuck at "Testing multiprocessor support" when booting up with rEFInd.

samcv commented on 2016-07-27 20:34 (UTC) (edited on 2016-07-27 20:34 (UTC) by samcv)

Change the PKGBUILD to use http instead of https. Looks like they disabled their https server... Weird. Anyway I guess it has to be switched back.

zerophase commented on 2016-07-27 20:27 (UTC)

When trying to download I receive curl: (35) error:140770FC:SSL routines:SSL23_GET_SERVER_HELLO:unknown protocol

Xorg commented on 2016-07-27 18:08 (UTC)

@samcv: Yes, because the tarball is not versionned... It's updated, and it uses HTTPS now, thank you.

samcv commented on 2016-07-23 11:23 (UTC) (edited on 2016-07-23 11:29 (UTC) by samcv)

When I download I get an md5sum of c709d3147295defc50e3f2b0e779a88e not 87c0fb1338183b5eaf11096d1d2f0475 as is listed in the PKGBUILD. Edit: Looks like it is downloading version 7.0. If you change pkgver=7.0 and pkgrev=0 it works fine. In addition would you change the source of the file to use 'https'? The server supports it and it would be nice for peace of mind. Thanks!

Xorg commented on 2016-06-01 08:04 (UTC)

@bryanparadis: Patched, thank you.

bryanparadis commented on 2016-06-01 00:20 (UTC)

Option 3) during the install is broken for me. It seems the /etc/memtest86-efi/grub.conf is incorrect. I have fixed it myself by wrapping the content in cat << EOF --snip-- EOF

Xorg commented on 2016-04-15 10:23 (UTC) (edited on 2016-04-15 10:24 (UTC) by Xorg)

@zman0900: Yes, sorry, in latest patch, I have changed how --status works, but I have forgotten to change help message. If MemTest86 is installed, it displays "MemTest86 is installed on your system with following parameters:" in bold. Don't worry about exit status, it is used in memtest86-efi.install file. It returns 1 if not installed (e.g. error), or 0 if installed. I have modified help now.

zman0900 commented on 2016-04-15 00:41 (UTC)

Help says "-s, --status Return status (1 if installed, else 0)", but when I run that it returns 0 even though it is already installed for systemd-boot.

nTia89 commented on 2016-04-09 17:42 (UTC)

@Xorg: thank you again, good work!

Xorg commented on 2016-04-09 10:55 (UTC)

@nTia89: Ok, instead of writing config files with "echo", I have added these files in source. It should be better. In fact, "memtest86-efi --status" works, it was only a return status (see help) used by memtest86-efi.install. But I have changed this, it shows some information now. :)

nTia89 commented on 2016-04-08 10:47 (UTC)

@Xorg: Oh, what a dumb I am! never, never, never work up to midnight because these are the results... anyway, now it works perfectly I want to point out two things: 1- I created a patch file ( with the right spaces; I know, I am pedant but now it's perfectly compliant with other configuration files. 2- memtest86-efi --status doesn't work... I get no output

Xorg commented on 2016-04-08 06:40 (UTC)

@nTia89: Ok, I have adjusted spaces. And I have fixed this issue. I had copy/paste your config, but in fact the path is /EFI/memtest86/memtestx64.efi (without the "86"). It should be better now. Try to run "memtest86-efi --remove" and then "memtest86-efi --install" after updating to memtest86-efi-6.3.0-4.

nTia89 commented on 2016-04-07 20:21 (UTC) (edited on 2016-04-07 20:23 (UTC) by nTia89)

@Xorg: thank you for your rapid reply. I installed new version and then executed the script. I have to point out two things: 1- adjust spaces in the new .conf, in order to get a perfect alignment: title****MemTest86 efi******/EFI/memtest86/memtest86x64.efi 2- and more important, unfortunately it doesn't work... but I don't know why! menu entry is correctly shown but when I choose it, I get: "Error loading ... .efi not found" I attach some photos: NB: my suggestion was previously read from our wiki:

Xorg commented on 2016-04-07 18:18 (UTC)

@nTia89: Of course, it's a good idea. It's done. :) Thank for these helpful information.

nTia89 commented on 2016-04-07 11:02 (UTC) (edited on 2016-04-07 12:26 (UTC) by nTia89)

@Xorg: Hi, first thanks for your work! I want to install memtest86-efi in my system; I use systemd-boot, that, in a few words, could be a menu for EFI applications. This means memtest86-efi files could be installed in ${esp}/EFI/memtest86/, as you already do for the choice number 2; but instead adding a firmware entry using `efibootmgr` you need to add a systemd-boot menu entry, that is a configuration file in the ${esp}/loader/entries/ which contains two lines: e.g. memtest86-efi.conf: #1 title MemTest86 #2 efi /EFI/memtest86/memtest86-x64.efi NB: I called `memtest86-efi` the configuration file and I used `x64` for example Can you provide feedback and then add it to your script?

Xorg commented on 2016-01-30 19:06 (UTC)

@mar77i: I will add unifont.bin in /usr/share/memtest86-efi, if it can help you. @bosyi: I will add efibootmgr as an optdepends, and also grub. I need to review this script. :)

bosyi commented on 2016-01-28 19:06 (UTC)

Add as dependency 'efibootmgr'. Add a new EFI boot entry... /usr/bin/memtest86-efi: line 48: efibootmgr: command not found

mar77i commented on 2016-01-25 10:37 (UTC)

This package doesn't work as installed here. I resolved a problem where running memtest would result in a black screen by reading the log and adding unifont.bin to my /boot from the iso. Not sure how much the issue is a packaging one, though.

Xorg commented on 2015-09-01 16:48 (UTC)

@esrevinu: changes applied, thanks.

esrevinu commented on 2015-09-01 16:39 (UTC)

Choice 3 doesn't work. My modification of script memtest86-efi is on

Xorg commented on 2015-09-01 08:32 (UTC)

@hackepeter: You have removed your comments, but I have still your 4 mails. I have updated the GRUB script, thank for you help.

Xorg commented on 2015-06-18 17:33 (UTC)

@Commander: I have added a configuration file for GRUB2. Run script 'memtest86-efi -i' and select option 3. Please report if it doesn't work.

Xorg commented on 2015-06-17 08:26 (UTC)

No, sorry. This package only provides files, and I have added a script to add a boot entry. I think you can copy files in your ESP, but I don't know how to configure GRUB to boot on MemTest86. But if there is a way, I can improve the package.

Commander commented on 2015-06-16 23:38 (UTC)

Is there any grub2 config for /etc/grub.d ?

Xorg commented on 2015-06-06 15:56 (UTC)

Oops sorry, this hardcoded version number is a bit ugly. Fixed, thanks.

tuborg commented on 2015-06-06 14:44 (UTC)

Thanks for the updates. Small typo - the iso is explicitly listed in the PKGBUILD, and still is for 6.0.0. Change that to "Memtest86-6.1.0.iso" and it installs fine.

Xorg commented on 2015-03-16 16:30 (UTC)

@pabs: I think it's ambiguous. Let me explain: - Here (, you can read that MemTest86 is «free to download with no restrictions on usage». - Download the ISO and mount it; there is a tarball called "src.tgz". Inside, you can find source files under GPL2 license. I've added the PassMark® EULA in package, but I think GPL2 is not wrong. And 'bash' was missing in dependency, it's needed to run my custom install script.

pabs commented on 2015-03-16 05:52 (UTC)

memtest86-efi is proprietary, not GPL2, can someone fix that?

Xorg commented on 2015-02-21 14:12 (UTC)

memtest86-efi-beta has been merged into memtest86-efi.

Xorg commented on 2014-11-02 14:23 (UTC)

MemTest86 is available in version 6.0 beta 1. I have made a new package: memtest86-efi-beta ( It is possible to install both memtest86-efi and memtest86-efi-beta.

Xorg commented on 2014-06-01 10:50 (UTC)

Ok, I see that. Problem is from upstream, I think developpers forgot to change it.

prMoriarty commented on 2014-05-31 18:52 (UTC)

in the lower left corner of the application is written 5.0 and in log: MemTest86 V5.0 Free Build: 1000 (64-bit)

Xorg commented on 2014-05-20 19:02 (UTC)

It is 5.1.0. Look in ISO, file "guide.pdf". But on the official website, there is only the "latest version", so when I change pkgver, it doesn't change source. If you have an URL with version, I want it. Thank.

prMoriarty commented on 2014-05-20 18:40 (UTC)

memtest86 writes that version is 5.0

Xorg commented on 2013-11-15 19:42 (UTC)

Ok, problem is solved. Thanks a lot.

awh commented on 2013-11-13 19:17 (UTC)

# memtest86-efi --install /usr/bin/memtest86-efi: line 110: conditional binary operator expected /usr/bin/memtest86-efi: line 110: syntax error near `;' /usr/bin/memtest86-efi: line 110: ` -u|--update) update; exit 0;;'