/boot/efi detected in the fstab of sda2: UUID=DDE9-FCDA (sda1)ls: cannot access : No such file or directory=================== UEFI/Legacy mode :BIOS is EFI-compatible, and is setup in EFI-mode for this installed-session.

So that should be enough right? Why would it not be a Uefi install?

Because it is impossible to install anything else in Uefi mode and impossible to run the command efibootmgr.

But when booting from the disk and running ls /sys/firmware the efi directory does not exist, which in turn means the dvd is booted in legacy mode, which in turn means that if I installed from it, it would install in legacy mode.

So simple, go into your bios settings and enable Uefi.

My bios settings screen has no entries even remotely relating to Uefi. I can't take screenshots of my bios settings so you will have to believe me on this.

Why not look in your motherboard manual for details of how to enable/disable Uefi?

I have two words in answer to that - find one!

Here are all the details I have of my motherboard (courtesy of hwinfo I think it was).

If anyone would like to have a stab at explaining all that then good luck to you, it has me completely beaten. Obviously my motherboard has the Uefi implementation from hell, but I would love to be able to do three things, run efibootmgr, boot shell.efi and install other distros in Uefi mode.

Oh yes, and I would also like to understand WIHIH but I think that is going to be a step too far!

I have put this under 'Other distros' as the tests were done on Ubuntu, but it equally applies to Mint.

viking777 wrote:I have no idea how my boot system works, I don't even know if it is Uefi or legacy bios, I think it is Uefi for the following reasons:

First, it's critical to distinguish between two things:

Whether your firmware is capable of booting in EFI mode.

Whether a specific boot is in EFI mode.

Most (in fact all, to the best of my knowledge) x86-64 systems with EFI have the ability to boot in either BIOS/legacy/CSM mode or in EFI mode. Thus, being EFI-capable does not guarantee an EFI-mode boot. Some of your tests hint at EFI-mode capability and others hint at (or prove) actual EFI-mode boots.

These are both suggestive, but not really conclusive evidence, of an EFI-mode install. You can install an EFI boot loader on a BIOS-booting computer; it just won't do anything. Likewise, you can install an EFI-mode boot loader on an EFI-capable computer but then boot it in BIOS mode (assuming another BIOS-mode boot loader is also installed).

Take this as seriously as you'd take anything else you read on the Web. Certainly it says nothing about a specific boot of the computer.

Excerpt from a boot-repair script

/boot/efi detected in the fstab of sda2: UUID=DDE9-FCDA (sda1)ls: cannot access : No such file or directory=================== UEFI/Legacy mode :BIOS is EFI-compatible, and is setup in EFI-mode for this installed-session.

The presence of /boot/efi in /etc/fstab implies that the installer did its work in EFI mode; however, it could be that the installer was buggy or that you (or some other tool) added such an entry manually afterward, so it's not really conclusive. I don't know how the Boot Repair script is detecting the firmware's EFI capabilities. My guess is that it's checking for EFI runtime variables, which would be conclusive proof of an EFI-mode boot, albeit redundant with the conclusive evidence you posted earlier.

So that should be enough right? Why would it not be a Uefi install?

In your case, the specific session you're running is an EFI-mode install. There's no mystery here. You've posted about this before, and I've said the same thing.

Because it is impossible to install anything else in Uefi mode and impossible to run the command efibootmgr.

It's hard to offer advice about your inability to boot in EFI mode because EFI user interfaces vary so much -- what works on one computer doesn't work on another one. As to efibootmgr, you're running into either a bug in efibootmgr or a bug in your firmware that's manifesting as an inability to use efibootmgr. Given the other information I have on your firmware, my guess is it's the latter.

But when booting from the disk and running ls /sys/firmware the efi directory does not exist, which in turn means the dvd is booted in legacy mode, which in turn means that if I installed from it, it would install in legacy mode.

EFI boots using El Torito, in which a FAT filesystem is stored in a file and used as if it were a boot floppy. Thus, the presence or absence of .efi files on the ISO-9660 filesystem are actually irrelevant. Most bootable Linux discs contain such files as duplicates of what's in the El Torito image, but this isn't guaranteed. Also, an improperly-prepared El Torito image can produce a disc that's unbootable in EFI mode despite the presence of .efi files in the ISO-9660 filesystem. To make matters worse, many Linux installation disk images use a "hybrid" (ISO-9660/MBR) format that enables them to be either burned to an optical disc or written to a USB flash drive. Such formats are fairly tortuous and can fail on some firmware (either BIOS or EFI).

