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

From ArchWiki
Jump to: navigation, search
(Crear un USB booteable de UEFI desde la ISO: Actualizar)
m (moviendo plantilla TranslationStatus a su lugar)
 
(57 intermediate revisions by 10 users not shown)
Line 2: Line 2:
 
[[en:Unified Extensible Firmware Interface]]
 
[[en:Unified Extensible Firmware Interface]]
 
[[it:Unified Extensible Firmware Interface]]
 
[[it:Unified Extensible Firmware Interface]]
 +
[[ja:Unified Extensible Firmware Interface]]
 
[[ru:Unified Extensible Firmware Interface]]
 
[[ru:Unified Extensible Firmware Interface]]
[[zh-CN:Unified Extensible Firmware Interface]]
+
[[zh-hans:Unified Extensible Firmware Interface]]
{{Article summary start|Sumario}}
+
{{TranslationStatus (Español)|Unified Extensible Firmware Interface|2018-08-31|538790}}
{{Article summary text|Visión general de la  Interfaz Extensible del Firmware Unificado.}}
+
{{Related articles start (Español)}}
{{Article summary heading|Descripción}}
+
{{Related|EFI system partition (Español)}}
{{Article summary text|Para poder iniciar Arch Linux, es necesario tener instalado en el [[Master_Boot_Record_(Español)|Master Boot Record (MBR)]] o en la [[GUID_Partition_Table_(Español)|GUID Partition Table (GPT)]] un gestor de arranque compatible con Linux como [[GRUB2 (Español)|GRUB(2)]], [[Syslinux_(Español)|Syslinux]], [[LILO|LILO]] o [[GRUB_Legacy|GRUB Legacy]]. El gestor de arranque es responsable de cargar el kernel y el [[Mkinitcpio_(Español)|ramdisk inicial]] antes de iniciar el [[Arch_Boot_Process_(Español)|proceso de arranque]].}}
+
{{Related|Arch boot process (Español)}}
{{Article summary heading|Relacionado}}
+
{{Related|GUID Partition Table (Español)}}
{{Article summary wiki|GUID Partition Table (Español)}}
+
{{Related|Secure Boot}}
{{Article summary wiki|Master Boot Record (Español)}}
+
{{Related articles end}}
{{Article summary wiki|Arch Boot Process (Español)}}
+
{{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.}}
{{Article summary end}}
 
  
'''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 comunmente desde el código de arranque del MBR (''MBR boot code''), seguido por los sistemas BIOS. Comenzó como EFI de Intel en las versiones 1.x y luego, un grupo de empresas denominado Fórum UEFI, se hizo cargo de su desarrollo, a partir del cual se llamó  EFI Unificado desde de la versión 2.0. Hasta el 23 de mayo de 2012, la Especificación 2.3.1 de UEFI 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|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. 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.}}
+
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]].
  
== Iniciar un sistema operativo usando la BIOS ==
+
== Versiones de UEFI ==
  
Una BIOS o ''«Basic Input-Output System»'' es el primer programa que se ejecuta cuando el sistema está encendido. Después de que todo el hardware se ha inicializado y la operación POST (''«Power On Self Test»'') se ha completado, la BIOS ejecuta el código de arranque por primera vez, ubicado en el primer dispositivo de la lista de dispositivos de arranque.
+
* 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]].
  
Si la lista de dispositivos de arranque comienza con una unidad de CD/DVD, entonces la entrada de [[wikipedia:es:eEl_Torito_(CD-ROM_Standard)|El-Torito]] en el CD/DVD se ejecuta. Así es como una unidad de CD/DVD funciona. Si la lista comienza con un disco duro, entonces la BIOS ejecuta el código de arranque del MBR situado en los primeros 440 bytes del disco. El código de arranque luego encadena o transfiere el proceso a un gestor de arranque, mucho más grande y complejo, que, a su vez, carga el sistema operativo.
+
La última especificación de UEFI se puede encontrar en http://uefi.org/specifications.
  
Básicamente, la BIOS no sabe cómo leer una tabla de particiones o sistema de archivos. Todo lo que hace es inicializar el hardware, para, a continuación, cargar y ejecutar el código de arranque de los 440-byte.
+
== Firmware de UEFI ==
  
=== Multiarranque en BIOS ===
+
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.
  
Dado que se puede obtener muy poco de un programa que debe adaptarse solo a los primeros 440 bytes del disco, para el inicio multiple usando la BIOS es necesario un gestor de arranque que gestione los arranques múltiples (multiarranque se refiere a arrancar múltiples sistemas operativos, no a arrancar un kernel en el formato multiboot especificado por los desarrolladores de GRUB). Así que, por lo general, un gestor de arranque común como [[GRUB2 (Español)|GRUB]], [[Syslinux (Español)|Syslinux]] o [[LILO]] sería cargado por la BIOS, el cual, seguidamente, se ocuparía de cargar el sistema operativo, ya sea cargando los sistemas en cadena, ya sea cargando directamente el kernel.
+
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.
  
== Arrancar un sistema operativo usando 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.
  
El firmware UEFI no soporta el arranque del sistema a través del método antes mencionado, que es la única manera apoyada por la BIOS. UEFI tiene la capacidad de leer tanto la tabla de particiones, como de reconocer los sistemas de archivos.
+
=== Sistemas UEFI que no son Mac ===
  
Los firmwares UEFI comunmente utilizados dan apoyo tanto a los sistemas de particionado MBR como GPT. Las EFI de Apple son conocidos por apoyar mapas de particionado Apple, además de MBR y GPT. La mayoría de los firmwares UEFI tienen soporte para acceder a sistemas de archivos FAT12 (disquetes), FAT16 y FAT32 en disco duro, y ISO9660 (y UDF) en CD/DVD. El firmware EFI en Apple puede acceder también a HFS/HFS+, aparte de los mencionados.
+
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)
  
UEFI no ejecuta ningún código de arranque del MBR tanto si existe como si no. En su lugar, utiliza una partición especial de la tabla de particiones, llamada ''«EFI SYSTEM PARTITION»'' (partición del sistema EFI), en la que se guardan los archivos necesarios para ser lanzado el firmware. Cada proveedor puede almacenar sus archivos en la carpeta <EFI SYSTEM PARTITION>/EFI/<FABRICANTE>/ y pueden usar el firmware o la shell (shell de UEFI) para iniciar el programa de arranque. Una partición del sistema EFI usa, por lo general, el formato FAT32.
+
{{Nota|El chip del sistema Atom de Intel es entregado con UEFI de 32 bit (desde el 2 de noviembre de 2013). Véase [[#Arrancar el kernel de 64-bit en UEFI de 32-bit|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].}}
  
Bajo UEFI, todos los programas que son cargados por un sistema operativo o por otros instrumentos (como aplicaciones de pruebas de memoria) o herramientas de recuperación fuera del sistema operativo, deben ser aplicaciones UEFI correspondiente a la arquitectura del firmware EFI. La mayor parte de los firmware UEFI en el mercado, incluyendo los recientes Mac de Apple, usan un firmware EFI x86_64. Solo algunos Mac más antiguos utilizan el firmware EFI i386, mientras que un sistema UEFI que no sea Apple, soporta el uso del firmware EFI i386.
+
=== Mac de Apple ===
  
{{Nota|Algunas unidades antiguas de las placas Intel Server se sabe que operan en Intel EFI firmware 1.10, y requieren aplicaciones EFI i386.}}
+
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.
  
Un firmware EFI x86_64 no incluye el soporte para lanzar aplicaciones de 32-bits, a diferencia del EFI de Linux y de Windows que incluyen dicho apoyo. En definitiva, el gestor de arranque debe ser compilado para la arquitectura correcta.
+
Para saber la arquitectura del firmware EFI en un Mac, debe arrancar Mac OS X y escribir en un terminal la siguiente orden:
  
=== Multiarranque en UEFI ===
+
$ ioreg -l -p IODeviceTree | grep firmware-abi
  
Debido a que cada sistema operativo o fabricante puede mantener sus propios archivos en la partición del sistema EFI sin afectar a otros, 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 cargarlo en cadena en un gestor de arranque para iniciar otros sistemas operativos.
+
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.
  
==== Multiarranque de Linux/Windows x86_64 en UEFI con GPT ====
+
== Configuración de las opciones del kernel de Linux para UEFI ==
  
Las versiones de Windows Vista (SP1+), 7 Professional y 8 x86_64, permiten arrancar de forma nativa utilizando el firmware UEFI. Pero para ello necesitan el sistema de particionado [[GUID Partition Table (Español)|GPT]] del disco utilizado, para el arranque UEFI. Las versiones de Windows x86_64 soportan tanto el arranque en sistemas UEFI-GPT como BIOS-MBR. 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 en cuanto a cómo hacer esto. Véase http://support.microsoft.com/default.aspx?scid=kb;EN-US;2581408 para más información.
+
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''' —{{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'' (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]] (GPT) —necesaria para dar soporte a UEFI—: {{bc|1=CONFIG_EFI_PARTITION=y}}
  
Estas limitaciones no existe en el kernel de Linux, sino que depende del gestor de arranque utilizado. Para un adecuado arranque de Windows con UEFI, el gestor de arranque de Linux utilizado también debe ser instalado en la modalidad UEFI-GPT, si arrancan ambos sistemas desde el mismo disco.
+
Obtenido de https://www.kernel.org/doc/Documentation/x86/x86_64/uefi.txt.
  
== Proceso de arranque bajo UEFI ==
+
{{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.}}
  
# Encendido del sistema -se inicia Power On Self Test, o el proceso POST-.
+
== Variables de UEFI ==
# Se carga el firmware UEFI.
 
# El firmware lee el gestor de arranque para determinar qué aplicación UEFI iniciar, y de dónde (es decir, desde qué disco y partición).
 
# El firmware UEFI inicia la aplicación desde la partición UEFISYS con formato FAT32 definido 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.
 
  
== Detectar la arquitectura del firmware 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:
  
Si se tiene un sistema UEFI que no es Mac , entonces tiene un UEFI firmware 2.x para x86_64 (también conocido como 64-bit).
+
$ efivar --list
  
Algunos de los conocidos firmwares UEFI 2.x para la arquitectura x86_64 son Phoenix SecureCore Tiano, Aptio AMI, Insyde H2O.
+
=== Soporte de las variables UEFI en el kernel de Linux ===
  
Algunos de los sistemas más conocidos que utilizan estos firmwares son Asus EZ Mode BIOS (placas base con Sandy Bridge P67 y H67),  MSI ClickBIOS, HP EliteBooks, Sony Vaio series Z, y muchas placas base Intel para servidor y escritorio.
+
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.
  
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.
+
===Requisitos para que el soporte de las variables UEFI funcione correctamente===
  
Para saber la arquitectura del firmware EFI en un Mac, debe arrancar Mac OS X y escribir la siguiente orden:
+
# La [[#Firmware de UEFI|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 loader|gestor de arranque EFI]], no a través de BIOS/CSM o «bootcamp» de Apple que también es BIOS/CSM)
 +
# 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}}).
 +
# 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, debe [[#Montar efivarfs|montar efivarfs]].
 +
# {{ic|efivar}} debe mostar (con la opción {{ic|-l}}) las variables EFI sin ningún error.
  
<pre>
+
Si el soporte para las variables de EFI no funciona, incluso después de cumplirse las condiciones precedentes, pruebe las siguientes soluciones:
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 de Apple del firmware EFI no es totalmente compatible con la especificación UEFI.
+
# Si cualquier herramienta del espacio de usuario no puede modificar los datos de las variables de EFI, compruebe la existencia de archivos en {{ic|/sys/firmware/efi/efivars/dump-*}}. Si existen, elimínelos, reinicie y vuelva a intentarlo de nuevo.
 +
# 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.
  
== Apoyo de UEFI en el Kernel de Linux ==
+
{{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.}}
  
=== Configuración de las opciones del Kernel de Linux para UEFI ===
+
==== Montar efivarfs ====
  
Las opciones requeridas para la configuración del kernel de Linux para sistemas UEFI son:
+
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'':
  
  CONFIG_EFI=y
+
  # mount -t efivarfs efivarfs /sys/firmware/efi/efivars
CONFIG_EFI_STUB=y
 
CONFIG_RELOCATABLE=y
 
CONFIG_FB_EFI=y
 
CONFIG_FRAMEBUFFER_CONSOLE=y
 
  
Para dar soporte a las variables/servicios Runtime de UEFI existe el módulo del kernel «efivars». Esta opción es importante, ya que es necesaria para manipular las variables Runtime de UEFI mediante herramientas como '''efibootmgr'''.
+
{{Nota|La orden anterior debe ejecutarse tanto '''fuera (antes)''' como '''dentro''' de [[chroot]], si procede.}}
 
 
  CONFIG_EFI_VARS=m
 
  
{{Nota|Esta opción está compilada como módulo en el kernel core/testing de Arch.}}
+
Consulte [https://www.kernel.org/doc/Documentation/filesystems/efivarfs.txt efivarfs.txt] para documentarse más sobre el kernel.
  
{{Nota|Para permitir a Linux acceder a los servicios de runtime de UEFI, la arquitectura del firmware UEFI y la arquitectura del procesador del kernel de Linux deben coincidir. Esto es independiente del gestor de arranque utilizado.}}
+
===Herramientas en el espacio de usuario===
  
{{Nota| Si la arquitectura del firmware UEFI y la del procesador del kernel de Linux son diferentes, entonces se debe utilizar el parámetro '''«noefi»''' en la línea de comandos del kernel para evitar el ''kernel panic'' y para que se pueda realizar el arranque correctamente. La opción «noefi» indica al kernel que no acceda a los servicios de runtime de UEFI.}}
+
Existen algunas herramientas que permiten acceder/modificar las variables UEFI, como:
  
Para la compatibilidad con UEFI es necesaria la opción [[GUID Partition Table (Español)|GPT]] (GUID Partition Table) de configuración para la tabla de particiones:  
+
* {{App|efivar|Herramienta y biblioteca para modificar las variables de UEFI (utilizada por efibootmgr)|https://github.com/rhboot/efivar|{{Pkg|efivar}}, {{AUR|efivar-git}}}}
 +
* {{App|efibootmgr|Herramienta para modificar las configuraciones del gestor de arranque del firmware de UEFI|https://github.com/rhboot/efibootmgr|{{Pkg|efibootmgr}}}}
 +
* {{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}}}}
 +
* {{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}}}}
 +
* {{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}}}}
  
  CONFIG_EFI_PARTITION=y
