I can run the very basic 'auto' rEFInd session, but would LOVE to understand deeper issues

[alan999]

Apologies if this is a long post - I wanted to explain the things I've tried and my understanding thus far, which may help reduce the need to ask me for further info on the way to a solution :)

I have my Linux system up and running (where I'm writing this) so it all works at one level. But, being not simply a 'tinkerer' but someone who uses Linux precisely because we can fret away at all the tiny things, I'm not at all satisfied at the fact that rEFInd just boots a very basic config and in the process:

does not and WILL NOT select the correcty os_xxxx.png for me. Yep, I've done the hacky thing of renaming os_arch.png to os_linux.png and if that were the only thing, well maybe I could live with it. But it isn't.

I should point out that this is my first time installing Linux on UEFI. I'd been running on a very old mainboard that was mft/GPT hybrid, so got very used to grub2. I'm fairly okay with installation, but I've had to read A LOT of new documentation to get this all up and running. However I have - and which is why I'm now posting here... because "I just don't understand why it won't work (as I want)" hahaha... I'm sure we've all been there!

I load an Arch Linux live iso via USB, and get into the shell. I completely clear the internal drives. I go for the SSD for system, creating a new GPT label:

Primary partition /dev/sda1 is 200mB EFI formatted. Changed the label to "EFS" because of later lack of success. Thought my issues might be down to that (it used "EFI" by default).

/dev/sda2 ext 4, now labelled "Arch Linux"

/dev/sda3 is swap space.

I mounted /dev/sda1 into /boot (obviously that's mount /dev/sda1 /mnt/boot during install.

I mounted all my drives, wrote the correct /etc/fstab.

Booted into the finished install I ran refind-install and it found my EFI partition etc. wrote out the correct files and config. I can boot from the graphical menu having edited out the references to the USB iso (as per your docs).

But this default boot, and which is the ONLY one I can make work, has this "linux" file system icon, and of course I DETEST it simply saying "vmlinuz-linux" at me, when I really want to make a dedicated menu stanza to include fallback, and tty options (and because I want to include some suspend ACPI stuff).

Can confirm that it/Arch is perfectly happy with with /boot/EFI/refind/ installation structure. According to the Arch wiki putting rEFInd elsewhere means manual updating later. I've done the complete install (from bare bones) up to DE three times now! I changed things, tried different configs to see if it made a difference. It didn't.

Then I went very carefully through refind.conf itself, taking careful note of the well documented sections, and editing accordingly. Currently I use graphical boot, simply because booting on an SSD text mode is so fleeting, and the only message I can detect is one telling me it's reading the contents of refind_linux.conf correctly. As far as I'm aware I have NO issues at all with the original manufacturer of the mainboard. This is a machine sold with Windows 10 installed. However, while the UEFI interface itself is a fancy graphical one (Gigabyte H81M-DS2V. bios H81M v5), and is themed in Windows blue colours, I did completely wipe my SSD for install - I created a new GPT label, so destroyed anything on the disk. I've also fiddled with those UEFI bios settings, and am confident that there's no coup in effect. For example I have set uefi_deep_legacy_scan off so that IIRC it means the machine won't attempt to store last boot details in NVRAM but will ask me again each time.

So, once I've got rEFInd suddenly booting vmlinuz-linux as the only labelled boot entry, the Antu theme then applies its own icon for linux.png and which is not only incorrect, but tells me that the bootloader isn't picking up on my install name anywhere. And again, all of this leads into a wider problem, so I'm not simply being picky about aesthetics here. Firstly I disabled the theme so that rEFInd is booting with its default appearance.

Off I went... more reading:

My current working config is simply:

"Boot with standard options" "root=UUID=6dbbb2b3-5f13-49b3-b0a5-c639bccf2897 rw intel-ucode splash=silent quiet" and which works, but again it is IMPOSSIBLE currently to use anything but this. Any other attempt to change to a menu stanza results in failure.

Firstly, to address picking up the correct system type I tried labelling the main ext4 partition with e2label during boot, changed the name to "Arch Linux". Nope. Same result.

I tried various suggested things like using PARTUUID, or UUID. I tried all manner of ways of pointing at the various directories but all to no avail.

Now the fun part, and major reason for posting. I had assumed, after two days of reading and re-reading the docs and completely failing, that something like this should work:

menuentry "Arch Linux" {
icon EFI/refind/icons/os_arch.png
volume "Arch Linux"
loader /boot/vmlinuz-linux
initrd /boot/initramfs-linux.img
options "root-UUID=6dbbb2b3-5f13-49b3-b0a5-c639bccf2897 rw intel-ucode splash=quiet silent"
submenuentry "Boot using fallback initramfs" {
initrd /boot/initramfs-linux-fallback.img
}
submenuentry "Boot to terminal" {
add_options "systemd.unit=multi-user.target"
}
}

It doesn't. Nor does specify volume by any other means work - nothing from blkid helps.

ANYTHING that I change, ANY time I deviate in the slightest from the simple one line boot config as written by the script, I get the following message. It's always the same message, it never varies, I get the same result, and I always have to reboot from the live installer to re-edit the config file:

[ 0.033615] [Firmware Bug]: TSC_DEADLINE disabled due to Errata: please update >microcode to version 0x22 (or later)

Sterting version 245.5-1-arch
::running hook [udev]
::Triggering uevents ...
ERROR: device '' not found. Skipping fsck.
::mounting '' on real root
mount: /new_root: no file system type specified.

You are now being dropped into an emergency shell.
sh: can't access tty: job control turned off
[rootfs]#

Now, I think I understand some of this. Is this because it HASN'T now loaded the ucode, and is failing because insecure?

Thing is that whatever/however I try to write my stanza - and by which I mean EVERY possible way I could think of pointing to the initrd files, prefixing or creating those file paths - HOWEVER I try to do this, I get this one, same error message always.

So, I'm able to boot, but completely unable to fathom out why I fail to create my own menu, and for rEFInd to pick up on my installation name.

[joevt]

The example in refind.conf-sample has a / before EFI in the icon path like this (same as in configfile.html):

menuentry "Arch Linux" {
    icon     /EFI/refind/icons/os_arch.png
    volume   "Arch Linux"
    loader   /boot/vmlinuz-linux
    initrd   /boot/initramfs-linux.img
    options  "root=PARTUUID=5028fa50-0079-4c40-b240-abfaf28693ea rw add_efi_memmap"
    submenuentry "Boot using fallback initramfs" {
        initrd /boot/initramfs-linux-fallback.img
    }
    submenuentry "Boot to terminal" {
        add_options "systemd.unit=multi-user.target"
    }
}

As for having rEFInd automatically choose the Arch icon:
1) NEWS.txt says the following:

- Added the "words" that make up a filesystem's label (delimited by spaces,
  dashes, or underscores) to the list of bases used to search for OS icons.
  For instance, if the filesystem's label is "Arch", rEFInd searches for
  os_Arch.icns; if it's "Fedora 17", it searches for os_Fedora.icns and
  os_17.icns; and if it's "NEW_GENTOO", it searches for os_NEW.icns and
  os_GENTOO.icns.

