Difference between revisions of "Unified Extensible Firmware Interface (Español)"

From ArchWiki
Jump to: navigation, search
(rm archived article)
(Actualizar artículo)
Line 6: Line 6:
 
[[zh-hans:Unified Extensible Firmware Interface]]
 
[[zh-hans:Unified Extensible Firmware Interface]]
 
{{Related articles start (Español)}}
 
{{Related articles start (Español)}}
{{Related|Arch Boot Process (Español)}}
+
{{Related|EFI system partition (Español)}}
{{Related|Master Boot Record (Español)}}
+
{{Related|Arch boot process (Español)}}
 
{{Related|GUID Partition Table (Español)}}
 
{{Related|GUID Partition Table (Español)}}
 +
{{Related|Secure Boot}}
 
{{Related articles end}}
 
{{Related articles end}}
{{Bad translation (Español)|desactualizada}}
+
{{TranslationStatus (Español)|Unified Extensible Firmware Interface|2018-08-31|538790}}
 +
{{Advertencia|Si bien es cieto que la instalación en modalidad UEFI es la opción a la que se tiende, no obstante, hay que advertir que las primeras implementaciones de UEFI «pueden» tener más inconvenientes que beneficios que su opositor BIOS. Por tanto, es recomendable hacer una búsqueda relacionada con su modelo de placa base particular para obtener información sobre la conveniencia de optar por la modalidad UEFI antes de continuar.}}
  