+
==== efibootmgr ====
  
{{Nota|Todas las opciones anteriores son necesarias para arrancar Linux en UEFI, y están habilitadas en los kernels de ArchLinux presentes en los repositorios oficiales.}}
+
{{Nota|
 +
*Si {{ic|efibootmgr}} no funciona en absoluto en su sistema, puede reiniciar en el [[#Intérprete de órdenes UEFI|intérprete de órdenes 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 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 [[rEFInd]] como ejemplo.
 +
}}
  
Obtenido desde http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=blob_plain;f=Documentation/x86/x86_64/uefi.txt;hb=HEAD .
+
Para añadir una nueva opción de arranque usando ''efibootmgr'', necesita saber tres cosas:
  
== Apoyo de las variables de UEFI ==
+
# 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)
  
UEFI define las variables como la interacción de un sistema operativo con el firmware. Las variables de arranque de UEFI 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 de UEFI Boot Secure, etc.
+
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:
  
{{Nota|Los siguientes pasos no funcionarán si el sistema se ha arrancado en modo BIOS y tampoco funcionarán si la arquitectura del procesador UEFI no coincide con la del kernel, es decir, la configuración UEFI x86_64  + Kernel x86 32-bit y viceversa, no funcionará. Esto es cierto únicamente para el módulo del kernel efivars y para efibootmgr. Los otros pasos (es decir, hasta la creación de <UEFISYS>/EFI/arch/refind/{refindx64.efi,refind.conf}) se pueden hacer, incluso, para iniciar en modo de BIOS/Legacy.}}
+
{{hc|$ findmnt /efi|2=
 +
TARGET SOURCE    FSTYPE OPTIONS
 +
/efi  /dev/sda1 vfat  rw,flush,tz=UTC
 +
}}
  
El acceso a los servicios de runtime de UEFI es proporcionado por el módulo del kernel «efivars», que se activa a través de la opción {{ic|<nowiki>CONFIG_EFI_VAR=m</nowiki>}} de configuración del kernel. Con este módulo, una vez cargado, se garantiza el acceso a las variables presentes en el directorio {{ic|/sys/firmware/efi/vars}}. Una forma de comprobar si el sistema ha arrancado en modo de inicio UEFI es cargar el módulo del kernel «efivars» y comprobar la existencia de la carpeta {{ic|/sys/firmware/efi/vars}} con debería tener un contenido similar a este:
+
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:
  
Muestra de salida (UEFI 2.3.1-x86_64 en Kernel x86_64):
+
  # efibootmgr --create --disk /dev/sda --part 1 --loader /EFI/refind/refind_x64.efi --label "rEFInd Boot Manager" --verbose
 
  # ls -1 /sys/firmware/efi/vars/
 
Boot0000-8be4df61-93ca-11d2-aa0d-00e098032b8c/
 
BootCurrent-8be4df61-93ca-11d2-aa0d-00e098032b8c/
 
BootOptionSupport-8be4df61-93ca-11d2-aa0d-00e098032b8c/
 
BootOrder-8be4df61-93ca-11d2-aa0d-00e098032b8c/
 
ConIn-8be4df61-93ca-11d2-aa0d-00e098032b8c/
 
ConInDev-8be4df61-93ca-11d2-aa0d-00e098032b8c/
 
ConOut-8be4df61-93ca-11d2-aa0d-00e098032b8c/
 
ConOutDev-8be4df61-93ca-11d2-aa0d-00e098032b8c/
 
ErrOutDev-8be4df61-93ca-11d2-aa0d-00e098032b8c/
 
Lang-8be4df61-93ca-11d2-aa0d-00e098032b8c/
 
LangCodes-8be4df61-93ca-11d2-aa0d-00e098032b8c/
 
MTC-eb704011-1402-11d3-8e77-00a0c969723b/
 
MemoryTypeInformation-4c19049f-4137-4dd3-9c10-8b97a83ffdfa/
 
PlatformLang-8be4df61-93ca-11d2-aa0d-00e098032b8c/
 
PlatformLangCodes-8be4df61-93ca-11d2-aa0d-00e098032b8c/
 
RTC-378d7b65-8da9-4773-b6e4-a47826a833e1/
 
del_var
 
new_var
 
  
Las Variables Runtime de UEFI no se cargan en el sistema operativo si se ha usado el parámetro del kernel «noefi» en el menú del gestor de arranque. Este parámetro indica al kernel que ignore completamente los Servicios Runtime de UEFI.
+
Consulte {{man|8|efibootmgr}} o el archivo [https://raw.githubusercontent.com/rhinstaller/efibootmgr/master/README README de efibootmgr] para obtener más información.
  
=== Herramientas del espacio de usuario ===
+
{{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.}}
  
Existen algunas herramientas que permiten acceder/modificar las variables UEFI, como:
+
== Intérprete de órdenes UEFI ==
  
# efibootmgr - Utilizada para crear/modificar las entradas de inicio del gestor de arranque de UEFI - {{Pkg|efibootmgr}} o {{AUR|efibootmgr-git}}
+
El intérprete de órdenes de UEFI es una intérprete/terminal para el firmware, que permite ejecutar aplicaciones UEFI que incluyen los cargadores de arranque UEFI. Aparte de esto, el intérprete 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.  
# uefivars - Simplemente accede a las variables - {{AUR|uefivars-git}} - utiliza la biblioteca efibootmgr.
 
# Firmware Test Suite de Ubuntu- fwts - {{AUR|fwts-git}} - la orden uefidump - {{ic|fwts uefidump}}
 
  
=== Sistemas UEFI en no-Mac  ===
+
=== Obtener el intérprete de órdenes UEFI ===
  
==== efibootmgr ====
+
Puede descargar un intérprete de órdenes UEFI con licencia BSD de Tianocore de Intel desde el proyecto UDK/EDK2.
  
{{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}}.}}
+
* 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.
 +
* 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 orden {{ic|efibootmgr}} funcionará únicamente si ha arrancado el sistema en modo UEFI, ya que '''necesita el acceso a las variables runtime de UEFI''' que son '''accesibles solo si se arranca en modo UEFI''' (sin usar el parámetro del kernel «noefi»). De lo contrario, se mostrará el mensaje de error {{ic | Fatal: Couldn't open either sysfs or procfs directories for accessing EFI variables}}.}}
+
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 no es posible usar {{ic|efibootmgr}}, algunas BIOS UEFI permiten a los usuarios gestionar directamente las opciones de UEFI Boot Manager desde el BIOS. Por ejemplo, algunas BIOS de ASUS tiene 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')}}
+
=== Lanzar el intérprete de órdenes UEFI ===
  
Inicialmente, el usuario deberá iniciar manualmente el cargador de arranque desde el propio firmware (tal vez usando la shell de UEFI) si el cargador de arranque de UEFI ha sido instalado cuando se inició el sistema en modo BIOS. Entonces {{ic|efibootmgr}} se deberá ejecutar para que la entrada del cargador de arranque UEFI se configure como la entrada predeterminada en el gestor de arranque 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}}).
  