2) The function for loading the icon is LoadOSIcon. The OSIconName parameter is a comma delimited list of possible OS names (called hints). For EFI (not Legacy) boot options, this list is populated by the SetLoaderDefaults function. The function will load an icon from the path containing the efi loader using the egLoadIconAnyType function (bypassing the hints process). The icon can have one the following formats: png,icns,jpg,jpeg,bmp. The name of the icon depends on the basename of the efi loader. For example, if the loader is /EFI/ubuntu/grubx64.efi then you can have an icon at /EFI/ubuntu/grubx64.icns. You could put the arch icon where the kernel is.
3) hints are created from various bits of information:
a) The last directory name. Using the above example: ubuntu. What path is your loader at?
b) Every word in the volume label name. Usually this is EFI. But for non EFI partitions, it could be anything. What is the volume label where the file you want to load is located? If it's "Arch Linux" then it should work, unless case sensitivity? Test that by duplicating the os_arch.icns file with a new name os_Arch.icns.
c) Specific loaders based on path or file name or volume label (the resulting hints are: linux, refit, refind, mac, hwtest, elilo, grub, win8, xom, win, network)
4) SetLoaderDefaults is called by AddLoaderEntry which is called by ScanEfiFileswhich scans for specific efi files, ScanLoaderDir which searches for EFI files and kernels, ScanNetboot which searchs for netboot servers, and ScanMacOsLoader which searchs for macOS boot loaders.

[alan999]

thank you - very helpful. To clarify perhaps:

Yes, I had seen the initial slash, but felt I went to some lengths to state that I had tried many MANY combinations of setting file paths... I'm a bit more of a "try it and see" type than anything else, and since I can always recover the system see no harm in keep trying.

That said, I also felt my post went on to explain there's a rather more fundamental issue at stake namely that WHATEVER I appear to do, all I get is the system loading some default, any deviation from which it seems utterly intolerant of - allowing of course that it's me and my code at fault, I'm certainly not criticising the software.

Will address your further points in a separate response for clarity.

[alan999]

The name of the icon depends on the basename of the efi loader. For example, if the loader is /EFI/ubuntu/grubx64.efi then you can have an icon at /EFI/ubuntu/grubx64.icns. You could put the arch icon where the kernel is.

that is helping to clear up a MASSIVE amount of confusion here! "path", "volume", "location" are terms that seemed to end up melding together!

In my installation, I have mounted the EFI partition /dev/sda1 into /boot which is located on /devsda2 which is the partition that contains the filesystem and is labelled "Arch Linux".

So, "Arch Linux" file system contains

/boot/EFI/refind/refind_x64.efi and this is (obviously perhaps) the location for /icons

Please note that all I've done is install stuff as it chose to be installed i.e. from a plain Arch installation, I simply installed rEFInd and let it do its thing. When I created the initial installation I did so by mounting the EFI partition into /boot and didn't write or create anything myself but simply let rEFInd do its work. Obviously if I have to start changing stuff I can, but first thing is to more fully understand all this. I'll be honest - so much time reading rather compact docs makes it harder at times, or feels like it does. Coming here to ask and having this kind of expansion feels utterly refreshing.

I should point out that the package that installed, I have only .png files in my icons folder.

I think my confusion lies almost entirely with understanding file structure as seen by the bootloader. To explain, at risk of repetition:

The EFI partition /dev/sda1 is LABEL "EFS" (I changed it, but can change it back again) and is a vfat partition. It is mounted into /boot where it shows up as /boot/EFI on /dev/sda2 which is LABEL "Arch Linux" and is ext4 partition.

Swap partition irrelevant methinks.

What rEFInd is doing is to load /boot/vmlinuz-linux every time. You talk about adding an icon (.png file) to the location of the kernel... presumably by this you mean here? In /boot I have

/boot/vmlinuz-linux
initramfs-linux.img
intel-ucode.img
refind_linux.conf
/EFI/refind/refind_x64.efi plus BOOT.CSV /icons /keys and refind.conf

but I thought... that is what rEFInd is supposed to do?? What's that line in the stanza doing, if it's not pointing rEFInd at the icons, it living in a subdirectory of my kernel??

Those are genuine questions. It's possible I simply have failed to grasp something utterly fundamental about all of this. All I've done is follow instructions. At this point I wonder if I've done something incorrectly, or missed some part of the process?

What else should I have done differently, or labelled or configured differently?

My point of asking is because I DO NOT WANT to have to 'hack' it to get it to look right. What I want is to understand what it is I did or didn't do correctly, such that I'm now completely unable to alter or customise things, as doing so just utterly breaks the boot process, as per my initial post.

[alan999]

Thank you! The tip about renaming my EFS partition helped a great deal! That's all good now, thanks. Going to leave it there for now :)

[joevt]

