You are not logged in.
To preface, I have read the rEFInd page and I've been using Arch for the better part of four years and I've never faced this issue just following the default instructions and using refind-install. This is my first time using it in a dual-boot system though.
As the title suggests, rEFInd shows Tux instead of the Arch Logo. It's not the issue suggested on section 7.3 of the rEFInd page.
Here's how rEFInd looks:
https://i.imgur.com/O2lYkh6.png
refind.conf: Note that the entries are "disabled" because I haven't done anything to it except use the default and add a theme, but that's irrelevant
#
# refind.conf
# Configuration file for the rEFInd boot menu
#
# Timeout in seconds for the main menu screen. Setting the timeout to 0
# disables automatic booting (i.e., no timeout). Setting it to -1 causes
# an immediate boot to the default OS *UNLESS* a keypress is in the buffer
# when rEFInd launches, in which case that keypress is interpreted as a
# shortcut key. If no matching shortcut is found, rEFInd displays its
# menu with no timeout.
#
timeout 20
# Whether to store rEFInd's rEFInd-specific variables in NVRAM (1, true,
# or on) or in files in the "vars" subdirectory of rEFInd's directory on
# disk (0, false, or off). Using NVRAM works well with most computers;
# however, it increases wear on the motherboard's NVRAM, and if the EFI
# is buggy or the NVRAM is old and worn out, it may not work at all.
# Storing variables on disk is a viable alternative in such cases, or
# if you want to minimize wear and tear on the NVRAM; however, it won't
# work if rEFInd is stored on a filesystem that's read-only to the EFI
# (such as an HFS+ volume), and it increases the risk of filesystem
# damage. Note that this option affects ONLY rEFInd's own variables,
# such as the PreviousBoot, HiddenTags, HiddenTools, and HiddenLegacy
# variables. It does NOT affect Secure Boot or other non-rEFInd
# variables.
# Default is true
#
use_nvram false
# A sample entry for a Linux 3.13 kernel with EFI boot stub support
# on a partition with a GUID of 904404F8-B481-440C-A1E3-11A5A954E601.
# This entry includes Linux-specific boot options and specification
# of an initial RAM disk. Note uses of Linux-style forward slashes.
# Also note that a leading slash is optional in file specifications.
menuentry Linux {
icon EFI/refind/icons/os_linux.png
volume 904404F8-B481-440C-A1E3-11A5A954E601
loader bzImage-3.3.0-rc7
initrd initrd-3.3.0.img
options "ro root=UUID=5f96cafa-e0a7-4057-b18f-fa709db5b837"
disabled
}
# Below is a more complex Linux example, specifically for Arch Linux.
# This example MUST be modified for your specific installation; if nothing
# else, the PARTUUID code must be changed for your disk. Because Arch Linux
# does not include version numbers in its kernel and initrd filenames, you
# may need to use manual boot stanzas when using fallback initrds or
# multiple kernels with Arch. This example is modified from one in the Arch
# wiki page on rEFInd (https://wiki.archlinux.org/index.php/rEFInd).
menuentry "Arch Linux" {
icon /EFI/refind/icons/os_arch.png
volume "Arch Linux"
loader /boot/vmlinuz-linux
initrd /boot/initramfs-linux.img
options "root=/dev/nvme0n1p2 rw add_efi_memmap initrd=/boot/intel-ucode.img"
submenuentry "Boot using fallback initramfs" {
initrd /boot/initramfs-linux-fallback.img
}
submenuentry "Boot to terminal" {
add_options "systemd.unit=multi-user.target"
}
disabled
}
lsblk:
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS
nvme1n1 259:0 0 1.8T 0 disk
├─nvme1n1p1 259:3 0 1G 0 part /boot
├─nvme1n1p2 259:4 0 16M 0 part
└─nvme1n1p3 259:5 0 1.8T 0 part
nvme2n1 259:1 0 1.8T 0 disk
nvme0n1 259:2 0 1.8T 0 disk
├─nvme0n1p1 259:6 0 32G 0 part [SWAP]
├─nvme0n1p2 259:7 0 512G 0 part /
└─nvme0n1p3 259:8 0 1.3T 0 part /home
I'm not sure what might be causing this. My suspicion is that it's because of my how OS's are separated across the drives:
nvme1 contains the ESP and windows whereas nvme0 contains Linux. nvme2 is just an identical third drive.
moderator edit -- replaced oversized image with link.
Pasting pictures and code
Last edited by happysamoyed (2023-08-03 22:39:37)
Offline
refind use some heuristics to determine the distro for the kernel for the automatically detected kernels (I think it is not reading the file itself for it). I know it use folder name and partition label as part of the ways for it.
Offline
rEFInd will automatically choose the Arch Linux icon (os_arch.png) for the boot entry when /etc/os-release is on the same partition as the kernel. If your /boot is a separate partition see Configuring the Boot Manager: Setting OS Icons.
A simple solution would be to set the /dev/nvme1n1p1 file system label to "Arch boot".
Offline
It looks like your rEFInd is reading the boot_linux.png icon. Another solution is just rename the arch logo os_arch.png in /efi/EFI/refind/icons to boot_linux.png. You can just rename the Tux logo to another name.
Offline
https://wiki.archlinux.org/title/rEFInd#For_kernels_automatically_detected_by_rEFInd wrote:rEFInd will automatically choose the Arch Linux icon (os_arch.png) for the boot entry when /etc/os-release is on the same partition as the kernel. If your /boot is a separate partition see Configuring the Boot Manager: Setting OS Icons.
A simple solution would be to set the /dev/nvme1n1p1 file system label to "Arch boot".
Unfortunately this doesn't work as it changes both icons to the Arch icon.
Offline
I think my larger issue is that it's booting into the Linux Kernel (vmlinuz) instead of booting into "Arch Linux" and I'm not exactly sure if that's a problem or not.
Offline
Unfortunately this doesn't work as it changes both icons to the Arch icon.
Right, I missed that you're dual-booting.
In that case, copy os_arch.png to /boot/vmlinuz-linux.png.
Offline
happysamoyed wrote:Unfortunately this doesn't work as it changes both icons to the Arch icon.
Right, I missed that you're dual-booting.
In that case, copy os_arch.png to /boot/vmlinuz-linux.png.
This seems to fix it, thank you.
Offline
@happysamoyed: which filesystem do you use?
In case of Btrfs have a look at this Thread:
https://bbs.archlinux.org/viewtopic.php?id=289313
Offline