That said, your conclusion that you've booted in BIOS mode because of the absence of a /sys/firmware/efi directory is almost certainly correct. It's possible you could force an EFI-mode boot by removing BIOS-boot support from the boot medium. This is likely to be tricky for a CD/DVD boot because of the need to prepare an El Torito image with EFI but not BIOS support. It could be easier with a USB flash drive, though: Just prepare a USB flash drive with a FAT filesystem and do a file-level copy of everything in the ISO-9660 filesystem to the flash drive. OTOH, the installer might want to see a filesystem with a particular name, so you might need to set it appropriately or use a combination of the DVD and the USB flash drive to boot the computer to run the installer.

So simple, go into your bios settings and enable Uefi.

My bios settings screen has no entries even remotely relating to Uefi. I can't take screenshots of my bios settings so you will have to believe me on this.

Try for yourself if you like - a lot of those entries are 'googlewhacks'!

To the best of my knowledge, Fujitsu doesn't make motherboards for desktop computers, but they do make laptop computers. You're more likely to find manuals for laptops if you search on the laptop's model number rather than the model number of the motherboard in the laptop. Checking Fujitsu's site for manuals might yield fruit; however, when I Googled the information you provided, I was led to a Fujitsu laptop model AH532, for which Fujitsu has this page, which has no obvious manual. Maybe it's hidden somewhere else, or maybe you've got another model for which Fujitsu actually has a manual; but based on my limited search, I'd say that Fujitsu is being anal-retentive with information about their products.

So why not boot with Refind and use it to boot the dvd in Uefi mode?

Because Refind doesn't see any efi entries on my dvd drive, in fact it doesn't see any entries on my dvd drive (or the shell entry in my ESP).

Sometimes these devices are hidden from rEFInd if the firmware doesn't scan them. You might be able to get some entries by using your firmware's own boot manager or by adjusting firmware boot options to explicitly include the optical drive in the boot list.

Another option is to prepare a hard disk partition that's at least as large as the disk and then do a low-level copy of the DVD to that partition, as in "sudo dd if=/dev/sr0 of=/dev/sda8" (or "sudo dd if=diskimage.iso of=/dev/sda8" to copy a disc image file), changing "/dev/sda8" as necessary. You can then install the rEFInd ISO-9660 driver and it should be able to boot from the image on the hard disk.

If anyone would like to have a stab at explaining all that then good luck to you, it has me completely beaten. Obviously my motherboard has the Uefi implementation from hell,

You've already explained it: Your EFI implementation is bug-ridden. It might be possible for Linux developers to include workarounds or fixes in tools like efibootmgr and rEFInd, but this would require that the developers have access to the hardware, or for somebody who owns the hardware and who has sufficient programming experience to submit a patch to the relevant application developers. (Speaking as the developer of rEFInd, I don't own any Samsung computer, and I lack the sort of budget that would enable me to buy one just to experiment with a known-buggy EFI implementation. If you care to lend me the computer, I can have a look at it, but I can't make any promises about finding fixes.)

A less radical solution is to check with Samsung to see if they've got an updated firmware. If not, contact tech support.

You might also try using Fedora and, if it has problems, contact Matthew Garrett. He's doing much of the really low-level EFI stuff for Linux, and so might know of solutions or at least be able to direct you to somebody who's working on whatever subsystem is causing problems. I suggested installing Fedora because Garrett was, until recently, a Red Hat employee and is still closely involved in the Fedora project. Thus, he might be more receptive to helping if you can reproduce problems in Fedora. Also, Fedora is well ahead of the pack in terms of EFI support. I'd say that Mint is somewhere in the middle, which really is not very good, since Linux as a whole is behind where it should be. This will improve with time, but it will take time to get the support to where it should be.

but I would love to be able to do three things, run efibootmgr, boot shell.efi and install other distros in Uefi mode.

