Error when selecting one of the Oses on my rEFInd menu

[Ryan]

|This is the error I receive when attempting to boot into Kali from the
menu:

Starting vmlinuz-3.12-kali1-amd64
Using load operations 'ro root=/dev/disk/by -
uuid/809768a8-8c1d-47de-b8cd-38522b6cefd0 initrd=/install/gtk/initrd.gz
quiet'
Failed to open initrd file: install\gtk\initrd.gz

Any ideas on what I can do? I do have Linux Mint 16 installed and
working, as well as Windows 8.1 (so this would be my third OS).

Thank you.
|

[Roderick W. Smith]

Are you booting with auto-detection or via a manual boot stanza? If the latter, please present that manual boot stanza and verify that the file install/gtk/initrd.gz actually exists on the same partition as the kernel. Note that the file may be in some subdirectory, probably of /boot or /boot/efi, from Linux's perspective (that is, /boot/install/gtk/initrd.gz or /boot/efi/install/gtk/initrd.gz).

If you're booting via an auto-detection sequence, please check to see if there's an initrd= option in your /boot/refind_linux.conf file. If so, verify that the initrd file is where you say it is. If there's no such option in refind_linux.conf.

One more thing: Disable the Windows Fast Startup feature, as described here:

http://www.eightforums.com/tutorials/6320-fast-startup-turn-off-windows-8-a.html

That feature is fundamentally incompatible with a dual-boot configuration, and it can cause the sort of errors you're reporting.

[Ryan]

Technically, this is a tripple boot. Windows 8 and Mint 16 are already working using the rEFInd menu. The Windows fast startup has already been disabled.

Here is a list of the partitions.
yeep@Mint-MoFo ~ $ lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
sda 8:0 0 698.7G 0 disk
├─sda1 8:1 0 450M 0 part
├─sda2 8:2 0 260M 0 part /boot/efi
├─sda3 8:3 0 128M 0 part
├─sda4 8:4 0 205.1G 0 part
├─sda5 8:5 0 350.5G 0 part /media/Storage
├─sda6 8:6 0 28G 0 part /
├─sda7 8:7 0 51.2G 0 part /home
├─sda8 8:8 0 7.5G 0 part
├─sda9 8:9 0 1M 0 part
└─sda10 8:10 0 55.7G 0 part

I have also attached a screen shot from gparted. I believe I see where it is looking for the initrd.gz file, and that is not on the boot/efi partition. I must have done something wrong when running the mkrlconf.sh in the second linux distro after installing.

FYI: sda10 is the partition housing Kali, and both linux distros share the swap partition.

Any ideas for moving the proper files to sda2?

I was reading through your webpage on the renaming options:
http://www.rodsbooks.com/refind/installing.html#naming

It would be great to organize that partition to be something of the effect of:
boot/efi/Windows
boot/efi/linuxmint
boot/efi/kali

Really just to keep my sanity. Is that possible?

Thank you for any help here,

Ryan

[Roderick W. Smith]

In my experience, the best way to boot multiple Linux distributions using rEFInd is to create an EFI/refind directory on the ESP for rEFInd and then have rEFInd read the Linux kernels from each distribution's /boot directory (which could be /boot on a root (/) partition or a separate /boot partition). Creating EFI/{distname} directories to house kernels is possible, but deviates from the usual kernel-location practices of the distributions and so creates more work and more places for things to go wrong.

This approach does require that you keep your kernels on a filesystem that the EFI can read, typically with the help of a rEFInd EFI filesystem driver (available for ext2/3/4fs, ReiserFS, Btrfs, HFS+, and ISO-9660), but that's not usually a problem -- only XFS and JFS are excluded, and you can always create a separate /boot partition that uses one of the supported filesystems if you want to use XFS or JFS for your root filesystem. You can even use FAT on your /boot partition with some distributions, although a few distributions will balk at that.

If this doesn't help, I need more information:

• Are you using auto-detection with a refind_linux.conf file or a manual boot stanza? If the former, I need to see the refind_linux.conf file; if the latter, I need to see the manual boot stanza in refind.conf.
• What partition(s) hold your kernels? Where are they mounted in Linux? In what directory/ies do the kernels reside? Show me the output of ls on the directory/ies that hold the kernels.
• What filesystem(s) are you using to hold your kernels?

[Ryan]

Auto detection vs. manual -
I believe I was using auto, as I followed your directions on the Mint forum to have rEFInd setup the process by running the mkrlconf.sh script in the second distro (because I had to install in CSM mode). However, I cannot find the refind_linux.conf file. I did copy and rename the refind_linux.conf file before the install of Kali, here is what it says:

