[SOLVED] Board no longer sees uefi as boot option

Mgrim · 2013-03-05 03:30:33

Hi,

I installed Arch on an ssd and was using rEFind to boot the system. It was working fine until I unhooked the ssd from the Mobo to install a hard drive with an old version of arch.( I was going to use the hd for extra space) However, when I hooked my ssd back up the bios did not detect the uefi. It shows the ssd but not the option to boot with uefi.

When I run lsblk -f from my old installation I can see that the ssd is not mounted to anything. I can mount the ssd with the old installation and see all my files. I just can't boot to the ssd. Any Ideas?

I have an Asus mobo and a Kingston ssd. Probably not relevant info but thought I would mention it just in-case.

Last edited by Mgrim (2013-03-08 05:42:47)

frank604 · 2013-03-05 03:40:30

I never owned a uefi pc so I may go about this wrong, but I'm sure more info would help. Could you show us your fstab and lsblk -f outputs? Also, ls -l /dev/disk/by-partuuid/ and your refind conf?

https://wiki.archlinux.org/index.php/UE … ing_rEFInd
https://wiki.archlinux.org/index.php/SSD

Last edited by frank604 (2013-03-05 03:42:20)

WonderWoofy · 2013-03-05 03:42:20

Sometimes motherboards can be extra "helpful" and turn on and off things with its auto-detection. Have you checked in your bios to see if it is set to do uefi+legacy bios? As it sounds as though it somehow got set to legacy bios only.

Note: Your motherboard may have different names for these settings.

Mgrim · 2013-03-05 03:51:21

Wow I wasn't expecting such a fast response. Thanks guys
Here is my lsblk -f
sda
├─sda1 /boot
├─sda2 [SWAP]
├─sda3 /
└─sda4 /home
sdb
├─sdb1
├─sdb2
├─sdb3
└─sdb4

I'm not sure how to generate an fstab output. Should I just post what in my

#
# /etc/fstab: static file system information
#
# <file system> <dir> <type> < options> <dump> <pass>
# /dev/sda1
UUID=109fdf23-7155-4097-891f-8e9ddb68bfa2 / ext4 rw,relatime,data=ordered 0 1

# /dev/sda2
UUID=d97e0e1a-4264-45a0-8a10-1f2139051b35 /home ext4 rw,relatime,data=ordered 0 2

# /dev/sda3
UUID=867B-71F6 /boot/efi vfat noatime 0 2

Mgrim · 2013-03-05 04:03:09

ls -l /dev/disk/by-partuuid/ output

lrwxrwxrwx 1 root root 10 Mar 4 15:12 0c20bfb2-b03b-467f-9faf-d8f7311027ec -> ../../sdb4
lrwxrwxrwx 1 root root 10 Mar 4 15:12 38362986-f8ad-416d-86eb-659f7e78f8c3 -> ../../sdb1
lrwxrwxrwx 1 root root 10 Mar 4 15:12 628b4764-b385-4f6c-a92c-8c1ccc551e19 -> ../../sdb3
lrwxrwxrwx 1 root root 10 Mar 4 15:12 82e01db0-b264-4555-910d-aa020bccb086 -> ../../sdb2
-not sure how to do this for sda drive

refind.conf

#
# refind.conf
# Configuration file for the rEFInd boot menu
#

# Timeout in seconds for the main menu screen. Setting the timeout to 0
# disables automatic booting (i.e., no timeout).
#
timeout 20

# Hide user interface elements for personal preference or to increase
# security:
#  banner      - the rEFInd title banner
#  label       - text label in the menu
#  singleuser  - remove the submenu options to boot Mac OS X in single-user
#                or verbose modes; affects ONLY MacOS X
#  hwtest      - the submenu option to run Apple's hardware test
#  arrows      - scroll arrows on the OS selection tag line
#  all         - all of the above
#
#hideui singleuser
#hideui all

# Set the name of a subdirectory in which icons are stored. Icons must
# have the same names they have in the standard directory. The directory
# name is specified relative to the main rEFInd binary's directory. If
# an icon can't be found in the specified directory, an attempt is made
# to load it from the default directory; thus, you can replace just some
# icons in your own directory and rely on the default for others.
# Default is "icons".
#
#icons_dir myicons

