Grub - refind and EFI partition/mount

bricem13 · 23 April 2025 17:25

Hi all

1st post here so short presentation and intro to my issues.

I am former arch user. I had it in dual boot for long and was quite satisfied except few late kernel issues and outdated AUR packages.
I decided to test Xubuntu and dropped it 1-2 days later to reinstall arch.
I could not get arch properly with refind (very very strange as I did as usual the refind-install).
So I ended in a mess and accidentally format the EFI partition (yup big big mistake). I choose to install manjaro as a good stable arch flavor and so far I like it a lot.

However I still have a mess with the bootloader.

So I installed manjaro, with grub, I mount my EFI partition on /boot/efi (with the boot flag) and could recover a working linux.

From there I copied the W-bootmanager in /boot/efi/EFI/Microsoft/Boot/.

Then I installed refind and ran refind-install.

It worked strangely till yesterday, I had at refind start:

W bootloader
a linux penguin icon
2 manjaro icons (one pointing to grub
the traditional reboot - shutdown… of refind

the penguin was not starting anything. F2 yields just an initramd without and root

I tried a couple of refind-install again (the file refind-linux.conf seemed correct) without any more success.

Now I had to re-install manjaro in order to boot with grub but I am afraid or re-installing refind and having again a mess.

The /boot folder is strangely populated:

[TuxBox boot]# tree -d
.
├── efi
│   └── EFI
│       ├── boot
│       ├── Manjaro
│       ├── Microsoft
│       │   └── Boot
│       ├── refind
│       │   ├── drivers_x64
│       │   ├── icons
│       │   │   └── svg
│       │   ├── icons-backup
│       │   │   └── svg
│       │   ├── keys
│       │   └── vars
│       └── tools
├── grub
│   ├── fonts
│   ├── locale
│   ├── themes
│   │   └── starfield
│   └── x86_64-efi
└── memtest86+

23 directories
[TuxBox boot]#

there are kernels in different directories:

/boot
/boot/efi

The directory /boot/efi/EFI/Manjaro/ contains grubx64.efi.

The /boot/efi/EFI/refind is an obvious reminiscent of previous installation.

So in short, I need your help!!

best regards
Brice

Teo · 23 April 2025 18:53

For the efi partition you need boot and esp flags.
Kernels have no place in efi, in general.

Other than that it doesn’t look so bad at all.
I guess you did not mount properly the efi (and grub installer did not find it or something similar but you are sparing us the logs)
Have you just tried the wiki for grub reinstall?

Refind and grub can happily coexist, you will just have both in your bios list. And in refind you will have 2 manjaro icons, one for chainloading grub and one for kernel. Other than that it is not a problem to have both.

bricem13 · 23 April 2025 19:06

the tree is from a fresh install with formatted /.

So it created the kernel in /boot/efi …

So far grub seems to work correctly, except it does not detect Win (for which I still have to recover the bootloader correctly).

The EFI partition has both boot and esp flags.

[TuxBox boot]# ls -l
total 173497
-rw-r--r-- 1 root root    153600 Mar 18 18:25 amd-ucode.img
drwx------ 3 root root       512 Jan  1  1970 efi
drwxr-xr-x 6 root root      4096 Apr 23 18:41 grub
-rw------- 1 root root 134787969 Apr 23 18:41 initramfs-6.12-x86_64-fallback.img
-rw------- 1 root root  19200773 Apr 23 18:40 initramfs-6.12-x86_64.img
-rw-r--r-- 1 root root   9683968 Feb 11 18:09 intel-ucode.img
-rw-r--r-- 1 root root        22 Apr  1 20:45 linux612-x86_64.kver
drwxr-xr-x 2 root root      4096 Apr 14 18:59 memtest86+
-rw-r--r-- 1 root root       350 Apr 23 21:07 refind_linux.conf
-rw-r--r-- 1 root root  13804032 Apr 14 18:59 vmlinuz-6.12-x86_64
[TuxBox boot]# ls -l efi/
total 166725
drwx------ 7 root root       512 Apr 23 21:08 EFI
-rwx------ 1 root root 130792344 Apr 21 21:40 initramfs-linux-fallback.img
-rwx------ 1 root root  14880690 Apr 21 21:40 initramfs-linux.img
-rwx------ 1 root root   9683968 Feb 11 18:09 intel-ucode.img
-rwx------ 1 root root  15368704 Apr 21 21:39 vmlinuz-linux
[TuxBox boot]#

in /boot/efi, the files are from April 21… I don’t catch that

After installing refind, I still have the penguin pointing to vmlinuz from EFI partition…

Aragorn · 23 April 2025 19:42

Not if one uses grub, no, but refind does require the kernels to be copied over to the $esp.

Teo · 23 April 2025 21:55

In any case those kernels in the efi have generic names, so they are not from manjaro but remnants from another OS. Which explains the penguin icon that does not do anything. Remove them.

linux-aarhus · 24 April 2025 06:46

That is normal when you have windows as option

The penguin is usually pointing to the kernel image located at /boot

The manjaro icons is because there is the grub loader - the manjaro loader and the fallback manjaro loader.

Systemd loader is red shield with a couple of arrows - what that means I have no idea
Grub is with Manjaro icon
Fallback is with Manjaro icon
The default is with Penguin icon
What the entry points to is shown beneath the rEFInd options below the icons.

When you mention AUR remember that Manjaro is not Arch - to use AUR you need to switch to Manjaro unstable branch and do a full system sync

sudo pacman-mirrors -aS unstable
sudo pacman -Syu

On my thinkpad x13 (no windows) I have systemd loader and two manjaro and the penguin.

The efi partition is 0xEF00 - $esp partition type

I am not particularly fond of rEFInd - just installed to know a little if someone should ask

You can use the Del to hide items you don’t want to see.

soundofthunder · 24 April 2025 08:27

rEFInd doesn’t require this at all.
Kernels have no place on an $ESP, nor on a vfat filesystem.

This is an illusion.

Note that /boot/efi is a mountpoint to the $ESP/EFI directory. From your output, the tree command is simply following that mountpoint to the $ESP.

This output is likely the result of having run tree -d from within the /boot directory.

$ESP: The EFI System Partition (ESP).
/boot/efi: Mountpoint to $ESP/EFI.
/boot: Parent directory containing Grub related files.

For the sake of illustration, to reach the $ESP/EFI directory via the commandline, both the directory and the mountpoint must be included, like this;

sudo ls /boot/efi/EFI

Likewise, to ask for a directory of $ESP/EFI/manjaro;

sudo ls /boot/efi/EFI/manjaro

or, the fallback location $ESP/EFI/BOOT;

sudo ls /boot/efi/EFI/BOOT

Aragorn · 24 April 2025 11:56

Then I am getting refind mixed up with systemd-boot, but I am pretty certain that one of them requires it.

And of course, if you use a kernel which is directly booted by the UEFI through the efistub code in the compressed kernel binary, then this kernel does also need to live on the $esp, because the UEFI cannot read a non-Microsoft filesystem — the Macintosh EFI can of course read hfsplus.

soundofthunder · 24 April 2025 17:54

Possibly.

I haven’t a clue about systemd-boot, except that it’s apparently easy to setup, and some seem to prefer it with encrypted volumes.

bricem13 · 24 April 2025 18:14

deleting the files in /boot/efi removed the penguin in refind, now: WIN + 2 times Manjaro and the refind options

Seems ok.

Question: can I safely remove grub and do I need to delete some stuff associated to it in /boot ?

soundofthunder · 24 April 2025 18:52

I’ve seen that claim made before, and to the extent that any filesystem must be readable to allow booting via the efi stub, it is valid.

If there were no EFI (.efi) specific drivers available for other filesystems, I’d have to agree that rEFInd would also have that limitation.

But there are;

Free Software: EFI/UEFI file system drivers

I suppose it’s not common knowledge.

Most users of rEFInd will never need to know, because support for booting the EFI stub is already built in, and an EFI filesystem driver for EXT4 is provided within the rEFInd directory heirarchy;

$ESP/EFI/refind/drivers_x64/ext4_x64.efi

or, in my case;

$ESP/EFI/BOOT/drivers_x64/ext4_x64.efi

because I moved rEFInd to the fallback location where it cannot be accidentally overwritten with (most) Linux tools (install-grub is safe to use).

This is taken from Rod Smith’s site and sums it up quite well:

To have rEFInd find Linux boot files on a BTRFS filesystem, the btrfs_x64.efi driver from the above link could be used, for example.

That said (and for non-rEFInd-related reasons), some might prefer to create a separate /boot partition as EXT4 when setting up their BTRFS systems.

Aragorn · 24 April 2025 19:04

I’ve done that. I use grub, but grub has problems with btrfs as well — and with xfs, for that matter.

soundofthunder · 24 April 2025 19:30

Which files, specifically, did you delete?
Can you please provide the output of:

sudo tree /boot/efi/EFI

Removing GRUB is not recommended.

One of the reasons for using rEFInd is to chainload the GRUB instances for whichever Linux flavours are installed in a multi-boot configuration.

While rEFInd allows to boot the efi stub directly (in the kernel), this should not be relied upon as your sole method of booting a Linux OS.

Teo · 24 April 2025 21:48

The ubuntu remnants i guess (initramfs withouth a number).

I would not remove grub. Keep it as a backup, and to be sure that all updates will function in the future. It is such a long aged default that it might be some script somewhere assuming it is present and crash something if it does not find it.

Me personally, i have a copy of refind and a uefi shell on the esp, one of them at the fallback. That saved me the need of usb stick once after a bios update wiped the os entries. I just had to guess where / and : keys are since the uefi shell uses US keyboard by default.

I tested refind but it added about 10 seconds to my boot time and even after a lot of play with the config file i could not get it to start under 5 seconds so i returned back to grub happily appearing after less then a second.

soundofthunder · 25 April 2025 02:41

I had no problem; but then, I’ve had some time to tweak the configuration to my liking.

It’s a simple setting; mine is set to: timeout 5;

(where timeout is expressed in seconds).

0 disables automatic boot
-1 boots the default OS without a timeout.

I have mine set to boot the previously booted OS, if I don’t interrupt it; the + positioned first achieves this:

default_selection "+,OpenCore,Microsoft,vmlinuz"

This works no matter how I might shuffle the disks around.

bricem13 · 25 April 2025 06:30

Here it is:

[brice@TuxBox:~]$ sudo tree /boot/efi/EFI
/boot/efi/EFI
├── boot
│   └── bootx64.efi
├── Manjaro
│   └── grubx64.efi
├── Microsoft
│   └── Boot
│       └── bootmgfw.efi
├── refind
│   ├── BOOT.CSV
│   ├── drivers_x64
│   │   └── ext4_x64.efi
│   ├── icons
│   │   ├── arrow_left.png
│   │   ├── arrow_right.png
│   │   ├── boot_linux.png
│   │   ├── boot_win.png
│   │   ├── func_about.png
│   │   ├── func_bootorder.png
│   │   ├── func_csr_rotate.png
│   │   ├── func_exit.png
│   │   ├── func_firmware.png
│   │   ├── func_hidden.png
│   │   ├── func_install.png
│   │   ├── func_reset.png
│   │   ├── func_shutdown.png
│   │   ├── mouse.png
│   │   ├── os_arch.png
│   │   ├── os_artful.png
│   │   ├── os_bionic.png
│   │   ├── os_centos.png
│   │   ├── os_chakra.png
│   │   ├── os_chrome.png
│   │   ├── os_clover.png
│   │   ├── os_crunchbang.png
│   │   ├── os_debian.png
│   │   ├── os_devuan.png
│   │   ├── os_elementary.png
│   │   ├── os_endeavouros.png
│   │   ├── os_fedora.png
│   │   ├── os_freebsd.png
│   │   ├── os_frugalware.png
│   │   ├── os_gentoo.png
│   │   ├── os_gummiboot.png
│   │   ├── os_haiku.png
│   │   ├── os_hwtest.png
│   │   ├── os_kubuntu.png
│   │   ├── os_legacy.png
│   │   ├── os_linuxmint.png
│   │   ├── os_linux.png
│   │   ├── os_lubuntu.png
│   │   ├── os_mac.png
│   │   ├── os_mageia.png
│   │   ├── os_mandriva.png
│   │   ├── os_manjaro.png
│   │   ├── os_netbsd.png
│   │   ├── os_network.png
│   │   ├── os_opensuse.png
│   │   ├── os_redhat.png
│   │   ├── os_refind.png
│   │   ├── os_refit.png
│   │   ├── os_slackware.png
│   │   ├── os_suse.png
│   │   ├── os_systemd.png
│   │   ├── os_trusty.png
│   │   ├── os_ubuntu.png
│   │   ├── os_uefi.png
│   │   ├── os_unknown.png
│   │   ├── os_void.png
│   │   ├── os_win8.png
│   │   ├── os_win.png
│   │   ├── os_xenial.png
│   │   ├── os_xubuntu.png
│   │   ├── os_zesty.png
│   │   ├── svg
│   │   │   ├── boot_win.svg
│   │   │   ├── func_csr_rotate.svg
│   │   │   ├── mouse.svg
│   │   │   ├── os_clover.svg
│   │   │   ├── os_debian.svg
│   │   │   ├── os_devuan.svg
│   │   │   ├── os_elementary.svg
│   │   │   ├── os_gummiboot.svg
│   │   │   ├── os_haiku.svg
│   │   │   ├── os_legacy.svg
│   │   │   ├── os_mac.svg
│   │   │   ├── os_netbsd.svg
│   │   │   ├── os_redhat.svg
│   │   │   ├── os_refind.svg
│   │   │   ├── os_refit.svg
│   │   │   ├── os_win.svg
│   │   │   ├── os_xenial.svg
│   │   │   ├── tool_fwupdate.svg
│   │   │   ├── tool_memtest.svg
│   │   │   └── tool_rescue.svg
│   │   ├── tool_apple_rescue.png
│   │   ├── tool_fwupdate.png
│   │   ├── tool_memtest.png
│   │   ├── tool_mok_tool.png
│   │   ├── tool_netboot.png
│   │   ├── tool_part.png
│   │   ├── tool_rescue.png
│   │   ├── tool_shell.png
│   │   ├── tool_windows_rescue.png
│   │   ├── transparent.png
│   │   ├── vol_efi.png
│   │   ├── vol_external.png
│   │   ├── vol_internal.png
│   │   ├── vol_net.png
│   │   └── vol_optical.png
│   ├── icons-backup
│   │   ├── arrow_left.png
│   │   ├── arrow_right.png
│   │   ├── boot_linux.png
│   │   ├── boot_win.png
│   │   ├── func_about.png
│   │   ├── func_bootorder.png
│   │   ├── func_csr_rotate.png
│   │   ├── func_exit.png
│   │   ├── func_firmware.png
│   │   ├── func_hidden.png
│   │   ├── func_install.png
│   │   ├── func_reset.png
│   │   ├── func_shutdown.png
│   │   ├── mouse.png
│   │   ├── os_arch.png
│   │   ├── os_artful.png
│   │   ├── os_bionic.png
│   │   ├── os_centos.png
│   │   ├── os_chakra.png
│   │   ├── os_chrome.png
│   │   ├── os_clover.png
│   │   ├── os_crunchbang.png
│   │   ├── os_debian.png
│   │   ├── os_devuan.png
│   │   ├── os_elementary.png
│   │   ├── os_endeavouros.png
│   │   ├── os_fedora.png
│   │   ├── os_freebsd.png
│   │   ├── os_frugalware.png
│   │   ├── os_gentoo.png
│   │   ├── os_gummiboot.png
│   │   ├── os_haiku.png
│   │   ├── os_hwtest.png
│   │   ├── os_kubuntu.png
│   │   ├── os_legacy.png
│   │   ├── os_linuxmint.png
│   │   ├── os_linux.png
│   │   ├── os_lubuntu.png
│   │   ├── os_mac.png
│   │   ├── os_mageia.png
│   │   ├── os_mandriva.png
│   │   ├── os_manjaro.png
│   │   ├── os_netbsd.png
│   │   ├── os_network.png
│   │   ├── os_opensuse.png
│   │   ├── os_redhat.png
│   │   ├── os_refind.png
│   │   ├── os_refit.png
│   │   ├── os_slackware.png
│   │   ├── os_suse.png
│   │   ├── os_systemd.png
│   │   ├── os_trusty.png
│   │   ├── os_ubuntu.png
│   │   ├── os_uefi.png
│   │   ├── os_unknown.png
│   │   ├── os_void.png
│   │   ├── os_win8.png
│   │   ├── os_win.png
│   │   ├── os_xenial.png
│   │   ├── os_xubuntu.png
│   │   ├── os_zesty.png
│   │   ├── svg
│   │   │   ├── boot_win.svg
│   │   │   ├── func_csr_rotate.svg
│   │   │   ├── mouse.svg
│   │   │   ├── os_clover.svg
│   │   │   ├── os_debian.svg
│   │   │   ├── os_devuan.svg
│   │   │   ├── os_elementary.svg
│   │   │   ├── os_gummiboot.svg
│   │   │   ├── os_haiku.svg
│   │   │   ├── os_legacy.svg
│   │   │   ├── os_mac.svg
│   │   │   ├── os_netbsd.svg
│   │   │   ├── os_redhat.svg
│   │   │   ├── os_refind.svg
│   │   │   ├── os_refit.svg
│   │   │   ├── os_win.svg
│   │   │   ├── os_xenial.svg
│   │   │   ├── tool_fwupdate.svg
│   │   │   ├── tool_memtest.svg
│   │   │   └── tool_rescue.svg
│   │   ├── tool_apple_rescue.png
│   │   ├── tool_fwupdate.png
│   │   ├── tool_memtest.png
│   │   ├── tool_mok_tool.png
│   │   ├── tool_netboot.png
│   │   ├── tool_part.png
│   │   ├── tool_rescue.png
│   │   ├── tool_shell.png
│   │   ├── tool_windows_rescue.png
│   │   ├── transparent.png
│   │   ├── vol_efi.png
│   │   ├── vol_external.png
│   │   ├── vol_internal.png
│   │   ├── vol_net.png
│   │   └── vol_optical.png
│   ├── keys
│   ├── refind.conf
│   ├── refind.conf-sample
│   ├── refind_x64.efi
│   └── vars
│       └── PreviousBoot
└── tools
    ├── Benchmark
    ├── blacklist.cfg
    ├── mt86.png
    ├── shellx64.efi
    └── unifont.bin

15 directories, 205 files
[brice@TuxBox:~]$

Under arch, I only had refind, no need for Grub and so far was working fine.

soundofthunder · 25 April 2025 09:20

Yes, that seems fine.

Your previous description wasn’t too specific, so it’s good to know you didn’t delete anything major.

That may be the case.

However, you might be greatly inconvenienced if there is ever an issue with rEFInd that prevents booting the efi stub.

The only options to recover would be to boot via a Manjaro ISO and enter a chroot environment to reinstall rEFInd or copy the necessary files manually. When multi-booting, especially, I wouldn’t want to limit my options unecessarily.

Nonetheless, you are the administrator of your machine, and ultimately the choice is yours.

The ideal procedure to remove GRUB is probably via package management (pacman). Make certain you have booted using the efistub, or any other method that isn’t GRUB, before committing.

Regards.

j8a · 25 April 2025 17:14

Hi @bricem13,
I reach to the same conclusion as @soundofthunder after watching this video:
‘https://www.youtube.com/watch?v=logJKbMOfa0’

Hope it helps,
Regards,

bricem13 · 27 April 2025 18:29

thank all for the replies! all OK now

Aragorn · 27 April 2025 18:42

Please mark the post that solved your problem — or that set you on your way to solving it — as the solution.