The error about /boot/efi means that nothing was mounted at /boot/efi. You need to correct this by editing /etc/fstab and then typing "sudo mount -a". (You can temporarily mount the ESP at /boot/efi by using mount without editing /etc/fstab, but you probably want the ESP to be mounted automatically at every boot, which editing /etc/fstab will accomplish.) Once you've done this, you can re-install the Debian package or run the install.sh script that's already installed in /usr/lib/refind-{version} to copy the rEFInd binaries from the main Linux filesystem to the ESP.

You can eliminate unwanted boot entries by deleting their files from the ESP or by editing the refind.conf file and playing with the dont_scan_dirs and/or dont_scan_files options.

I've already wasted enough time because of this uefi crap. I have tried installing multiple linuxes, including the Olivia, which supposedly has efi support, which didn't work for me. I have no way of disabling efi in bios (or is it efi now?). The only boot choices I have is hard drive and cd drive.

So I've been trying to install Refind and I'm having difficulty at line 3 at installing for windows

I believe you've moved one directory too deep. Before typing "xcopy", try typing "dir" -- you should see a directory called "refind", among other things. Try backing out to C:\refind and then typing the xcopy command.

Thanks for helping me to install, you were correct.Now I have the boot manager giving me a choice between windows, and supposedly Maya (penguin logo) and Olivia (Ubuntu logo)Neither load, not sure if its Refind issue at all, Ill post what it says anyhow:

The one with penguin logo (witch I think is Mint 13 Maya XFCE) is named:boot boot\vmlinuz-3.2.0-23-generic from 189 Gib ex4 volume

The one with Ubuntu logo (witch I think is Olivia) is named:boot boot\vmlinuz-3.8.0-19-generic from 183 Gib ex4 volume

When I try to boot the penguin, I getStarting vmlinuz-3.2.0-23-genericUsing load options 'initrd=boot\initrd.img-3.2.0-23-generic'Error: unsupported while loading vmlinuz-3.2.0-23-generichit any key to continue

When I try to boot Olivia, I get:it loads a bunch of stuff and then gets to:BusyBox v1.20.2 (ubuntu 1:1.20.0-8ubuntu1) built-in shell (ash)*enter help for list of commands*(initramfs)

srs5694 wrote:The error about /boot/efi means that nothing was mounted at /boot/efi. You need to correct this by editing /etc/fstab and then typing "sudo mount -a". (You can temporarily mount the ESP at /boot/efi by using mount without editing /etc/fstab, but you probably want the ESP to be mounted automatically at every boot, which editing /etc/fstab will accomplish.) Once you've done this, you can re-install the Debian package or run the install.sh script that's already installed in /usr/lib/refind-{version} to copy the rEFInd binaries from the main Linux filesystem to the ESP.

You can eliminate unwanted boot entries by deleting their files from the ESP or by editing the refind.conf file and playing with the dont_scan_dirs and/or dont_scan_files options.

Thanks, got it working from the vmlinuz option with the mkrlconf, but I'm still a bit puzzled by something.

It's picking up the linuxmint options (shimx64.exi, grubx64.efi), but neither work, both drop me into a grub prompt. Is there something I should be doing to get a normal grub menu? I can see how renaming .efi files will remove them from the rEFInd menu, but I can't tell whether I should be deleting them from my ESP partition (LRS_ESP on this laptop), or from /boot/efi. I seem to have efi files and grub files in both those places, but I don't know which takes precedence and when.

rEFInd can't launch a kernel that old by itself. To boot this installation, you must either upgrade the kernel (to 3.3.0 or later) or install another EFI boot loader instead of or in addition to rEFInd.

When I try to boot Olivia, I get:it loads a bunch of stuff and then gets to:BusyBox v1.20.2 (ubuntu 1:1.20.0-8ubuntu1) built-in shell (ash)*enter help for list of commands*(initramfs)

Chances are rEFInd isn't passing the root= option to the kernel. Ordinarily, rEFInd reads this from a file called /boot/refind_linux.conf. If you installed with default options (no separate /boot partition), the simplest way around this problem is to use a brand-new experimental version of rEFInd that can pass this option to the kernel even without the refind_linux.conf file. You can get it here:

You'll need to copy that over your existing refind_x64.efi file on the ESP. Alternatively, you can hit F2 or Insert twice and add an appropriate "root=" option to the kernel parameters, but you must know the name of your root filesystem (/dev/sda5, say) to do this.

tsdadm wrote:It's picking up the linuxmint options (shimx64.exi, grubx64.efi), but neither work, both drop me into a grub prompt. Is there something I should be doing to get a normal grub menu?

That's a GRUB configuration issue. It's possible that running update-grub will fix the problem, but I can make no promises about that.

tsdadm wrote:I can see how renaming .efi files will remove them from the rEFInd menu, but I can't tell whether I should be deleting them from my ESP partition (LRS_ESP on this laptop), or from /boot/efi. I seem to have efi files and grub files in both those places, but I don't know which takes precedence and when.

Normally the EFI System Partition (ESP) is mounted at /boot/efi, so the two are one and the same.