# Use a custom title banner instead of the rEFInd icon and name. The file
# path is relative to the directory where refind.efi is located. The color
# in the top left corner of the image is used as the background color
# for the menu screens. Currently uncompressed BMP images with color
# depths of 24, 8, 4 or 1 bits are supported.
#
#banner hostname.bmp

# Custom images for the selection background. There is a big one (144 x 144)
# for the OS icons, and a small one (64 x 64) for the function icons in the
# second row. If only a small image is given, that one is also used for
# the big icons by stretching it in the middle. If only a big one is given,
# the built-in default will be used for the small icons.
#
# Like the banner option above, these options take a filename of an
# uncompressed BMP image file with a color depth of 24, 8, 4, or 1 bits.
#
#selection_big   selection-big.bmp
#selection_small selection-small.bmp

# Use text mode only. When enabled, this option forces rEFInd into text mode.
#
#textonly

# Set the screen's video resolution. Pass this option two values,
# corresponding to the X and Y resolutions. Note that not all resolutions
# are supported. On UEFI systems, passing an incorrect value results in a
# message being shown on the screen to that effect, along with a list of
# supported modes. On EFI 1.x systems (e.g., Macintoshes), setting an
# incorrect mode silently fails. On both types of systems, setting an
# incorrect resolution results in the default resolution being used.
# A resolution of 1024x768 usually works, but higher values often don't.
# Default is "0 0" (use the system default resolution, usually 800x600).
#
#resolution 1024 768

# Launch specified OSes in graphics mode. By default, rEFInd switches
# to text mode and displays basic pre-launch information when launching
# all OSes except OS X. Using graphics mode can produce a more seamless
# transition, but displays no information, which can make matters
# difficult if you must debug a problem. Also, on at least one known
# computer, using graphics mode prevents a crash when using the Linux
# kernel's EFI stub loader. You can specify an empty list to boot all
# OSes in text mode.
# Valid options:
#   osx     - Mac OS X
#   linux   - A Linux kernel with EFI stub loader
#   elilo   - The ELILO boot loader
#   grub    - The GRUB (Legacy or 2) boot loader
#   windows - Microsoft Windows
# Default value: osx
#
#use_graphics_for osx,linux

# Which non-bootloader tools to show on the tools line, and in what
# order to display them:
#  shell           - the EFI shell (requires external program; see rEFInd
#                    documentation for details)
#  gptsync         - the (dangerous) gptsync.efi utility (requires external
#                    program; see rEFInd documentation for details)
#  apple_recovery  - boots the Apple Recovery HD partition, if present
#  mok_tool        - makes available the Machine Owner Key (MOK) maintenance
#                    tool, MokManager.efi, used on Secure Boot systems
#  about           - an "about this program" option
#  exit            - a tag to exit from rEFInd
#  shutdown        - shuts down the computer (a bug causes this to reboot
#                    EFI systems)
#  reboot          - a tag to reboot the computer
# Default is shell,apple_recovery,mok_tool,about,shutdown,reboot
#
#showtools shell, mok_tool, about, reboot, exit

# Directories in which to search for EFI drivers. These drivers can
# provide filesystem support, give access to hard disks on plug-in
# controllers, etc. In most cases none are needed, but if you add
# EFI drivers and you want rEFInd to automatically load them, you
# should specify one or more paths here. rEFInd always scans the
# "drivers" and "drivers_{arch}" subdirectories of its own installation
# directory (where "{arch}" is your architecture code); this option
# specifies ADDITIONAL directories to scan.
# Default is to scan no additional directories for EFI drivers
#
#scan_driver_dirs EFI/tools/drivers,drivers

# Which types of boot loaders to search, and in what order to display them:
#  internal      - internal EFI disk-based boot loaders
#  external      - external EFI disk-based boot loaders
#  optical       - EFI optical discs (CD, DVD, etc.)
#  hdbios        - BIOS disk-based boot loaders
#  biosexternal  - BIOS external boot loaders (USB, eSATA, etc.)
#  cd            - BIOS optical-disc boot loaders
#  manual        - use stanzas later in this configuration file
# Note that the legacy BIOS options require firmware support, which is
# not present on all computers.
# On UEFI PCs, default is internal,external,optical,manual
# On Macs, default is internal,hdbios,external,biosexternal,optical,cd,manual
#
#scanfor internal,external,optical,manual