Para utilizar efibootmgr, primero cargue el módulo del kernel «efivars»:
+
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}}.
  
# modprobe efivars
+
{{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.}}
  
Si, al ejecutar esta orden, recibe el error '''no such device found''' (''«no se ha encontrado el dispositivo»''), ello significa que no ha arrancado en modo UEFI o que, por alguna razón, el kernel no puede acceder a las variables runtime de UEFI (¿por la existencia de «noefi», quizás?).
+
=== Órdenes importantes del intérprete UEFI ===
  
Compruebe si hay archivos en la carpeta ''/sys/firmware/efi/vars/''. Este directorio y sus contenidos son creados por el módulo del kernel «efivars» y solo existirá si se ha arrancado en modo UEFI, sin la presencia del parámetro del kernel «noefi» .
+
Las órdenes del intérprete 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.
  
Si la carpeta ''/sys/firmware/efi/vars/'' está vacía o no existe, entonces la orden {{ic|efibootmgr}} no funcionará. Si no puede hacer el arranque de la ISO/CD/DVD/USB en la modalidad UEFI consulte [[#Crear un USB booteable de UEFI desde la ISO ]].
+
Puede obtener más información en http://software.intel.com/en-us/articles/efi-shells-and-scripting/
  
{{Nota|Las siguientes órdenes utilizan el cargador de arranque {{pkg |gummiboot}} como ejemplo.}}
+
==== bcfg ====
  
{{out of date|[[Gummiboot]] tiene su propio instalador ahora, por lo que las instrucciones siguientes no se debe utilizar para instalar [[gummiboot]]. Este ejemplo debería ser cambiado para usar otro supuesto.}}
+
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]
  
Suponga que el archivo boot-loader para ser lanzado es {{ic|boot/efi/EFI/gummiboot/gummibootx64.efi}}. El mismo {{Ic|/boot/efi/EFI/gummiboot/gummibootx64.efi}} puede ser dividido en {{ic|/boot/efi}} y {{ic|/EFI/gummiboot/gummibootx64.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 X e Y son marcadores de posición para los valores reales - por ejemplo: - en {{ic|/dev/sda1}}, X=a; Y=1).
+
{{Nota|
 +
*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 del intérprete de órdenes UEFI no proporciona soporte para la orden {{ic|bcfg}}. Consulte [[#Obtener el intérprete de órdenes UEFI]] para un binario UEFI shell v2 modificado que puede funcionar en UEFI con firmwares anteriores a 2.3.
 +
}}
  
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:
+
Para conocer una lista de entradas de arranque actuales:
  
  # findmnt /boot/efi
+
  Shell> bcfg boot dump -v
TARGET SOURCE  FSTYPE OPTIONS
 
/boot/efi  /dev/sdXY  vfat        rw,flush,tz=UTC
 
  
A continuación, cree la entrada de arranque usando efibootmgr de la siguiente manera:
+
Para añadir una entrada para rEFInd (por ejemplo) como cuarta (la numeración empieza desde cero) en el menú de arranque:
  
  # efibootmgr -c -g -d /dev/sdX -p Y -w -L "Gummiboot" -l '\EFI\gummiboot\gummibootx64.efi'
+
  Shell> bcfg boot add 3 FS0:\EFI\refind\refind_x64.efi "rEFInd"
  
En la orden anterior {{ic|/boot/efi/EFI/gummiboot/gummibootx64.efi}} interpreta {{ic|/boot/efi}} y {{ic|/EFI/gummiboot/gummibootx64.efi}}, que, a su vez, lo interpretan como: disco -> {{ic|/dev/sdX}} -> partición -> {{ic|Y}} -> archivo {{ic|/EFI/gummiboot/gummibootx64.efi}}.
+
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.
  
UEFI utiliza barra diagonal invertida (\) como separador de ruta (similar a las rutas de Windows).
+
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]]:
  
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 el arranque del sistema. Se puede obtener más información a partir de [http://linux.dell.com/cgi-bin/gitweb/gitweb.cgi?p=efibootmgr.git;a=blob_plain;f=README;hb=HEAD efibootmgr GIT README] .
+
Shell> bcfg boot add '''N''' fs'''V''':\vmlinuz-linux "Arch Linux"
 +
Shell> bcfg boot -opt '''N''' "root='''/dev/sdX#''' initrd=\initramfs-linux.img"
  
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\gummiboot\gummibootx64.efi}} o {{ic|\efi\gummiboot\gummibootx64.efi}} no hay diferencia (esto cambia si la codificación del sistema de archivos es UTF-8).
+
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.
  
== Gestores de arranque de Linux para UEFI ==
+
Para quitar la opción de arranque cuarta:
  
Véase [[UEFI Bootloaders]].
+
Shell> bcfg boot rm 3
  
== Crear una ''«UEFI System Partition»'' en Linux ==
+
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):
  