PRE-KALI INSTALL:
"Boot with standard options" "ro root=UUID=98b1f229-9ba9-4f2d-bd6e-dd31d74b63a6 quiet splash "
"Boot to single-user mode" "ro root=UUID=98b1f229-9ba9-4f2d-bd6e-dd31d74b63a6 quiet splash single"
"Boot with minimal options" "ro root=UUID=98b1f229-9ba9-4f2d-bd6e-dd31d74b63a6"

At this point, I do have the modified version of the refind.conf, but I am 95% sure that the kali install and running of mkrlconf.sh did not modify it. I know this because I modified it in the past to get rEFInd to ignore the "generic" kernel, which happens to be all that can be found for mint right now. That entry is as follows:

"Pound sign here"RDH - Adding to remove the "/vmlinux" listing in menu
dont_scan_dirs /

Directory system holding kernels:
MINT: FAT
KALI: EXT4

This is not necessariy what I have to have or what I wanted, it is just how it is right now.

The rest of your questions should be answered in the file attached. I marked them as to which OS is being used, but you should recognize the change in prompt. Also, the only way I can get in Kali, is to change to CSM mode in the "BIOS". Please let me know if I can get any more information for you.

Note: I have a pretty strong feeling that is not the Mint Kernel I was using before the Kali install. I know that Mint installs at least two kernels and I was having to avoid one using that dont_scan_dirs / before to avoid it. In addition (silly way to figure that out follows), the other Mint boot screen just showed the mint icon while processing the boot, know I see the code being run which is what it did when I chose the "incorrect" kernel on a previous mint install.

Worst case scenario, I do have a clone of the HD that I made right before doing the install of Kali. I could restore that to see which kernel is in use, or to just start over completely (was hoping not to do that, but I did prepare for it)

[Roderick W. Smith]

First, install/gtk is a very strange location for an initrd file. rEFInd does not search that directory by default, so the only way for rEFInd to be looking there is if you explicitly told it to do so. You could do this in at least three ways:

• By creating a manual boot stanza
• By using the also_scan_dirs parameter in refind.conf
• By explicitly using the initrd= option in refind_linux.conf

I recommend you check all these possibilities to try to figure out where rEFInd is getting that option.

Also, you can learn something about a boot option by examining the text that appears underneath the option when you highlight it (but before you hit Enter to boot). For instance, the screenshot on the rEFInd main Web page shows "Boot vmlinuz-3.5.0-27-generic from UBUNTU BOOT" as the text. This indicates both the kernel filename (vmlinuz-3.5.0-27-generic, which includes the path, which is in the root directory in this case) and the boot partition (called UBUNTU BOOT here, although in many cases it will be descriptive, like 25 GiB ext4 volume). The description is set manually in the case of a manual boot stanza, so it can be anything. Compare your working Mint and non-working Kali descriptions.

It looks like you do not have a refind_linux.conf file for Mint, but you do have one for Kali. (There is a refind_linux_pre_kali.conf file for Mint, but rEFInd will ignore that file.) If this file is absent, rEFInd attempts to get the bare-bones boot data from a file called /etc/fstab, so presumably Mint is booting correctly with that data. You can leave it alone or create a refind_linux.conf file, as you see fit. Note that the refind_linux.conf file must be unique for each distribution, so in your case your Mint and Kali files should be different. These files must reside in the directory that holds the kernels, wherever that is. Normally it's /boot in Linux, but if you use also_scan_dirs in refind.conf and manually move your kernels, it could be somewhere else.

It's unclear from your description if the refind_linux.conf file you presented in your most recent post is from Mint or from Kali. If you're trying to use it from Kali, it won't work, because the UUID it contains (98b1f229-9ba9-4f2d-bd6e-dd31d74b63a6) is the UUID for your Mint root filesystem. Thus, using that refind_linux.conf file with Kali will hopelessly confuse the kernel. At best, you'll boot into Mint, probably with some hardware not working. At worst, the boot will fail completely. If you're using that file with Kali, I recommend you delete it in Kali and run mkrlconf.sh in Kali to generate a fresh one.

An unrelated issue: Your installations seem to use the Microsoft Basic Data type codes for your Linux filesystems. This creates the possibility of accidentally trashing them from Windows. See this page for information on correcting this problem

[Ryan]

First, install/gtk is a very strange location for an initrd file. rEFInd does not search >that directory by default, so the only way for rEFInd to be looking there is if you >explicitly told it to do so. You could do this in at least three ways:

By creating a manual boot stanza
By using the also_scan_dirs parameter in refind.conf
By explicitly using the initrd= option in refind_linux.conf

I recommend you check all these possibilities to try to figure out where rEFInd is >getting that option.

I will check the above possibilities and return with the results

---

