Before you trust a downloaded EFI binary or a rebuilt kernel, grub-file can tell you whether GRUB even recognises its type. It reports through its exit status alone, so it slots into a shell script without touching the file or the bootloader.
Allow about ten minutes. You need the grub-file command from the grub-common package and a readable file to inspect. These examples use GRUB 2.12-1ubuntu7.3, installed on Ubuntu. Reading an ordinary file is unprivileged: do not use this command as a reason to run a whole script with sudo.
Start with the command's own help. This is read-only and needs no elevated privileges:
$ command -v grub-file
/usr/bin/grub-file
$ dpkg-query -W -f='${Package} ${Version}\n' grub-common
grub-common 2.12-1ubuntu7.3
$ grub-file --help | sed -n '1,4p'
grub-file (GRUB) 2.12-1ubuntu7.3
Usage: file OPTIONS FILE
Check if FILE is of specified type.
The usage line says file, but the installed executable is grub-file. That is a quirk of this generated help text, not a second command to run. The local manual lists the available checks and the -h, --help, -u and --usage options. There is no --version option, so use the package query or the first line of --help when recording the version.
Checkpoint: if command -v finds nothing, install or repair the package through your normal system administration process. Do not copy a similarly named binary from an untrusted location.
Every check has the form grub-file OPTION FILE. The option states the type you want to test, for example:
--is-x86_64-efi tests an x86_64 EFI file.--is-x86-linux tests an x86 Linux kernel.--is-x86-bios-bootsector tests a BIOS boot sector.--is-x86-multiboot and --is-x86-multiboot2 test the two x86 Multiboot formats.The manual also provides checks for ARM, ARM64, IA64, MIPS, MIPSEL, SPARC64 and PowerPC Linux files, several Xen and BSD kernel formats, EFI files for several architectures, hibernation images, XNU kernels and other boot-related formats. Pick the architecture and format deliberately: a file name, directory or distribution label does not prove that the contents have that type.
Use the long option exactly as shown. Shell quoting is useful when the path contains spaces or begins with a character that could confuse a larger wrapper:
$ grub-file --is-x86_64-efi '/path/to/EFI/ubuntu/grubx64.efi'
This command prints nothing on success. It does not repair, convert, sign, install or copy the file.
Run a check and save $? immediately. A status of zero means the file matched the requested type. A non-zero status does not always mean the same thing: status 1 is a normal negative result, while other statuses can point to an input or processing problem.
$ grub-file --is-x86_64-efi /usr/lib/grub/x86_64-efi/monolithic/grubx64.efi
$ printf 'exit status: %s\n' "$?"
exit status: 0
$ grub-file --is-x86_64-efi /usr/lib/grub/i386-pc/boot.img
$ printf 'exit status: %s\n' "$?"
exit status: 1
The first installed GRUB image is an x86_64 EFI file. The second is an i386 PC BIOS image, so a failed x86_64 EFI test is the expected answer here, and there is no diagnostic output for either result. In a script, branch on the status rather than trying to parse standard output:
$ candidate='/path/to/candidate.efi'
$ if grub-file --is-x86_64-efi "$candidate"; then
> printf '%s\n' 'x86_64 EFI file'
> else
> status=$?
> if [ "$status" -eq 1 ]; then
> printf '%s\n' 'not an x86_64 EFI file'
> else
> printf 'grub-file could not inspect the file, status %s\n' "$status" >&2
> exit "$status"
> fi
> fi
Checkpoint: test the option against a file whose type you already know. A successful command with the wrong option is not evidence that the file is suitable for your machine.
Permissions are checked before file classification. A missing path, for example, produces an error and a non-zero status:
$ grub-file --is-x86-linux /path/to/missing-kernel
grub-file: error: cannot open `/path/to/missing-kernel': No such file or directory
$ printf 'exit status: %s\n' "$?"
exit status: 1
Do not confuse that error with a clean type mismatch. Check the path and readability without changing anything:
$ ls -l -- /path/to/candidate
$ test -r /path/to/candidate && printf '%s\n' 'readable'
Some boot files are deliberately readable only by root. If the path is correct but access is denied, establish whether your account should have access before reaching for elevated privileges. If you have an approved reason to inspect it, elevate only the single command:
$ sudo grub-file --is-x86-linux /path/to/protected-kernel
$ printf 'exit status: %s\n' "$?"
Warning: a password prompt, status 7 or another access error is not a type result. Do not loosen permissions on a kernel or EFI file just to make a check convenient, and do not run a downloaded file to determine its type; grub-file reads it as data only.
grub-file is a classifier, not a complete boot validation tool. A matching EFI result does not prove that firmware will find it, that Secure Boot will accept its signature, that its configuration is correct, or that the target architecture is the one your machine uses. A matching Linux result does not prove the kernel has the required modules, initramfs or command-line settings either.
Keep this check separate from commands that write to the ESP, alter GRUB configuration or install a bootloader. Those operations can make a system unbootable and may need a recovery path. Run grub-file first, record its status, then carry out the change only under your normal change-control process. This guide changes no persistent state, so there is nothing to undo when a check returns 1.
If you do not know which test applies, ask for the complete installed list and select one option from it:
$ grub-file --help | sed -n '1,80p'
Do not infer support from a newer GRUB guide or from another host. Option availability can vary with the installed package, and this Ubuntu build reports its own supported checks. For a repeatable deployment script, test the exact package image used by that deployment and treat an unknown option as a script error.
grub-file and grub-common versions.