You can boot an EFI shell from rEFInd: Install it in the EFI/tools directory or the root directory on the ESP and it should show up as an option in the rEFInd menu, on the second row of (smaller) icons. (It should be called shellx64.efi.) Note that there are several EFI shell binaries, and not all of them will work. You probably need a 64-bit shell, not a 32-bit shell of a "fat" (32-/64-bit) binary. There are also version 1 and version 2 shells, with version 2 shells being more troublesome. (Theoretically, the troubles should be gone with an EFI as recent as yours, but given your other problems, I wouldn't rule anything out in terms of problems.)

As far as I can tell, your problems aren't with UEFI generally, but with Samsung's UEFI implementation. This is nothing new: We've had buggy BIOSes for years. Linux has had 20 years to come to grips with these problems, so the workarounds are mature, and BIOSes from the last decade or so have had fewer problems than the BIOSes from the 1980s and early 1990s. EFI is newer, manufacturers have rushed their EFI implementations out with insufficient testing, and the Linux community has neglected the coming EFI storm for too long, leading to the sorts of problems you're having. They will subside with time.

One more comment: Given the severity of your problems, you should seriously consider ditching EFI-mode booting on your computer. This is most easily done by wiping the hard disk, creating a new MBR partition table on it, and re-installing everything; however, you can do it by converting from GPT to MBR and converting your existing OS installations, if necessary.

For those of us who either don't buy into the necessity for, or don't give a flip about EFI and Secure Boot, the solution is so simple. I've disabled secure boot and use legacy BIOS mode. That way I have the advantage of the GPT partitioning scheme of all primary partitions, and can run whatever I want on my machine.

Yes, I know and it is that sort of idiocy that I am constantly banging on about. It annoys the living crap out of me. I posted this a couple of days ago:

First I have to apologise for Uefi. Actually not for Uefi, which, if you can ever get it to work, is an improvement on the old bios booting, but instead for the people that matter in the Linux world (not me obviously) who have declared it a solved problem and just moved on. You, I, and everyone that has actually tried to use it know that it is about as solved as the meaning of life, but sadly it receives less attention than that question - this is a disgrace to the Linux world and deeply upsets people as dedicated to Linux as I am.

@srs5694 First of all sorry for the seeming confusion about the machine specs, they are in my signature at the bottom of each post, but I didn't tell you that, so my mistake.

These are both conclusive evidence of an EFI-mode boot.

Good. I have an efi boot (incidentally the two 'conclusive' pieces of evidence are present in Mint as well as Ubuntu, in fact I have even more dmesg entries for EFI in mint than I do in Ubuntu, but as you say in your refind pages there can sometimes be dozens of them).

EFI boots using El Torito, in which a FAT filesystem is stored in a file and used as if it were a boot floppy. Thus, the presence or absence of .efi files on the ISO-9660 filesystem are actually irrelevant.

OK. that is good information, but I am just trying to work out a way of finding which mode I am using when booting from a dvd. The absence of any .efi files (wherever they might be placed) is likely to indicate that it is not an efi capable disk. The presence of such files should at least indicate that an attempt has been made to make the disc efi capable. Whether or not it has been a success is obviously another matter.

It's possible you could force an EFI-mode boot by removing BIOS-boot support from the boot medium. This is likely to be tricky for a CD/DVD boot because of the need to prepare an El Torito image with EFI but not BIOS support. It could be easier with a USB flash drive, though: Just prepare a USB flash drive with a FAT filesystem and do a file-level copy of everything in the ISO-9660 filesystem to the flash drive. OTOH, the installer might want to see a filesystem with a particular name, so you might need to set it appropriately or use a combination of the DVD and the USB flash drive to boot the computer to run the installer.

Tricky?? - You are a master of understatement Rod Do you think it is right that people should be having to do this? I know none of this is your fault, and I can't tell you how much I respect you for the time and trouble you have taken to try and make this subject accessible to people when most others just bury their heads in the sand and mutter "It just works" out of their backsides, but surely techniques like that are a step too far?

Another option is to prepare a hard disk partition that's at least as large as the disk and then do a low-level copy of the DVD to that partition, as in "sudo dd if=/dev/sr0 of=/dev/sda8" (or "sudo dd if=diskimage.iso of=/dev/sda8" to copy a disc image file), changing "/dev/sda8" as necessary. You can then install the rEFInd ISO-9660 driver and it should be able to boot from the image on the hard disk.

This sounds like a workable idea, but it really comes into the 'step too far' category.

Sometimes these devices are hidden from rEFInd if the firmware doesn't scan them. You might be able to get some entries by using your firmware's own boot manager or by adjusting firmware boot options to explicitly include the optical drive in the boot list.

My optical drive is included in the boot list in fact it is top of that list.

You've already explained it: Your EFI implementation is bug-ridden. It might be possible for Linux developers to include workarounds or fixes in tools like efibootmgr and rEFInd, but this would require that the developers have access to the hardware, or for somebody who owns the hardware and who has sufficient programming experience to submit a patch to the relevant application developers. (Speaking as the developer of rEFInd, I don't own any Samsung computer, and I lack the sort of budget that would enable me to buy one just to experiment with a known-buggy EFI implementation. If you care to lend me the computer, I can have a look at it, but I can't make any promises about finding fixes.)

Although I thank you for the offer, lending you my laptop is not really a practical solution given that firstly I use this machine on a day to day basis, it is not a test machine, and secondly we don't even live on the same continent!

A less radical solution is to check with Samsung to see if they've got an updated firmware.

I already flashed the bios to the latest version there are no other updates on offer (and I don't think there ever will be given the level of support they are offering with this machine).

If not, contact tech support.

About Linux! Get real!

You might also try using Fedora

I have already done so, the dvd certainly seems to boot in Uefi mode (as evidenced by the /sys/firmware and dmesg tests). I haven't installed it because I don't really like Fedora that much.

You can boot an EFI shell from rEFInd: Install it in the EFI/tools directory or the root directory on the ESP and it should show up as an option in the rEFInd menu, on the second row of (smaller) icons

I have a couple of things to say about that, they go together. Firstly I am not sure about this, but does Refind include an efi shell entry by default? The thing is, that when I first booted with Refind, I am pretty sure I remember seeing a shell entry in the second row of icons (not where I was expecting it to be I must say). Was this my own shell entry or was it a built-in entry? I assumed it was the latter. The trouble is I can't test this at the moment, because, as a result of messing around with my ESP last night I managed to lose access to two out of my three installed distros (only Mint was left, I don't know why it remained, but it did). I always keep partition images of all my partitions so I was able to replace the ESP and have a normal boot back within a few minutes, but unfortunately my shell entry is now gone because the partition image was made before I added the shell. The other point (and this may be a bug in refind, I am not sure). I do not like icons, I don't like them in file managers and I don't like them in boot managers either, so one of the first things I did after starting to use Refind was to change it to text mode (thank you for including that option btw). I did this well before trashing my ESP and therefore the shell file was still in place. I can however categorically assure you that there was no entry for the efi shell in the text mode of refind. The entries About, Reboot and Shutdown were all there, but the Shell entry wasn't.

One more comment: Given the severity of your problems, you should seriously consider ditching EFI-mode booting on your computer. This is most easily done by wiping the hard disk, creating a new MBR partition table on it, and re-installing everything; however, you can do it by converting from GPT to MBR and converting your existing OS installations, if necessary.

Given what happened last night you could well be right, although I am not going to do it given the effort it took me to get the darned thing going in the first place.

I guess I will just have to live with that small frisson of excitement when I boot up a live dvd or a distro and wonder which mode I will be in today.

Thanks for your help Rod, much appreciated. You are right in that my own problem, at the moment at least, is a fairly unique one and not worthy of any developers time, I understand that, but it won't stop me seeking answers to it or complaining about it. I wonder how many more unfortunates like me there will be before Uefi boot reaches the maturity of bios boot?

tdockery97 wrote:For those of us who either don't buy into the necessity for, or don't give a flip about EFI and Secure Boot, the solution is so simple. I've disabled secure boot and use legacy BIOS mode. That way I have the advantage of the GPT partitioning scheme of all primary partitions, and can run whatever I want on my machine.

The solution is simple for you Todd, not for me, I don't have any option to choose which mode I use, I just have to accept whatever mode it thinks it will boot in today. My only option is to completely erase my hard disk and start over, and I am not even sure if that will work, because that I how I started with this machine when I bought it, (a blank disk) and it still ended up with whatever it is I have now. My efi implementation is a nightmare over which I have absolutely no control.

viking777 wrote:OK. that is good information, but I am just trying to work out a way of finding which mode I am using when booting from a dvd. The absence of any .efi files (wherever they might be placed) is likely to indicate that it is not an efi capable disk. The presence of such files should at least indicate that an attempt has been made to make the disc efi capable. Whether or not it has been a success is obviously another matter.

That's not absolutely certain. OpenSUSE, for instance, provides a DVD with no files that end in .efi on the ISO-9660 filesystem. There is, though, an El Torito image that will boot the disc in EFI mode on at least some computers.

It's possible you could force an EFI-mode boot by removing BIOS-boot support from the boot medium. This is likely to be tricky for a CD/DVD boot

Tricky?? - You are a master of understatement Rod Do you think it is right that people should be having to do this?

Of course I'm not suggesting that people should have to do that. I was offering a possible workaround for your particular (and rare) problem. What's more, as time goes on, tools like UNetbootin could incorporate such functionality -- to prepare an EFI-only or BIOS-only disk from a hybrid-boot image file.

most others just bury their heads in the sand and mutter "It just works" out of their backsides

In point of fact, on many computers it does "just work." Based on your posts, your computer seems to be at the extreme "bad" end of the range, which skews your perception of the issue. The author of the piece linked to a few posts earlier has probably had experience with computers in the middle or at the other end of the range. Personally, I really only got a good handle on EFI issues after I'd dealt with three or four implementations; it's only after seeing several EFIs that you can begin to see what's common between them, what represents implementation-specific features, and what represents implementation-specific bugs.

If not, contact tech support.

About Linux! Get real!

I am. Your problem is with the firmware. The firmware's decision of how to boot (BIOS vs. EFI), and lack of explicit options to control this, is by definition a pre-boot issue that has the potential to affect all OSes, not just Linux. Furthermore, if Linux users don't bother to complain to manufacturers about their cruddy products, the manufacturers might not even realize they've got a problem. Although I agree that most manufacturers are unlikely to be very responsive to this problem, a slim chance of a positive response is better than no chance of a response -- the latter is certain if you don't contact them.

does Refind include an efi shell entry by default? The thing is, that when I first booted with Refind, I am pretty sure I remember seeing a shell entry in the second row of icons (not where I was expecting it to be I must say). Was this my own shell entry or was it a built-in entry?

There is no shell built into the rEFInd binary per se; instead, rEFInd searches for a shell binary in certain locations (the root of the ESP and the ESP's EFI/tools directory). If it finds one, it shows the icon by default. (An existing shell can be disabled by using the "showtools" option in refind.conf, though.)

The rEFInd CD and USB flash drive images include a shell binary, since those packages are intended as emergency recovery systems more than as a way to install rEFInd. I don't include a shell in the main rEFInd binary packages, though. Thus, you may have seen a shell if you booted from a USB flash drive or CD version of rEFInd, and it would have disappeared if/when you installed rEFInd to your hard disk. Getting it back is a matter of copying the file. EFI shell binaries can be found various places. You can find links in the rEFInd documentation, and more are available in the Arch Linux wiki, among other places.

one of the first things I did after starting to use Refind was to change it to text mode (thank you for including that option btw). I did this well before trashing my ESP and therefore the shell file was still in place. I can however categorically assure you that there was no entry for the efi shell in the text mode of refind. The entries About, Reboot and Shutdown were all there, but the Shell entry wasn't.

If the shell binary is present and if it's not been disabled by removing it from the "showtools" option, the shell will appear in both the GUI and the text-mode views. In fact, I just went and double-checked this on the latest version. The EFI shell appears as "Start EFI Shell" in text mode.

You are right in that my own problem, at the moment at least, is a fairly unique one and not worthy of any developers time, I understand that, but it won't stop me seeking answers to it or complaining about it. I wonder how many more unfortunates like me there will be before Uefi boot reaches the maturity of bios boot?

I didn't mean to suggest that fixing obscure bugs was "not worthy of any developers time"; I was just pointing out that obscure bugs are difficult to fix in the open source world, simply because so much of the development is done in a distributed fashion and depends on developers with the correct skills having access to the affected hardware. They're worth fixing -- it's just that developers like me, who get little or no support, lack the resources to fix certain problems. I can't justify buying a sample of every computer whose users report problems that I can't reproduce on any of my own computers, for instance. I'm sure that Red Hat, Novell, and Canonical can afford a wider range of hardware, but none of them is including rEFInd with their distributions. They are all including efibootmgr, though, so trying those distributions and filing bug reports with them about your efibootmgr problem might bear fruit. Still, whatever problem you're running into with efibootmgr is likely to be pretty obscure. (Unless perhaps its a permissions issue -- you have been running it as root or via sudo, haven't you?)

The rEFInd CD and USB flash drive images include a shell binary, since those packages are intended as emergency recovery systems more than as a way to install rEFInd. I don't include a shell in the main rEFInd binary packages, though. Thus, you may have seen a shell if you booted from a USB flash drive or CD version of rEFInd

I have tried various versions of Refind, the current one is the binary zip file installed to a usb key with these instructions:

Tip: If you want to make your own bootable USB flash drive, download the binary zip file or CD-R image file, prepare a USB flash drive with a FAT32 partition, and then use the install.sh program's --usedefault option, and perhaps the --alldrivers option, as in bash install.sh --usedefault /dev/sdd1 --alldrivers to install to the first partition on /dev/sdd. This procedure should work even on a BIOS-booted computer.

I guess this is not supposed to have a shell of its own. I replaced the efi shell into the ESP

But it still isn't shown by refind (sorry about the pic quality, not easy with a phone taking pics of a screen - too many reflections).

2013-02-22 18.27.15.jpg (150.71 KiB) Viewed 7420 times

What's more, as time goes on, tools like UNetbootin could incorporate such functionality -- to prepare an EFI-only or BIOS-only disk from a hybrid-boot image file.

I really hope so.

I understand your point - for some people Uefi does work, and a person's judgement is bound to be decide by their own experiences and mine have been completely negative.

Thanks once again for trying to help, but it looks like in my case there is no easy solution. I might consider your suggestion of filing bugs against efibootmgr as that is certainly a factor for me. In fact back in December I already filed a bug which is slightly relevant to this and is still unaddressed:

If your ESP is mounted at /boot/efi (as is typical on a Mint installation), the EFI shell should be in /boot/efi/EFI/tools, not in /boot/efi/Tools. Typing "sudo mv /boot/efi/Tools /boot/efi/EFI/" should make the shell appear in the rEFInd menu.

As a side note, this doubling-up of "efi" in the path seems to trip up a lot of people. It's not really an EFI problem, though; it's a consequence of somebody's decision about where it makes sense to mount the ESP. With hindsight, I think I'd either mount it at /boot/esp or at /boot to avoid that problem -- but mounting it at /boot would create a new set of problems. It works well in practice if you can prepare your ESP yourself rather than rely on an existing one, and is a popular choice among users of Arch Linux; but when installing on a dual-boot system with an existing ESP, mounting at /boot can result in errors if the disk fills up.

But it still isn't shown by refind (sorry about the pic quality, not easy with a phone taking pics of a screen - too many reflections).

2013-02-22 18.27.15.jpg

When it's present in text mode, the EFI shell will appear below the OS entries that you've shown in this screen shot.

Thanks once again for trying to help, but it looks like in my case there is no easy solution. I might consider your suggestion of filing bugs against efibootmgr as that is certainly a factor for me. In fact back in December I already filed a bug which is slightly relevant to this and is still unaddressed:

I doubt if the second of those is related to your problem. The first is of course your bug report, but I believe you filed the bug report against GRUB when it's really a bug in the firmware that affects the kernel and/or efibootmgr. There's not much GRUB can do if the files it relies upon aren't present.

If your ESP is mounted at /boot/efi (as is typical on a Mint installation), the EFI shell should be in /boot/efi/EFI/tools, not in /boot/efi/Tools. Typing "sudo mv /boot/efi/Tools /boot/efi/EFI/" should make the shell appear in the rEFInd menu.

I moved it to /boot/efi/EFI/Tools/Shell.efi.It still doesn't show up

Don't worry about it, from the little I saw of it when it did choose to appear it wasn't worth the bother anyway. Although I guess there are different versions, the one I am using now (or trying to use I should say) is the 64bit from the Arch wiki link you gave me, and I have both versions installed, the beta and the old, neither of them are seen. Another interesting point about that wiki article is that the command they talk most about is 'bcfg'. On the shell I did get to see (the one provided by your USB flash drive image I think) that command didn't even exist, so if the Arch wiki writers don't have a grasp on this, the rest of us have no chance.

If your ESP is mounted at /boot/efi (as is typical on a Mint installation), the EFI shell should be in /boot/efi/EFI/tools, not in /boot/efi/Tools. Typing "sudo mv /boot/efi/Tools /boot/efi/EFI/" should make the shell appear in the rEFInd menu.

(Change the path to refind.conf if rEFInd is installed somewhere else on your system.)

Don't worry about it, from the little I saw of it when it did choose to appear it wasn't worth the bother anyway.

Like bash, it's definitely worth having once you know how to use it.

Another interesting point about that wiki article is that the command they talk most about is 'bcfg'. On the shell I did get to see (the one provided by your USB flash drive image I think) that command didn't even exist, so if the Arch wiki writers don't have a grasp on this, the rest of us have no chance.

Please read the wiki more thoroughly. There's a rather prominent Note that reads:

Arch wiki wrote:Note: UEFI Shell 1.0 does not support bcfg command.

The version I include in my USB flash drive and CD images is the version 1 shell because the version 2 shell doesn't work on many older implementations -- and "older" includes many computers sold as new as recently as a year ago.

That all looks OK. I do have one suggestion, though: Rename /boot/efi/EFI/Tools/Shell.efi to /boot/efi/EFI/tools/shell.efi. Case shouldn't matter on a FAT filesystem, but there is at least one buggy EFI implementation in which it does, and rEFInd codes the name in lowercase (both "shell.efi" and "tools"), although the "EFI" directory is in uppercase. (I used the case that has seemed to be most common in my experience, hence the inconsistency.) Note that you'll probably have to rename to an unrelated name and then back to the same name with different case, since "mv" will refuse to rename to a name that differs only in case on a FAT filesystem. You could also try renaming shell.efi to shellx64.efi. That shouldn't matter, since it should scan for both filenames, but it's worth a try....

Thanks for that srs, I tried both of those renames (removing the capitals and adding x64 to the name) and neither resulted in the shell being visible. I even went back to 'icon' mode to see if that makes a difference, but it doesn't.

I also tried another experiment I inserted my Fedora 17 disc into the cd tray (which I know is Uefi because left to its own devices it boots into Uefi mode). I then booted from Refind on the usbkey to see if it showed any differences. Indeed it did, but not the ones I wanted. Amusingly, as well as the usual entries it asked me if I would like to boot MacOSx from a 1Mb partition . Of course I accepted the offer (I have never used OsX ) but unsurprisingly all I got was a grub prompt. It also offered me another choice - Boot from fallback loader on BOOT. Now the Fedora cd does have an entry (on the iso9660 filesystem of course) called /EFI/BOOT/BOOTX64.efi so I presume that is what it meant. Naturally I tried this as well and got another grub prompt (strange also that in both cases the grub prompt was for the 0.97 version of grub - ie grub legacy, not what I would have expected). I booted again from Refind without the Fedora disk in and these two entries had disappeared. If nothing else it proves that Refind is scanning my dvd drive even if it is not picking up anything remotely bootable.

Feel free to respond if you wish, but I think personally I have given up trying to make sense of what is happening here (for the time being at least), thanks for your excellent support.

Edit> I found an answer to the grub legacy question Fed17 uses grub-legacy-fedora-git which includes gpt patches. Apparently they switched to grub2 in Fed18.

viking777 wrote:Thanks for that srs, I tried both of those renames (removing the capitals and adding x64 to the name) and neither resulted in the shell being visible. I even went back to 'icon' mode to see if that makes a difference, but it doesn't.

My best guess at this point is that you've got filesystem damage on your ESP. I've seen similar things in the past; the FAT driver that's included in most EFIs seems to be rather finicky at best, and it can sometimes ignore files that other FAT drivers can see just fine. The only solution I'm aware of is to do a file-level backup of the ESP, create a fresh FAT filesystem on the partition, and restore all the files.

I also tried another experiment I inserted my Fedora 17 disc into the cd tray (which I know is Uefi because left to its own devices it boots into Uefi mode). I then booted from Refind on the usbkey to see if it showed any differences. Indeed it did, but not the ones I wanted. Amusingly, as well as the usual entries it asked me if I would like to boot MacOSx from a 1Mb partition . Of course I accepted the offer (I have never used OsX ) but unsurprisingly all I got was a grub prompt.

This is because Fedora is bending over backwards to make its media bootable on anything. This includes creating a boot disc that has Mac-specific features that make it look like an OS X boot disc to a Mac -- and to rEFInd. Naturally, the program it boots is GRUB, not OS X.

It also offered me another choice - Boot from fallback loader on BOOT. Now the Fedora cd does have an entry (on the iso9660 filesystem of course) called /EFI/BOOT/BOOTX64.efi so I presume that is what it meant. Naturally I tried this as well and got another grub prompt (strange also that in both cases the grub prompt was for the 0.97 version of grub - ie grub legacy, not what I would have expected).

Through version 17, Fedora used its own patched version of GRUB Legacy as an EFI-mode boot loader, although Fedora switched to GRUB 2 for BIOS-mode boots a couple of versions earlier. Fedora 18 has switched to GRUB 2 to EFI-mode booting, though.