# Delay for the specified number of seconds before scanning disks.
# This can help some users who find that some of their disks
# (usually external or optical discs) aren't detected initially,
# but are detected after pressing Esc.
# The default is 0.
#
#scan_delay 5

# When scanning volumes for EFI boot loaders, rEFInd always looks for
# Mac OS X's and Microsoft Windows' boot loaders in their normal locations,
# and scans the root directory and every subdirectory of the /EFI directory
# for additional boot loaders, but it doesn't recurse into these directories.
# The also_scan_dirs token adds more directories to the scan list.
# Directories are specified relative to the volume's root directory. This
# option applies to ALL the volumes that rEFInd scans. If a specified
# directory doesn't exist, it's ignored (no error condition results).
# The default is to scan no additional directories.
#
#also_scan_dirs boot,EFI/linux/kernels

# Directories that should NOT be scanned for boot loaders. By default,
# rEFInd doesn't scan its own directory or the EFI/tools directory.
# You can "blacklist" additional directories with this option, which
# takes a list of directory names as options. You might do this to
# keep EFI/boot/bootx64.efi out of the menu if that's a duplicate of
# another boot loader or to exclude a directory that holds drivers
# or non-bootloader utilities provided by a hardware manufacturer. If
# a directory is listed both here and in also_scan_dirs, dont_scan_dirs
# takes precedence. Note that this blacklist applies to ALL the
# filesystems that rEFInd scans, not just the ESP.
#
#dont_scan_dirs EFI/boot,EFI/Dell

# Files that should NOT be included as EFI boot loaders (on the
# first line of the display). If you're using a boot loader that
# relies on support programs or drivers that are installed alongside
# the main binary or if you want to "blacklist" certain loaders by
# name rather than location, use this option. Note that this will
# NOT prevent certain binaries from showing up in the second-row
# set of tools. Most notably, MokManager.efi is in this blacklist,
# but will show up as a tool if present in certain directories. You
# can control the tools row with the showtools token.
# The default is shim.efi,MokManager.efi,TextMode.efi,ebounce.efi,GraphicsConsole.efi
#
#dont_scan_files shim.efi,MokManager.efi

# Scan for Linux kernels that lack a ".efi" filename extension. This is
# useful for better integration with Linux distributions that provide
# kernels with EFI stub loaders but that don't give those kernels filenames
# that end in ".efi", particularly if the kernels are stored on a
# filesystem that the EFI can read. When uncommented, this option causes
# all files in scanned directories with names that begin with "vmlinuz"
# or "bzImage" to be included as loaders, even if they lack ".efi"
# extensions. The drawback to this option is that it can pick up kernels
# that lack EFI stub loader support and other files. Most notably, if you
# want to give a kernel a custom icon by placing an icon with the kernel's
# filename but a ".icns" extension in the same directory as the kernel, this
# option will cause the icon file to show up as a non-functional loader tag.
# Default is to NOT scan for kernels without ".efi" extensions.
#
scan_all_linux_kernels

# Set the maximum number of tags that can be displayed on the screen at
# any time. If more loaders are discovered than this value, rEFInd shows
# a subset in a scrolling list. If this value is set too high for the
# screen to handle, it's reduced to the value that the screen can manage.
# If this value is set to 0 (the default), it's adjusted to the number
# that the screen can handle.
#
#max_tags 0

# Set the default menu selection.  The available arguments match the
# keyboard accelerators available within rEFInd.  You may select the
# default loader using:
#  - A digit between 1 and 9, in which case the Nth loader in the menu
#    will be the default. 
#  - Any substring that corresponds to a portion of the loader's title
#    (usually the OS's name or boot loader's path).
#
#default_selection 1