'''Unified Extensible Firmware Interface''' (o UEFI para abreviar) es un nuevo tipo de firmware que fue diseñado inicialmente por Intel (conocido con el nombre de EFI entonces) principalmente para los sistemas basados ​​en Itanium. Se introdujeron así nuevas formas de arrancar un sistema operativo distintas del método usado comúnmente desde el «código de arranque del [[Master Boot Record (Español)|MBR]]», seguido por los sistemas [[Wikipedia:es:BIOS|BIOS]]. Comenzó como EFI de Intel en las versiones 1.x y luego, un grupo de empresas denominado UEFI Forum, se hizo cargo de su desarrollo, a partir del cual se llamó  EFI Unificado desde de la versión 2.0. Hasta el 24 de julio de 2013, la Especificación 2.4 de UEFI (liberada el 11 de julio de 2013) es la versión más reciente.
+
La [http://www.uefi.org/ Unified Extensible Firmware Interface] (UEFI o EFI para abreviar) es un nuevo modelo de interfaz para interactuar entre los sistemas operativos y el firmware. Proporciona un entorno estándar para iniciar un sistema operativo y ejecutar aplicaciones previas al inicio.
  
{{Nota|
+
Es un método distito del comunmente usado «[[Partitioning#Master Boot Record (bootstrap code)|código de arranque MBR]]» seguido por los sistemas [[Wikipedia:BIOS|BIOS]]. Consulte [[Arch boot process]] para conocer sus diferencias y el proceso de arranque con UEFI. Para configurar los cargadores de arranque UEFI, vea [[:Category:Boot loaders]].
* Esta página explica '''qué es UEFI''' y '''el apoyo de UEFI en el kernel de Linux'''.  No describe la configuración de los gestores de arranque UEFI. Para obtener esta última información consulte [[Boot loaders]].
 
* Salvo que se especifique expresamente como EFI 1.x, los términos EFI y UEFI se utilizarán indistintamente para referirse al firmware 2.x de UEFI . También, a menos que se indique explícitamente, estas instrucciones son de carácter general y no específicas para Mac. Algunas instrucciones pueden no funcionar o pueden ser diferentes en los Mac de Apple. La implementación EFI de Apple no es ni la versión 1.x de EFI ni la versión 2.x, sino una combinación de ambas. Este tipo de firmware no entra dentro de ninguna versión de la especificación UEFI uno y, por lo tanto, no es un estándar del firmware de UEFI.}}
 
 
 
== Diferencias entre BIOS y UEFI ==
 
Véase [[Arch boot process (Español)#Tipos de firmware]] para conocer más detalles.
 
  
== Proceso de arranque bajo UEFI ==
+
== Versiones de UEFI ==
# Encendido del sistema — se inicia Power On Self Test — o el proceso [[wikipedia:es:POST|POST]].
 
# Se carga el firmware UEFI. El firmware inicializa el hardware necesario para el arranque.
 
# El firmware lee el gestor de arranque para determinar qué aplicación UEFI iniciar, y desde dónde (es decir, desde qué disco y partición).
 
# El firmware UEFI inicia la aplicación desde la partición UEFI definida en la entrada de arranque del gestor de arranque del firmware.
 
# La aplicación UEFI puede iniciar otra aplicación (como la shell de UEFI o un gestor de arranque como rEFInd), o el kernel y el initramfs (en el caso de un gestor de arranque como GRUB) en función de cómo se ha configurado la aplicación UEFI.
 
  
{{Nota|En algunos sistemas UEFI el único camino posible para iniciar la aplicación UEFI en el arranque (si no tiene una entrada personalizada en el menú de inicio de UEFI) es ponerlo en este lugar fijo: {{ic|<PARTICIÓN DEL SISTEMA EFI>/EFI/boot/bootx64.efi}} (para sistemas x86 de 64-bit)}}
+
* UEFI comenzó como EFI de Intel en las versiones 1.x.
 +
* Luego, un grupo de empresas denominado UEFI Forum, se hizo cargo de su desarrollo, a partir del cual se llamó EFI Unificado desde de la versión 2.0.
 +
* Salvo que se especifique expresamente como EFI 1.x, los términos EFI y UEFI se utilizarán indistintamente para referirse al firmware 2.x de UEFI .
 +
* La implementación EFI de Apple no es ni la versión 1.x de EFI ni la versión 2.x, sino una combinación de ambas. Este tipo de firmware no entra dentro de ninguna versión de la especificación (U)EFI uno y, por lo tanto, no es un estándar del firmware de UEFI. A menos que se indique explícitamente, estas instrucciones son generales y algunas de ellas pueden no funcionar o pueden ser diferentes en [[MacBook|Apple Macs]].
  
=== Multiarranque en UEFI ===
+
La última especificación de UEFI se puede encontrar en http://uefi.org/specifications.
Debido a que cada sistema operativo o fabricante puede mantener sus propios archivos en la partición del sistema EFI (''«EFI System Partition»'') sin afectar a otros sistemas operativos, el multiarranque con UEFI consiste únicamente en lanzar una aplicación UEFI diferente, correspondiente al gestor de arrranque de un particular sistema operativo. Esto elimina la necesidad de recurrir a mecanismos de cargar los sistemas operativos en cadena con un gestor de arranque para iniciar uno u otro.
 
  
==== Arranque de Microsoft Windows ====
+
== Firmware de UEFI ==
Las versiones de 64-bit de Windows Vista (SP1+), 7 y 8, permiten arrancar de forma nativa utilizando el firmware UEFI x86_64. Windows fuerza el tipo de partición en función del firmware utilizado, es decir, si Windows se inicia en el modo UEFI, es que viene instalado en un disco GPT. Si Windows se inicia en modo BIOS legacy, significa que solo se puede instalar en un disco MBR. Esta es una limitación impuesta por el instalador de Windows. Así Windows soporta bien el arranque UEFI-GPT o solo arranque BIOS-MBR, pero no el arranque UEFI-MRB o BIOS-GPT.
 
  
Estas limitaciones no existen en el kernel de Linux, sino que depende del gestor de arranque utilizado. Sin embargo, esta limitación de Windows se debe tener en cuenta si el usuario quiere arrancar Windows y Linux en el mismo disco, ya que la configuración del gestor de arranque en sí depende del tipo de firmware y de la partición del disco utilizada. En el caso de arranque dual de Windows y Linux en el mismo disco, es recomendable seguir el método utilizado por Windows, ya sea el arranque UEFI-GPT o solo arranque BIOS-MBR, no los otros dos casos.
+
Con UEFI, cada programa, ya sea un cargador de sistema operativo o una utilidad (por ejemplo, una aplicación de prueba de memoria o una herramienta de recuperación), debe ser una aplicación EFI correspondiente a la arquitectura/bitness del firmware de UEFI.
  
Las versiones de Windows de 32-bit únicamente soportan el arranque en sistemas BIOS-MBR. Siga las instrucciones proporcionadas en el enlace del foro en las secciones apropiadas respecto a cómo hacer esto. Véase http://support.microsoft.com/kb/2581408 para más información.
+
La gran mayoría de los firmwares UEFI, incluidos los recientes Macs de Apple, usan el firmware UEFI x86_64. Los únicos dispositivos conocidos que utilizan UEFI IA32 (32 bits) son Apple Mac antiguos (anteriores a 2008), algunos ultrabooks Intel Cloverfield y algunas tarjetas del servidor Intel antiguo que se sabe que operan con firmware Intel EFI 1.10.
  
=== Detectar la arquitectura del firmware UEFI ===
+
Un firmware UEFI x86_64 no incluye soporte para el inicio de aplicaciones EFI de 32 bits (a diferencia de las versiones de Linux y Windows x86_64, que incluyen dicho soporte). Por lo tanto, la aplicación EFI debe compilarse para el firmware de esa específica arquitectura del procesador.
==== Sistemas UEFI que no son Mac ====
 
{{Bad translation (Español)|sección desactualizada}}
 
Compruebe si el directorio {{ic|/sys/firmware/efi}} existe; si existe, significa que el kernel ha arrancado en modalidad EFI. En ese caso, significa que la arquitectura de UEFI coincide con la del kernel (es decir, i686 o x86_64)
 
  
{{Nota|El chip del sistema Atom de Intel es entregado con UEFI de 32 bit (desde el 2 de noviembre de 2013). Véase esta página para obtener más información.}}
+
=== Sistemas UEFI que no son Mac ===
  
==== Mac de Apple ====
+
Compruebe si el directorio {{ic|/sys/firmware/efi}} existe; si existe, significa que el kernel ha arrancado en modalidad UEFI. En ese caso, se presumirá que la arquitectura de UEFI coincidirá con la del kernel (es decir, i686 o x86_64)
Los Mac anteriores a 2008 tienen, en su mayoría, un firware i386-efi, mientras que los Mac >=2008 tienen, en su mayoría, x86_64-efi. Todos los Mac capaces de ejecutar el kernel de Mac OS X Snow Leopard 64-bit tienen un firmware EFI 1.x para x86_64.
 
  
Para saber la arquitectura del firmware EFI en un Mac, debe arrancar Mac OS X y escribir en un terminal la siguiente orden:
+
{{Nota|El chip del sistema Atom de Intel es entregado con UEFI de 32 bit (desde el 2 de noviembre de 2013). Véase [[#Booting 64-bit kernel on 32-bit UEFI|esta página]] para obtener más información. Vea también [https://software.intel.com/en-us/blogs/2015/07/22/why-cheap-systems-run-32-bit-uefi-on-x64-systems esta publicación del blog de Intel].}}
  
<pre>
+
=== Mac de Apple ===
ioreg -l -p IODeviceTree | grep firmware-abi
 
</pre>
 
  
Si la orden devuelve EFI32 entonces es un firmware EFI 1.x para i386. Si devuelve EFI64, entonces es un firmware EFI 1.x para x86_64. Mac no tiene un firmware 2.x UEFI, porque la implementación del firmware EFI de Apple no es totalmente compatible con la especificación UEFI 2.x.
+
Los [[Mac]] anteriores a 2008 tienen, en su mayoría, un firware IA32 EFI, mientras que los Mac >=2008 tienen, en su mayoría, x86_64 EFI. Todos los Mac capaces de ejecutar el kernel de Mac OS X Snow Leopard de 64-bit tienen un firmware EFI 1.x para x86_64.
  
=== Secure Boot ===
+
Para saber la arquitectura del firmware EFI en un Mac, debe arrancar Mac OS X y escribir en un terminal la siguiente orden:
Para una visión general sobre Secure Boot en linux véase http://www.rodsbooks.com/efi-bootloaders/secureboot.html. Esta sección se centra en cómo configurar Secure Boot en Arch Linux. Para empezar se explicará el procedimiento de arranque de archiso con Secure Boot activado.
 
Arrancar la imagen archiso con Secure Boot activado es posible ya que las aplicaciones PreLoader.efi y HashTool.efi se añadieron a la misma. Aparecerá un mensaje que dice «Failed to Start loader... I will now execute HashTool.» Para utilizar HashTool de modo que introduzca el hash de loader.efi y vmlinzu.efi, siga estos pasos:
 
* Seleccione {{ic|OK}}.
 
* En el menú principal de HashTool, seleccione {{ic|Enroll Hash}}, elija {{ic|\loader.efi}} y confirme con {{ic|Yes}}. Una vez más, seleccione {{ic|Enroll Hash}} y {{ic|archiso}} para entrar en el directorio archiso, y, a continuación, seleccione {{ic|vmlinuz-efi}} y confirme con {{ic|Yes}}. Por último, seleccione {{ic|Exit}} para volver al menú de selección del dispositivo de arranque.
 
* En el menú de selección del dispositivo de arranque, seleccione  {{ic|Arch Linux archiso x86_64 UEFI CD}}.
 
Iniciada la imagen de archiso, se le presentará un prompt de shell, accediendo automáticamente como root. Para comprobar si archiso arrancó con SecureBoot, utilice esta orden:
 
  
  $ od -An -t u1 /sys/firmware/efi/vars/SecureBoot-1234abcde-5678-/data
+
  $ ioreg -l -p IODeviceTree | grep firmware-abi
  
Si es así, esta orde devuelve el número entero 1 al final de una lista de 5, por ejemplo:
+
Si la orden devuelve EFI32, entonces es el firmware EFI IA32 (32 bits). Si devuelve EFI64, entonces es el firmware EFI x86_64. La mayoría de los Mac no tienen firmware UEFI 2.x ya que la implementación de EFI de Apple no es totalmente compatible con la especificación UEFI 2.x.
  
  6 0 0 0 1
+
== Configuración de las opciones del kernel de Linux para UEFI ==
  
Los caracteres denotados por XXXX difieren de una máquina a otra. Para ayudar con esto, se puede usar la implementación del tabulador o listar las variables de efi.
 
 
== Configuración de las opciones del Kernel de Linux para UEFI ==
 
 
Las opciones requeridas para la configuración del kernel de Linux para sistemas UEFI son:
 
Las opciones requeridas para la configuración del kernel de Linux para sistemas UEFI son:
  
 +
CONFIG_RELOCATABLE=y
 
  CONFIG_EFI=y
 
  CONFIG_EFI=y
 
  CONFIG_EFI_STUB=y
 
  CONFIG_EFI_STUB=y
CONFIG_RELOCATABLE=y
 
 
  CONFIG_FB_EFI=y
 
  CONFIG_FB_EFI=y
 
  CONFIG_FRAMEBUFFER_CONSOLE=y
 
  CONFIG_FRAMEBUFFER_CONSOLE=y
  
* Soporte para las Variables Runtime de UEFI (sistema de archivos '''efivarfs''' - {{ic|/sys/firmware/efi/efivars}}). Esta opción es importante, ya que es necesaria para manipular las Variables Runtime de UEFI usando herramientas como {{ic|/usr/bin/gummiboot}}. La opción de configuración siguiente está añadida en el kernel 3.10 y posterior: {{bc|1=CONFIG_EFIVAR_FS=y}}
+
* Soporte para las ''Variables Runtime de UEFI'' (el sistema de archivos '''efivarfs''' {{ic|/sys/firmware/efi/efivars}}). Esta opción es importante, ya que es necesaria para manipular las variables runtime de UEFI usando herramientas como {{ic|/usr/bin/efibootmgr}}. La opción de configuración siguiente está añadida en el kernel 3.10 y posterior.: {{bc|1=CONFIG_EFIVAR_FS=y}}
  
* Soporte para las Variables Runtime de UEFI (interfaz '''efivars sysfs''' - {{ic|/sys/firmware/efi/vars}}). Esta opción debe ser desactivada.: {{bc|1=CONFIG_EFI_VARS=n}}
+
* Soporte para las ''Variables Runtime de UEFI'' (la interfaz antigua '''efivars sysfs''' {{ic|/sys/firmware/efi/vars}}). Esta opción debe ser desactivada para evitar posibles problemas entre efivarfs con sysfs-efivars activados.: {{bc|1=CONFIG_EFI_VARS=n}}
  
* Opción de configuración de GUID Partition Table ([[GUID Partition Table (Español)|GPT]]) - necesaria para dar soporte a UEFI: {{bc|1=CONFIG_EFI_PARTITION=y}}
+
* Opción de configuración de [[GUID Partition Table]] (GPT) —necesaria para dar soporte a UEFI—: {{bc|1=CONFIG_EFI_PARTITION=y}}
  
{{Nota|Todas las opciones anteriores son necesarias para arrancar Linux en UEFI, y están activadas en los kernels de ArchLinux presentes en los repositorios oficiales.}}
+
Obtenido de https://www.kernel.org/doc/Documentation/x86/x86_64/uefi.txt.
  
Obtenido de https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/plain/Documentation/x86/x86_64/uefi.txt .
+
{{Nota|Todas las opciones anteriores son necesarias para arrancar Linux con UEFI, y están activadas en los [[kernels]] de ArchLinux presentes en los repositorios oficiales.}}
  
 
== Variables de UEFI ==
 
== Variables de UEFI ==
UEFI define las variables como la interacción de un sistema operativo con el firmware. Las variables de arranque de UEFI (''«UEFI Boot Variables»'') son utilizadas por el cargador de arranque y por el sistema operativo únicamente durante la primera fase de arranque. Las variables runtime de UEFI permiten a un sistema operativo gestionar ciertos ajustes del firmware como la gestión del arranque de UEFI o la gestión de las claves para el protocolo Boot Secure de UEFI, etc. Se puede obtener el listado de variables utilizando:
 
$ efivar -l
 
  
=== Apoyo de las Variables de UEFI en el Kernel ===
+
UEFI define las variables como la interacción de un sistema operativo con el firmware. Las variables de arranque de UEFI (''«UEFI Boot Variables»'') son utilizadas por el cargador de arranque y por el sistema operativo únicamente durante la primera fase de arranque. Las variables «''runtime''» de UEFI permiten a un sistema operativo gestionar ciertos ajustes del firmware, como la gestión del arranque de UEFI o la gestión de las claves para el protocolo «''Boot Secure''» de UEFI, etc. Se puede obtener el listado de las variables utilizando:
El Kernel de Linux expone los datos de las variables de EFI en el espacio de usuario a través de 2 interfaces:
 
  
* Interfaz '''sysfs-efivars ANTIGUA''' (CONFIG_EFI_VARS) - completada por el módulo del kernel {{ic|efivars}} en {{ic|/sys/firmware/efi/vars}} - con un límite de tamaño de 1024 byte como máximo por dato de variable, sin soporte para las variables de UEFI Secure Boot (debido a la limitación del tamaño) y no recomendado por ningún desarrollador del kernel. Aún así, mantenido por los desarrolladores del kernel ,pero '''completamente desactivado en los kernels oficiales de Arch''''.
+
$ efivar --list
  
* Interfaz '''efivarfs NUEVA''' ('''EFI''' '''VAR'''iable '''F'''ile'''S'''ystem) (CONFIG_EFIVAR_FS) - montada usando el módulo del kernel {{ic|efivarfs}} en {{ic|/sys/firmware/efi/efivars}} - sustituye a la anterior interfaz, sin limitaciones de tamaño para las variables, con soporte para las variables de UEFI Secure Boot y recomendado por los desarrolladores del kernel. Introducido en el kernel 3.8 y módulo {{ic|efivarfs}} NUEVO separado del módulo {{ic|efivars}} ANTIGUO en el kernel 3.10 .
+
=== Soporte de las variables UEFI en el kernel de Linux ===
  
==== Inconsistencia entre efivarfs y sysfs-efivars ====
+
El kernel de Linux expone los datos de las variables UEFI en el espacio de usuario a través de la interfaz '''efivarfs''' ('''EFI''' '''VAR'''iable '''F'''ile'''S'''ystem) ({{ic|CONFIG_EFIVAR_FS}}) —montada utilizando el módulo del kernel {{ic|efivarfs}} en {{ic|/sys/firmware/efi/efivars}}— no tiene límite de tamaño máximo y admite las variables «''Secure Boot''» de UEFI. Introducido en kernel 3.8.
Activar tanto sysfs-efivars ANTIGUO  como efivarfs NUEVO simultáneamente puede causar problemas de inconsistencia de datos (véase https://lkml.org/lkml/2013/4/16/473 para más información). Debido a que el VIEJO sysfs-efivars está completamente desactivado en los kernel oficiales de Arch (desde '''core/{{Pkg|linux}}-3.11''' y '''core/{{Pkg|linux-lts}}-3.10'''), únicamente el NUEVO efivarfs será activado/soportado en lo sucesivo. Todas las variables de UEFI respecto a las herramientas y utilidades disponibles en los [[Official repositories (Español)|repositorios oficiales]] soportan efivarfs desde el 1 de octubre de 2013.
 
  
{{Nota|Como efecto secundario de la desactivación del ANTIGUO sysfs-efivars, el módulo {{ic|efi_pstore}} también está desactivado en los kernel oficiales de Arch como funcionalidad de EFI pstore.}}
+
===Requisitos para que el soporte de las variables UEFI funcione correctamente===
  
Si tiene ambas interfaces activadas, deberá desactivar una de ellas, y desactivar y volver a activar la otra interfaz (para actualizar los datos y evitar inconsistencias) antes de acceder a los datos de EFI VAR utilizando cualquier herramienta en el espacio de usuario:
+
# La [[#UEFI firmware bitness|arquitectura]] del procesador del Kernel y del procesador de UEFI deben coincidir.
 
+
# El kernel debe arrancar en modo EFI (a través de [[EFISTUB]] o de cualquier otro [[Boot loaders|gestor de arranque EFI]], no a través de BIOS/CSM o «bootcamp» de Apple que también es BIOS/CSM)
Para desactivar sysfs-efivars y refrescar efivarfs:
 
# modprobe -r efivars
 
 
# umount /sys/firmware/efi/efivars
 
# modprobe -r efivarfs
 
 
# modprobe efivarfs
 
# mount -t efivarfs efivarfs /sys/firmware/efi/efivars
 
 
 
Para desactivar efivarfs y refrescar sysfs-efivars:
 
# umount /sys/firmware/efi/efivars
 
# modprobe -r efivarfs
 
 
# modprobe -r efivars
 
# modprobe efivars
 
 
 
===Requisitos del soporte de las variables UEFI para que funcione correctamente===
 
 
# El soporte para EFI Runtime Services debe estar presente en el kernel ({{ic|1=CONFIG_EFI=y}}, compruebe si están presente con {{ic|zgrep CONFIG_EFI /proc/config.gz}}).
 
# El soporte para EFI Runtime Services debe estar presente en el kernel ({{ic|1=CONFIG_EFI=y}}, compruebe si están presente con {{ic|zgrep CONFIG_EFI /proc/config.gz}}).
# La arquitectura del procesador del Kernel y del procesador de EFI deben coincidir.
 
# El kernel debe arrancar en modo EFI (a través de [[EFISTUB]] o de cualquier otro [[Boot loaders|gestor de arranque EFI]], no a través de BIOS/CSM o «bootcamp» de Apple que también es BIOS/CSM)
 
 
# Los EFI Runtime Services del kernel NO DEBEN ser desactivados a través de un terminal, es decir, el parámetro {{ic|noefi}} del kernel NO DEBE ser usado.  
 
# Los EFI Runtime Services del kernel NO DEBEN ser desactivados a través de un terminal, es decir, el parámetro {{ic|noefi}} del kernel NO DEBE ser usado.  
# El sistema de archivos {{ic|efivarfs}} debe estar montado en {{ic|/sys/firmware/efi/efivars}}, en otro caso, sigua [[#Montar efivarfs|esta sección]].
+
# El sistema de archivos {{ic|efivarfs}} debe estar montado en {{ic|/sys/firmware/efi/efivars}}, en otro caso, debe [[#Montar efivarfs|montar efivarfs]].
# {{ic|efivar}} debe mostar (con la opción {{ic|-l}}) las variables EFI sin ningún error. Para una muestra de salida véase [[#Sample_List_of_UEFI_Variables]]{{Broken section link}}.
+
# {{ic|efivar}} debe mostar (con la opción {{ic|-l}}) las variables EFI sin ningún error.
  
 
Si el soporte para las variables de EFI no funciona, incluso después de cumplirse las condiciones precedentes, pruebe las siguientes soluciones:
 
Si el soporte para las variables de EFI no funciona, incluso después de cumplirse las condiciones precedentes, pruebe las siguientes soluciones:
Line 140: Line 95:
 
# Si el paso anterior no resuelve el problema, intente arrancar con el parámetro del kernel {{ic|efi_no_storage_paranoia}} para desactivar la variable efi del kernel que comprueba el espacio de almacenamiento, la cual puede impedir la escritura/modificación de las variables de efi.
 
# Si el paso anterior no resuelve el problema, intente arrancar con el parámetro del kernel {{ic|efi_no_storage_paranoia}} para desactivar la variable efi del kernel que comprueba el espacio de almacenamiento, la cual puede impedir la escritura/modificación de las variables de efi.
  
{{Nota|{{ic|efi_no_storage_paranoia}} solo debe utilizarse cuando sea necesario y no se debe dejar como una opción de arranque normal. El efecto de este parámetro en la línea de órdenes del kernel cancela una garantía que se pone en marcha para ayudar a evitar la saturación de las máquinas cuando NVRAM se llena demasiado.}}
+
{{Advertencia|{{ic|efi_no_storage_paranoia}} solo debe utilizarse cuando sea necesario y no se debe dejar como una opción de arranque normal. El efecto de este parámetro en la línea de órdenes del kernel cancela una garantía que se pone en marcha para ayudar a evitar la saturación de las máquinas cuando NVRAM se llena demasiado.}}
  
 
==== Montar efivarfs ====
 
==== Montar efivarfs ====
Si {{ic|efivarfs}} no se monta automáticamente en {{ic|/sys/firmware/efi/efivars}} por [[systemd (Español)|systemd]] durante el arranque, entonces necesita montarla manualmente para dejar expuesto el soporte para las variables de UEFI a las herramientas del espacio de usuario tales como {{ic|efibootmgr}}, etc.:
+
 
 +
Si {{ic|efivarfs}} no se monta automáticamente en {{ic|/sys/firmware/efi/efivars}} por [[systemd (Español)|systemd]] durante el arranque, entonces necesita montarla manualmente para dejar expuesto el soporte para las variables de UEFI a las herramientas del espacio de usuario tales como ''efibootmgr'':
  
 
  # mount -t efivarfs efivarfs /sys/firmware/efi/efivars
 
  # mount -t efivarfs efivarfs /sys/firmware/efi/efivars
  
{{Nota|La orden anterior debe ejecutarse tanto FUERA (ANTES) como DENTRO de '''chroot''', si procede.}}
+
{{Nota|La orden anterior debe ejecutarse tanto '''fuera (antes)''' como '''dentro''' de [[chroot]], si procede.}}
  
También es una buena idea para el montaje automático de {{ic|efivarfs}} durante el arranque, hacerlo mediante {{ic|/etc/fstab}}, de la siguiente manera:
+
Consulte [https://www.kernel.org/doc/Documentation/filesystems/efivarfs.txt efivarfs.txt] para documentarse más sobre el kernel.
  
{{hc|/etc/fstab|<nowiki>
+
===Herramientas en el espacio de usuario===
efivarfs    /sys/firmware/efi/efivars    efivarfs    defaults    0    0
 
</nowiki>}}
 
  
===Herramientas en el espacio de usuario===
 
 
Existen algunas herramientas que permiten acceder/modificar las variables UEFI, como:  
 
Existen algunas herramientas que permiten acceder/modificar las variables UEFI, como:  
  
# '''efivar''' - Herramienta y biblioteca para modificar las variables de UEFI (usado por efibootmgr de vathpela) - https://github.com/vathpela/efivar - {{Pkg|efivar}} o {{AUR|efivar-git}}
+
* {{App|efivar|Herramienta y biblioteca para modificar las variables de UEFI (utilizada por efibootmgr)|https://github.com/rhboot/efivar|{{Pkg|efivar}}, {{AUR|efivar-git}}}}
# '''efibootmgr''' - Herramienta para modificar las configuraciones del gestor de arranque del firmware de UEFI. Los desarrolladores del código  efibootmgr (linuxdell) no proporcionan soporte a efivarfs. Un fork de efibootmgr de Fedora por Peter Jones (vathpela) soporta tanto efivarfs como sysfs-efivars. Actualmente se utiliza, en el repositorio oficial core, el paquete {{Pkg|efibootmgr}} y, en AUR, el paquete {{AUR|efibootmgr-pjones-git}}{{Broken package link (Español)|{{aur-mirror|efibootmgr-pjones-git}}}} - https://github.com/vathpela/efibootmgr/tree/libefivars
+
* {{App|efibootmgr|Herramienta para modificar las configuraciones del gestor de arranque del firmware de UEFI|https://github.com/rhboot/efibootmgr|{{Pkg|efibootmgr}}}}
# '''uefivars''' - Simplemente accede al listado de las variables de EFI con alguna información adicional sobre el PCI (utiliza el código de efibootmgr) - https://github.com/fpmurphy/Various/tree/master/uefivars-2.0 solo admite efivarfs y https://github.com/fpmurphy/Various/tree/master/uefivars-1.0 solo admite sysfs-efivars. Paquete de AUR {{AUR|uefivars-git}}  
+
* {{App|uefivars|Vuelca un listado de las variables de EFI con alguna información adicional sobre la PCI (utiliza el código de efibootmgr)|https://github.com/fpmurphy/Various/tree/master/uefivars-2.0|{{AUR|uefivars-git}}}}
# '''efitools''' - Herramientas para crear y configura los propios Certificados Secure Boot de UEFI, Claves y Binarios Firmados (requiere efivarfs) - {{AUR|efitools-git}}{{Broken package link (Español)|package not found}}
+
* {{App|efitools|Herramientas para manipular las plataformas de ''secure boot'' de UEFI|https://git.kernel.org/pub/scm/linux/kernel/git/jejb/efitools.git|{{Pkg|efitools}}}}
# '''Suite de comprobación de firmware, de Ubuntu''' - https://wiki.ubuntu.com/FirmwareTestSuite/ - {{AUR|fwts}}{{Broken package link (Español)|{{aur-mirror|fwts}}}} (junto con {{AUR|fwts-efi-runtime-dkms}}{{Broken package link (Español)|{{aur-mirror|fwts-efi-runtime-dkms}}}}) o {{AUR|fwts-git}}
+
* {{App|Suite de comprobación de firmware, de Ubuntu|Conjunto de herramientas de comprobación que realiza verificaciones de estado en el firmware de ordenadores con Intel/AMD|https://wiki.ubuntu.com/FirmwareTestSuite/|{{AUR|fwts-git}}}}
  
 
==== efibootmgr ====
 
==== efibootmgr ====
{{Advertencia|Usar {{ic|efibootmgr}} en los Mac de Apple podría dañar el firmware y podría ser necesario flashear la ROM de la placa base. Ha habido informes de errores con respecto a este bug tracker en Ubuntu/Launchpad. Utilice la orden bless únicamente si tiene un Mac. La utilidad experimental «bless» para Linux es desarrollado por los desarrolladores de Fedora - {{AUR|mactel-boot}}.}}
 
  
 
{{Nota|
 
{{Nota|
*Si {{ic|efibootmgr}} no funciona en absoluto en su sistema, puede reiniciar en la Shell v2 de UEFI y utilizar la orden {{ic|bcfg}} para crear una entrada de arranque en el gestor de arranque.
+
*Si {{ic|efibootmgr}} no funciona en absoluto en su sistema, puede reiniciar en la [[#La shell de UEFI|shell de UEFI]] y utilizar la orden {{ic|bcfg}} para crear una entrada de arranque en el gestor de arranque.
*Si no es posible usar {{ic|efibootmgr}}, algunos firmwares UEFI permiten a los usuarios gestionar directamente las opciones de UEFI Boot Manager desde la BIOS. Por ejemplo, algunas BIOS de ASUS tienen una opción llamada «Add New Boot Option» (''«Añadir nueva opción de arranque»'') que permite seleccionar una partición de sistema EFI local e introducir manualmente la ubicación del código de EFI (por ejemplo {{ic|1=\EFI\refind\refind_x64.efi}}).
+
*Si no es posible usar {{ic|efibootmgr}}, algunos firmwares UEFI permiten a los usuarios gestionar directamente las entradas de inicio de UEFI desde la interfaz que aparece durante el arranque. Por ejemplo, algunas BIOS de ASUS tienen una opción llamada «Add New Boot Option» (''«Añadir nueva opción de arranque»'') que permite seleccionar una partición de sistema EFI local e introducir manualmente la ubicación del código de EFI (por ejemplo {{ic|1=\EFI\refind\refind_x64.efi}}).
*Las siguientes órdenes utilizan el cargador de arranque {{Pkg|refind-efi}} como ejemplo.
+
*Las siguientes órdenes utilizan el cargador de arranque [[rEFInd]] como ejemplo.
 
}}
 
}}
  
Supongamos que el archivo boot-loader para ser lanzado es {{ic|/boot/efi/EFI/refind/refind_x64.efi}}. El mismo {{ic|/boot/efi/EFI/refind/refind_x64.efi}} puede ser dividido en {{ic|/boot/efi}} y {{ic|/EFI/refind/refind_x64.efi}}, donde {{ic|/boot/efi}} es el punto de montaje de la partición del sistema UEFI, que se supone que es {{ic|/dev/sdXY}} (en este caso {{ic|X}} e {{ic|Y}} son marcadores de posición para los valores reales - por ejemplo: - en {{ic|/dev/sda1}}, {{ic|1=X=a}}; {{ic|1=Y=1}}).
+
Para añadir una nueva opción de arranque usando ''efibootmgr'', necesita saber tres cosas:
  
Para determinar la ruta real del dispositivo para la partición del sistema UEFI (debe tener el formato {{ic|/dev/sdXY}}), pruebe con la orden:
+
# El disco que contiene la [[EFI system partition (Español)]] (ESP): {{ic|/dev/sd''X''}}
 +
# El número de partición de la ESP en ese disco: la {{ic|''Y''}} en {{ic|/dev/sdX''Y''}}
 +
# La ruta a la aplicación EFI (relativa a la raíz de la ESP)
  
# findmnt /boot/efi
+
Por ejemplo, si desea agregar una opción de arranque para {{ic|/efi/EFI/refind/refind_x64.efi}} donde {{ic|/efi}} es el punto de montaje de la partición ESP, ejecute:
TARGET SOURCE  FSTYPE OPTIONS
 
/boot/efi /dev/sdXY  vfat        rw,flush,tz=UTC
 
  
Compruebe que el soporte para las variables de UEFI en el kernel funciona correctamente ejecutando la orden:
+
{{hc|$ findmnt /efi|2=
 +
TARGET SOURCE    FSTYPE OPTIONS
 +
/efi  /dev/sda1 vfat  rw,flush,tz=UTC
 +
}}
  
  # efivar -l
+
En este ejemplo, esto indica que la partición ESP está en el disco {{ic|/dev/sda}} y el número de la partición es 1. La ruta a la aplicación EFI relativa a la raíz de la ESP es {{ic|/EFI/refind/refind_x64.efi}}. Sabiendo esto, se crearía la entrada de arranque de la siguiente manera:
  
Si efivar enumera las variables UEFI sin ningún error, entonces se puede continuar. Si no es así, compruebe si todas las condiciones [[#Requisitos del soporte de las variables UEFI para que funcione correctamente|descritas aquí]] se cumplen.
+
# efibootmgr --create --disk /dev/sda --part 1 --loader /EFI/refind/refind_x64.efi --label "rEFInd Boot Manager" --verbose
  
A continuación, cree la entrada de arranque usando efibootmgr de la siguiente manera:
+
Consulte {{man|8|efibootmgr}} o el archivo [https://raw.githubusercontent.com/rhinstaller/efibootmgr/master/README README de efibootmgr] para obtener más información.
  
# efibootmgr -c -d /dev/sdX -p Y -l /EFI/refind/refind_x64.efi -L "rEFInd"
+
{{Nota|1=UEFI utiliza una barra invertida {{ic|\}} como separador de ruta, pero ''efibootmgr'' convierte automáticamente los separadores de ruta en barra normal {{ic|/}} al estilo UNIX.}}
  
{{Nota|1=UEFI utiliza la barra invertida {{ic|\}} como separador de ruta (similar a las rutas de Windows), pero el paquete oficial {{Pkg|efibootmgr}} proporciona soporte a las rutas de estilo unix con barras diagonales {{ic|/}} como separador de ruta para la opción {{ic|-l}}. Efibootmgr convierte internamente {{ic|/}} a {{ic|\}} antes de codificar la ruta de acceso del cargador. Este importante comportamiento que añadió esta característica a efibootmgr está en http://linux.dell.com/cgi-bin/cgit.cgi/efibootmgr.git/commit/?id=f38f4aaad1dfa677918e417c9faa6e3286411378 .}}
+
== La shell de UEFI ==
  
En la orden anterior {{ic|/boot/efi/EFI/refind/refind_x64.efi}} interpreta a {{ic|/boot/efi}} y a {{ic|/EFI/refind/refind_x64.efi}}, que, a su vez, lo interpretan como: disco: {{ic|/dev/sdX}} → partición:  {{ic|Y}} →  archivo: {{ic|/EFI/refind/refind_x64.efi}}.
+
La shell (esto es, el intérprete de línea de órdenes) de UEFI es una shell/terminal para el firmware, que permite ejecutar aplicaciones UEFI que incluyen los cargadores de arranque UEFI. Aparte de esto, la shell también se puede utilizar para obtener información variada sobre el sistema o del firmware del mapa de la memoria (memmap), modificar las variables del gestor de arranque (bcfg), ejecutar programas de gestión de particiones (diskpart), cargar los controladores UEFI, editar archivos de texto (edit), hexedit, etc.  
  
La «etiqueta» es el nombre de la entrada del menú que se muestra en el menú de inicio UEFI. Este nombre es elegido por el usuario y no afecta al arranque del sistema. Se puede obtener más información a partir de [http://linux.dell.com/cgi-bin/cgit.cgi/efibootmgr.git/plain/README efibootmgr GIT README].
+
=== Obtener la shell de UEFI ===
  
El sistema de archivos FAT32 no distingue entre mayúsculas y minúsculas, ya que no utiliza codificación UTF-8 de forma predeterminada. En este caso, el firmware utiliza  «EFI» en letra mayúscula, en lugar de minúsculas («efi»), por lo tanto, usando {{ic|\EFI\refind\refindx64.efi}} o {{ic|\efi\refind\refind_x64.efi}}  no hay diferencia (esto cambia si la codificación del sistema de archivos es UTF-8).
+
Puede descargar una shell de UEFI con licencia BSD de Tianocore de Intel desde el proyecto UDK/EDK2.
  
==EFI System Partition==
+
* Paquete de [[AUR]] {{AUR|uefi-shell-git}} (recomendado) —proporciona la shell x86_64 para x86_64 (64-bit) de UEFI y la shell IA32 para IA32 (32-bit) de UEFI— compilado directamente de la última fuente de TianoCore EDK2.
La EFI System Partition (''«Partición del Sistema EFI»'') (también llamada ESP o EFISYS) es una particón física formateada con FAT32  (en la tabla de partición principal del disco, no en LVM o RAID software, etc.) desde donde el firmware UEFI lanza las aplicaciones y el gestor de arranque de UEFI. Es una partición independiente del sistema operativo que actúa como el lugar de almacenamiento para los gestores de arranque EFI y las aplicaciones que el firmware  lanza después. Es obligatoria para arrancar UEFI. Debe estar marcada como código tipo '''EF00''' o '''ef00''' con gdisk, o la etiqueta '''boot''' si se utiliza GNU Parted (únicamente para discos GPT). Se recomienda mantener el tamaño de ESP en 512 MiB aunque los tamaños más pequeños/grandes también valen (sin embargo, para los tamaños más pequeños, estos tienen que ser mayores que el límite mínimo del tamaño del sistema de archivos de la partición FAT32 (según lo dispuesto por la especificación FAT32 de Microsoft). Para obtener más información, visite este [[Wikipedia:EFI_System_partition|enlace]].
+
* Hay copias de la shell v1 y v2 en el directorio EFI en la imagen de instalación de Arch.
 +
* [https://github.com/tianocore/edk2/tree/master/ShellBinPkg Binarios precompilados de la shell v2 de UEFI] (puede no estar actualizado).
 +
* [https://github.com/tianocore/edk2/tree/master/EdkShellBinPkg Binarios precompilados de UEFI Shell v1] (no actualizado por los desarrolladores).
 +
* [https://ptpb.pw/~Shell2.zip Binario precompilado de la shell v2 de UEFI con bcfg modificado para trabajar con el firmware UEFI pre-2.3] —del cargador de arranque Clover EFI—.
  
{{Nota|
+
La versión 2.0 de la shell únicamente funciona en sistemas UEFI 2.3 + y se recomienda su uso con preferencia a la shell 1.0 en esos sistemas. La versión 1.3 de la shell debería funcionar en todos los sistemas UEFI, independientemente de la especificación de la versión del firmware. Más información en [http://sourceforge.net/apps/mediawiki/tianocore/index.php?title=ShellPkg ShellPkg] y [http://sourceforge.net/mailarchive/message.php?msg_id=28690732 este correo].
* Se recomienda siempre usar GPT para el arranque de UEFI, dado que algunos firmwares UEFI no permiten arranque desde MBR .
 
* Con GNU Parted, la etiqueta {{ic|boot}}, (que no se debe confundir con la etiqueta {{ic|legacy_boot}}), tiene diferente efecto según se aplique a un disco MBR o a un disco GPT. En discos MBR, marca la partición como activa . En discos GPT, cambia el código del tipo de partición a {{ic|EFI System Partition}}. Parted no tiene etiqueta para marcar una partición como ESP en discos MBR (esto se puede hacer usando fdisk, sin embargo).
 
* La documentación de Microsoft señala el tamaño de ESP: Para unidades «Advanced Format 4K Native drives (4-KB-por-sector)», el tamaño mínimo es de 260 MB, debido a la limitación del formato del archivo FAT32. El tamaño mínimo de la partición de las unidades FAT32 es calculado con el tamaño del sector (4KB) x 65527 &#61; 256 MB. La unidades «Advanced Format 512e» no se ven afectadas por esta limitación, ya que su tamaño de sector emulado es de 512 bytes. 512 bytes x 65527 &#61; 32 MB, que es inferior a los 100 MB de tamaño mínimo para esta partición. De: http://technet.microsoft.com/en-us/library/hh824839.aspx#DiskPartitionRules
 
* En el caso de [[EFISTUB]], los kernels y los archivos initramfs deben ser almacenados en la partición del sistema EFI. En aras de una mayor simplicidad, también se puede utilizar la propia partición ESP como partición {{ic|/boot}}, en lugar de utilizar una partición {{ic|/boot}} separada, para arrancar EFISTUB.
 
}}
 
  
=== Discos particionados para GPT ===
+
=== Lanzar la shell de UEFI ===
* Crear una partición con el tipo de partición {{ic|ef00}} o {{ic|EF00}} usando gdisk (del paquete {{Pkg|gptfdisk}}). Después formatear la partición como FAT32 usando {{ic|mkfs.fat -F32 /dev/<PARTICIÓN>}}
 
(o)
 
* Crear una partición FAT32 y con GNU Parted establecer/activar la etiqueta {{ic|boot}} (no la etiqueta {{ic|legacy_boot}}) en dicha partición.
 
 
 
{{Nota|Si recibe el mensaje {{ic|WARNING: Not enough clusters for a 32 bit FAT!}}, reduzca el tamaño del clúster con la orden {{ic|mkfs.fat -s2 -F32 ...}} o {{ic|-s1}}, de lo contrario la partición puede ser ilegible para UEFI.}}
 
 
 
=== Discos particionados para MBR ===
 
Cree una partición asignándole el tipo {{ic|0xEF}} usando fdisk (del paquete {{Pkg|util-linux}} ). Después formatee esta partición como FAT32 usando {{ic|mkfs.fat -F32 /dev/<PARTICIÓN>}}
 
 
 
=== ESP en RAID ===
 
Es posible hacer de ESP una parte de una matriz RAID1, pero ello conlleva el riesgo de corromper los datos, así como otras consideraciones a tener en cuenta cuando se crea la ESP. Véase https://bbs.archlinux.org/viewtopic.php?pid=1398710#p1398710 and https://bbs.archlinux.org/viewtopic.php?pid=1390741#p1390741 para obtener más detalles.
 
 
 
== Shell de UEFI ==
 
La Shell de UEFI es una shell/terminal para el firmware que permite ejecutar aplicaciones UEFI que incluyen los cargadores de arranque UEFI. Aparte de esto, la shell también se puede utilizar para obtener información variada sobre el sistema o el firmware del mapa de la memoria (memmap), modificar las variables  del gestor de arranque (bcfg), ejecutar programas de gestión de particiones (diskpart), cargar los controladores UEFI, editar archivos de texto (edit), hexedit, etc.
 
  
=== Obtener la shell de UEFI ===
+
Algunas placas base Asus y otras basadas en el firmware UEFI AMI Aptio x86_64 (de Sandy Bridge en adelante) ofrecen una opción llamada {{ic|«Launch EFI Shell from filesystem device»}}. Para estas placas base, descargue la shell de UEFI x86_64 y cópiela a la partición del sistema UEFI renombrándola como {{ic|<UEFI_SYSTEM_PARTITION>/shellx64.efi}} (normalmente en la carpeta {{ic|/boot/efi/shellx64.efi}}).
Puede descargar una Shell de UEFI con licencia BSD de Tianocore de Intel desde el proyecto Sourceforge.net UDK/EDK2.
 
  
* Paquete '''{{AUR|uefi-shell-svn}}{{Broken package link (Español)|{{aur-mirror|uefi-shell-svn}}}}''' desde [[AUR]] (recomendado) - proporciona una Shell x86_64 para sistemas x86_64 y una Shell IA32 para sistemas i686 - compilado directamente desde la última fuente SVN EDK2 de Tianocore
+
Los sistemas con un firmware UEFI Phoenix SecureCore Tiano se sabe que llevan integrada la shell de UEFI, la cual se puede iniciar presionando las teclas {{ic|F6}}, {{ic|F11}} o {{ic|F12}}.
* [https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2/ShellBinPkg/UefiShell/X64/Shell.efi Precompiled x86_64 UEFI Shell v2 binary] (puede no estar actualizado)
 
* [https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2/EdkShellBinPkg/FullShell/X64/Shell_Full.efi Precompiled x86_64 UEFI Shell v1 binary] (no actualizado por los desarrolladores)
 
* [https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2/ShellBinPkg/UefiShell/Ia32/Shell.efi Precompiled IA32 UEFI Shell v2 binary] (puede no estar actualizado)
 
* [https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2/EdkShellBinPkg/FullShell/Ia32/Shell_Full.efi Precompiled IA32 UEFI Shell v1 binary] (no actualizado por los desarrolladores)
 
  
La versión 2.0 de la Shell únicamente funciona en sistemas UEFI 2.3 + y se recomienda su uso con preferencia a la Shell 1.0 en esos sistemas. La versión 1.3 de la Shell debería funcionar en todos los sistemas UEFI, independientemente de la especificación de la versión del firmware. Más información en [http://sourceforge.net/apps/mediawiki/tianocore/index.php?title=ShellPkg ShellPkg] y [http://sourceforge.net/mailarchive/message.php?msg_id=28690732 este correo].
+
{{Nota|Si es incapaz de lanzar la shell de UEFI directamente desde el firmware mediante cualquiera de los métodos mencionados anteriormente, cree una unidad USB formateada con FAT32 conteniendo la {{ic|Shell.efi}}, copiada con la ruta {{ic|(USB)/efi/boot/bootx64.efi}}. Este USB debería aparecer en el menú de arranque del firmware. La inicialización de esta opción lanzará la shell de UEFI.}}
  
=== Lanzar la shell de UEFI ===
+
=== Órdenes importantes de la shell de UEFI ===
Algunas placas base Asus y otras basadas en el firmware UEFI AMI Aptio x86_64 (de Sandy Bridge en adelante) ofrecen una opción llamada {{ic|«Launch EFI Shell from filesystem device»}}. Para estas placas base, descargue la  Shell de UEFI x86_64 y cópiela a la partición del sistema UEFI como {{ic|<UEFI_SYSTEM_PARTITION>/shellx64.efi}} (normalmente en la carpeta {{ic|/boot/efi/shellx64.efi}}).
 
  
Los sistemas con un firmware UEFI Phoenix SecureCore Tiano se sabe que llevan integrada la Shell de UEFI, la cual se puede iniciar presionando las teclas {{ic|F6}}, {{ic|F11}} o {{ic|F12}}.
+
Las órdenes de la shell de UEFI generalmente dan soporte a la opción {{ic|-b}} que hace una pausa después de la salida de cada página. Ejecute {{ic|help -b}} para ver las órdenes disponibles.
 
 
{{Nota|Si es incapaz de lanzar la Shell de UEFI directamente desde el firmware mediante cualquiera de los métodos mencionados anteriormente, cree una unidad USB formateada con FAT32 conteniendo la {{ic|Shell.efi}} copiada con la ruta {{ic|(USB)/efi/boot/bootx64.efi}}. Este USB debería aparecer en el menú de arranque del firmware. La inicialización de esta opción lanzará la Shell de UEFI.}}
 
 
 
=== Órdenes importantes de la shell de UEFI ===
 
Las órdenes de la Shell de UEFI generalmente dan soporte a la opción {{ic|-b}} que hace una pausa después de la salida de cada página. {{ic|map}} que lista los sistemas de archivos reconocidos ({{ic|fs0}}, ...) y los dispositivos de almacenamiento de datos ({{ic|blk0}}, ...). Ejecute {{ic|help -b}} para ver las órdenes disponibles.
 
  
 
Puede obtener más información en http://software.intel.com/en-us/articles/efi-shells-and-scripting/
 
Puede obtener más información en http://software.intel.com/en-us/articles/efi-shells-and-scripting/
  
 
==== bcfg ====
 
==== bcfg ====
La orden BCFG se utiliza para modificar las entradas en la NVRAM de UEFI, lo que permite cambiar las entradas de arranque o las opciones del controlador. Esta orden se describe con detalle en la página 83 (sección 5.3) del documento pdf «UEFI Shell Specification 2.0».
+
 
 +
La orden {{ic|bcfg}}  se utiliza para modificar las entradas en la NVRAM de UEFI, lo que permite cambiar las entradas de arranque o las opciones del controlador. Esta orden se describe con detalle en la página 83 (sección 5.3) del documento [http://www.uefi.org/sites/default/files/resources/UEFI_Shell_Spec_2_0.pdf UEFI Shell Specification 2.0]
  
 
{{Nota|
 
{{Nota|
 
*Se recomienda probar {{ic|bcfg}} únicamente si {{ic|efibootmgr}} no puede crear entradas de inicio que funcionen en el propio sistema.
 
*Se recomienda probar {{ic|bcfg}} únicamente si {{ic|efibootmgr}} no puede crear entradas de inicio que funcionen en el propio sistema.
*La versión 1 del binario oficial de la Shell de UEFI no proporciona soporte para la orden {{ic|bcfg}}. Puede descargar una [http://dl.dropbox.com/u/17629062/Shell2.zip Shell de UEFI modificada] que puede trabajar con firmwares pre-2.3 de UEFI.}}
+
*La versión 1 del binario oficial de la shell de UEFI no proporciona soporte para la orden {{ic|bcfg}}. Consulte [[#Obtener la shell de UEFI]] para un binario UEFI shell v2 modificado que puede funcionar en UEFI con firmwares anteriores a 2.3.
 +
}}
  
 
Para conocer una lista de entradas de arranque actuales:
 
Para conocer una lista de entradas de arranque actuales:
Line 259: Line 189:
 
  Shell> bcfg boot dump -v
 
  Shell> bcfg boot dump -v
  
Para añadir una entrada en el menú de inicio para rEFInd (por ejemplo) como cuarta (la numeración empieza desde cero) en el menú de arranque:
+
Para añadir una entrada para rEFInd (por ejemplo) como cuarta (la numeración empieza desde cero) en el menú de arranque:
 +
 
 +
Shell> bcfg boot add 3 FS0:\EFI\refind\refind_x64.efi "rEFInd"
 +
 
 +
donde {{ic|FS0:}} es la asignación correspondiente a la partición del sistema UEFI y {{ic|FS0:\EFI\refind\refind_x64.efi}} es el archivo que se pondrá en marcha.
  
Shell> bcfg boot add 3 fs0:\EFI\refind\refind_x64.efi "rEFInd"
+
Para agregar una entrada con el fin de iniciar directamente su sistema, sin un gestor de arranque, configure una opción de arranque utilizando su kernel como [[EFISTUB#UEFI_Shell|EFISTUB]]:
  
donde {{ic|fs0:}} es la asignación correspondiente a la partición del sistema UEFI y {{ic|\EFI\arch\refind\refindx64.efi}} es el archivo que se pondrá en marcha.
+
Shell> bcfg boot add '''N''' fs'''V''':\vmlinuz-linux "Arch Linux"
 +
Shell> bcfg boot -opt '''N''' "root='''/dev/sdX#''' initrd=\initramfs-linux.img"
 +
 
 +
donde {{ic|N}} es la prioridad, {{ic|V}} es el número de volumen donde se encuetra la partición de sistema EFI, y {{ic|/dev/sdX#}} es la partición raíz.
  
 
Para quitar la opción de arranque cuarta:
 
Para quitar la opción de arranque cuarta:
Line 269: Line 206:
 
  Shell> bcfg boot rm 3
 
  Shell> bcfg boot rm 3
  
Para mover la opción de arranque #3 a #0 (es decir, la primera o la entrada por defecto en el menú de inicio de UEFI):
+
Para mover la opción de arranque #3 a #0 (es decir, a la primera posición o la entrada por defecto en el menú de inicio de UEFI):
  
 
  Shell> bcfg boot mv 3 0
 
  Shell> bcfg boot mv 3 0
Line 280: Line 217:
  
 
  Shell> bcfg -? -v -b
 
  Shell> bcfg -? -v -b
 +
 +
==== map ====
 +
 +
La orden {{ic|map}} muestra un mapeado de los dispositivos, es decir, los nombres de los sistemas de archivos disponibles ({{ic|FS0}}) y los dispositivos de almacenamiento ({{ic|blk0}}).
 +
 +
Antes de ejecutar órdenes relacionadas con el sistema de archivos, como {{ic|cd}} o {{ic|ls}}, debe cambiar la shell al sistema de archivos correspondiente, escribiendo su nombre:
 +
 +
Shell> FS0:
 +
FS0:\> cd EFI/
  
 
==== edit ====
 
==== edit ====
La orden EDIT proporciona un editor de texto básico, con una interfaz similar al editor de textos nano, pero ligeramente menos funcional. Maneja codificación UTF-8 y se hace cargo del final de la línea LF frente a [[wikipedia:es:CRLF|CRLF]].
 
  
Para editar, por ejemplo, {{ic|refind.conf}} de rEFInd en la partición del sistema UEFI (fs0: en el firmware):
+
La orden {{ic|edit}} proporciona un editor de texto básico, con una interfaz similar al editor de texto nano, pero ligeramente menos funcional. Maneja codificación UTF-8 y se hace cargo del final de la línea LF frente a [[wikipedia:es:CRLF|CRLF]].
 +
 
 +
Para editar, por ejemplo, {{ic|refind.conf}} de rEFInd en la partición del sistema UEFI (FS0: en el firmware):
  
  Shell> fs0:
+
  Shell> edit FS0:\EFI\refind\refind.conf
FS0:\> cd \EFI\arch\refind
 
FS0:\EFI\arch\refind\> edit refind.conf
 
  
 
Escriba {{ic|Ctrl-E}} para obtener ayuda.
 
Escriba {{ic|Ctrl-E}} para obtener ayuda.
  
 
== Soporte para arrancar UEFI ==
 
== Soporte para arrancar UEFI ==
 +
 
=== Crear un USB arrancable con UEFI desde la ISO ===
 
=== Crear un USB arrancable con UEFI desde la ISO ===
Siga las instrucciones del siguiente [[USB_Installation_Media_(Español)#Crear USB para arrancar desde sistemas BIOS y UEFI|artículo]]
 
  
=== Eliminar el apoyo de arranque de UEFI desde la ISO ===
+
Siga las instrucciones del siguiente artículo [[USB Installation Media (Español)#Crear USB para arrancar desde sistemas BIOS y UEFI]]
{{Nota|Esta sección menciona la eliminación de la ayuda de arranque UEFI '''únicamente''' desde un CD/DVD (soporte óptico), no desde una unidad flash USB.}}
 
  
La mayoría de los Mac EFI de 32-bit y algunos Mac EFI de 64 bits  se niegan a arrancar desde un CD/DVD bootable una combinación de UEFI(X64)+BIOS. Si se desea continuar con la instalación mediante medios ópticos, puede que sea necesario, primero, eliminar el apoyo a UEFI.
+
=== Eliminar el apoyo de arranque de UEFI de una unidad óptica ===
  
* Monte el soporte de instalación oficial y obtenga la {{ic|archisolabel}} como se muestra en la sección anterior.
+
{{Nota|Esta sección menciona la eliminación de la ayuda de arranque UEFI desde un '''CD/DVD únicamente''' (soporte óptico), no desde una unidad flash USB.}}
 +
 
 +
La mayoría de los Mac EFI de 32-bit y algunos Mac EFI de 64 bits se niegan a arrancar desde un CD/DVD bootable con una combinación de UEFI(X64)+BIOS. Si se desea continuar con la instalación con soportes ópticos, puede que sea necesario, primero, eliminar el apoyo a UEFI.
 +
 
 +
* Monte el soporte de instalación oficial y obtenga el {{ic|archisolabel}} como se muestra en la sección anterior.
  
 
  # mount -o loop ''input.iso'' /mnt/iso
 
  # mount -o loop ''input.iso'' /mnt/iso
  
* Reconstruya la ISO usando {{ic|xorriso}} desde {{pkg|libisoburn}}:
+
* Después reconstruya la ISO, excluyendo el soporte de arranque de UEFI de la imágen destinada al disco óptico, utilizando {{ic|xorriso}} de {{pkg|libisoburn}}. Asegúrese de configurar el archisolabel correcto, por ejemplo «ARCH_201411» o similar:
  
 
{{bc|1=
 
{{bc|1=
Line 323: Line 271:
 
* Grabe {{ic|''output.iso''}} en el disco óptico y continúe con la instalación de forma normal.
 
* Grabe {{ic|''output.iso''}} en el disco óptico y continúe con la instalación de forma normal.
  
== Probar UEFI en sistemas sin soporte nativo ==
+
=== Arrancar el kernel de 64-bit en UEFI de 32-bit ===
=== OVMF para máquinas virtuales  ===
 
OVMF [http://sourceforge.net/apps/mediawiki/tianocore/index.php?title=OVMF] es un proyecto para activar la compatibilidad de UEFI para máquinas virtuales. OVMF contiene una muestra de firmware UEFI para QEMU.
 
  
Se puede compilar OVMF (con el apoyo de Secure Boot) con {{AUR|ovmf-svn}}{{Broken package link (Español)|{{aur-mirror|ovmf-svn}}}} disponible en AUR y ejecutándolo como sigue:
+
La imagen ISO oficial ([[Archiso]]) no admite el arranque en sistemas UEFI de 32 bits ({{Bug|53182}}) ya que utiliza EFISTUB (a través del administrador de arranque [[systemd-boot]] para el menú) para arancar el kernel en modo UEFI. Para arrancar un kernel de 64 bits con UEFI de 32 bits, debe usar un gestor de arranque que no se base en el código de arranque de EFI para lanzar los kernel.
  
qemu-system-x86_64 -enable-kvm -net none -m 1024 -bios /usr/share/ovmf/x86_64/bios.bin
+
{{Sugerencia|la imagen iso de [[Archboot]] admite el arranque en sistemas UEFI de 32 bits.}}
  
=== DUET para sistemas BIOS únicamente ===
+
==== Utilizar GRUB ====
DUET es un proyecto tianocore que permite cargar en cadena un entorno UEFI completo desde un sistema BIOS, de manera similar al arranque de los sistemas operativos en entorno BIOS. Este método se está discutiendo ampliamente en http://www.insanelymac.com/forum/topic/186440-linux-and-windows-uefi-boot-using-tianocore-duet-firmware/ . Imágenes DUET precompiladas se pueden descargar de uno de los repositorios de https://gitorious.org/tianocore_uefi_duet_builds . Instrucciones específicas para la creación de DUET están disponible en https://gitorious.org/tianocore_uefi_duet_builds/tianocore_uefi_duet_installer/blobs/raw/master/Migle_BootDuet_INSTALL.txt .
 
  
También puede probar http://sourceforge.net/projects/cloverefiboot/ que proporciona imágenes DUET modificadas que puedan contener algunos arreglos específicos del sistema y son más frecuentemente actualizadas en comparación con las de los repositorios gitorious.
+
Esta sección describe cómo configurar [[GRUB]] como el cargador de arranque UEFI del USB.
  
==Solución de problemas==
+
* [[USB flash installation media#Using_manual_formatting|Crear una instalación en un soporte USB modificable]]. Como vamos a usar GRUB, solo tiene que seguir los pasos hasta la parte donde empieza la explicación de {{ic|syslinux}}.
=== Windows 7 no se inicia en la modalidad UEFI  ===
 
Si tiene instalado Windows en un disco duro  con particionado GPT y sigue teniendo otro disco duro diferente con particionado MBR en su ordenador, entonces es posible que la BIOS UEFI está dando su apoyo CSM a este último (para arrancar particiones MBR) y por ello Windows no arranca. Para resolver este problema convierta el particionado de su disco MBR a GPT, o desactive el puerto SATA del disco duro cuando esté conectado, o bien, desenchufe el puerto SATA de este disco duro.
 
  
Placas base con este tipo de problema:
+
* [[GRUB/Tips and tricks#GRUB standalone|Crear una imagen independiente de GRUB]] para sistemas UEFI de 32 bits:
  
Gigabyte Z77X-UD3H rev. 1.1 (BIOS UEFI versión F19e)
+
# echo 'configfile ${cmdpath}/grub.cfg' > /tmp/grub.cfg
 +
# grub-mkstandalone -d /usr/lib/grub/i386-efi -O i386-efi --modules="part_gpt part_msdos" --locales="en@quot" --themes="" -o "''/mnt/usb/''EFI/boot/bootia32.efi" "boot/grub/grub.cfg=/tmp/grub.cfg" -v
  
- La opción ''«UEFI Only»'' de la BIOS UEFI no pretende hacer que la BIOS UEFI arranque desde CSM.
+
* Cree {{ic|''/mnt/usb''/EFI/boot/grub.cfg}}  con los siguientes contenidos (sustituya {{ic|ARCH_YYYYMM}} con la etiqueta archiso adecuada, por ejemplo {{ic|ARCH_201507}}):
  
=== Windows cambia el orden de arranque ===
+
{{Sugerencia|
En algunas placas base (confirmado en ASRock Z77 Extreme4) Windows 8 cambia el orden de inicio en la NVRAM cada vez que se arranca. Esto se puede solucionar haciendo que el Windows Boot Manager sea cargado por otro gestor de arranque en lugar de arrancar con Windows.
+
* La etiqueta archiso se puede obtener del archivo ''.iso '' con la herramienta {{ic|isoinfo}} del paquete {{Pkg|cdrtools}}, o {{ic|iso-info}} de {{Pkg|libcdio}}.
Ejecutar esta orden en una consola como administrador en Windows:
+
* Las entradas de configuración dadas también pueden ingresarse dentro de una [[GRUB#Using_the_command_shell|shell de GRUB]].
bcdedit /set {bootmgr} path \EFI\boot_app_dir\boot_app.efi
+
}}
 
 
=== El soporte USB arranca mostrando una pantalla en negro ===
 
* Este fallo puede deberse a un problema con [[Kernel mode setting (Español)|KMS]]. Pruebe [[Kernel mode setting (Español)#Desactivar modesetting|desactivando KMS]]durante el arranque del USB.
 
 
 
* Si el problema no se debe a KMS, entonces puede ser debido a un error en el arranque de [[EFISTUB]] (véase [https://bugs.archlinux.org/task/33745] y [https://bbs.archlinux.org/viewtopic.php?id=156670] para obtener más información.). Tanto la ISO Oficial ([[Archiso]]) utilizan EFISTUB (mediante el gestor de arranque [[Gummiboot]] para el menú) para iniciar el kernel en modalidad UEFI. En tal caso hay que usar [[GRUB (Español)|GRUB]] como gestor de arranque de UEFI para el USB siguiendo la sección siguiente.
 
 
 
==== Utilizar GRUB ====
 
* Cree un USB arrancable como soporte de la instalación, siguiendo las instrucciones de este [[USB flash installation media (Español)|enlace]]. Después de eso, siga los pasos siguientes para utilizar GRUB en lugar de Gummiboot.
 
  
* Realice una copia de seguridad de {{ic|<USB>/EFI/boot/loader.efi}} a {{ic|<USB>/EFI/boot/gummiboot.efi}}
+
Para el ISO oficial:
  
* [[GRUB_(Español)#Construir_una_aplicaci.C3.B3n_UEFI_Standalone_para_GRUB|Cree una imagen autónoma de GRUB]]{{Broken section link}} y cópiela en {{ic|<USB>/EFI/boot/loader.efi}}
+
{{hc|''/mnt/usb''/EFI/boot/grub.cfg|2=
 
 
* Cree el archivo {{ic|<USB>/EFI/boot/grub.cfg}} con el siguiente contenido:
 
 
 
{{hc|grub.cfg para ISO Oficial|<nowiki>
 
 
insmod part_gpt
 
insmod part_gpt
 
insmod part_msdos
 
insmod part_msdos
Line 384: Line 316:
 
fi
 
fi
  
menuentry "Arch Linux archiso x86_64" {
+
menuentry "Arch Linux archiso x86_64 UEFI USB" {
 
     set gfxpayload=keep
 
     set gfxpayload=keep
     search --no-floppy --set=root --label ARCHISO_XXXXXX
+
     search --no-floppy --set=root --label ''ARCH_YYYYMM''
     linux /arch/boot/x86_64/vmlinuz archisobasedir=arch archisolabel=ARCHISO_XXXXXX add_efi_memmap
+
     linux /arch/boot/x86_64/vmlinuz archisobasedir=arch archisolabel=''ARCH_YYYYMM'' add_efi_memmap
     initrd /arch/boot/x86_64/archiso.img
+
     initrd /arch/boot/intel_ucode.img /arch/boot/x86_64/archiso.img
 
}
 
}
 +
}}
 +
 +
== Probar UEFI en sistemas sin soporte nativo ==
 +
 +
=== OVMF para máquinas virtuales  ===
 +
 +
[https://tianocore.github.io/ovmf/ OVMF] es un proyecto de TianoCore destinado a activar la compatibilidad de UEFI para máquinas virtuales. OVMF contiene una muestra de firmware UEFI para QEMU.
 +
 +
Se puede instalar {{pkg|ovmf}} desde el repositorio extra.
 +
 +
Es [https://www.linux-kvm.org/downloads/lersek/ovmf-whitepaper-c770f8c.txt recomendable] hacer una copia local del conjunto de variables no volátiles para su máquina virtual:
 +
 +
$ cp /usr/share/ovmf/x64/OVMF_VARS.fd my_uefi_vars.bin
 +
 +
Para usar el firmware OVMF y el conjunto de variables, añada la siguiente orden a su QEMU:
 +
 +
-drive if=pflash,format=raw,readonly,file=/usr/share/ovmf/x64/OVMF_CODE.fd \
 +
-drive if=pflash,format=raw,file=my_uefi_vars.bin
 +
 +
Por ejemplo:
 +
 +
$ qemu-system-x86_64 -enable-kvm -m 1G -drive if=pflash,format=raw,readonly,file=/usr/share/ovmf/x64/OVMF_CODE.fd -drive if=pflash,format=raw,file=my_uefi_vars.bin …
 +
 +
=== DUET para sistemas BIOS únicamente ===
 +
 +
DUET es un proyecto TianoCore que permite cargar en cadena un entorno UEFI completo desde un sistema BIOS, de manera similar al arranque de los sistemas operativos en entorno BIOS. Este método se está discutiendo ampliamente en http://www.insanelymac.com/forum/topic/186440-linux-and-windows-uefi-boot-using-tianocore-duet-firmware/ . Imágenes DUET precompiladas se pueden descargar de uno de los repositorios de https://gitorious.org/tianocore_uefi_duet_builds. Instrucciones específicas para la creación de DUET están disponible en https://gitorious.org/tianocore_uefi_duet_builds/tianocore_uefi_duet_installer/blobs/raw/master/Migle_BootDuet_INSTALL.txt .
 +
 +
También puede probar http://sourceforge.net/projects/cloverefiboot/ que proporciona imágenes DUET modificadas que puedan contener algunos arreglos específicos del sistema y son más frecuentemente actualizadas en comparación con las de los repositorios gitorious.
 +
 +
==Solución de problemas==
 +
 +
=== Windows 7 no se inicia en la modalidad UEFI  ===
 +
 +
Si tiene instalado Windows en un disco duro con particionado GPT y sigue teniendo otro disco duro diferente con particionado MBR en su ordenador, entonces es posible que el firmware (UEFI) está dando su apoyo CSM a este último (para arrancar particiones MBR) y por ello Windows no arranca. Para resolver este problema convierta el particionado de su disco MBR a GPT, o desactive el puerto SATA del disco duro cuando esté conectado, o bien, desenchufe el puerto SATA de este disco duro.
 +
 +
Placas base con este tipo de problema:
 +
 +
*Gigabyte Z77X-UD3H rev. 1.1 (BIOS UEFI versión F19e)
 +
 +
**La opción ''«UEFI Only»'' de la BIOS UEFI no pretende hacer que la BIOS UEFI arranque desde CSM.
 +
 +
=== Windows cambia el orden de arranque ===
  
menuentry "UEFI Shell x86_64 v2" {
+
Si el [[dual boot with Windows|arranque dual con Windows]] y su placa base solo inicia Windows de forma inmediata en lugar mostrar la elección de su aplicación EFI, existen varias causas posibles y soluciones alternativas.
    search --no-floppy --set=root --label ARCHISO_XXXXXX
+
 
    chainloader /EFI/shellx64_v2.efi
+
* Asegúrese de que el [[Dual boot with Windows#Fast_Start-Up|inicio rápido]] esté desactivado en las opciones de energía de Windows
}
+
* Asegúrese de que [[Secure Boot]] esté desactivado en su BIOS (si no está utilizando un gestor de arranque firmado)
   
+
* Asegúrese de que el orden de arranque de UEFI no tiene establecido primero «''Windows Boot Manager''» utilizando, por ejemplo,  [[#efibootmgr]] and what you see in the configuration tool of the UEFI. Algunas placas base anulan, por defecto, cualquier configuración establecida con efibootmgr por Windows, si la detecta. Esto se confirma en una computadora portátil Packard Bell.
menuentry "UEFI Shell x86_64 v1" {
+
* Si su placa base está iniciando la ruta de inicio predeterminada ({{ic|\EFI\BOOT\BOOTX64.EFI}}), este archivo puede haber sido sobrescrito con el cargador de arranque de Windows. Intente configurar la ruta de inicio correcta, por ejemplo utilizando [[#efibootmgr]].
    search --no-floppy --set=root --label ARCHISO_XXXXXX
+
* Si los pasos anteriores no funcionan, puede decirle al gestor de arranque de Windows que ejecute una aplicación EFI diferente. Desde un prompt de órdenes de «Windows Administrator»: {{bc|# bcdedit /set "{bootmgr}" path "\EFI\''path''\''to''\''app.efi''"}}
    chainloader /EFI/shellx64_v1.efi
+
* Alternativamente, puede establecer una secuencia de órdenes de inicio en Windows que garantice que el orden de inicio esté configurado correctamente cada vez que inicie Windows.
}
+
*# Abra un promtp de órdenes (símbolo del sistema) con privilegios de administrador. Ejecute {{ic|bcdedit /enum firmware}} y encuentre la entrada de inicio deseada.
</nowiki>}}
+
*# Copie el Identificador, incluidos los corchetes, por ejemplo {{ic|<nowiki>{31d0d5f4-22ad-11e5-b30b-806e6f6e6963}</nowiki>}}
 +
*# Cree un archivo por lotes con la siguiente orden {{ic|bcdedit /set "{fwbootmgr}" DEFAULT "{''copied boot identifier''}"}}
 +
*# Abra ''gpedit.msc'' y en  ''Local Computer Policy > Computer Configuration > Windows Settings > Scripts(Startup/Shutdown)'', seleccione ''Startup''
 +
*# En la pestaña ''Scripts'', seleccione el botón ''Add'', y seleccione su archivo por lotes.
 +
 
 +
=== El soporte USB se topa con una pantalla negra ===
 +
 
 +
Este problema puede ocurrir debido a un problema con [[KMS]]. Pruebe [[Kernel mode setting#Disabling_modesetting|desactivar KMS]] mientras arranca el USB.
  
{{hc|grub.cfg para ISO de Archboot|<nowiki>
+
=== El cargador de arranque UEFI no aparece en el menú del firmware ===
insmod part_gpt
 
insmod part_msdos
 
insmod fat
 
  
insmod efi_gop
+
En ciertas placas base UEFI, como algunas placas con un chipset Intel Z77, agregar entradas con {{ic|efibootmgr}} o {{ic|bcfg}} desde la shell de UEFI no funcionará, porque no aparecerán en la lista del menú de arranque después de haber sido agregadas a NVRAM.
insmod efi_uga
 
insmod video_bochs
 
insmod video_cirrus
 
  
insmod font
+
Este problema se debe a que las placas base solo pueden cargar Microsoft Windows. Para resolver esto, debe colocar el archivo ''.efi'' en la ubicación que usa Windows.
  
if loadfont "${prefix}/fonts/unicode.pf2" ; then
+
Copie el archivo {{ic|bootx64.efi}} del soporte de instalación de Arch Linux ({{ic|FSO:}}) en el directorio de Microsoft de la partición [[ESP]] de su disco duro ({{ic|FS1:}}). Haga esto arrancando la shell EFI y escribiendo:
    insmod gfxterm
 
    set gfxmode="1024x768x32;auto"
 
    terminal_input console
 
    terminal_output gfxterm
 
fi
 
  
menuentry "Arch Linux x86_64 Archboot" {
+
Shell> mkdir FS1:\EFI\Microsoft
    set gfxpayload=keep
+
Shell> mkdir FS1:\EFI\Microsoft\Boot
    search --no-floppy --set=root --file /boot/vmlinuz_x86_64
+
Shell> cp FS0:\EFI\BOOT\bootx64.efi FS1:\EFI\Microsoft\Boot\bootmgfw.efi
    linux /boot/vmlinuz_x86_64 cgroup_disable=memory loglevel=7 add_efi_memmap
 
    initrd /boot/initramfs_x86_64.img
 
}
 
  
menuentry "UEFI Shell x86_64 v2" {
+
Después del reinicio, las entradas agregadas a la NVRAM deben aparecer en el menú de inicio.
    search --no-floppy --set=root --file /boot/vmlinuz_x86_64
 
    chainloader /EFI/tools/shellx64_v2.efi
 
}
 
   
 
menuentry "UEFI Shell x86_64 v1" {
 
    search --no-floppy --set=root --file /boot/vmlinuz_x86_64
 
    chainloader /EFI/tools/shellx64_v1.efi
 
}
 
</nowiki>}}
 
  
 
== Véase también ==
 
== Véase también ==
 +
 
* [[Wikipedia:UEFI]]
 
* [[Wikipedia:UEFI]]
* [http://www.uefi.org/home/ UEFI Forum] - contains the official [http://www.uefi.org/specs/ UEFI Specifications] - GUID Partition Table is part of UEFI Specification
+
* [http://www.uefi.org/home/ UEFI Forum] - contains the official [http://uefi.org/specifications UEFI Specifications] - GUID Partition Table is part of UEFI Specification
 
* [https://www.happyassassin.net/2014/01/25/uefi-boot-how-does-that-actually-work-then/ UEFI boot: how does that actually work, then? - A blog post by AdamW]
 
* [https://www.happyassassin.net/2014/01/25/uefi-boot-how-does-that-actually-work-then/ UEFI boot: how does that actually work, then? - A blog post by AdamW]
* [[Wikipedia:EFI System partition]]
+
* [https://www.kernel.org/doc/Documentation/x86/x86_64/uefi.txt Linux Kernel x86_64 UEFI Documentation]
* [http://blog.uncooperative.org/blog/2014/02/06/the-efi-system-partition/ The EFI System Partition and the Default Boot Behavior]
+
* [https://www.intel.com/content/www/us/en/architecture-and-technology/unified-extensible-firmware-interface/efi-homepage-general-technology.html Intel's page on EFI]
* [https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/plain/Documentation/x86/x86_64/uefi.txt Linux Kernel x86_64 UEFI Documentation]
+
* [https://firmware.intel.com/ Intel Architecture Firmware Resource Center]
* [http://www.intel.com/technology/efi/ Intel's page on EFI]
+
* [https://firmware.intel.com/blog/linux-efi-boot-stub Matt Fleming - The Linux EFI Boot Stub]
* [http://uefidk.intel.com/ Intel UEFI Community Resource Center]
+
* [https://firmware.intel.com/blog/accessing-uefi-variables-linux Matt Fleming - Accessing UEFI Variables from Linux]
* [http://uefidk.intel.com/blog/linux-efi-boot-stub Matt Fleming - The Linux EFI Boot Stub]
 
* [http://uefidk.intel.com/blog/accessing-uefi-variables-linux Matt Fleming - Accessing UEFI Variables from Linux]
 
 
* [http://www.rodsbooks.com/linux-uefi/ Rod Smith - Linux on UEFI: A Quick Installation Guide]
 
* [http://www.rodsbooks.com/linux-uefi/ Rod Smith - Linux on UEFI: A Quick Installation Guide]
 
* [https://lkml.org/lkml/2011/6/8/322 UEFI Boot problems on some newer machines (LKML)]
 
* [https://lkml.org/lkml/2011/6/8/322 UEFI Boot problems on some newer machines (LKML)]
* [http://linuxplumbers.ubicast.tv/videos/plumbing-uefi-into-linux/ LPC 2012 Plumbing UEFI into Linux]
+
* [https://linuxplumbers.ubicast.tv/videos/plumbing-uefi-into-linux/ LPC 2012 Plumbing UEFI into Linux]
* [http://linuxplumbers.ubicast.tv/videos/uefi-tutorial-part-1/ LPC 2012 UEFI Tutorial : part 1]
+
* [https://linuxplumbers.ubicast.tv/videos/uefi-tutorial-part-1/ LPC 2012 UEFI Tutorial : part 1]
* [http://linuxplumbers.ubicast.tv/videos/uefi-tutorial-part-2/ LPC 2012 UEFI Tutorial : part 2]
+
* [https://linuxplumbers.ubicast.tv/videos/uefi-tutorial-part-2/ LPC 2012 UEFI Tutorial : part 2]
* [http://sourceforge.net/apps/mediawiki/tianocore/index.php?title=Welcome_to_TianoCore Intel's Tianocore Project] for Open-Source UEFI firmware which includes DuetPkg for direct BIOS based booting and OvmfPkg used in QEMU and Oracle VirtualBox
+
* [http://www.tianocore.org/ Intel's TianoCore Project] for Open-Source UEFI firmware which includes DuetPkg for direct BIOS based booting and OvmfPkg used in QEMU and Oracle VirtualBox
* [http://homepage.ntlworld.com/jonathan.deboynepollard/FGA/efi-boot-process.html FGA: The EFI boot process]
+
* [https://jdebp.eu/FGA/efi-boot-process.html FGA: The EFI boot process]
* [http://www.microsoft.com/whdc/device/storage/GPT_FAQ.mspx Microsoft's Windows and GPT FAQ]
+
* [https://docs.microsoft.com/en-us/windows-hardware/manufacture/desktop/windows-and-gpt-faq Microsoft's Windows and GPT FAQ]
* [https://gitorious.org/tianocore_uefi_duet_builds/pages/Windows_x64_BIOS_to_UEFI Convert Windows x64 from BIOS-MBR mode to UEFI-GPT mode without Reinstall]
+
* [https://gitlab.com/tianocore_uefi_duet_builds/tianocore_uefi_duet_installer/wikis/Windows_x64_BIOS_to_UEFI Convert Windows x64 from BIOS-MBR mode to UEFI-GPT mode without Reinstall]
* [https://gitorious.org/tianocore_uefi_duet_builds/pages/Linux_Windows_BIOS_UEFI_boot_USB Create a Linux BIOS+UEFI and Windows x64 BIOS+UEFI bootable USB drive]
+
* [https://gitlab.com/tianocore_uefi_duet_builds/tianocore_uefi_duet_installer/wikis/Linux_Windows_BIOS_UEFI_boot_USB Create a Linux BIOS+UEFI and Windows x64 BIOS+UEFI bootable USB drive]
 
* [http://rodsbooks.com/bios2uefi/ Rod Smith - A BIOS to UEFI Transformation]
 
* [http://rodsbooks.com/bios2uefi/ Rod Smith - A BIOS to UEFI Transformation]
* [http://software.intel.com/en-us/articles/efi-shells-and-scripting/ EFI Shells and Scripting - Intel Documentation]
+
* [https://software.intel.com/en-us/articles/efi-shells-and-scripting/ EFI Shells and Scripting - Intel Documentation]
* [http://software.intel.com/en-us/articles/uefi-shell/ UEFI Shell  - Intel Documentation]
+
* [https://software.intel.com/en-us/articles/uefi-shell/ UEFI Shell  - Intel Documentation]
 
* [http://www.hpuxtips.es/?q=node/293 UEFI Shell - bcfg command info]
 
* [http://www.hpuxtips.es/?q=node/293 UEFI Shell - bcfg command info]
* [http://dl.dropbox.com/u/17629062/Shell2.zip UEFI Shell v2 binary with bcfg modified to work with UEFI pre-2.3 firmware - from Clover efiboot]
 

Revision as of 11:06, 31 August 2018

Estado de la traducción: este artículo es una versión traducida de Unified Extensible Firmware Interface. Fecha de la última traducción/revisión: 2018-08-31. Puedes ayudar a actualizar la traducción, si adviertes que la versión inglesa ha cambiado: ver cambios.
Advertencia: Si bien es cieto que la instalación en modalidad UEFI es la opción a la que se tiende, no obstante, hay que advertir que las primeras implementaciones de UEFI «pueden» tener más inconvenientes que beneficios que su opositor BIOS. Por tanto, es recomendable hacer una búsqueda relacionada con su modelo de placa base particular para obtener información sobre la conveniencia de optar por la modalidad UEFI antes de continuar.

La Unified Extensible Firmware Interface (UEFI o EFI para abreviar) es un nuevo modelo de interfaz para interactuar entre los sistemas operativos y el firmware. Proporciona un entorno estándar para iniciar un sistema operativo y ejecutar aplicaciones previas al inicio.

Es un método distito del comunmente usado «código de arranque MBR» seguido por los sistemas BIOS. Consulte Arch boot process para conocer sus diferencias y el proceso de arranque con UEFI. Para configurar los cargadores de arranque UEFI, vea Category:Boot loaders.

Versiones de UEFI

  • UEFI comenzó como EFI de Intel en las versiones 1.x.
  • Luego, un grupo de empresas denominado UEFI Forum, se hizo cargo de su desarrollo, a partir del cual se llamó EFI Unificado desde de la versión 2.0.
  • Salvo que se especifique expresamente como EFI 1.x, los términos EFI y UEFI se utilizarán indistintamente para referirse al firmware 2.x de UEFI .
  • La implementación EFI de Apple no es ni la versión 1.x de EFI ni la versión 2.x, sino una combinación de ambas. Este tipo de firmware no entra dentro de ninguna versión de la especificación (U)EFI uno y, por lo tanto, no es un estándar del firmware de UEFI. A menos que se indique explícitamente, estas instrucciones son generales y algunas de ellas pueden no funcionar o pueden ser diferentes en Apple Macs.

La última especificación de UEFI se puede encontrar en http://uefi.org/specifications.

Firmware de UEFI

Con UEFI, cada programa, ya sea un cargador de sistema operativo o una utilidad (por ejemplo, una aplicación de prueba de memoria o una herramienta de recuperación), debe ser una aplicación EFI correspondiente a la arquitectura/bitness del firmware de UEFI.

La gran mayoría de los firmwares UEFI, incluidos los recientes Macs de Apple, usan el firmware UEFI x86_64. Los únicos dispositivos conocidos que utilizan UEFI IA32 (32 bits) son Apple Mac antiguos (anteriores a 2008), algunos ultrabooks Intel Cloverfield y algunas tarjetas del servidor Intel antiguo que se sabe que operan con firmware Intel EFI 1.10.

Un firmware UEFI x86_64 no incluye soporte para el inicio de aplicaciones EFI de 32 bits (a diferencia de las versiones de Linux y Windows x86_64, que incluyen dicho soporte). Por lo tanto, la aplicación EFI debe compilarse para el firmware de esa específica arquitectura del procesador.

Sistemas UEFI que no son Mac

Compruebe si el directorio /sys/firmware/efi existe; si existe, significa que el kernel ha arrancado en modalidad UEFI. En ese caso, se presumirá que la arquitectura de UEFI coincidirá con la del kernel (es decir, i686 o x86_64)

Nota: El chip del sistema Atom de Intel es entregado con UEFI de 32 bit (desde el 2 de noviembre de 2013). Véase esta página para obtener más información. Vea también esta publicación del blog de Intel.

Mac de Apple

Los Mac anteriores a 2008 tienen, en su mayoría, un firware IA32 EFI, mientras que los Mac >=2008 tienen, en su mayoría, x86_64 EFI. Todos los Mac capaces de ejecutar el kernel de Mac OS X Snow Leopard de 64-bit tienen un firmware EFI 1.x para x86_64.

Para saber la arquitectura del firmware EFI en un Mac, debe arrancar Mac OS X y escribir en un terminal la siguiente orden:

$ ioreg -l -p IODeviceTree | grep firmware-abi

Si la orden devuelve EFI32, entonces es el firmware EFI IA32 (32 bits). Si devuelve EFI64, entonces es el firmware EFI x86_64. La mayoría de los Mac no tienen firmware UEFI 2.x ya que la implementación de EFI de Apple no es totalmente compatible con la especificación UEFI 2.x.

Configuración de las opciones del kernel de Linux para UEFI

Las opciones requeridas para la configuración del kernel de Linux para sistemas UEFI son:

CONFIG_RELOCATABLE=y
CONFIG_EFI=y
CONFIG_EFI_STUB=y
CONFIG_FB_EFI=y
CONFIG_FRAMEBUFFER_CONSOLE=y
  • Soporte para las Variables Runtime de UEFI (el sistema de archivos efivarfs/sys/firmware/efi/efivars—). Esta opción es importante, ya que es necesaria para manipular las variables runtime de UEFI usando herramientas como /usr/bin/efibootmgr. La opción de configuración siguiente está añadida en el kernel 3.10 y posterior.:
    CONFIG_EFIVAR_FS=y
  • Soporte para las Variables Runtime de UEFI (la interfaz antigua efivars sysfs/sys/firmware/efi/vars—). Esta opción debe ser desactivada para evitar posibles problemas entre efivarfs con sysfs-efivars activados.:
    CONFIG_EFI_VARS=n
  • Opción de configuración de GUID Partition Table (GPT) —necesaria para dar soporte a UEFI—:
    CONFIG_EFI_PARTITION=y

Obtenido de https://www.kernel.org/doc/Documentation/x86/x86_64/uefi.txt.

Nota: Todas las opciones anteriores son necesarias para arrancar Linux con UEFI, y están activadas en los kernels de ArchLinux presentes en los repositorios oficiales.

Variables de UEFI

UEFI define las variables como la interacción de un sistema operativo con el firmware. Las variables de arranque de UEFI («UEFI Boot Variables») son utilizadas por el cargador de arranque y por el sistema operativo únicamente durante la primera fase de arranque. Las variables «runtime» de UEFI permiten a un sistema operativo gestionar ciertos ajustes del firmware, como la gestión del arranque de UEFI o la gestión de las claves para el protocolo «Boot Secure» de UEFI, etc. Se puede obtener el listado de las variables utilizando:

$ efivar --list

Soporte de las variables UEFI en el kernel de Linux

El kernel de Linux expone los datos de las variables UEFI en el espacio de usuario a través de la interfaz efivarfs (EFI VARiable FileSystem) (CONFIG_EFIVAR_FS) —montada utilizando el módulo del kernel efivarfs en /sys/firmware/efi/efivars— no tiene límite de tamaño máximo y admite las variables «Secure Boot» de UEFI. Introducido en kernel 3.8.

Requisitos para que el soporte de las variables UEFI funcione correctamente

  1. La arquitectura del procesador del Kernel y del procesador de UEFI deben coincidir.
  2. El kernel debe arrancar en modo EFI (a través de EFISTUB o de cualquier otro gestor de arranque EFI, no a través de BIOS/CSM o «bootcamp» de Apple que también es BIOS/CSM)
  3. El soporte para EFI Runtime Services debe estar presente en el kernel (CONFIG_EFI=y, compruebe si están presente con zgrep CONFIG_EFI /proc/config.gz).
  4. Los EFI Runtime Services del kernel NO DEBEN ser desactivados a través de un terminal, es decir, el parámetro noefi del kernel NO DEBE ser usado.
  5. El sistema de archivos efivarfs debe estar montado en /sys/firmware/efi/efivars, en otro caso, debe montar efivarfs.
  6. efivar debe mostar (con la opción -l) las variables EFI sin ningún error.

Si el soporte para las variables de EFI no funciona, incluso después de cumplirse las condiciones precedentes, pruebe las siguientes soluciones:

  1. Si cualquier herramienta del espacio de usuario no puede modificar los datos de las variables de EFI, compruebe la existencia de archivos en /sys/firmware/efi/efivars/dump-*. Si existen, elimínelos, reinicie y vuelva a intentarlo de nuevo.
  2. Si el paso anterior no resuelve el problema, intente arrancar con el parámetro del kernel efi_no_storage_paranoia para desactivar la variable efi del kernel que comprueba el espacio de almacenamiento, la cual puede impedir la escritura/modificación de las variables de efi.
Advertencia: efi_no_storage_paranoia solo debe utilizarse cuando sea necesario y no se debe dejar como una opción de arranque normal. El efecto de este parámetro en la línea de órdenes del kernel cancela una garantía que se pone en marcha para ayudar a evitar la saturación de las máquinas cuando NVRAM se llena demasiado.

Montar efivarfs

Si efivarfs no se monta automáticamente en /sys/firmware/efi/efivars por systemd durante el arranque, entonces necesita montarla manualmente para dejar expuesto el soporte para las variables de UEFI a las herramientas del espacio de usuario tales como efibootmgr:

# mount -t efivarfs efivarfs /sys/firmware/efi/efivars
Nota: La orden anterior debe ejecutarse tanto fuera (antes) como dentro de chroot, si procede.

Consulte efivarfs.txt para documentarse más sobre el kernel.

Herramientas en el espacio de usuario

Existen algunas herramientas que permiten acceder/modificar las variables UEFI, como:

  • efivar — Herramienta y biblioteca para modificar las variables de UEFI (utilizada por efibootmgr)
https://github.com/rhboot/efivar || efivar, efivar-gitAUR
  • efibootmgr — Herramienta para modificar las configuraciones del gestor de arranque del firmware de UEFI
https://github.com/rhboot/efibootmgr || efibootmgr
  • uefivars — Vuelca un listado de las variables de EFI con alguna información adicional sobre la PCI (utiliza el código de efibootmgr)
https://github.com/fpmurphy/Various/tree/master/uefivars-2.0 || uefivars-gitAUR
  • efitools — Herramientas para manipular las plataformas de secure boot de UEFI
https://git.kernel.org/pub/scm/linux/kernel/git/jejb/efitools.git || efitools
  • Suite de comprobación de firmware, de Ubuntu — Conjunto de herramientas de comprobación que realiza verificaciones de estado en el firmware de ordenadores con Intel/AMD
https://wiki.ubuntu.com/FirmwareTestSuite/ || fwts-gitAUR

efibootmgr

Nota:
  • Si efibootmgr no funciona en absoluto en su sistema, puede reiniciar en la shell de UEFI y utilizar la orden bcfg para crear una entrada de arranque en el gestor de arranque.
  • Si no es posible usar efibootmgr, algunos firmwares UEFI permiten a los usuarios gestionar directamente las entradas de inicio de UEFI desde la interfaz que aparece durante el arranque. Por ejemplo, algunas BIOS de ASUS tienen una opción llamada «Add New Boot Option» («Añadir nueva opción de arranque») que permite seleccionar una partición de sistema EFI local e introducir manualmente la ubicación del código de EFI (por ejemplo \EFI\refind\refind_x64.efi).
  • Las siguientes órdenes utilizan el cargador de arranque rEFInd como ejemplo.

Para añadir una nueva opción de arranque usando efibootmgr, necesita saber tres cosas:

  1. El disco que contiene la EFI system partition (Español) (ESP): /dev/sdX
  2. El número de partición de la ESP en ese disco: la Y en /dev/sdXY
  3. La ruta a la aplicación EFI (relativa a la raíz de la ESP)

Por ejemplo, si desea agregar una opción de arranque para /efi/EFI/refind/refind_x64.efi donde /efi es el punto de montaje de la partición ESP, ejecute:

$ findmnt /efi
TARGET SOURCE    FSTYPE OPTIONS
/efi   /dev/sda1 vfat   rw,flush,tz=UTC

En este ejemplo, esto indica que la partición ESP está en el disco /dev/sda y el número de la partición es 1. La ruta a la aplicación EFI relativa a la raíz de la ESP es /EFI/refind/refind_x64.efi. Sabiendo esto, se crearía la entrada de arranque de la siguiente manera:

# efibootmgr --create --disk /dev/sda --part 1 --loader /EFI/refind/refind_x64.efi --label "rEFInd Boot Manager" --verbose

Consulte efibootmgr(8) o el archivo README de efibootmgr para obtener más información.

Nota: UEFI utiliza una barra invertida \ como separador de ruta, pero efibootmgr convierte automáticamente los separadores de ruta en barra normal / al estilo UNIX.

La shell de UEFI

La shell (esto es, el intérprete de línea de órdenes) de UEFI es una shell/terminal para el firmware, que permite ejecutar aplicaciones UEFI que incluyen los cargadores de arranque UEFI. Aparte de esto, la shell también se puede utilizar para obtener información variada sobre el sistema o del firmware del mapa de la memoria (memmap), modificar las variables del gestor de arranque (bcfg), ejecutar programas de gestión de particiones (diskpart), cargar los controladores UEFI, editar archivos de texto (edit), hexedit, etc.

Obtener la shell de UEFI

Puede descargar una shell de UEFI con licencia BSD de Tianocore de Intel desde el proyecto UDK/EDK2.

La versión 2.0 de la shell únicamente funciona en sistemas UEFI 2.3 + y se recomienda su uso con preferencia a la shell 1.0 en esos sistemas. La versión 1.3 de la shell debería funcionar en todos los sistemas UEFI, independientemente de la especificación de la versión del firmware. Más información en ShellPkg y este correo.

Lanzar la shell de UEFI

Algunas placas base Asus y otras basadas en el firmware UEFI AMI Aptio x86_64 (de Sandy Bridge en adelante) ofrecen una opción llamada «Launch EFI Shell from filesystem device». Para estas placas base, descargue la shell de UEFI x86_64 y cópiela a la partición del sistema UEFI renombrándola como <UEFI_SYSTEM_PARTITION>/shellx64.efi (normalmente en la carpeta /boot/efi/shellx64.efi).

Los sistemas con un firmware UEFI Phoenix SecureCore Tiano se sabe que llevan integrada la shell de UEFI, la cual se puede iniciar presionando las teclas F6, F11 o F12.

Nota: Si es incapaz de lanzar la shell de UEFI directamente desde el firmware mediante cualquiera de los métodos mencionados anteriormente, cree una unidad USB formateada con FAT32 conteniendo la Shell.efi, copiada con la ruta (USB)/efi/boot/bootx64.efi. Este USB debería aparecer en el menú de arranque del firmware. La inicialización de esta opción lanzará la shell de UEFI.

Órdenes importantes de la shell de UEFI

Las órdenes de la shell de UEFI generalmente dan soporte a la opción -b que hace una pausa después de la salida de cada página. Ejecute help -b para ver las órdenes disponibles.

Puede obtener más información en http://software.intel.com/en-us/articles/efi-shells-and-scripting/

bcfg

La orden bcfg se utiliza para modificar las entradas en la NVRAM de UEFI, lo que permite cambiar las entradas de arranque o las opciones del controlador. Esta orden se describe con detalle en la página 83 (sección 5.3) del documento UEFI Shell Specification 2.0

Nota:
  • Se recomienda probar bcfg únicamente si efibootmgr no puede crear entradas de inicio que funcionen en el propio sistema.
  • La versión 1 del binario oficial de la shell de UEFI no proporciona soporte para la orden bcfg. Consulte #Obtener la shell de UEFI para un binario UEFI shell v2 modificado que puede funcionar en UEFI con firmwares anteriores a 2.3.

Para conocer una lista de entradas de arranque actuales:

Shell> bcfg boot dump -v

Para añadir una entrada para rEFInd (por ejemplo) como cuarta (la numeración empieza desde cero) en el menú de arranque:

Shell> bcfg boot add 3 FS0:\EFI\refind\refind_x64.efi "rEFInd"

donde FS0: es la asignación correspondiente a la partición del sistema UEFI y FS0:\EFI\refind\refind_x64.efi es el archivo que se pondrá en marcha.

Para agregar una entrada con el fin de iniciar directamente su sistema, sin un gestor de arranque, configure una opción de arranque utilizando su kernel como EFISTUB:

Shell> bcfg boot add N fsV:\vmlinuz-linux "Arch Linux"
Shell> bcfg boot -opt N "root=/dev/sdX# initrd=\initramfs-linux.img"

donde N es la prioridad, V es el número de volumen donde se encuetra la partición de sistema EFI, y /dev/sdX# es la partición raíz.

Para quitar la opción de arranque cuarta:

Shell> bcfg boot rm 3

Para mover la opción de arranque #3 a #0 (es decir, a la primera posición o la entrada por defecto en el menú de inicio de UEFI):

Shell> bcfg boot mv 3 0

Para mostrar el texto de ayuda de bcfg:

Shell> help bcfg -v -b

o

Shell> bcfg -? -v -b

map

La orden map muestra un mapeado de los dispositivos, es decir, los nombres de los sistemas de archivos disponibles (FS0) y los dispositivos de almacenamiento (blk0).

Antes de ejecutar órdenes relacionadas con el sistema de archivos, como cd o ls, debe cambiar la shell al sistema de archivos correspondiente, escribiendo su nombre:

Shell> FS0:
FS0:\> cd EFI/

edit

La orden edit proporciona un editor de texto básico, con una interfaz similar al editor de texto nano, pero ligeramente menos funcional. Maneja codificación UTF-8 y se hace cargo del final de la línea LF frente a CRLF.

Para editar, por ejemplo, refind.conf de rEFInd en la partición del sistema UEFI (FS0: en el firmware):

Shell> edit FS0:\EFI\refind\refind.conf

Escriba Ctrl-E para obtener ayuda.

Soporte para arrancar UEFI

Crear un USB arrancable con UEFI desde la ISO

Siga las instrucciones del siguiente artículo USB Installation Media (Español)#Crear USB para arrancar desde sistemas BIOS y UEFI

Eliminar el apoyo de arranque de UEFI de una unidad óptica

Nota: Esta sección menciona la eliminación de la ayuda de arranque UEFI desde un CD/DVD únicamente (soporte óptico), no desde una unidad flash USB.

La mayoría de los Mac EFI de 32-bit y algunos Mac EFI de 64 bits se niegan a arrancar desde un CD/DVD bootable con una combinación de UEFI(X64)+BIOS. Si se desea continuar con la instalación con soportes ópticos, puede que sea necesario, primero, eliminar el apoyo a UEFI.

  • Monte el soporte de instalación oficial y obtenga el archisolabel como se muestra en la sección anterior.
# mount -o loop input.iso /mnt/iso
  • Después reconstruya la ISO, excluyendo el soporte de arranque de UEFI de la imágen destinada al disco óptico, utilizando xorriso de libisoburn. Asegúrese de configurar el archisolabel correcto, por ejemplo «ARCH_201411» o similar:
$ xorriso -as mkisofs -iso-level 3 \
    -full-iso9660-filenames\
    -volid "archisolabel" \
    -appid "Arch Linux CD" \
    -publisher "Arch Linux <https://www.archlinux.org>" \
    -preparer "prepared by $USER" \
    -eltorito-boot isolinux/isolinux.bin \
    -eltorito-catalog isolinux/boot.cat \
    -no-emul-boot -boot-load-size 4 -boot-info-table \
    -isohybrid-mbr "/mnt/iso/isolinux/isohdpfx.bin" \
    -output output.iso /mnt/iso/
  • Grabe output.iso en el disco óptico y continúe con la instalación de forma normal.

Arrancar el kernel de 64-bit en UEFI de 32-bit

La imagen ISO oficial (Archiso) no admite el arranque en sistemas UEFI de 32 bits (FS#53182) ya que utiliza EFISTUB (a través del administrador de arranque systemd-boot para el menú) para arancar el kernel en modo UEFI. Para arrancar un kernel de 64 bits con UEFI de 32 bits, debe usar un gestor de arranque que no se base en el código de arranque de EFI para lanzar los kernel.

Sugerencia: la imagen iso de Archboot admite el arranque en sistemas UEFI de 32 bits.

Utilizar GRUB

Esta sección describe cómo configurar GRUB como el cargador de arranque UEFI del USB.

# echo 'configfile ${cmdpath}/grub.cfg' > /tmp/grub.cfg
# grub-mkstandalone -d /usr/lib/grub/i386-efi -O i386-efi --modules="part_gpt part_msdos" --locales="en@quot" --themes="" -o "/mnt/usb/EFI/boot/bootia32.efi" "boot/grub/grub.cfg=/tmp/grub.cfg" -v
  • Cree /mnt/usb/EFI/boot/grub.cfg con los siguientes contenidos (sustituya ARCH_YYYYMM con la etiqueta archiso adecuada, por ejemplo ARCH_201507):
Sugerencia:
  • La etiqueta archiso se puede obtener del archivo .iso con la herramienta isoinfo del paquete cdrtools, o iso-info de libcdio.
  • Las entradas de configuración dadas también pueden ingresarse dentro de una shell de GRUB.

Para el ISO oficial:

/mnt/usb/EFI/boot/grub.cfg
insmod part_gpt
insmod part_msdos
insmod fat

insmod efi_gop
insmod efi_uga
insmod video_bochs
insmod video_cirrus

insmod font

if loadfont "${prefix}/fonts/unicode.pf2" ; then
    insmod gfxterm
    set gfxmode="1024x768x32;auto"
    terminal_input console
    terminal_output gfxterm
fi

menuentry "Arch Linux archiso x86_64 UEFI USB" {
    set gfxpayload=keep
    search --no-floppy --set=root --label ARCH_YYYYMM
    linux /arch/boot/x86_64/vmlinuz archisobasedir=arch archisolabel=ARCH_YYYYMM add_efi_memmap
    initrd /arch/boot/intel_ucode.img /arch/boot/x86_64/archiso.img
}

Probar UEFI en sistemas sin soporte nativo

OVMF para máquinas virtuales

OVMF es un proyecto de TianoCore destinado a activar la compatibilidad de UEFI para máquinas virtuales. OVMF contiene una muestra de firmware UEFI para QEMU.

Se puede instalar ovmf desde el repositorio extra.

Es recomendable hacer una copia local del conjunto de variables no volátiles para su máquina virtual:

$ cp /usr/share/ovmf/x64/OVMF_VARS.fd my_uefi_vars.bin

Para usar el firmware OVMF y el conjunto de variables, añada la siguiente orden a su QEMU:

-drive if=pflash,format=raw,readonly,file=/usr/share/ovmf/x64/OVMF_CODE.fd \
-drive if=pflash,format=raw,file=my_uefi_vars.bin

Por ejemplo:

$ qemu-system-x86_64 -enable-kvm -m 1G -drive if=pflash,format=raw,readonly,file=/usr/share/ovmf/x64/OVMF_CODE.fd -drive if=pflash,format=raw,file=my_uefi_vars.bin …

DUET para sistemas BIOS únicamente

DUET es un proyecto TianoCore que permite cargar en cadena un entorno UEFI completo desde un sistema BIOS, de manera similar al arranque de los sistemas operativos en entorno BIOS. Este método se está discutiendo ampliamente en http://www.insanelymac.com/forum/topic/186440-linux-and-windows-uefi-boot-using-tianocore-duet-firmware/ . Imágenes DUET precompiladas se pueden descargar de uno de los repositorios de https://gitorious.org/tianocore_uefi_duet_builds. Instrucciones específicas para la creación de DUET están disponible en https://gitorious.org/tianocore_uefi_duet_builds/tianocore_uefi_duet_installer/blobs/raw/master/Migle_BootDuet_INSTALL.txt .

También puede probar http://sourceforge.net/projects/cloverefiboot/ que proporciona imágenes DUET modificadas que puedan contener algunos arreglos específicos del sistema y son más frecuentemente actualizadas en comparación con las de los repositorios gitorious.

Solución de problemas

Windows 7 no se inicia en la modalidad UEFI

Si tiene instalado Windows en un disco duro con particionado GPT y sigue teniendo otro disco duro diferente con particionado MBR en su ordenador, entonces es posible que el firmware (UEFI) está dando su apoyo CSM a este último (para arrancar particiones MBR) y por ello Windows no arranca. Para resolver este problema convierta el particionado de su disco MBR a GPT, o desactive el puerto SATA del disco duro cuando esté conectado, o bien, desenchufe el puerto SATA de este disco duro.

Placas base con este tipo de problema:

  • Gigabyte Z77X-UD3H rev. 1.1 (BIOS UEFI versión F19e)
    • La opción «UEFI Only» de la BIOS UEFI no pretende hacer que la BIOS UEFI arranque desde CSM.

Windows cambia el orden de arranque

Si el arranque dual con Windows y su placa base solo inicia Windows de forma inmediata en lugar mostrar la elección de su aplicación EFI, existen varias causas posibles y soluciones alternativas.

  • Asegúrese de que el inicio rápido esté desactivado en las opciones de energía de Windows
  • Asegúrese de que Secure Boot esté desactivado en su BIOS (si no está utilizando un gestor de arranque firmado)
  • Asegúrese de que el orden de arranque de UEFI no tiene establecido primero «Windows Boot Manager» utilizando, por ejemplo, #efibootmgr and what you see in the configuration tool of the UEFI. Algunas placas base anulan, por defecto, cualquier configuración establecida con efibootmgr por Windows, si la detecta. Esto se confirma en una computadora portátil Packard Bell.
  • Si su placa base está iniciando la ruta de inicio predeterminada (\EFI\BOOT\BOOTX64.EFI), este archivo puede haber sido sobrescrito con el cargador de arranque de Windows. Intente configurar la ruta de inicio correcta, por ejemplo utilizando #efibootmgr.
  • Si los pasos anteriores no funcionan, puede decirle al gestor de arranque de Windows que ejecute una aplicación EFI diferente. Desde un prompt de órdenes de «Windows Administrator»:
    # bcdedit /set "{bootmgr}" path "\EFI\path\to\app.efi"
  • Alternativamente, puede establecer una secuencia de órdenes de inicio en Windows que garantice que el orden de inicio esté configurado correctamente cada vez que inicie Windows.
    1. Abra un promtp de órdenes (símbolo del sistema) con privilegios de administrador. Ejecute bcdedit /enum firmware y encuentre la entrada de inicio deseada.
    2. Copie el Identificador, incluidos los corchetes, por ejemplo {31d0d5f4-22ad-11e5-b30b-806e6f6e6963}
    3. Cree un archivo por lotes con la siguiente orden bcdedit /set "{fwbootmgr}" DEFAULT "{copied boot identifier}"
    4. Abra gpedit.msc y en Local Computer Policy > Computer Configuration > Windows Settings > Scripts(Startup/Shutdown), seleccione Startup
    5. En la pestaña Scripts, seleccione el botón Add, y seleccione su archivo por lotes.

El soporte USB se topa con una pantalla negra

Este problema puede ocurrir debido a un problema con KMS. Pruebe desactivar KMS mientras arranca el USB.

El cargador de arranque UEFI no aparece en el menú del firmware

En ciertas placas base UEFI, como algunas placas con un chipset Intel Z77, agregar entradas con efibootmgr o bcfg desde la shell de UEFI no funcionará, porque no aparecerán en la lista del menú de arranque después de haber sido agregadas a NVRAM.

Este problema se debe a que las placas base solo pueden cargar Microsoft Windows. Para resolver esto, debe colocar el archivo .efi en la ubicación que usa Windows.

Copie el archivo bootx64.efi del soporte de instalación de Arch Linux (FSO:) en el directorio de Microsoft de la partición ESP de su disco duro (FS1:). Haga esto arrancando la shell EFI y escribiendo:

Shell> mkdir FS1:\EFI\Microsoft
Shell> mkdir FS1:\EFI\Microsoft\Boot
Shell> cp FS0:\EFI\BOOT\bootx64.efi FS1:\EFI\Microsoft\Boot\bootmgfw.efi

Después del reinicio, las entradas agregadas a la NVRAM deben aparecer en el menú de inicio.

Véase también