png is one of the valid icon formats (and it's the format used in the rEFInd icons folder).

EFI doesn't know about linux mount points. It's not going to see EFI mounted in "Arch Linux" for example. EFI (or EFS or whatever name you gave it) will be a seperate file system / volume. You sure it was the EFI volume name that was changed to EFS and not the EFI folder name in the EFI volume?

You can go in the EFI Shell and try to find your EFI partition and Linux partition by typing "FS0:", "fs1:", etc. incrementing the file system numer (type "map" to get a list). Type "vol" to get the file system volume label name.

If rEFInd finds /boot/vmlinuz-linux then I think it will load an icon /boot/vmlinuz-linux.png if you create it or copy it.

If you can use the EFI Shell to see where /boot/vmlinuz-linux is at (using dir, cd, etc., like in Windows cmd shell), then you can type vol to see what the volume name is. If the volume name includes "arch" then rEFInd should choose the os_arch.png icon. If the volume name is ARCHBOOT then it won't work since arch is not a seperate word.

In the stanza, the icon line is first and is relative to the current directory which is probably that of the rEFInd binary. Starting the path with a slash makes the path relative to the root directory. In the root directory should be the EFI folder, which contains a refind folder, which contains the icon folder.

The next line of the stanza is "volume" which will change the current directory to the file system having the specified volume label.

The lines after volume will be relative to the root directory of volume.

[alan999]

Further thanks - this too is very helpful. Yes, I realise that in the various helpful replies above it often reiterates what's writtten on the webiste and in documentation, but there's a big difference in reception when it's in digestible snippets! That said, there has been some ESSENTIAL clarfication of certain terms, which had looked a little fuzzy elsewhere.

Anyway, more to the point: have managed to install a shell, so from within rEFInd I can confirm that the EFI partition, at FS0 is indeed "Arch". There are three BLK entries mapped. I can access BLK1: and which is called "Arch" (I'm guessing this represents what appears as /dev/sda1 elsewhere.

BLK2 and BLK3 are inaccessible from FS0: but again imagine this is expected behaviour, with those representing /dev/sda2 (where the system files are) and /dev/sda3 which is swap file.

Very happy that things are behaving as expected - it was the simple change to the label of the EFI/EFS partition (those terms seem to be entirely interchangeable). Once I changed that - again, ARCH is okay, presumably ARCH_BOOT or "ARCH <something>" would be fine... but no good if it's a single longer word. Purely out of curiosity, before I ask a final question, what if I called it "ARCHLINUX"? Yes/no? "ARCH_LINUX" presumably... but would that confuse things? Kind of important to know for future reference (the things I learn here, and on this machine, I port to future setups. I find they get better with time).</something>

Last question: I have gdisk packaged (Arch) so have installed it. I copied it over into the EFI/tools/ folder, but ... no dice. Booting into the rEFInd main window it doesn't show up, despite it's listed as enabled.

I built the files from source according to your web page. It ended up being the same thing. So, question is: what do I need to do/change such that I can use gdisk from the menu? Am I correct in assuming it has its own menu icon, or do I run gdisk from inside the shell?

edit: should have mentioned... I did a 'map' from the shell, and it found the paths to the kernel. It was listed directly under FS0:, with no root or absolute paths, it simply listed the contents right there. For example:

FSO:> vmlinuz-linux

No slashes or paths. And yes, the vol name for it was (again) ARCH. So, to create a menu stanza do I still need to specify a file path relative to something, or can it look like this:

menuentry Arch {
icon refind/icons/os_arch.png
volume ARCH
loader vmlinuz-linux
initrd initramfs-linux.img
options "<stuff>"
}</stuff>

or do I still need to indicate paths relative to... to what exactly?

[joevt]

I am confused because I can't see what you are seeing, and I don't use linux from rEFInd.

You can pipe output from EFI Shell commands to a text file (the partition needs to be writable which means it should be formated as FAT like the EFI partition or any other partition).
help * > help_all.txt
map -v > map_v.txt

You are saying the EFI partition is labeled as Arch instead of EFI? That is strange. Do you mean it has a folder named Arch?
You can do a recersive dir command to get a list of all the files:
dir -r fs0: > dir_r_fs0.txt

I think the EFI partition should be labeled EFI and you should find another way to get the Arch icon. It would be less weird that way.

blk are block devices. They might not have a corresponding file system. It's possible for blk1 to correspond to fs0.

You only have one file system? blk2 and blk3 might refer to partitions that you don't have a file system driver for. I don't expect swap to have a file system, but the partition containing the system files should. What is the format of the systems partition? Do you have the ext4_x64.efi installed in the rEFInd drivers_x64 folder? Is the partition encrypted (if that is a thing)?

FSO:> vmlinuz-linux maybe this means FS0 is a image file and not a partition? I guess I might like a look at map.txt. I am not familiar with how refind/linux works.

Paths in the stanza are always relative to someting. Before the "volume" line, the path is relative to the location of refind if the path does not start with a slash, or relative to the root directory of the partition containing refind if the path starts with a slash. After the "volume" line, paths are relative to the root directory of the file system having the specified volume label.

For each file system, you can do a vol command like this vol fs0 to show the volume label without changing the current file system. You can pipe that output to different files vol fs0 > vol_fs0.txt

Is gdisk in the /EFI/tools directory on the EFI partition (outside of the rEFInd folder)? Is gdisk in the showtools list in the refind.conf file? Is gdisk named gdisk.efi or gdisk_x64.efi (or whatever the architecture of rEFInd is)? Is gdisk the EFI binary and not the linux binary?

Icon Hints are generated from words in a volume label that are delimited by spaces, dashes (-), or underscores ( _ ) so ARCHLINUX would not work but all your other examples would.

[alan999]

You are saying the EFI partition is labeled as Arch instead of EFI? That is strange. Do you mean it has a folder named Arch?

Yes, because one of the early responses suggested this, and indeed this is PRECISELY what is suggested by Rod Smith on his website which goes into great detail of the SEVEN ways it's possible to have rEFInd select the correct system icon. The other thing I could have done, I now realise, is to simply copy the desired icon into /boot and rename it vmlinuz.png - that would work too. But as it is yes, I simply changed the default label given to my EFI partition by parted. Doesn't seem like that big of a deal does it? It's only a label. It's the correct format, and 'internally' i.e. as the system file structure was created by rEFInd's install script, the directories inside that partition are all correct.

One file system? Please clarify. I have installed my operating system to a single partition on a single physical disk. The structure of that disk I listed in my first post, but I'll summarise here. I created a primary vfat partition for EFI, added two further partitions - one .ext4 for my Linux file system, and SWAP remainder for a swap file. So yes, if you mean it in that sense I have a "single" file system.

I don't have the ext4.efi too installed no - why would I? I wasn't planning to use the boot loader to manipulate my files - I tend to do that once I'm booted up. That said, I might put it in, as that could be handy.

I think we've found the prolem with gdisk ! Yep, I copied across the version packaged for Arch (to the correct location). Didn't look right, as it's just a shared library file. I did download everything from Sourceforge - again according to the instructions given by Rod Smith. I compiled them as instructed. Thing was, once done I had the EXACT same file as the one I'd copied over from my /usr/lib . I do have the Windows .exe files, but I thought those weren't useful. Apart from that though, I do not understand - between the Arch Wiki and Rod's own pages, how I'm supposed to have the correct gdisk when building it produces the same 'wrong' version I already had provided by the package maintainers. The suggested "

And yes - it's enabled in the config. You answered my question by suggesting that if it were the correct file type, it would show up in the menu. I'll go look into that a bit further. If you think it would help if I upload the output from FS0: I'll do so :)

Since my initial post, and since I've continued to explore all of this etc. I've realised partly what my stop error message was when booting. It's because the intel-ucode updates STILL haven't covered my exact model of CPU, and so that (very common, it turns out) timing bug means the microcode cannot be loaded by initramfs, because that's what causes the kernel panic and shuts me down.

As it stands, I have no code against Spectre and other stuff... off topic so I won't go on, but # cat /proc/cpuinfo has listed

cpu_meltdown spectre_v1 spectre_v2 spec_store_bypass l1tf mds swapgs itlb_multihit

oh dear. Still, I have a working system, and can now write my own stanzas. Turns out there's really not much point (see above) since the microcode won't load. So, I'll just stick with the default. Oh yes - so, vmlinuz-linux has picked up my initramfs for me, I haven't needed to specify it in refind_linux.config which is cool :)

[joevt]

Each partition is a file system. EFI and your system partiton. You have vmlinuz in the EFI partition? My Ubuntu only has grub.efi in the EFI partition. I have the ext4 file system driver installed so rEFInd can find the kernel on the Ubuntu partition and list that as an option (bypassing grub).

I guess it doesn't matter what the EFI partition is called. It has a EFI GUID in the GPT to mark it as the EFI partition.

For gdisk, there are seperate versions for macOS, Linux, EFI, etc.. The EFI version should have a efi suffix. I haven't tried building it myself. I think the EFI version is a seperate code base from gpt fdisk. So if you were building it from https://sourceforge.net/projects/gptfdisk/ then it's probably wrong. The correct source is at https://sourceforge.net/projects/uefigptfdisk . Once it's built, and has the correct suffix, you should be able to find it in the EFI Shell (fs0:, dir, cd, etc.). Executables in the listing may be colored green, directories are colored blue. You can run the executable by typing its name "gdisk.efi" or "gdisk_x64.efi". Maybe you'll get an error if it's not a proper efi executable.

[joevt]

Having the ext4 efi driver installed can help refind choose the correct icon.
Read https://sourceforge.net/p/refind/discussion/general/thread/ce7f15a280