{{Nota|UEFI System Partition y EFI System Partition (ESP) es lo mismo, esta terminología se utiliza indistintamente en algunos lugares.}}
+
Shell> bcfg boot mv 3 0
{{Nota|La partición UEFISYS puede ser de cualquier tamaño con el apoyo del sistema de archivos FAT32. Según la documentación de Microsoft, el tamaño mínimo de la partición/volumen para el sistema de archivos FAT32 es de 512 MiB. Por ello es recomendable que la partición UEFISYS sea, al menos, de 512 MiB. Tamaños mayores quizás sean más aconsejables, sobre todo si se utilizan varios gestores de arranque UEFI, o arranques de múltiples sistemas operativos a través de UEFI, a fin de que haya suficiente espacio en la partición para guardar todos los archivos relacionados. Si está utilizando el arranque EFISTUB en Linux, entonces necesita asegurarse que hay suficiente espacio disponible para mantener el Kernel y los archivos initramfs en la partición UEFISYS.}}
 
{{Nota|El ESP debe estar fuera de LVM o cualquier otro RAID software o sistemas RAID. ESP debe ser accesible por el firmware UEFI, el cual no puede leer LVM y sistemas similares.}}
 
  
{{Nota|Si utilizamos el arranque EFISTUB de Linux, entonces necesitaremos asegurarnos de que hay suficiente espacio disponible para mantener el Kernel y los archivos initramfs en la partición UEFISYS.}}
+
Para mostrar el texto de ayuda de bcfg:
  
