Updated: February 22, 2017
The problem you are facing is as follows. You have a multi-boot system with several instances of different operating systems, mostly Linux. You have recently installed a Red Hat distro, like Fedora, the Fedora derivative Chapeau, CentOS or alike, and you want it to be in charge of the GRUB2 bootloader sequence. So far so good.
However, when you try to boot an entry other than the above distro, you get a weird error that says: error: can't find command 'linux' and error: can't find command 'initrd'. This effectively breaks your system. What now? Let's fix it.
First of all, this issue applies to systems with UEFI, and only those that are not booting in the legacy mode. The reason for this failure is very simple, but it may look horrid to the untrained eye. In newer systems with the EFI implementation, the old MBR method no longer applies. The mechanism and the locations are slightly different, and so are the tools that manage the bootloader.
Specifically, you have a special FAT-32 formatted partition, which gets mounted as /boot/efi, and it contains the EFI images needed to start your distro. Think of this as a tiny ext2 partition that you used for /boot with LVM and alike in the past.
The location of the GRUB2 configuration file is also different, as I've written in my GRUB2 tutorial update recently. The file is now located under /boot/efi/EFI/<os>/grub.cfg. This means if you want to update the config file, on non-Debian systems, you will need to run:
grub2-mkconfig -o /boot/efi/EFI/<os>/grub.cfg
The tools that manage GRUB2, i.e. GRUB tools, also have their own specific EFI implementation, and these packages also need to be installed on your system to actually allow you to create valid, EFI-supported GRUB2 configuration files, so that you can actually boot on new, modern hardware. And therein lies our problem.
I encountered this while testing Chapeau 24, a new wannabe Fuduntu, a spin of Fedora that comes with all the goodies out of the box. Except several critical packages that would make it fully EFI compatible. Namely, the distro is missing EFI modules, without which you cannot generate valid GRUB2 config files.
But wait, let us not just blame Chapeau. Because the same problem occurred while I was testing Fedora 25, so there are really no excuses. This is naughty behavior, and it needs to be fixed. Amateurish work for the likes of Fedora.
Invalid files = invalid commands. Indeed, in EFI systems, the linux and initrd commands, which are used to load the kernel and the initramfs are replaced with linuxefi and initrdefi commands. Check your GRUB2 config file, I bet it only has linux and initrd directives. For example:
linux /boot/vmlinuz-4.7.4-200.fc24.x86_64 root=UUID=ed3fb745-2168-4cb8-91c0-d1b09b68fdf4 ro rhgb quiet
Hence the error we saw earlier, when you try to boot them:
error: can't find command 'linux'
error: can't find command 'initrd'
What we need to do is install the necessary EFI modules and then re-generate the config file. But since the distro may have a wrong type of implementation, you will actually have to generate the config file twice, but let's do it step by step. First, install the missing stuff (substitute dnf for yum, depending on your distro):
dnf install grub2-efi-modules
Then, generate the config (twice) - this is because your distro may not be conforming to the proper EFI specification, and it will be going to the classic location for its config file, and this whole thing is just wild and broken. But never mind that.
grub2-mkconfig -o /boot/grub2/grub.cfg
grub2-mkconfig -o /boot/efi/EFI/<os>/grub.cfg
Check that you have the right menu. Then entries mentioned earlier should have linux and initrd commands replaced with linuxefi and initrdefi. Reboot, and you should be up and running.
linuxefi /boot/vmlinuz-4.7.4-200.fc24.x86_64 root=UUID=ed3fb745-2168-4cb8-91c0-d1b09b68fdf4 ro rhgb quiet
The other side of the coin of this problem is that for Fedora-like systems, the bootloader may only pick the rescue kernel, and not the valid production kernels, so you may end up in a rescue console. This is a bug, and should be fixed. To wit, you will have something like below, and only the first instance will be chained in the menu. You can work around this by manually fixing the grub.cfg file, or creating symbolic links, similar to what openSUSE does, where vmlinuz and initrd always point to the last set of files. I really do not understand why this isn't a standard in all distributions. Also, if you do this manually, remember to make the necessary change after every kernel update. But overall, this is yet another regression in the big Linux world.
-rw-------. root ... initramfs-0-rescue-...5a3d90d85.img
-rw-------. root ... initramfs-4.6.3-300.fc24.x86_64.img
-rw-------. root ... initramfs-4.6.6-300.fc24.x86_64.img
-rw-------. root ... initramfs-4.7.9-200.fc24.x86_64.img
If you are planning on multi-booting with Red Hat distros, then you need to remember your specific one might not come with all the goodies to make this experience smooth and simple. I don't know why, but please remember this, so you can plan accordingly. The issue isn't big, but it may annoy you. Alternatively, just set a different distro to be in charge of your boot plan.
I hope you learned something new today. Do not be afraid of big error messages, they may often hide simple problems, like neglect and bad QA or a botched EFI setup. Plus you now know a little more around GRUB2 and how it works with new systems. Not terrifying, just a bit more complex, like everything else created post 2012, with too much object-oriented nonsense and/or Python. Have fun, children of the Internet.