Also, you can learn something about a boot option by examining the text that appears >underneath the option when you highlight it (but before you hit Enter to boot). For >instance, the screenshot on the rEFInd main Web page shows "Boot vmlinuz-3.5.0-27-generic >from UBUNTU BOOT" as the text. This indicates both the kernel filename
(vmlinuz-3.5.0-27- generic, which includes the path, which is in the root directory in >this case) >and the boot partition (called UBUNTU BOOT here, although in many cases it >will be descriptive, like 25 GiB ext4 volume). The description is set manually in the >case of a manual boot stanza, so it can be anything. Compare your working Mint and >non-working Kali >descriptions.

Where can I find these descriptions for comparison? In the refind_linx.conf file?

---

It looks like you do not have a refind_linux.conf file for Mint, but you do have one for >Kali. (There is a refind_linux_pre_kali.conf file for Mint, but rEFInd will ignore that >file.)

That was done on purpose so I could reference it in the future.

---

If this file is absent, rEFInd attempts to get the bare-bones boot data from a file >called /etc/fstab, so presumably Mint is booting correctly with that data. You can leave >it alone or create a refind_linux.conf file, as you see fit. Note that the >refind_linux.conf file must be unique for each distribution, so in your case your Mint >and Kali files should be different. These files must reside in the directory that holds >the kernels, wherever that is. Normally it's /boot in Linux, but if you use >also_scan_dirs in refind.conf and manually move your kernels, it could be somewhere else.

Should I move them all the the FAT partition where the Windows setup and Mint kernel reside right now?

---

It's unclear from your description if the refind_linux.conf file you presented in your >most recent post is from Mint or from Kali.

That was the old Mint file

---

If you're trying to use it from Kali, it won't work, because the UUID it contains >(98b1f229-9ba9-4f2d-bd6e-dd31d74b63a6) is the UUID for your Mint root filesystem. Thus, >using that refind_linux.conf file with Kali will hopelessly confuse the kernel. At best, >you'll boot into Mint, probably with some hardware not working. At worst, the boot will >fail completely. If you're using that file with Kali, I recommend you delete it in Kali >and run mkrlconf.sh in Kali to generate a fresh one.

I don't know what is being used for Kali, as I can only boot into it using a CSM/Grub combo. I can run the mkrlconf.sh in Kali, should it be put in a specific place ahead of time? Do I need to move the kernel ahead of time? (To the FAT partition?)

---

An unrelated issue: Your installations seem to use the Microsoft Basic Data type codes >for your Linux filesystems. This creates the possibility of accidentally trashing them >from Windows. See this page for information on correcting this problem

I will use the link you have given me to GPT fdisk process. Although, this seems to be used to "block" windows view of the partitions that house Linux. Is this more of a saftey issue, so you do not accidentally cause a problem for linux?

Thanks and I will go preform your three recommended methods.

[Roderick W. Smith]

Also, you can learn something about a boot option by examining the text that appears underneath the option when you highlight it (but before you hit Enter to boot).

Where can I find these descriptions for comparison? In the refind_linx.conf file?

As I said, these descriptions appear in the rEFInd boot menu itself when you highlight an option.

It looks like you do not have a refind_linux.conf file for Mint, but you do have one for Kali. (There is a refind_linux_pre_kali.conf file for Mint, but rEFInd will ignore that file.)

That was done on purpose so I could reference it in the future.

You can't rename configuration files willy-nilly and expect them to work. rEFInd looks for a file called refind_linux.conf in the same directory as the Linux kernel. No other filename will work for this purpose. Of course, if you renamed the file in order to have rEFInd ignore it, that's fine.

These files must reside in the directory that holds the kernels, wherever that is. Normally it's /boot in Linux, but if you use also_scan_dirs in refind.conf and manually move your kernels, it could be somewhere else.

Should I move them all the the FAT partition where the Windows setup and Mint kernel reside right now?

The refind_linux.conf file's contents applies to the Linux kernels in the same directory as the file itself. If you've copied kernel files to the ESP, then you must also put the refind_linux.conf file there.

That said, if you're manually copying Linux kernels so that rEFInd can use them, you're doing it the hard way. You should be able to use EFI filesystem drivers to get rEFInd to read the kernels from the Linux /boot directory. If this is impossible because you're using XFS or JFS on that directory, then I recommend creating a small /boot partition to hold the kernel files.

I can run the mkrlconf.sh in Kali, should it be put in a specific place ahead of time? Do I need to move the kernel ahead of time? (To the FAT partition?)

The mkrlconf.sh script can be anywhere. As I said, rEFInd should be able to pick up kernels in Linux's /boot directory if that directory is on a FAT, HFS+, ReiserFS, Btrfs, or ext2/3/4 filesystem and if you're using an appropriate driver. See the drivers page of the rEFInd documentation for details.

I will use the link you have given me to GPT fdisk process. Although, this seems to be used to "block" windows view of the partitions that house Linux. Is this more of a saftey issue, so you do not accidentally cause a problem for linux?

Precisely. The page to which I linked describes the problem in detail.