=== Discos particionados para GPT ===
+
Shell> help bcfg -v -b
Dos opciones:
 
* Usar GNU Parted/GParted: Cree una partición FAT32. Ajuste la partición con el flag «boot» para marcarla como activa.
 
* Usar GPT fdisk (conocido también como gdisk): Cree una partición con gdisk con el código tipo «EF00». Después formatee la partición como FAT32 usando {{ic | mkfs.vfat -F32 /dev/<PARTICIÓN>}}
 
  
{{Nota|Ajustar el flag «boot» en una partición con sistema MBR marcará dicha partición como «activa», mientras que el mismo flag «boot» en una partición con sistema GPT marcará la partición como «partición del sistema UEFI» (''"UEFI System Partition"'').}}
+
o
  
{{Advertencia|No utilice las utilidades de linux fdisk, cfdisk o sfdisk para cambiar el código de los tipos de particiones en un disco con sistema GPT. Del mismo modo no utilice gptfdisk, gdisk, cgdisk o sgdisk en un disco MBR, ya que lo convierte automáticamente a GPT (la operación se producirá sin pérdida de datos, pero el sistema no podrá arrancar).}}
+
Shell> bcfg -? -v -b
  
=== Discos particionados para MBR ===
+
==== map ====
Dos opciones:
 
* Usar GNU Parted/GParted: Cree una partición FAT32. Cambie el código del tipo de la partición a 0xEF utilizando fdisk, cfdisk o sfdisk.
 
* Usar GPT fdisk Cree una partición con código 0xEF y formatéela como FAT32 usando {{ic|mkfs.vfat -F32 /dev/<PARTICIÓN>}}
 
  
{{Nota| Se recomienda usar siempre el sistema GPT para el arranque de UEFI, ya que algunos firwares UEFI no permiten el arranque desde sistemas MBR.}}
+
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}}).
  
== Shell de UEFI ==
+
Antes de ejecutar órdenes relacionadas con el sistema de archivos, como {{ic|cd}} o {{ic|ls}}, debe cambiar el intérprete de órdenes al sistema de archivos correspondiente, escribiendo su nombre:
  
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.
+
Shell> FS0:
 +
