Ok maybe there’s the problem.
Inside my boot folder there is an empty efi folder. That’s it.
I didn’t check that section of the guide because it was optional and was meant to add special entries, which I didn’t think I needed.
This means that your ESP is not mounted properly (or at all).
Check your fstab to see details of ESP (/boot/efi) and mount it before proceeding with refind installation and configuration.
Read the wiki guide carefully. It’s all there.
It seems that it’s not automatic for extra cases. Each user/system is different, so do what is needed for yours.
If it’s in fstab, whouldn’t it be mounted automatically?
Also, would doing refind-install --usedefault /dev/sdXY (replacing sdxy with my partition) be a bad idea? From what I’m reading it looks like it should do the trick.
Also, in fstab the efi partition is listed to mount on /boot/efi as following:
UUID=F3AC-AD23 /boot/efi vfat umask=0077 0 2
I checked with lsblk -f and the partition in question is this:
sda1 vfat FAT32 NO_LABEL F3AC-AD23 508,3M 1% /boot/efi
Things seems to check out on that side.
Also, the efi folder can’t be accessed actually, it’s not that it’s empty.
cd: permission denied: /boot/efi
However, the partition is already mounted there.
mount: /boot/efi: /dev/sda1 already mounted on /boot/efi.
If you don’t want to boot via rEFInd into grub you should run
# mkrlconf
in order to create a /boot/refind_linux.conf. Have a look at the created file, and change the command lines to your need. In additon, you could adjiust the dont_scan_dirs parameter in $esp/EFI/refind/refind.conf in order to omit the grub loaders like this
dont_scan_dirs SYSTEM:EFI/Boot,EFI/EndeavourOS/,EFI/Microsoft,EFI/Microsoft/Boot,EFI/ubuntu,EFI/Void
where $esp is your esp partition, e.g. /boot/efi.
After a reboot you should see an additional entry in the rEFInd screen which is created via the /boot/refind_linux.conf.
If you want to hide those grub entries from refind, you can do so to not accidentally use grub. If you have an unusual partition/subvolume layout you can update your ESP:EFI/refind/refind.conf
ie:
also_scan_dirs ESP:EFI/boot,ESP:EFI,@/boot,@Arch/boot,@Archcraft/boot,@Fedora/boot,@EndeavourOS/boot,@Garuda/boot,@GarudaWayfire/boot,@Manjaro/boot,@Ubuntu/boot,@Debian/boot
You can define the boot entries you want generated in your /boot/refind_linux.conf
"Boot with standard options" "root=UUID=9efeede0-772b-4de5-879d-5911e938fd91 rw rootflags=subvol=@Arch/@ quiet splash loglevel=3 nvme_load=YES nvidia-drm.modeset=1 initrd=@Arch\@\boot\amd-ucode.img initrd=@Arch\@\boot\initramfs-%v.img"
"Boot to single-user mode" "root=UUID=9efeede0-772b-4de5-879d-5911e938fd91 rw rootflags=subvol=@Arch/@ quiet splash loglevel=3 nvme_load=YES nvidia-drm.modeset=1 single initrd=@Arch\@\boot\amd-ucode.img initrd=@Arch\@\boot\initramfs-%v.img"
"Boot to terminal" "root=UUID=9efeede0-772b-4de5-879d-5911e938fd91 rw add_efi_memmap initrd=@Arch\@\boot\amd-ucode.img initrd=@Arch\@\boot\initramfs-%v.img systemd.unit=multi-user.target"
I don’t mind grub being an option, I can hide it and use it if I ever for some reason need to. It’s the fact that the option to boot the os directly isn’t there. When I get home I will try mkrlconf and hopefully that will help getting the option to show up. 3 more hours of work to go before I go home.
Part of the problem is that the efi folder is somehow locked and can’t be accessed
Just sudo edit the file in terminal. Sudo micro or vim
Not possible. It just won’t happen.
Even trying to create it with sudo failed.
I see above that you had a cd failed with permission denied. But I didn’t see mention of trying to edit the file, actually.
sudo micro /boot/efi/EFI/refind/refind.conf should work fine if you have your ESP mounted there. Unless you mounted it at /efi or somewhere else.
When my computer starts refind shows two options, neither has an endeavouros logo, which I’d love to have but it’s not a big deal.
You can copy an icon into your /boot directory that matches the name of the vmlinuz file to match the created entry if it doesn’t auto detect the OS icon. With numbered kernels this can be annoying to maintain, but with arch you should have linux,linux-zen, etc that you set and forget.
vmlinuz-linux-zen.png
vmlinuz-linux.png
fstab listed it as there, so I think it SHOULD be there.
Forgive my ignorance, why would it be possible to edit the file if I can’t even see the content of the folder? I will try to do as you suggest this evening after work but while I’m sitting here, doing nothing, because saturday shifts are dead as hell, I may as well ask question to potentially learn something.
Also, I did move the png file there, still didn’t get the icon on refind, but I will double check everything this evening and report back.
It just the permissions of the mount location that require superuser to see and edit the contents. I dont know how yours is set up, but mine is set with a umask 0077 so only root can view and modify, no one else has access.
Oooh… That makes sense, thank you khaneliman.
I look forward to check the file tonight at home, very kind of ya.
You were absolutely right, the conf file is indeed there.
As I was typing the command to open it in a text editor I pressed tab to autocomplete, and when it didn’t autocomplete I assumed there was nothing, so good news! I learned something!
Thank you!
So in theory, if my work exahusted brain is understanding things right, I should add the following line:
extra_kernel_version_strings linux-hardened,linux-zen,linux-lts,linux
Am I misunderstanding things again?
If you want to boot from the vmlinux-linux image using rEFInd you just need to download an icon that is .png that you want to use and rename it to vmlinuz-linux.png if you are using the standard current kernel. Then copy it to the boot folder. Then when you boot the Icon should show in rEFInd. This is the simplest way. If you are using other kernels it gets more complicated.
Edit: I don’t need to edit the rEFInd .conf file to do this.
Hi ricklinux, thanks for the post
I may have done something wrong I reckon, this is the content of my boot folder:
The endeavouros png file is there and is named as it should, if I understand correctly.
So does it not show up in rEFInd?
Edit: You may also need one for the lts kernel.
vmlinuz-linux-lts.png
Also icons that you do not need in rEFInd you hide by using the del key such as grub if you don’t want to boot from the grubx64.efi file.
I was really hopeful but that didn’t do the trick either, adding another png file for lts that is.
I’m not sure what your problem is?
Edit: Did you make a bunch of changes to the .conf file? I don’t use it. (No changes)
Looks exactly as I have set up for a functioning os image for a refind boot entry. vmlinuz-linux.png, vmlinuz-linux-lts.png, and vmlinuz-linux-zen.png if you want all to have icons. The only config option related to icons in the refind.conf is related to where to find icons to use when auto detecting installations.
http://www.rodsbooks.com/refind/configfile.html#icons
In addition to hiding boot loaders, you can adjust their icons. You can do this in any of seven ways for auto-detected boot loaders:
- You can name an icon file after your boot loader, but with an extension of .icns, .png, .bmp, .jpg, or .jpeg depending on the icon’s format. For instance, if you’re using loader.efi, you might name the icon file loader.png. (If you use the scan_all_linux_kernels option, you can give an icon for a Linux kernel without a .efi extension a name based on the kernel name but with an appropriate extension—for instance, bzImage-5.4.0.png will serve as the icon for the bzImage-5.4.0 kernel.)
- If you’re booting macOS from its standard boot loader, or if you place a boot loader file for any OS in the root directory of a partition, you can create a file called .VolumeIcon.icns, .VolumeIcon.png, .VolumeIcon.bmp, .VolumeIcon.jpg, or .VolumeIcon.jpeg that holds an icon file. MacOS uses the .VolumeIcon.icns file for its volume icons, so rEFInd picks up these icons automatically, provided they include appropriate bitmaps.
- You can place a boot loader in a directory with a name that matches one of rEFInd’s standard icons, which take names of the form os_name.icns or os_name.png. To use such an icon, you would place the boot loader in the directory called name. For instance, the boot loader in the EFI/freebsd directory will use rEFInd’s os_freebsd.png icon.
- You can give the filesystem from which the boot loader is loaded a name that matches the OS name component of the icon filename. For instance, if you call your boot filesystem CentOS, it matches the os_centos.png icon. This match is performed on a word-by-word basis within the name, with “words” being delimited by spaces, dashes (-), colons (:), and underscores (_). Thus, a volume called Debian-boot will match os_debian.png or os_boot.png.
- You can give the GPT partition from which the boot loader is loaded a name that matches the OS name component of the icon filename. This works much like the previous method, except that you’d use a tool like gdisk or parted to set the partition’s name, rather than tune2fs or GParted to set the filesystem’s name. Note that rEFInd ignores some common default partition names (namely Microsoft basic data, Linux filesystem, and Apple HFS/HFS+) when implementing this rule, since other rules are likely to produce more accurate results.
- rEFInd attempts to guess the Linux distribution based on data in the /etc/os-release file. This file will only be accessible if a separate /boot partition is not used, though. Manually adjusting the os-release file to change an OS icon in rEFInd is not recommended.
- Certain boot loaders have hard-coded icons associated with them. For instance, filenames beginning with vmlinuz or bzImage acquire the Linux “Tux” icon and the bootmgfw.efi loader acquires a Windows icon. Fedora and Red Hat kernels can be identified by the presence of .fc or .el strings in their filenames, and so acquire suitable icons automatically. For the most part, these are the associations you want to overcome with the preceding rules, but sometimes renaming a boot loader to a more conventional name is the better approach. Renaming a locally-compiled kernel so that it acquires a Fedora or Red Hat icon is reasonable, but I don’t recommend renaming precompiled kernels unless you also manually copy them to the ESP.
Did you at least get the booting functionality working correctly now?