# Sample manual configuration stanzas. Each begins with the "menuentry"
# keyword followed by a name that's to appear in the menu (use quotes
# if you want the name to contain a space) and an open curly brace
# ("{"). Each entry ends with a close curly brace ("}"). Common
# keywords within each stanza include:
#
#  volume    - identifies the filesystem from which subsequent files
#              are loaded. You can specify the volume by label or by
#              a number followed by a colon (as in "0:" for the first
#              filesystem or "1:" for the second).
#  loader    - identifies the boot loader file
#  initrd    - Specifies an initial RAM disk file
#  icon      - specifies a custom boot loader icon
#  ostype    - OS type code to determine boot options available by
#              pressing Insert. Valid values are "MacOS", "Linux",
#              "Windows", and "XOM". Case-sensitive.
#  graphics  - set to "on" to enable graphics-mode boot (useful
#              mainly for MacOS) or "off" for text-mode boot.
#              Default is auto-detected from loader filename.
#  options   - sets options to be passed to the boot loader; use
#              quotes if more than one option should be passed or
#              if any options use characters that might be changed
#              by rEFInd parsing procedures (=, /, #, or tab).
#  disabled  - use alone or set to "yes" to disable this entry.
#
# Note that you can use either DOS/Windows/EFI-style backslashes (\)
# or Unix-style forward slashes (/) as directory separators. Either
# way, all file references are on the ESP from which rEFInd was
# launched.
# Use of quotes around parameters causes them to be interpreted as
# one keyword, and for parsing of special characters (spaces, =, /,
# and #) to be disabled. This is useful mainly with the "options"
# keyword. Use of quotes around parameters that specify filenames is
# permissible, but you must then use backslashes instead of slashes,
# except when you must pass a forward slash to the loader, as when
# passing a root= option to a Linux kernel.

# Below are several sample boot stanzas. All are disabled by default.
# Find one similar to what you need, copy it, remove the "disabled" line,
# and adjust the entries to suit your needs.

# A sample entry for a Linux 3.3 kernel with its new EFI boot stub
# support on a filesystem called "KERNELS". This entry includes
# Linux-specific boot options and specification of an initial RAM disk.
# Note uses of Linux-style forward slashes, even in the initrd
# specification. Also note that a leading slash is optional in file
# specifications.
menuentry Linux {
	icon EFI/refind/icons/os_linux.icns
	volume KERNELS
	loader bzImage-3.3.0-rc7
	initrd initrd-3.3.0.img
	options "ro root=UUID=5f96cafa-e0a7-4057-b18f-fa709db5b837"
	disabled
}

# A sample entry for loading Ubuntu using its standard name for
# its GRUB 2 boot loader. Note uses of Linux-style forward slashes
menuentry Ubuntu {
	loader /EFI/ubuntu/grubx64.efi
	icon /EFI/refined/icons/os_linux.icns
	disabled
}

# A minimal ELILO entry, which probably offers nothing that
# auto-detection can't accomplish.
menuentry "ELILO" {
	loader \EFI\elilo\elilo.efi
	disabled
}

# Like the ELILO entry, this one offers nothing that auto-detection
# can't do; but you might use it if you want to disable auto-detection
# but still boot Windows....
menuentry "Windows 7" {
	loader \EFI\Microsoft\Boot\bootmgfw.efi
	disabled
}

# EFI shells are programs just like boot loaders, and can be
# launched in the same way. You can pass a shell the name of a
# script that it's to run on the "options" line. The script
# could initialize hardware and then launch an OS, or it could
# do something entirely different.
menuentry "Windows via shell script" {
	icon \EFI\refind\icons\os_win.icns
	loader \EFI\tools\shell.efi
	options "fs0:\EFI\tools\launch_windows.nsh"
	disabled
}

# Mac OS is normally detected and run automatically; however,
# if you want to do something unusual, a manual boot stanza may
# be the way to do it. This one does nothing very unusual, but
# it may serve as a starting point. Note that you'll almost
# certainly need to change the "volume" line for this example
# to work.
menuentry "My Mac OS X" {
	icon \EFI\refind\icons\os_mac.icns
	volume "OS X boot"
	loader \System\Library\CoreServices\boot.efi
	disabled
}

Last edited by Mgrim (2013-03-05 16:07:44)

jasonwryan · 2013-03-05 05:35:58

Please use code tags when pasting to the boards:
https://wiki.archlinux.org/index.php/Fo … s_and_Code

srs5694 · 2013-03-05 16:22:19