FS0:\> cd EFI/
  
=== Enlaces de descarga de la shell de UEFI ===  
+
==== edit ====
  
Puede descargar una Shell de UEFI con licencia BSD de Tianocore de Intel desde el proyecto Sourceforge.net UDK/EDK2.
+
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]].
  
* [https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2/ShellBinPkg/UefiShell/X64/Shell.efi x86_64 UEFI Shell 2.0 (Beta)]
+
Para editar, por ejemplo, {{ic|refind.conf}} de rEFInd en la partición del sistema UEFI (FS0: en el firmware):
* [https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2/EdkShellBinPkg/FullShell/X64/Shell_Full.efi x86_64 UEFI Shell 1.0 (Old)]
 
* [https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2/ShellBinPkg/UefiShell/Ia32/Shell.efi i386 UEFI Shell 2.0 (Beta)]
 
* [https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2/EdkShellBinPkg/FullShell/Ia32/Shell_Full.efi i386 UEFI Shell 1.0 (Old)]
 
  
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].
+
Shell> edit FS0:\EFI\refind\refind.conf
  
=== Lanzar la shell de UEFI ===
+
Escriba {{ic|Ctrl-E}} para obtener ayuda.
  
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}}).
+
== Soporte para arrancar UEFI ==
  
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.
+
=== Crear un USB arrancable con UEFI desde la ISO ===
  
{{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.}}
+
Siga las instrucciones del siguiente artículo [[USB Installation Media (Español)#Crear USB para arrancar desde sistemas BIOS y UEFI]]
  
=== Órdenes importantes de la shell de UEFI ===  
+
=== Eliminar el apoyo de arranque de UEFI de una unidad óptica ===
  
Puede obtener más información en http://software.intel.com/en-us/articles/efi-shells-and-scripting/
+
{{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.}}
  
==== bcfg ====
+
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.
  
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».
+
* Monte el soporte de instalación oficial y obtenga el {{ic|archisolabel}} como se muestra en la sección anterior.
  
{{Nota|Se recomienda probar {{ic|bcfg}} únicamente si {{ic|efibootmgr}} no puede crear entradas de inicio que funcionen en el propio sistema.}}
+
# mount -o loop ''input.iso'' /mnt/iso
  
{{Nota| La Shell 1.0 de UEFI no es compatible con la orden {{ic|bcfg}}.}}
+
* 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:
  
Para conocer una lista de entradas de arranque actuales:
+
{{bc|1=
 +
$ 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 {{ic|''output.iso''}} en el disco óptico y continúe con la instalación de forma normal.
  
Shell> bcfg boot dump -v
+
=== Arrancar el kernel de 64-bit en UEFI de 32-bit ===
  
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:
+
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.
  
Shell> bcfg boot add 3 fs0:\EFI\arch\refind\refindx64.efi "Arch Linux (rEFInd)"
+
{{Sugerencia|la imagen iso de [[Archboot]] admite el arranque en sistemas UEFI de 32 bits.}}
  
donde fs0: es la asignación correspondiente a la partición del sistema UEFI y \EFI\arch\refind\refindx64.efi es el archivo que se pondrá en marcha.
+
==== Utilizar GRUB ====
  
Para quitar la opción de arranque cuarta:
+
Esta sección describe cómo configurar [[GRUB]] como el cargador de arranque UEFI del USB.
  
Shell> bcfg boot rm 3
+
* [[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}}.
  
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):
+
* [[GRUB/Tips and tricks#GRUB standalone|Crear una imagen independiente de GRUB]] para sistemas UEFI de 32 bits:
  
  Shell> bcfg boot mv 3 0
+
  # 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
  
Para mostrar el texto de ayuda bcfg:
+
* 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}}):
  
Shell> help bcfg -v -b
+
{{Sugerencia|
 +
* 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}}.
 +
* Las entradas de configuración dadas también pueden ingresarse dentro de una [[GRUB#Using_the_command_shell|shell de GRUB]].
 +
}}
  
o
+
Para el ISO oficial:
  
Shell> bcfg -? -v -b
+
{{hc|''/mnt/usb''/EFI/boot/grub.cfg|2=
 +
insmod part_gpt
 +
insmod part_msdos
 +
insmod fat
  
==== edit ====
+
insmod efi_gop
 +
insmod efi_uga
 +
insmod video_bochs
 +
insmod video_cirrus
  
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]].
+
insmod font
  
Para editar, por ejemplo refind.conf de rEFInd en la partición del sistema UEFI (fs0: en el firmware)
+
if loadfont "${prefix}/fonts/unicode.pf2" ; then
 +
    insmod gfxterm
 +
    set gfxmode="1024x768x32;auto"
 +
    terminal_input console
 +
    terminal_output gfxterm
 +
fi
  
Shell> fs0:
+
menuentry "Arch Linux archiso x86_64 UEFI USB" {
FS0:\> cd \EFI\arch\refind
+
    set gfxpayload=keep
FS0:\EFI\arch\refind\> edit refind.conf
+
    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
 +
}
 +
}}
  
== Compatibilidad de Hardware ==
+
== Probar UEFI en sistemas sin soporte nativo ==
  
Página principal [[HCL/Firmwares/UEFI]]
+
=== OVMF para máquinas virtuales  ===
  
