rEFInd is designed to automatically remove certain redundant entries. One of these redundancies is shimx64.efi, if grubx64.efi is also present. Thus, your statement that "[i]t should be grub64.efi and shim64.efi" is not correct, unless you created a manual boot stanza for one or both of these files.
In your case, you've got three entries:
grubx64.efi -- This is the GRUB binary that Ubuntu installed. Selecting it launches GRUB, which loads the Linux kernel and boots it using the GRUB boot loader mechanism for the Linux kernel. GRUB may present its own menu or not, depending on its configuration. This menu is likely to include options for all your Linux kernels, and perhaps for other OSes or special functions. If you don't select any option from the GRUB menu, it probably launches the latest (currently 3.13.0-52) kernelvm-linuz-3.13.0.32-generic.efi.signed -- This option loads the 3.13.0-32 Linux kernel, which is the kernel that ships with Ubuntu 14.04 LTS (the version released in April of 2014). rEFInd launches the kernel as if it were an EFI application, relying on the EFI stub loader as a boot loader and bypassing GRUB.vm-linuz-3.13.0-52-generic.efi.signed -- This option is just like the preceding one, except that it launches the more up-to-date 3.13.0-52 kernel, which includes bug fixes and new features collected over the past year.
As a practical matter, you should use whatever works best for you. In most cases, the GRUB option and the rEFInd option for the latest kernel will result in systems that function identically by most measures. There may be some tiny differences, like a slightly different Command line: line in your dmesg output, but these will have no practical effects. Depending on your GRUB configuration and the contents of /boot/refind_linux.conf, there could be other differences, such as graphical vs. text-mode startup messages; or in extreme cases one might boot and the other might not. A direct kernel boot is likely to be easier to fix if something goes wrong, because GRUB can be complex and difficult to debug. Also, if you want to boot an older kernel for some reason, doing so from the rEFInd menu may be a little easier than doing it from GRUB, especially if GRUB is configured to boot without showing you its own menu. OTOH, if there's no /boot/refind_linux.conf file or if it's misconfigured, GRUB might boot properly where rEFInd's direct kernel launch might fail or set things up sub-optimally.
As you continue to use and upgrade the system, you may see additional direct kernel options appear in rEFInd's menu. You can manually uninstall kernels you know you're not going to use; or typing sudo apt-get autoremove in a Terminal will remove all but three of them (usually the original kernel and the two most recent ones). It's generally a good idea to keep at least two kernels around. The reason is that kernel bugs are sometimes introduced, so you want to have the option of booting back to an older kernel in case you run into such a problem.
If you want to remove options you're not using from rEFInd's display, you can do so in various ways:
- You can use the
dont_scan_volumes, dont_scan_dirs, and dont_scan_files options in refind.conf (usually in /boot/efi/EFI/refind/ from Ubuntu). These options remove particular boot loaders from the menu based on locations or filenames without actually deleting them.
- You can set
scan_all_linux_kernels false in refind.conf. This will cause rEFInd to ignore Linux kernels that lack .efi extensions. (Note that your kernels have .efi.signed extensions, which will be ignored with this option set to false.)
- You can remove the EFI driver for the filesystem on which your kernel resides. This driver is usually in
/boot/efi/EFI/refind/drivers_x64 from Linux. Removing this driver will remove all of the direct Linux boot options.
- You can delete the files entirely. This is not an option if you want to remove the entries that directly boot the Linux kernel, since GRUB needs those files to boot Linux; but you might consider it if you don't want to see the GRUB option or if something else is showing up (say, an old Windows boot entry for a Windows installation you've deleted). Most boot entries will show up in subdirectories of
/boot/efi/EFI/ under Ubuntu, but some may be elsewhere.
If you've got precisely the three entries you described, if you were to remove the direct-kernel entries, you'd probably be better off bypassing rEFInd and using GRUB directly -- after all, there's little point to having a boot manager with just one boot option. Removing the GRUB entry might make some sense, but having it available is also worthwhile in case you run into a problem with the EFI stub loader down the line.
