# Figuring out rEFInd

## sgarcia

OK, I've got a reliable boot of my new EFI enabled kernel under rEFInd, but I'm not exactly sure why it's working.  I've tried multiple ways to feed it the appropriate parameters via refind.conf, but so far, as near as I can tell, refind.conf is being completely ignored.

What finally got me up was a post in another thread that suggested placing the kernel and initramfs into the EFI/gentoo directory, along with a file called refind_linux.conf.  That file contains one line -- the name Gentoo and the boot options, roughly what I've been using for years :

```
"Gentoo"  "root=/dev/ram0 init=/linuxrc ramdisk=8192 real_root=/dev/sda3 udev"
```

The kernel is named vmlinuz.efi and the initramfs file is named initramfs.cpio.gz.  Nowhere do I specify which initramfs to use, it just seems to pick it up.  When I used normal "gentoo" style names they were ignored.

The problem is that I'd like to be able to have more than one kernel and its associated initramfs in the same directory.  Since I'm using generic names, I don't know how to get it to associate a new kernel with its correct initramfs.  If I could use refind.conf, there are all kinds of mechanisms for setting that up, but like I say, I can't get rEFInd to pick up on its configuration file.  

I've put a copyof refind.conf in with its binary (in EFI/refind) in the root of the efi partition, and in EFI/boot (along with a copy of rEFInd named BOOTX64.EFI. )

As a minor issue, the Gentoo icon shows up OK for the scanned Gentoo kernel, probably because of the directory name.  The "reboot" icon shows up correctly Everything else is either generic or a blank square.  The EFI shell icon is a blank square, and it only is picked up if the binay is placed in the root of the partition.

----------

## srs5694

 *sgarcia wrote:*   

> OK, I've got a reliable boot of my new EFI enabled kernel under rEFInd, but I'm not exactly sure why it's working.  I've tried multiple ways to feed it the appropriate parameters via refind.conf, but so far, as near as I can tell, refind.conf is being completely ignored.

 

Later, you say you've got multiple rEFInd binaries on the ESP. You may want to simplify; that will eliminate a possible source of confusion, in that right now, if you modify refind.conf, you could be modifying the one that's associated with a rEFInd binary that you're not running. You can then test with an obvious change, such as uncommenting (or commenting out) the "textonly" option, which tells rEFInd to run in text mode rather than its default graphical mode.

If refind.conf is being ignored, that suggests either filesystem damage or a flaky EFI implementation. Some supply a case-sensitive StriCmp() function, for instance. This function should do a case-insensitive string comparison, but if the firmware does a case-sensitive comparison, that shows up as any number of weird problems relating to file access, among other things. I've only seen this on a board with Gigabyte's "Hybrid EFI," which is pretty flaky; but there could be equally weird problems with others. One Intel board I've got developed weird file-access problems after my FAT32 ESP collected a modest number of files. Switching to FAT16 alleviated that problem; however, I must emphasize that the EFI spec says that the ESP must be FAT32, not FAT16, and Windows will often have problems installing to a system with a FAT16 ESP.

 *Quote:*   

> What finally got me up was a post in another thread that suggested placing the kernel and initramfs into the EFI/gentoo directory, along with a file called refind_linux.conf.  That file contains one line -- the name Gentoo and the boot options, roughly what I've been using for years :
> 
> ```
> "Gentoo"  "root=/dev/ram0 init=/linuxrc ramdisk=8192 real_root=/dev/sda3 udev"
> ```
> ...

 

This is all documented on rEFInd's "Methods of Booting Linux" Web page (which is also included in the rEFInd downloads). rEFInd searches for an initial RAM disk file that matches the version of the kernel you use, the version number being encoded in the filenames of both files. If you don't use version numbers in the filenames, then you can directly boot just one kernel per directory -- at least, if you use the automatic detection system. You can create manual configuration stanzas, as documented on rEFInd's "Configuring the Boot Manager" page, to boot kernels stored using whatever names you like.

 *Quote:*   