tsdadam wrote:I can see how renaming .efi files will remove them from the rEFInd menu, but I can't tell whether I should be deleting them from my ESP partition (LRS_ESP on this laptop), or from /boot/efi. I seem to have efi files and grub files in both those places, but I don't know which takes precedence and when.

Normally the EFI System Partition (ESP) is mounted at /boot/efi, so the two are one and the same.

That's what I thought, but the two have different entries. For example:

at /boot/efi/EFI I have five directories: Boot, linuxmint, Microsoft, refind, tools. If I look at linuxmint I have grub.cfg, grubx64.efi and shimx64.efi.

at mount LRS_ESP/EFI I have the following directories: Boot, linuxmint, Microsoft. In linuxmint there's only shimx64.efi

tsdadam wrote:That's what I thought, but the two have different entries. For example:

at /boot/efi/EFI I have five directories: Boot, linuxmint, Microsoft, refind, tools. If I look at linuxmint I have grub.cfg, grubx64.efi and shimx64.efi.

at mount LRS_ESP/EFI I have the following directories: Boot, linuxmint, Microsoft. In linuxmint there's only shimx64.efi

There are three likely possibilities:

It's possible you've got more than one ESP. (The EFI spec does explicitly permit this.)

Something other than the ESP may be mounted at /boot/efi on your computer.

The partition you're referring to as LRS_ESP may not be your ESP. Some manufacturers are shipping computers with what might be called "pseudo-ESPs" -- FAT partitions that hold EFI boot loader files but that do not have the type code for an ESP. To verify a partition's type code, use gdisk on the disk and view the partition table (as in "gdisk -l /dev/sda"). ESPs have a type code of EF00 in gdisk. "Pseudo-ESPs" normally show up with a type code of FFFF (a catchall code for unknown types).

rEFInd doesn't check the partition type code; it searches all the partitions that the EFI can read. This includes the ESP, other FAT partitions, any partitions that use filesystems for which you've loaded drivers, and HFS+ partitions on Macs.

tsdadam wrote:That's what I thought, but the two have different entries. For example:

at /boot/efi/EFI I have five directories: Boot, linuxmint, Microsoft, refind, tools. If I look at linuxmint I have grub.cfg, grubx64.efi and shimx64.efi.

at mount LRS_ESP/EFI I have the following directories: Boot, linuxmint, Microsoft. In linuxmint there's only shimx64.efi

There are three likely possibilities:

It's possible you've got more than one ESP. (The EFI spec does explicitly permit this.)

Something other than the ESP may be mounted at /boot/efi on your computer.

The partition you're referring to as LRS_ESP may not be your ESP. Some manufacturers are shipping computers with what might be called "pseudo-ESPs" -- FAT partitions that hold EFI boot loader files but that do not have the type code for an ESP. To verify a partition's type code, use gdisk on the disk and view the partition table (as in "gdisk -l /dev/sda"). ESPs have a type code of EF00 in gdisk. "Pseudo-ESPs" normally show up with a type code of FFFF (a catchall code for unknown types).

rEFInd doesn't check the partition type code; it searches all the partitions that the EFI can read. This includes the ESP, other FAT partitions, any partitions that use filesystems for which you've loaded drivers, and HFS+ partitions on Macs.

Chances are rEFInd isn't passing the root= option to the kernel. Ordinarily, rEFInd reads this from a file called /boot/refind_linux.conf. If you installed with default options (no separate /boot partition), the simplest way around this problem is to use a brand-new experimental version of rEFInd that can pass this option to the kernel even without the refind_linux.conf file. You can get it here:

You'll need to copy that over your existing refind_x64.efi file on the ESP. Alternatively, you can hit F2 or Insert twice and add an appropriate "root=" option to the kernel parameters, but you must know the name of your root filesystem (/dev/sda5, say) to do this.

I copied the file over the existing one, but still got the same response

Chances are rEFInd isn't passing the root= option to the kernel. Ordinarily, rEFInd reads this from a file called /boot/refind_linux.conf. If you installed with default options (no separate /boot partition), the simplest way around this problem is to use a brand-new experimental version of rEFInd that can pass this option to the kernel even without the refind_linux.conf file. You can get it here:

You'll need to copy that over your existing refind_x64.efi file on the ESP. Alternatively, you can hit F2 or Insert twice and add an appropriate "root=" option to the kernel parameters, but you must know the name of your root filesystem (/dev/sda5, say) to do this.

I copied the file over the existing one, but still got the same response

Instead of pressing the Enter key, try hitting F2 or Insert twice. That will open a simple line editor that will show you your kernel options and enable you to edit them. For this to be helpful, you'll need to figure out what the right options are for your system; they vary from one installation to another.

Chances are rEFInd isn't passing the root= option to the kernel. Ordinarily, rEFInd reads this from a file called /boot/refind_linux.conf. If you installed with default options (no separate /boot partition), the simplest way around this problem is to use a brand-new experimental version of rEFInd that can pass this option to the kernel even without the refind_linux.conf file. You can get it here:

You'll need to copy that over your existing refind_x64.efi file on the ESP. Alternatively, you can hit F2 or Insert twice and add an appropriate "root=" option to the kernel parameters, but you must know the name of your root filesystem (/dev/sda5, say) to do this.

I copied the file over the existing one, but still got the same response

I didn't try alternative boot loaders for Maya as of yet...

And it worked!!! Youre a life saver. linux mint community - uefi 1-0This sorted my laptop issue, but I still cant boot an older Maya Xfce on my desktop (which doesnt even have uefi), anyways heres the post I made about it

outline wrote:Okay so, I have been using an Windows install of Olivia Mate, in fact which I'm using right now. As I completed backing up all of my data from this computer to my laptop, I finally installed Maya XfceInstallation went fine except that when it was already preparing to reboot, it didnt and I had to force turn off the computer.Now the Xfce doesnt show up in the boot menu at all (only Vista and Olivia there), and of course this Acer AM5630 is not Efi.

should I try installing one of the alternative boot loaders like you mentioned here?

rEFInd can't launch a kernel that old by itself. To boot this installation, you must either upgrade the kernel (to 3.3.0 or later) or install another EFI boot loader instead of or in addition to rEFInd.

Chances are rEFInd isn't passing the root= option to the kernel. Ordinarily, rEFInd reads this from a file called /boot/refind_linux.conf. If you installed with default options (no separate /boot partition), the simplest way around this problem is to use a brand-new experimental version of rEFInd that can pass this option to the kernel even without the refind_linux.conf file. You can get it here:

You'll need to copy that over your existing refind_x64.efi file on the ESP. Alternatively, you can hit F2 or Insert twice and add an appropriate "root=" option to the kernel parameters, but you must know the name of your root filesystem (/dev/sda5, say) to do this.

I copied the file over the existing one, but still got the same response

Instead of pressing the Enter key, try hitting F2 or Insert twice. That will open a simple line editor that will show you your kernel options and enable you to edit them. For this to be helpful, you'll need to figure out what the right options are for your system; they vary from one installation to another.

Also wanted to ask if I can somehow put this root=/dev/sda10 option into default possibly? I noticed when I rebooted I had to put it in again in order for OS to boot...

outline wrote:should I try installing one of the alternative boot loaders like you mentioned here?

Yes. An old 3.2.x-series kernel requires another boot loader, such as GRUB 2, Fedora's patched GRUB Legacy, or ELILO. Alternatively, you could upgrade the kernel to a newer one, although that might require you to compile it yourself, which is a subject that's far too involved for this thread. There are quite a few Web pages that describe how to do it, such as:

If you try this and have troubles, please start a new thread on the topic.

outline wrote:Also wanted to ask if I can somehow put this root=/dev/sda10 option into default possibly? I noticed when I rebooted I had to put it in again in order for OS to boot...

Yes. That's the purpose of the refind_linux.conf file I mentioned earlier. If it didn't work for you, try this:

Delete /boot/refind_linux.conf

Run the mkrlconf.sh script that comes with rEFInd. (You'll need to use sudo to run it.) This will create a new /boot/refind_linux.conf file that should work.

If that doesn't work, then you may need to edit the file manually.

Oh, and one more thing: I've just released rEFInd version 0.7.0. Compared to 0.6.12, 0.7.0 is mostly about driver improvements, including a new Btrfs driver. If you're using something much older than 0.6.12, though, it's worth upgrading; there have been a lot of improvements in the 0.6.x series.

I have no idea if this has anything to do with rEFInd, but this seemed like a good place to start.

I have the latest rEFInd installed and it is working great. However, I have been trying to test new distros for fun and have been unable to boot from disc. I know that some of them requuire CSM mode in the BIOS, but that makes no difference. The Ubuntu 12.10 disc has booted from day 1 in UEFI mode, with security off. As of tonight (first time I have tried in a awhile) I cannot get the disc to boot. I just end up in the rEFInd menu.

I pressed F12 on boot to force which media to boot from and selected the disc. Strangely, I end up with a small version of the rEFInd menu on screen and no affiliation with the typical menu one would see when using the ubuntu live cd.

Any ideas would be much appreciated. I know 100% this Ubuntu 12.10 disc worked in the past.

YeeP wrote:I have the latest rEFInd installed and it is working great. However, I have been trying to test new distros for fun and have been unable to boot from disc. I know that some of them requuire CSM mode in the BIOS, but that makes no difference. The Ubuntu 12.10 disc has booted from day 1 in UEFI mode, with security off. As of tonight (first time I have tried in a awhile) I cannot get the disc to boot. I just end up in the rEFInd menu.

I pressed F12 on boot to force which media to boot from and selected the disc. Strangely, I end up with a small version of the rEFInd menu on screen and no affiliation with the typical menu one would see when using the ubuntu live cd.

This sounds like you may have a defective disc, or perhaps a failing optical drive. When the firmware fails to boot from the disc, it drops back to rEFInd on the hard disk.

It could also be a Secure Boot thing, but only if you've set up rEFInd to boot using Secure Boot. In this scenario, if the distribution you're trying lacks Secure Boot support, booting it will fail and the system will drop back to rEFInd.