WonderWoofy wrote:

Sometimes motherboards can be extra "helpful" and turn on and off things with its auto-detection. Have you checked in your bios to see if it is set to do uefi+legacy bios? As it sounds as though it somehow got set to legacy bios only.

I believe you're on the right track, but it's not likely to be the firmware settings; it's likely to be the entry for rEFInd itself that's been lost. At least two of my UEFI motherboards do this -- when a disk is unplugged and the computer powered on, the firmware removes any boot manager entries that refer to boot programs on that disk. The result is that the disk becomes unbootable until the entry is restored.

Sometimes you can restore the entry using a user interface in the firmware itself; however, this seems to be rare. Chances are you'll need to boot either to an EFI shell or to Linux using an emergency boot tool. Since Mgrim says that rEFInd was in use, my suggestion is to create a bootable USB flash drive or CD-R of rEFInd -- images for both are available on the rEFInd downloads page. It should then be possible to launch Linux (possibly directly, or definitely by launching rEFInd on the main system disk from the emergency rEFInd). In Linux, use efibootmgr to restore rEFInd as a boot option. Both possibilities are covered in the rEFInd documentation and the Arch wiki.

swordfish · 2013-03-05 16:50:30

Mgrim wrote:

Here is my lsblk -f
sda
├─sda1 /boot
├─sda2 [SWAP]
├─sda3 /
└─sda4 /home
sdb
├─sdb1
├─sdb2
├─sdb3
└─sdb4
I'm not sure how to generate an fstab output. Should I just post what in my
#
# /etc/fstab: static file system information
#
# <file system> <dir> <type> < options> <dump> <pass>
# /dev/sda1
UUID=109fdf23-7155-4097-891f-8e9ddb68bfa2 / ext4 rw,relatime,data=ordered 0 1
# /dev/sda2
UUID=d97e0e1a-4264-45a0-8a10-1f2139051b35 /home ext4 rw,relatime,data=ordered 0 2
# /dev/sda3
UUID=867B-71F6 /boot/efi vfat noatime 0 2

In lsblk / is mounted to sda3, but in your /etc/fstab it is mounted to sda1 and /boot/efi is mounted to sda3. It's either a typo or you've messed up something

Mgrim · 2013-03-06 22:31:37

Thanks for your answers. I believe srs5694 is right on the heart of the matter. Though, I think it's weird that a Mobo would be able to delete something on a drive. Anyway, following this logic, I was able to boot my system by directly accessing refind through the efi shell. Now the trick will be restoring the boot record so that it boots automatically.

Mgrim · 2013-03-08 05:36:47

Thank You Gentlemen, I have restored my lost boot record with the EFI shell and the instructions on the wiki. Case closed!!

srs5694 · 2013-03-08 17:49:15

Mgrim wrote:

Thanks for your answers. I believe srs5694 is right on the heart of the matter. Though, I think it's weird that a Mobo would be able to delete something on a drive.

The firmware isn't deleting files, just references to files in the firmware's NVRAM. EFI has its own boot manager, which stores a list of boot loaders in NVRAM. I'm not sure what the developers' reason for doing it this way was, but in practice it's turning out to be a source of problems (like yours), since it creates an extra possible point of failure in the boot process -- if the NVRAM entry is deleted or damaged, the system stops booting until that problem is fixed.

WonderWoofy · 2013-03-08 20:20:05

srs5694 wrote:

I believe you're on the right track, but it's not likely to be the firmware settings; it's likely to be the entry for rEFInd itself that's been lost. At least two of my UEFI motherboards do this -- when a disk is unplugged and the computer powered on, the firmware removes any boot manager entries that refer to boot programs on that disk. The result is that the disk becomes unbootable until the entry is restored.

This is a most ridiculous design decision. I am not sure how any reasonable person might think that this would be a good thing to implement on a system.

@OP, I always keep something as \EFI\boot\bootx64.efi as a "if all else fails" kind of thing. I had this as the UEFI shell, but the most recent update of Gummiboot, seemed to automatically copy itself to this position (as well as \EFI\arch\gummibootx64.efi). But this is okay, since I also have an entry there to boot into the UEFI shell.

srs5694 · 2013-03-09 01:42:48