> As a minor issue, the Gentoo icon shows up OK for the scanned Gentoo kernel, probably because of the directory name.  The "reboot" icon shows up correctly Everything else is either generic or a blank square.  The EFI shell icon is a blank square, and it only is picked up if the binay is placed in the root of the partition.

 

These missing icons are one of the things that make me think you may have filesystem damage on your ESP. Before you do anything else, though, try restoring the icons subdirectory from a fresh download of rEFInd; it could be some of the icon files are missing or damaged. If that doesn't help, try running dosfsck on the ESP, and if that doesn't help, try backing it up, creating a fresh filesystem on the ESP, and restoring your files.

----------

## sgarcia

 *srs5694 wrote:*   

> 
> 
> Later, you say you've got multiple rEFInd binaries on the ESP. You may want to simplify; that will eliminate a possible source of confusion, in that right now, if you modify refind.conf, you could be modifying the one that's associated with a rEFInd binary that you're not running. You can then test with an obvious change, such as uncommenting (or commenting out) the "textonly" option, which tells rEFInd to run in text mode rather than its default graphical mode.

 

Well, I suspect my problems with refind.conf may have been self inflicted.  I uncommented the textonly option and that worked -- but the manual stanzas I had defined still weren't working.  It turned out I hadn't modified the scan order to enable them.

 *srs5694 wrote:*   

> 
> 
> If refind.conf is being ignored, that suggests either filesystem damage or a flaky EFI implementation. Some supply a case-sensitive StriCmp() function, for instance. This function should do a case-insensitive string comparison, but if the firmware does a case-sensitive comparison, that shows up as any number of weird problems relating to file access, among other things. I've only seen this on a board with Gigabyte's "Hybrid EFI," which is pretty flaky; but there could be equally weird problems with others. One Intel board I've got developed weird file-access problems after my FAT32 ESP collected a modest number of files. Switching to FAT16 alleviated that problem; however, I must emphasize that the EFI spec says that the ESP must be FAT32, not FAT16, and Windows will often have problems installing to a system with a FAT16 ESP.

 

That's not much of a consideration.   :Smile:   I haven't used Windows on a machine of my own in a recent decade -- I don't see it is likely in a near future decade either.

 *srs5694 wrote:*   

> 
> 
>  *Quote:*   As a minor issue, the Gentoo icon shows up OK for the scanned Gentoo kernel, probably because of the directory name.  The "reboot" icon shows up correctly Everything else is either generic or a blank square.  The EFI shell icon is a blank square, and it only is picked up if the binay is placed in the root of the partition. 
> 
> These missing icons are one of the things that make me think you may have filesystem damage on your ESP. Before you do anything else, though, try restoring the icons subdirectory from a fresh download of rEFInd; it could be some of the icon files are missing or damaged. If that doesn't help, try running dosfsck on the ESP, and if that doesn't help, try backing it up, creating a fresh filesystem on the ESP, and restoring your files.

 

Yes, I think I did have a problem with the filesystem.  fsck found a number of problems, and fixed most of them.  However one (a filename "outside" the LFN area) it kept finding but refusing to fix.  I finally backed up and remade the filesystem.  I also reinstalled rEFInd, this time using the install script.

One of those fixed the icon problem.  At that point rEFInd was still not finding my manual stanzas, so I looked closer and found the problem with how I had configured it.

Thanks!  I think I'm fully up and running in the EFI department.  Now I just have to finish the rest of building a working system, in my copious spare time.  :/

----------

## srs5694

I'm glad to hear you found and fixed the problems!

FWIW, I've just released a new version of rEFInd. I've bumped the version number up to 0.4.0, but this is mainly because I've added in EFI filesystem drivers that users had to track down from other sources in the past; the changes from 0.3.5 are pretty minor otherwise, especially for UEFI/PC users.

----------