== Crear un USB booteable de UEFI desde la ISO ==
+
[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.
  
{{Nota|1=Las siguientes instrucciones son específicas para el soporte oficial [[Archiso]]; la preparación de [[Archboot]] es idéntica, con [https://bbs.archlinux.org/viewtopic.php?pid=1190788#p1190788 refind.conf] en lugar de la que se menciona a continuación (que es para Archiso) y sin el requisito de la etiqueta del sistema de archivos.}}
+
Se puede instalar {{pkg|ovmf}} desde el repositorio extra.
  
{{Nota| El USB puede utilizar tanto una tabla de particiones MBR como GPT (por lo que podría muy bien utilizar un USB ya particionado). El sistema de archivos puede ser FAT32 (recomendado) o FAT16. FAT12 está diseñado para discos flexibles y, por lo tanto, no se recomienda para las unidades USB.}}
+
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:
  
En primer lugar, crearemos una tabla de particiones y una partición, como máximo, en el USB. Monte la imagen ISO desde la [https://www.archlinux.org/download/ página de descarga de Arch Linux].
+
$ cp /usr/share/ovmf/x64/OVMF_VARS.fd my_uefi_vars.bin
  
{{bc|1=<nowiki>
+
Para usar el firmware OVMF y el conjunto de variables, añada la siguiente orden a su QEMU:
# mkdir -p /mnt/{usb,iso}
 
# mount -o loop archlinux-2012.12.01-dual.iso /mnt/iso
 
</nowiki>}}
 
  
A continuación, cree un sistema de archivos FAT32 en la partición del USB (desmontar antes si es necesario) con el LABEL tal como se utiliza en la configuración Archiso. Obtener la etiqueta de {{ic|/mnt/iso/loader/entries/archiso-x86_64.conf}}; esto es utilizado por el hook {{ic|archiso}} en initramfs para identificar la ruta udev para el soporte de instalación. {{ic|mkfs.vfat}} forma parte del paquete {{Pkg|dosfstools}}.
+
-drive if=pflash,format=raw,readonly,file=/usr/share/ovmf/x64/OVMF_CODE.fd \
 +
-drive if=pflash,format=raw,file=my_uefi_vars.bin
  
{{bc|1=<nowiki>
+
Por ejemplo:
# awk 'BEGIN {FS="="} /archisolabel/ {print $3}' /mnt/iso/loader/entries/archiso-x86_64.conf | xargs mkfs.vfat -F32 /dev/sdXY -n
 
</nowiki>}}
 
  
Monte la partición FAT32 del USB recién creada y copie el contenido de los medios de instalación al dispositivo USB.
+
$ 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 …
  
{{bc|1=<nowiki>
+
=== DUET para sistemas BIOS únicamente ===
# mount /dev/sdXY /mnt/usb
 
# cp -a /mnt/iso/* /mnt/usb
 
# sync
 
# umount /mnt/{usb,iso}</nowiki>}}
 
  
=== Reparar errores ===
+
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 .
  
Podemos encontrarnos el error: ''"No loader found. Configuration files in /loader/entries/*.conf are needed."'' Una posible solución es usar un gestor de arranque UEFI diferente al incluido, gummiboot.
+
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.
  
Descargaremos [https://www.archlinux.org/packages/extra/any/refind-efi/download/ refind-efi pkg] y extraeremos el archivo {{ic|/usr/lib/refind/refind_x64.efi}} de dicho paquete para {{ic|(USB)/EFI/boot/bootx64.efi}} (sobrescribir o cambiar el nombre de cualquier archivo {{ic|(USB)/EFI/boot/bootx64.efi}} existente).
+
==Solución de problemas==
  
A continuación, copiaremos este texto a {{ic|EFI/boot/refind.conf}}. Nos aseguraremos de que la etiqueta (''label'') en la sección del menú de Arch ({{ic|ARCH_201302}} en este caso) coincide con el de su usb.
+
=== Windows 7 no se inicia en la modalidad UEFI  ===
  
{{hc|refind.conf|<nowiki>
+
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.
timeout 5
 
textonly
 
  
showtools about,reboot,shutdown,exit
+
Placas base con este tipo de problema:
# scan_driver_dirs EFI/tools/drivers_x64
 
scanfor manual,internal,external,optical
 
  
scan_delay 1
+
*Gigabyte Z77X-UD3H rev. 1.1 (BIOS UEFI versión F19e)
dont_scan_dirs EFI/boot
 
  
max_tags 0
+
**La opción ''«UEFI Only»'' de la BIOS UEFI no pretende hacer que la BIOS UEFI arranque desde CSM.
default_selection "Arch Linux Archiso x86_64 UEFI USB"
 
  
menuentry "Arch Linux Archiso x86_64 UEFI USB" {
+
=== Windows cambia el orden de arranque ===
  loader /arch/boot/x86_64/vmlinuz
 
  initrd /arch/boot/x86_64/archiso.img
 
  ostype Linux
 
  graphics off
 
  options "archisobasedir=arch archisolabel=ARCH_201302 add_efi_memmap"
 
}
 
  
menuentry "UEFI x86_64 Shell 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.
  loader /EFI/shellx64_v2.efi
 
  graphics off
 
}
 
  
menuentry "UEFI x86_64 Shell v1" {
+
* 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
  loader /EFI/shellx64_v1.efi
+
* Asegúrese de que [[Secure Boot]] esté desactivado en su BIOS (si no está utilizando un gestor de arranque firmado)
  graphics off
+
* 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 ({{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]].
</nowiki>}}
+
* 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''"}}
 +
* 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.
 +
*# 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.
  
Ahora debería ser capaz de arrancar con éxito, y poder elegir qué EFI desea cargar.
+
=== El soporte USB se topa con una pantalla negra ===
  
== Eliminar el apoyo de arranque de UEFI desde la ISO ==
+
Este problema puede ocurrir debido a un problema con [[KMS]]. Pruebe [[Kernel mode setting#Disabling_modesetting|desactivar KMS]] mientras arranca el USB.
  
{{Advertencia | En el caso de la combinación UEFI+isohybrid-MBR realmente causa problemas, por lo que sería mejor simplemente arrancar UEFI siguiendo las instrucciones de la sección anterior para el lápiz USB.}}
+
=== El cargador de arranque UEFI no aparece en el menú del firmware ===
  
La mayoría de los Mac EFI de 32-bit y algunos Mac EFI de 64 bits  se niegan a arrancar desde 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 eliminar el apoyo a UEFI primero.
+
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.
  
Monte el soporte de instalación oficial y obtenga la {{ic|archisolabel}} como se muestra en la sección anterior.
+
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.
  
Reconstruya la ISO usando {{ic|xorriso}} desde {{pkg|libisoburn}}:
+
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:
  
{{bc|1=<nowiki>
+
Shell> mkdir FS1:\EFI\Microsoft
$ xorriso -as mkisofs -iso-level 3 \
+
Shell> mkdir FS1:\EFI\Microsoft\Boot
    -full-iso9660-filenames\
+
Shell> cp FS0:\EFI\BOOT\bootx64.efi FS1:\EFI\Microsoft\Boot\bootmgfw.efi
    -volid "ARCH_201212" \
 
    -appid "Arch Linux CD" \
 
    -publisher "Arch Linux <https://www.archlinux.org>" \
 
    -preparer "prepared like a BAWSE" \
 
    -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 "~/archiso.iso" "/mnt/iso/"</nowiki>}}
 
  
Grabe {{ic|~/archiso.iso}} en el disco óptico y continúe con la instalación normalmente.
+
Después del reinicio, las entradas agregadas a la NVRAM deben aparecer en el menú de inicio.
  
 
== Véase también ==
 
== Véase también ==
  
* Página de Wikipedia en [http://en.wikipedia.org/wiki/UEFI UEFI]
+
* [[Wikipedia:UEFI]]
* Página de Wikipedia en [http://en.wikipedia.org/wiki/EFI_System_partition UEFI SYSTEM Partition]
+
* [http://www.uefi.org/home/ UEFI Forum] - contains the official [http://uefi.org/specifications UEFI Specifications] - GUID Partition Table is part of UEFI Specification
* [http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=blob_plain;f=Documentation/x86/x86_64/uefi.txt;hb=HEAD Linux Kernel UEFI Documentation]
+
* [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]
* [http://www.uefi.org/home/ UEFI Forum] - contiene las [http://www.uefi.org/specs/ Especificaciones UEFI] oficiales - GUID Partition Table es una parte de la Especificación UEFI
+
* [https://www.kernel.org/doc/Documentation/x86/x86_64/uefi.txt Linux Kernel x86_64 UEFI Documentation]
* [http://sourceforge.net/apps/mediawiki/tianocore/index.php?title=Welcome_to_TianoCore Intel's Tianocore Project] para el firmware UEFI Open-Source que incluye DuetPkg para inicios basados en BIOS y OvmfPkg usado en QEMU y VirtualBox Oracle
+
* [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]
* [http://www.intel.com/technology/efi/ Intel's page on EFI]
+
* [https://firmware.intel.com/ Intel Architecture Firmware Resource Center]
* [http://homepage.ntlworld.com/jonathan.deboynepollard/FGA/efi-boot-process.html FGA: The EFI boot process]
+
* [https://firmware.intel.com/blog/linux-efi-boot-stub Matt Fleming - The Linux EFI Boot Stub]
* [http://www.microsoft.com/whdc/device/storage/GPT_FAQ.mspx Microsoft's Windows and GPT FAQ] - Contiene amplia información sobre el inicio de Windows en modalidad UEFI
+
* [https://firmware.intel.com/blog/accessing-uefi-variables-linux Matt Fleming - Accessing UEFI Variables from Linux]
* [https://gitorious.org/tianocore_uefi_duet_builds/pages/Windows_x64_BIOS_to_UEFI Convert Windows Vista SP1+ or 7 x86_64 boot from BIOS-MBR mode to UEFI-GPT mode without Reinstall]
+
* [http://www.rodsbooks.com/linux-uefi/ Rod Smith - Linux on UEFI: A Quick Installation Guide]
* [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://lkml.org/lkml/2011/6/8/322 UEFI Boot problems on some newer machines (LKML)]
 +
* [https://linuxplumbers.ubicast.tv/videos/plumbing-uefi-into-linux/ LPC 2012 Plumbing UEFI into Linux]
 +
* [https://linuxplumbers.ubicast.tv/videos/uefi-tutorial-part-1/ LPC 2012 UEFI Tutorial : part 1]
 +
* [https://linuxplumbers.ubicast.tv/videos/uefi-tutorial-part-2/ LPC 2012 UEFI Tutorial : part 2]
 +
* [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
 +
* [https://jdebp.eu/FGA/efi-boot-process.html FGA: The EFI boot process]
 +
* [https://docs.microsoft.com/en-us/windows-hardware/manufacture/desktop/windows-and-gpt-faq Microsoft's Windows and GPT FAQ]
 +
* [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://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]
* [https://lkml.org/lkml/2011/6/8/322 UEFI Boot problems on some newer machines (LKML)]
+
* [https://software.intel.com/en-us/articles/efi-shells-and-scripting/ EFI Shells and Scripting - Intel Documentation]
* [http://software.intel.com/en-us/articles/efi-shells-and-scripting/ EFI Shells and Scripting - Intel Documentation]
+
* [https://software.intel.com/en-us/articles/uefi-shell/ UEFI Shell  - Intel Documentation]
* [http://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://hackthejoggler.freeforums.org/download/file.php?id=28 Some useful 32-bit UEFI Shell utilities]
 
* [http://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]
 
* [http://linuxplumbers.ubicast.tv/videos/uefi-tutorial-part-2/ LPC 2012 UEFI Tutorial : part 2]
 

Latest revision as of 20:17, 28 October 2018

Estado de la traducción
Este artículo es una traducción de Unified Extensible Firmware Interface, revisada por última vez el 2018-08-31. Si advierte que la versión inglesa ha cambiado puede ayudar a actualizar la traducción, bien por usted mismo o bien avisando al equipo de traducción.
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 el intérprete de órdenes 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.

Intérprete de órdenes UEFI

El intérprete de órdenes de UEFI es una intérprete/terminal para el firmware, que permite ejecutar aplicaciones UEFI que incluyen los cargadores de arranque UEFI. Aparte de esto, el intérprete 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 el intérprete de órdenes UEFI

Puede descargar un intérprete de órdenes 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 el intérprete de órdenes 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 del intérprete UEFI

Las órdenes del intérprete 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 del intérprete de órdenes UEFI no proporciona soporte para la orden bcfg. Consulte #Obtener el intérprete de órdenes 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 el intérprete de órdenes 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