WonderWoofy wrote:

srs5694 wrote:
I believe you're on the right track, but it's not likely to be the firmware settings; it's likely to be the entry for rEFInd itself that's been lost. At least two of my UEFI motherboards do this -- when a disk is unplugged and the computer powered on, the firmware removes any boot manager entries that refer to boot programs on that disk. The result is that the disk becomes unbootable until the entry is restored.
This is a most ridiculous design decision. I am not sure how any reasonable person might think that this would be a good thing to implement on a system.

I agree, but we're stuck with it, at least on certain models.

@OP, I always keep something as \EFI\boot\bootx64.efi as a "if all else fails" kind of thing. I had this as the UEFI shell, but the most recent update of Gummiboot, seemed to automatically copy itself to this position (as well as \EFI\arch\gummibootx64.efi). But this is okay, since I also have an entry there to boot into the UEFI shell.

There's a little program that was included with rEFIt called "ebounce" that does nothing more than launch another boot loader (e.efi or elilo.efi). It seemed pointless to me when I began working on rEFInd, but I'm thinking of dusting it off and updating it to launch rEFInd so that it can be used as EFI/BOOT/bootx64.efi or as grubx64.efi on a system with Secure Boot and shim.

cfr · 2013-03-09 02:28:37

I use the default location trick as well. I have grub there though rEFInd is the default. If I need to reset the firmware settings to default (e.g. to get bluetooth working is the usual reason), it wipes all entries from the EFI boot list. And there is no way to restore them without booting but you can't boot because the firmware finds nothing to boot. (The built-in entries are still there but if you wiped the Windows install, Lenovo's restore etc., you are out of luck.) The default location works great though. If the entries disappear, the firmware still finds and boots grub.

(I've never managed to boot into an EFI shell, though. Even though the wiki claims one should be built-in.)

Last edited by cfr (2013-03-09 02:30:20)

WonderWoofy · 2013-03-09 02:50:53

@cfr, I have never been able to get to this fabled firmware UEFI shell either. Honestly, I think that it is typical for Tiano SecureCore to have this, but I have also never heard a thinkpad owner indicate that it is present on their machine.

I too have reset my bios, but not intentionally. On my machine (and I presume others), F10 is "save and exit" while F9 is "reset to defaults"... stupid design decision if you ask me.

cfr · 2013-03-09 03:53:22

Lots of dumb design decisions. Zapping the EFI menu on resetting BIOS defaults is one of them. At least, it is if you don't provide a way to restore the entries or to boot the machine!

Arch Linux

#1 2013-03-05 03:30:33

[SOLVED] Board no longer sees uefi as boot option

#2 2013-03-05 03:40:30

Re: [SOLVED] Board no longer sees uefi as boot option

#3 2013-03-05 03:42:20

Re: [SOLVED] Board no longer sees uefi as boot option

#4 2013-03-05 03:51:21

Re: [SOLVED] Board no longer sees uefi as boot option

#5 2013-03-05 04:03:09

Re: [SOLVED] Board no longer sees uefi as boot option

#6 2013-03-05 05:35:58

Re: [SOLVED] Board no longer sees uefi as boot option

#7 2013-03-05 16:22:19

Re: [SOLVED] Board no longer sees uefi as boot option

#8 2013-03-05 16:50:30

Re: [SOLVED] Board no longer sees uefi as boot option

#9 2013-03-06 22:31:37

Re: [SOLVED] Board no longer sees uefi as boot option

#10 2013-03-08 05:36:47

Re: [SOLVED] Board no longer sees uefi as boot option

#11 2013-03-08 17:49:15

Re: [SOLVED] Board no longer sees uefi as boot option

#12 2013-03-08 20:20:05

Re: [SOLVED] Board no longer sees uefi as boot option

#13 2013-03-09 01:42:48

Re: [SOLVED] Board no longer sees uefi as boot option

#14 2013-03-09 02:28:37

Re: [SOLVED] Board no longer sees uefi as boot option

#15 2013-03-09 02:50:53

Re: [SOLVED] Board no longer sees uefi as boot option

#16 2013-03-09 03:53:22

Re: [SOLVED] Board no longer sees uefi as boot option

Board footer