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

From ArchWiki
Jump to: navigation, search
(Mac de Apple)
(26 intermediate revisions by 2 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-CN:Unified Extensible Firmware Interface]]
Line 14: Line 15:
 
{{Article summary end}}
 
{{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.
+
'''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 UEFI Forum, se hizo cargo de su desarrollo, a partir del cual se llamó  EFI Unificado desde de la versión 2.0. Hasta el 24 de julio de 2012, la Especificación 2.4 de UEFI (liberada el 11 de julio de 2013) es la versión más reciente.
  
 
{{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.}}
 
{{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.}}
  
== Iniciar un sistema operativo usando la BIOS ==
+
Antes de entender UEFI, es importante entender cómo arrancan los sistemas pre-UEFI (BIOS). Esto se explica en las secciones siguientes.
  
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.
+
== BIOS ==
  
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.
+
Una BIOS o ''«Basic Input-Output System»'' es el primer programa (firmware) que se ejecuta cuando el sistema está encendido. En la mayoría de los casos, este se almacena en una memoria flash en la propia placa base e independiente del almacenamiento del sistema.
  
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.
+
=== Proceso de arranque bajo BIOS===
 +
 
 +
# Encendido del sistema —Power On Self Test—, o proceso [[wikipedia:es:POST|POST]].
 +
# Después del POST la BIOS inicializa el hardware necesario para el arranque del sistema (disco, controladores del teclado, etc.).
 +
# La BIOS ejecuta el código de los primeros 440 bytes (la región del código de arranque del MBR) del primer disco de los que aparecen ordenados en la BIOS.
 +
# El código de arranque del MBR entonces toma el control desde la BIOS y ejecuta el código de la siguiente etapa (en su caso) (normalmente, el código del gestor de arranque).
 +
# El código lanzado (segunda etapa) (el gestor de arranque presente) entonces lee los archivos de configuración y apoyo.
 +
# En base a los datos de los archivos de configuración, el gestor de arranque carga el kernel e initramfs en la memoria del sistema (RAM), e inicia el kernel.
  
 
=== Multiarranque en BIOS ===
 
=== Multiarranque en BIOS ===
Line 30: Line 38:
 
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.
 
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.
  
== Arrancar un sistema operativo usando UEFI ==
+
== UEFI ==
  
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.
+
UEFI tiene la capacidad de leer tanto la tabla de particiones, como de reconocer los sistemas de archivos. Por lo tanto, no está limitado por la limitación de código de 440 bytes (código de arranque MBR) como en los sistemas BIOS. No utiliza el código de arranque MBR en absoluto.
  
 
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.
 
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.
  
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.
+
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 {{ic|<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 (principalmente) o FAT16.
  
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.
+
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 antiguos (anteriores a 2008) que funcionan utilizando EFI IA32 (32-bit), algunos ultrabooks recientes de Intel Cloverfield y algunas placas bases de Intel Servers, son conocidos por operar con un firmware EFI 1.10 de Intel.
  
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.
+
Un firmware EFI x86_64 no incluye el soporte para lanzar aplicaciones de 32-bit (a diferencia del EFI de Linux y de Windows x86_64 que incluyen dicho apoyo). En definitiva, la aplicación UEFI (esto es, el gestor de arranque) debe ser compilada para la arquitectura correcta.
  
=== Multiarranque en UEFI ===
+
=== Proceso de arranque bajo UEFI ===
  
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.
+
# Encendido del sistema &mdash;se inicia Power On Self Test&mdash; o el proceso POST.
 +
# Se carga el firmware UEFI. El firmware inicializa el hardware necesario para el arranque.
 +
# El firmware lee el gestor de arranque para determinar qué aplicación UEFI iniciar, y desde dónde (es decir, desde qué disco y partición).
 +
# El firmware UEFI inicia la aplicación desde la partición UEFI definida en la entrada de arranque del gestor de arranque del firmware.
 +
# La aplicación UEFI puede iniciar otra aplicación (como la shell de UEFI o un gestor de arranque como rEFInd), o el kernel y el initramfs (en el caso de un gestor de arranque como GRUB) en función de cómo se ha configurado la aplicación UEFI.
  
==== Multiarranque de Linux/Windows x86_64 en UEFI con GPT ====
+
{{Nota|En algunos sistemas UEFI el único camino posible para iniciar la aplicación UEFI en el arranque (si no tiene una entrada personalizada en el menú de inicio de UEFI) es ponerlo en este lugar fijo: {{ic|<EFI SYSTEM PARTITION>/EFI/boot/bootx64.efi}} (para sistemas x86 de 64-bit)}}
  
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.
+
=== Multiarranque en UEFI ===
  
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.
+
Debido a que cada sistema operativo o fabricante puede mantener sus propios archivos en la partición del sistema EFI (''«EFI System Partition»'') sin afectar a otros sistemas operativos, el multiarranque con UEFI consiste únicamente en lanzar una aplicación UEFI diferente, correspondiente al gestor de arrranque de un particular sistema operativo. Esto elimina la necesidad de recurrir a mecanismos de cargar los sistemas operativos en cadena con un gestor de arranque para iniciar uno u otro.
  
== Proceso de arranque bajo UEFI ==
+
==== Arranque de Microsoft Windows ====
  
# Encendido del sistema -se inicia Power On Self Test, o el proceso POST-.
+
Las versiones de 64-bit de Windows Vista (SP1+), 7 y 8, permiten arrancar de forma nativa utilizando el firmware UEFI x86_64. Windows fuerza el tipo de partición en función del firmware utilizado, es decir, si Windows se inicia en el modo UEFI, es que viene instalado en un disco GPT. Si Windows se inicia en modo BIOS legacy, significa que solo se puede instalar en un disco MBR. Esta es una limitación impuesta por el instalador de Windows. Así Windows soporta bien el arranque UEFI-GPT o solo arranque BIOS-MBR, pero no el arranque UEFI-BIOS o MBR-GPT.
# 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 ==
+
Estas limitaciones no existen en el kernel de Linux, sino que depende del gestor de arranque utilizado. Sin embargo, esta limitación de Windows se debe tener en cuenta si el usuario quiere arrancar Windows y Linux en el mismo disco, ya que la configuración del gestor de arranque en sí depende del tipo de firmware y de la partición del disco utilizada. En el caso de arranque dual de Windows y Linux en el mismo disco, es recomendable seguir el método utilizado por Windows, ya sea el arranque UEFI-GPT o solo arranque BIOS-MBR, no los otros dos casos.
  
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).
+
Las versiones de Windows de 32-bit únicamente soportan el arranque en sistemas BIOS-MBR. Siga las instrucciones proporcionadas en el enlace del foro en las secciones apropiadas respecto a cómo hacer esto. Véase http://support.microsoft.com/default.aspx?scid=kb;EN-US;2581408 para más información.
  
Algunos de los conocidos firmwares UEFI 2.x para la arquitectura x86_64 son Phoenix SecureCore Tiano, Aptio AMI, Insyde H2O.
+
=== Detectar la arquitectura del firmware UEFI ===
  
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.
+
==== Sistemas UEFI que no son Mac ====
  
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.
+
Compruebe si el directorio {{ic|/sys/firmware/efi}} existe; si existe, significa que el kernel ha arrancado en modalidad EFI. En ese caso, significa que la arquitectura de UEFI coincide con la del kernel (es decir, i686 o x86_64)
  
Para saber la arquitectura del firmware EFI en un Mac, debe arrancar Mac OS X y escribir la siguiente orden:
+
==== Mac de Apple ====
 +
 
 +
Los Mac anteriores a 2008 tienen, en su mayoría, un firware i386-efi, mientras que los Mac >=2008 tienen, en su mayoría, x86_64-efi. Todos los Mac capaces de ejecutar el kernel de Mac OS X Snow Leopard 64-bit tienen un firmware EFI 1.x para x86_64.
 +
 
 +
Para saber la arquitectura del firmware EFI en un Mac, debe arrancar Mac OS X y escribir en un terminal la siguiente orden:
  
 
<pre>
 
<pre>
Line 76: Line 88:
 
</pre>
 
</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 la orden devuelve EFI32 entonces es un firmware EFI 1.x para i386. Si devuelve EFI64, entonces es un firmware EFI 1.x para x86_64. Mac no tiene un firmware 2.x UEFI, porque la implementación del firmware EFI de Apple no es totalmente compatible con la especificación UEFI 2.x.
 +
 
 +
=== 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.
 +
 
 +
====Listado de muestra de las variables de UEFI====
 +
 
 +
Muestra de salida en un Lenovo Thinkpad E430 3254-DAQ (características: UEFI 2.3.1-x86_64, firmware x86_64, compatible con Secure Boot):
 +
 +
{{hc|UEFI Variables List|<nowiki>
 +
$ efivar -l
 +
0b7646a4-6b44-4332-8588-c8998117f2ef-BmEssentialVariableNames
 +
0ec1a7f5-4904-40a0-8eab-4bcc4666da45-PbaStatusVar
 +
1054354b-b543-4dfe-558b-a7ad6351c9d8-DptfProtocolSetupVar
 +
1827cfc7-4e61-4273-b796-d35f4b0c88fc-LenovoHiddenSetting
 +
1bad711c-d451-4241-b1f3-8537812e0c70-MeBiosExtensionSetup
 +
2a4dc6b7-41f5-45dd-b46f-2dd334c1cf65-LBC
 +
2a4dc6b7-41f5-45dd-b46f-2dd334c1cf65-LBL
 +
2a4dc6b7-41f5-45dd-b46f-2dd334c1cf65-LBOL
 +
2a4dc6b7-41f5-45dd-b46f-2dd334c1cf65-LBOP0000
 +
2a4dc6b7-41f5-45dd-b46f-2dd334c1cf65-LBOP0001
 +
2a4dc6b7-41f5-45dd-b46f-2dd334c1cf65-LBOP0002
 +
2a4dc6b7-41f5-45dd-b46f-2dd334c1cf65-LBOP0003
 +
2a4dc6b7-41f5-45dd-b46f-2dd334c1cf65-LBOP0004
 +
2a4dc6b7-41f5-45dd-b46f-2dd334c1cf65-LBOP0005
 +
2a4dc6b7-41f5-45dd-b46f-2dd334c1cf65-LBOP0006
 +
2a4dc6b7-41f5-45dd-b46f-2dd334c1cf65-LBOP0007
 +
2a4dc6b7-41f5-45dd-b46f-2dd334c1cf65-LBOP0008
 +
2a4dc6b7-41f5-45dd-b46f-2dd334c1cf65-LBOP0009
 +
2a4dc6b7-41f5-45dd-b46f-2dd334c1cf65-LBOP000A
 +
2a4dc6b7-41f5-45dd-b46f-2dd334c1cf65-LBOP000B
 +
2a4dc6b7-41f5-45dd-b46f-2dd334c1cf65-LBOP000C
 +
2a4dc6b7-41f5-45dd-b46f-2dd334c1cf65-LBOP000D
 +
2a4dc6b7-41f5-45dd-b46f-2dd334c1cf65-LBOP000E
 +
2a4dc6b7-41f5-45dd-b46f-2dd334c1cf65-LBOP000F
 +
2a4dc6b7-41f5-45dd-b46f-2dd334c1cf65-LBOP0010
 +
2a4dc6b7-41f5-45dd-b46f-2dd334c1cf65-LBOP0011
 +
2a4dc6b7-41f5-45dd-b46f-2dd334c1cf65-LBOP0012
 +
2a4dc6b7-41f5-45dd-b46f-2dd334c1cf65-LBOP0013
 +
2a4dc6b7-41f5-45dd-b46f-2dd334c1cf65-LBOP0014
 +
2a4dc6b7-41f5-45dd-b46f-2dd334c1cf65-LBOP0015
 +
2a4dc6b7-41f5-45dd-b46f-2dd334c1cf65-LBOP0016
 +
2a4dc6b7-41f5-45dd-b46f-2dd334c1cf65-LBOP0017
 +
2a4dc6b7-41f5-45dd-b46f-2dd334c1cf65-LBOP0018
 +
2a4dc6b7-41f5-45dd-b46f-2dd334c1cf65-LenovoConfig
 +
2a4dc6b7-41f5-45dd-b46f-2dd334c1cf65-LenovoSystemConfig
 +
2a4dc6b7-41f5-45dd-b46f-2dd334c1cf65-LKOP0000
 +
2a4dc6b7-41f5-45dd-b46f-2dd334c1cf65-LKOP0001
 +
2a4dc6b7-41f5-45dd-b46f-2dd334c1cf65-LKOP0002
 +
2a4dc6b7-41f5-45dd-b46f-2dd334c1cf65-LKOP0003
 +
2a4dc6b7-41f5-45dd-b46f-2dd334c1cf65-LKOP0004
 +
2a4dc6b7-41f5-45dd-b46f-2dd334c1cf65-LKOP0005
 +
2a4dc6b7-41f5-45dd-b46f-2dd334c1cf65-LKOP0006
 +
2a4dc6b7-41f5-45dd-b46f-2dd334c1cf65-LWO
 +
34f73d4d-963e-4c65-b3b3-515e720175d6-SaProtocolSetupVar
 +
3e72b3ad-2b91-424a-ad73-c3270e91ed88-PwdStatusVar
 +
4650c401-93f1-4aeb-b87d-c8204c047dec-SctHotkey
 +
47355e9f-0857-45e1-8a6f-a4f5eda89a77-LocalSecurityVars
 +
4a67b082-0a4c-41cf-b6c7-440b29bb8c4f-LoaderDeviceIdentifier
 +
4a67b082-0a4c-41cf-b6c7-440b29bb8c4f-LoaderDevicePartUUID
 +
4a67b082-0a4c-41cf-b6c7-440b29bb8c4f-LoaderEntriesAuto
 +
4a67b082-0a4c-41cf-b6c7-440b29bb8c4f-LoaderEntrySelected
 +
4a67b082-0a4c-41cf-b6c7-440b29bb8c4f-LoaderFirmwareInfo
 +
4a67b082-0a4c-41cf-b6c7-440b29bb8c4f-LoaderFirmwareType
 +
4a67b082-0a4c-41cf-b6c7-440b29bb8c4f-LoaderImageIdentifier
 +
4a67b082-0a4c-41cf-b6c7-440b29bb8c4f-LoaderInfo
 +
4a67b082-0a4c-41cf-b6c7-440b29bb8c4f-LoaderTimeExecUSec
 +
4a67b082-0a4c-41cf-b6c7-440b29bb8c4f-LoaderTimeInitUSec
 +
4a67b082-0a4c-41cf-b6c7-440b29bb8c4f-LoaderTimeMenuUSec
 +
4c19049f-4137-4dd3-9c10-8b97a83ffdfa-MemoryTypeInformation
 +
4c19049f-4137-4dd3-9c10-8b97a83ffdfa-MemoryTypeInformationBackup
 +
4dfbbaab-1392-4fde-abb8-c41cc5ad7d5d-Setup
 +
5e724c0c-5c03-4543-bcb6-c1e23de24136-TpmSaveState
 +
608dc793-15de-4a7f-a0c5-6c29beaf5d23-MemRestoreVariable
 +
6403753b-abde-4da2-aa11-6983ef2a7a69-TpmAcpiData
 +
65827a61-99e2-4f07-a7aa-0b1f98edad39-PlatformOpRomSetup
 +
67c3208e-4fcb-498f-9729-0760bb4109a7-LenovoFlashScratch1
 +
67c3208e-4fcb-498f-9729-0760bb4109a7-LenovoScratchData
 +
67c3208e-4fcb-498f-9729-0760bb4109a7-MailBoxQ
 +
753ab903-444c-41f8-a235-569e8341147e-TcgSetup
 +
7d4adce1-930d-40c7-9cd2-6d2148413dc7-CpuProtocolSetupVar
 +
7da81437-866b-4143-8e08-a25c6ef0fa5b-SaPpiSetupVar
 +
8be4df61-93ca-11d2-aa0d-00e098032b8c-Boot0000
 +
8be4df61-93ca-11d2-aa0d-00e098032b8c-Boot0001
 +
8be4df61-93ca-11d2-aa0d-00e098032b8c-Boot0002
 +
8be4df61-93ca-11d2-aa0d-00e098032b8c-Boot0003
 +
8be4df61-93ca-11d2-aa0d-00e098032b8c-Boot0004
 +
8be4df61-93ca-11d2-aa0d-00e098032b8c-Boot0005
 +
8be4df61-93ca-11d2-aa0d-00e098032b8c-Boot0006
 +
8be4df61-93ca-11d2-aa0d-00e098032b8c-Boot0007
 +
8be4df61-93ca-11d2-aa0d-00e098032b8c-Boot0008
 +
8be4df61-93ca-11d2-aa0d-00e098032b8c-Boot0009
 +
8be4df61-93ca-11d2-aa0d-00e098032b8c-Boot000A
 +
8be4df61-93ca-11d2-aa0d-00e098032b8c-Boot000B
 +
8be4df61-93ca-11d2-aa0d-00e098032b8c-Boot000C
 +
8be4df61-93ca-11d2-aa0d-00e098032b8c-Boot000D
 +
8be4df61-93ca-11d2-aa0d-00e098032b8c-Boot000E
 +
8be4df61-93ca-11d2-aa0d-00e098032b8c-Boot000F
 +
8be4df61-93ca-11d2-aa0d-00e098032b8c-Boot0010
 +
8be4df61-93ca-11d2-aa0d-00e098032b8c-Boot0011
 +
8be4df61-93ca-11d2-aa0d-00e098032b8c-Boot0012
 +
8be4df61-93ca-11d2-aa0d-00e098032b8c-Boot0013
 +
8be4df61-93ca-11d2-aa0d-00e098032b8c-Boot0014
 +
8be4df61-93ca-11d2-aa0d-00e098032b8c-Boot0015
 +
8be4df61-93ca-11d2-aa0d-00e098032b8c-Boot0016
 +
8be4df61-93ca-11d2-aa0d-00e098032b8c-Boot0017
 +
8be4df61-93ca-11d2-aa0d-00e098032b8c-Boot0018
 +
8be4df61-93ca-11d2-aa0d-00e098032b8c-BootCurrent
 +
8be4df61-93ca-11d2-aa0d-00e098032b8c-BootOptionSupport
 +
8be4df61-93ca-11d2-aa0d-00e098032b8c-BootOrder
 +
8be4df61-93ca-11d2-aa0d-00e098032b8c-BootOrderDefault
 +
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-DIAGSPLSHSCRN
 +
8be4df61-93ca-11d2-aa0d-00e098032b8c-ErrOutDev
 +
8be4df61-93ca-11d2-aa0d-00e098032b8c-HDDPWD
 +
8be4df61-93ca-11d2-aa0d-00e098032b8c-KEK
 +
8be4df61-93ca-11d2-aa0d-00e098032b8c-Key0000
 +
8be4df61-93ca-11d2-aa0d-00e098032b8c-Key0001
 +
8be4df61-93ca-11d2-aa0d-00e098032b8c-Key0002
 +
8be4df61-93ca-11d2-aa0d-00e098032b8c-Key0003
 +
8be4df61-93ca-11d2-aa0d-00e098032b8c-Key0004
 +
8be4df61-93ca-11d2-aa0d-00e098032b8c-Key0005
 +
8be4df61-93ca-11d2-aa0d-00e098032b8c-Key0006
 +
8be4df61-93ca-11d2-aa0d-00e098032b8c-LastBootCurrent
 +
8be4df61-93ca-11d2-aa0d-00e098032b8c-OsIndications
 +
8be4df61-93ca-11d2-aa0d-00e098032b8c-OsIndicationsSupported
 +
8be4df61-93ca-11d2-aa0d-00e098032b8c-PlatformLang
 +
8be4df61-93ca-11d2-aa0d-00e098032b8c-PlatformLangCodes
 +
8be4df61-93ca-11d2-aa0d-00e098032b8c-ProtectedBootOptions
 +
8be4df61-93ca-11d2-aa0d-00e098032b8c-SecureBoot
 +
8be4df61-93ca-11d2-aa0d-00e098032b8c-SetupHotKey
 +
8be4df61-93ca-11d2-aa0d-00e098032b8c-SetupMode
 +
8be4df61-93ca-11d2-aa0d-00e098032b8c-SimpleBootFlag
 +
8be4df61-93ca-11d2-aa0d-00e098032b8c-Timeout
 +
955b9041-133a-4bcf-90d1-97e1693c0e30-IEIT
 +
955b9041-133a-4bcf-90d1-97e1693c0e30-SecureBootOption
 +
9da5909e-ef5e-4851-8715-bf9e22b7a600-BGRTLogoIndex
 +
9dab39a4-3f8a-47ac-80c3-400729332c81-FirmwarePerformanceDataTable
 +
a2c1808f-0d4f-4cc9-a619-d1e641d39d49-LenovoSecurityConfig
 +
af9ffd67-ec10-488a-9dfc-6cbf5ee22c2e-AcpiGlobalVariable
 +
c3eeae98-23bf-412b-ab60-efcbb48e1534-SMBIOSELOG000
 +
c3eeae98-23bf-412b-ab60-efcbb48e1534-SMBIOSELOGNUMBER
 +
c3eeae98-23bf-412b-ab60-efcbb48e1534-SMBIOSMEMSIZE
 +
c4975200-64f1-4fb6-9773-f6a9f89d985e-SaPegData
 +
d719b2cb-3d3a-4596-a3bc-dad00e67656f-db
 +
d719b2cb-3d3a-4596-a3bc-dad00e67656f-dbx
 +
e5bbf7be-2417-499b-97db-39f4896391bc-BuildDate
 +
e5bbf7be-2417-499b-97db-39f4896391bc-BuildTime
 +
e6c2f70a-b604-4877-85ba-deec89e117eb-PchInit
 +
e6c2f70a-b604-4877-85ba-deec89e117eb-PchS3Peim
 +
eb704011-1402-11d3-8e77-00a0c969723b-MTC
 +
f9f0b131-f346-4f16-80dd-f941072b3a7d-iFfsData
 +
</nowiki>}}
  
 
== Apoyo de UEFI en el Kernel de Linux ==
 
== Apoyo de UEFI en el Kernel de Linux ==
Line 90: Line 258:
 
  CONFIG_FRAMEBUFFER_CONSOLE=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'''.
+
* Soporte para las Variables Runtime de UEFI (sistema de archivos '''efivarfs''' - {{ic|/sys/firmware/efi/efivars}}). Esta opción es importante, ya que es necesaria para manipular las Variables Runtime de UEFI usando herramientas como {{ic|/usr/bin/gummiboot}}. La opción de configuración siguiente está añadida en el kernel 3.10 y posterior: {{bc|1=CONFIG_EFIVAR_FS=y}}
 
+
  CONFIG_EFI_VARS=m
+
  
{{Nota|Esta opción está compilada como módulo en el kernel core/testing de Arch.}}
+
* Soporte para las Variables Runtime de UEFI (interfaz '''efivars sysfs''' - {{ic|/sys/firmware/efi/vars}}). Esta opción es importante, ya que es necesaria para manipular las Variables Runtime de UEFI usando herramientas compatibles con '''efivarfs''': {{bc|1=CONFIG_EFI_VARS=n}}
  
{{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.}}
+
* Opción de configuración de GUID Partition Table ([[GUID Partition Table (Español)|GPT]]) - necesaria para dar soporte a UEFI: {{bc|1=CONFIG_EFI_PARTITION=y}}
  
{{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.}}
+
{{Nota|Todas las opciones anteriores son necesarias para arrancar Linux en UEFI, y están activadas en los kernels de ArchLinux presentes en los repositorios oficiales.}}
  
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:  
+
Obtenido de http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=blob_plain;f=Documentation/x86/x86_64/uefi.txt;hb=HEAD .
  
  CONFIG_EFI_PARTITION=y
+
=== Apoyo de las Variables de UEFI en el Kernel ===
  
{{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.}}
+
El Kernel de Linux expone los datos de las variables de EFI en el espacio de usuario a través de 2 interfaces:
  
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 .
+
# '''efivarfs''' (módulo del kernel efivarfs, {{ic|/sys/firmware/efi/efivars}}) que fue diseñado para superar las limitaciones de la interfaz sysfs-efivars.
 +
# Antigua interfaz '''sysfs-efivars''' (módulo del kernel efivarfs, {{ic|/sys/firmware/efi/vars}}) que ha sido desactivado desde linux-3.11 (existe paquete en Arch)
  
== Apoyo de las variables de UEFI ==
+
efivarfs se introdujo en el kernel 3.8 y la mayoría de sus errores fueron subsanados en el kernel 3.10.
  
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.
+
La ejecución de sysfs-efivars y efivarfs al mismo tiempo, puede dar lugar a inconsistencia de los datos de las variables de EFI en el kernel y es desaconsejable. Para el futuro, efivarfs será la forma recomendada para usar las herramientas de interacción de las variables de EFI con el kernel. Todas las herramientas relacionadas con las variables UEFI tienen el soporte '''efivarfs''' en los repositorios oficiales desde el 18-septiembre-2013.
  
{{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.}}
+
==== Requisitos del soporte de las variables UEFI para que funcione correctamente ====
  
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:
+
# El soporte para EFI Runtime Services debe estar presente en el kernel (CONFIG_EFI=y).
 +
# La arquitectura del procesador del Kernel y del procesador de EFI deben coincidir.
 +
# El kernel debe arrancar en modo EFI (a través de EFISTUB o de cualquier gestor de arranque EFI, no a través de BIOS/CSM o "bootcamp" de Apple que también es BIOS/CSM)
 +
# Los EFI Runtime Services del kernel NO DEBEN ser desactivados a través de un terminal, por ejemplo, el parámetro «noefi» del kernel NO DEBE ser usado.
 +
# 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 de comprobación del espacio de almacenamiento que puede impedir la escritura/modificación de las variables de efi.
  
Muestra de salida (UEFI 2.3.1-x86_64 en Kernel x86_64):
+
{{Nota|{{ic|efi_no_storage_paranoia}} solo debe utilizarse cuando sea necesario y no se debe dejar como una opción de arranque normal. El efecto de este parámetro en la línea de órdenes del kernel cancela una garantía que se pone en marcha para ayudar a evitar la saturación de las máquinas cuando NVRAM se llena demasiado.}}
+
# 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.
+
==== Inconsistencia entre efivarfs y sysfs-efivars ====
  
=== Herramientas del espacio de usuario ===
+
Tanto sysfs-efivars como efivarfs se pueden ejecutar al mismo tiempo, pero esto puede provocar incoherencias entre los datos de sysfs-efivars y los datos de efivarfs, especialmente si los datos en ambos se modifican simultáneamente. Véase https://lkml.org/lkml/2013/4/16/473 para más información. Por lo tanto, es aconsejable utilizar solo una interfaz a la vez y desactivar la otra.
  
Existen algunas herramientas que permiten acceder/modificar las variables UEFI, como:
+
{{Nota|De core/linux-3.11 en adelante efivars y los módulos efi_pstore ya no se compilan (este cambio solo afecta al kernel de Arch, los desarrolladores no han eliminado el código de sysfs-efivars). Únicamente efivarfs tiene el apoyo a partir de core/linux-3.11 en Arch.}}
  
# efibootmgr - Utilizada para crear/modificar las entradas de inicio del gestor de arranque de UEFI - {{Pkg|efibootmgr}} o {{AUR|efibootmgr-git}}
+
===== Cambiar a efivarfs =====
# 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  ===
+
{{Nota|Las siguientes órdenes deberían ejecutarse ANTES de efectuar '''chroot''', si procede.}}
  
==== efibootmgr ====
+
# umount /sys/firmware/efi/efivars
 +
# modprobe -r efivars
  
{{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}}.}}
+
# modprobe efivarfs
 +
# mount -t efivarfs efivarfs /sys/firmware/efi/efivars
  
{{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}}.}}
+
Verifique que todo ha ido bien ejecutando la orden {{ic|efivars -l}}. Si efivar no puede enumerar las variables UEFI, compruebe si todas las condiciones [[#Requisitos del soporte de las variables UEFI para que funcione correctamente|descritas aquí]] se cumplen.
  
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.
+
===== Cambiar a sysfs-efivars =====
  
Para utilizar efibootmgr, primero cargue el módulo del kernel «efivars»:
+
{{Nota|Las siguientes órdenes deberían ejecutarse ANTES de efectuar '''chroot''', si procede.}}
 +
 
 +
# umount /sys/firmware/efi/efivars
 +
# modprobe -r efivars
  
 
  # modprobe efivars
 
  # modprobe efivars
  
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?).
+
Verifique que todo ha ido bien ejecutando la orden {{ic|efivars -l}}. Si efivar no puede enumerar las variables UEFI, compruebe si todas las condiciones [[#Requisitos del soporte de las variables UEFI para que funcione correctamente|descritas aquí]] se cumplen.
  
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» .
+
== Herramientas en el espacio de usuario ==
  
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 ]].
+
Existen algunas herramientas que permiten acceder/modificar las variables UEFI, como:
  
{{Nota|Las siguientes órdenes utilizan el cargador de arranque {{pkg |gummiboot-efi}} como ejemplo.}}
+
# '''efivar''' - Herramienta y biblioteca para modificar las variables de UEFI (usado por efibootmgr de vathpela) - https://github.com/vathpela/efivar - {{Pkg|efivar}} o {{AUR|efivar-git}}
 +
# '''efibootmgr''' - Herramienta para modificar las configuraciones del gestor de arranque del firmware de UEFI. Los desarrolladores del código  efibootmgr (linuxdell) no proporcionan soporte a efivarfs. Un fork de efibootmgr de Fedora por Peter Jones (vathpela) soporta tanto efivarfs y sysfs-efivars. Actualmente se utiliza en el repositorio oficial core el paquete {{Pkg|efibootmgr}} y en AUR el paquete {{AUR|efibootmgr-pjones-git}} - https://github.com/vathpela/efibootmgr/tree/libefivars
 +
# '''uefivars''' - Simplemente accede al listado de las variables de EFI con alguna información adicional sobre el PCI (utiliza el código de efibootmgr) - https://github.com/fpmurphy/Various/tree/master/uefivars-2.0 solo admite efivarfs y https://github.com/fpmurphy/Various/tree/master/uefivars-1.0 solo admite sysfs-efivars. Paquete de AUR {{AUR|uefivars-git}}
 +
# '''efitools''' - Herramientas para crear y configura los propios Certificados Secure Boot de UEFI, Claves y Binarios Firmados (requiere efivarfs) - {{AUR|efitools-git}}
 +
# '''Suite de comprobación de firmware, de Ubuntu''' - https://wiki.ubuntu.com/FirmwareTestSuite/ - {{AUR|fwts}} (junto con {{AUR|fwts-efi-runtime-dkms}}) o {{AUR|fwts-git}}
  
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).
+
==== efibootmgr ====
 +
 
 +
{{Advertencia |Usar {{ic|efibootmgr}} en los Mac de Apple podría dañar el firmware y podría ser necesario flashear la ROM de la placa base. Ha habido informes de errores con respecto a este bug tracker en Ubuntu/Launchpad. Utilice la orden bless únicamente si tiene un Mac. La utilidad experimental «bless» para Linux es desarrollado por los desarrolladores de Fedora - {{AUR|mactel-boot}}.}}
 +
 
 +
{{Nota|
 +
*Si {{ic|efibootmgr}} no funciona en absoluto en su sistema, puede reiniciar en la Shell v2 de UEFI y utilizar la orden {{ic|bcfg}} para crear una entrada de arranque en el gestor de arranque.
 +
*Si 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 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 {{Pkg|refind-efi}} como ejemplo.
 +
*Los desarrolladores de efibootmgr http://linux.dell.com/git/efibootmgr.git no proporcionan soporte para efivarfs. Sin embargo, el efibootmgr de vathpela da apoyo a efivarfs y se utiliza actualmente en el paquete oficial de efibootmgr. sysfs-efivars  también se desactiva por completo en el kernel de Arch y soporta solo efivarfs. En esta sección se parte del supuesto de que se está utilizando solo efivarfs y efibootmgr de vathpela.}}
 +
 
 +
Supongamos que el archivo boot-loader para ser lanzado es {{ic|/boot/efi/EFI/refind/refind_x64.efi}}. El mismo {{ic|/boot/efi/EFI/refind/refind_x64.efi}} puede ser dividido en {{ic|/boot/efi}} y {{ic|/EFI/refind/refind_x64.efi}}, donde {{ic|/boot/efi}} es el punto de montaje de la partición del sistema UEFI, que se supone que es {{ic|/dev/sdXY}} (en este caso X e Y son marcadores de posición para los valores reales - por ejemplo: - en {{ic|/dev/sda1}}, X=a; Y=1).
  
 
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 determinar la ruta real del dispositivo para la partición del sistema UEFI (debe tener el formato {{ic|/dev/sdXY}}), pruebe con la orden:
Line 177: Line 346:
 
  TARGET SOURCE  FSTYPE OPTIONS
 
  TARGET SOURCE  FSTYPE OPTIONS
 
  /boot/efi  /dev/sdXY  vfat        rw,flush,tz=UTC
 
  /boot/efi  /dev/sdXY  vfat        rw,flush,tz=UTC
 +
 +
Compruebe que el soporte para las variables de UEFI en el kernel funciona correctamente ejecutando la orden:
 +
 +
# efivar -l
 +
 +
Si efivar enumera las variables UEFI sin ningún error, entonces se puede continuar. Si no es así, compruebe si todas las condiciones [[#Requisitos del soporte de las variables UEFI para que funcione correctamente|descritas aquí]] se cumplen.
  
 
A continuación, cree la entrada de arranque usando efibootmgr de la siguiente manera:
 
A continuación, cree la entrada de arranque usando efibootmgr de la siguiente manera:
  
  # efibootmgr -c -g -d /dev/sdX -p Y -w -L "Gummiboot" -l '\EFI\gummiboot\gummibootx64.efi'
+
  # efibootmgr -c -d /dev/sdX -p Y -l /EFI/refind/refind_x64.efi -L "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}}.
+
{{Nota|1=UEFI utiliza la barra invertida {{ic|\}} como separador de ruta (similar a las rutas de Windows), pero el paquete oficial {{Pkg|efibootmgr}} proporciona soporte a las rutas de estilo unix con barras diagonales {{ic|/}} como separador de ruta para la opción {{ic|-l}}. Efibootmgr convierte internamente {{ic|/}} a {{ic|\}} antes de codificar la ruta de acceso del cargador. Este importante comportamiento que añadió esta característica a efibootmgr está en http://linux.dell.com/cgi-bin/cgit.cgi/efibootmgr.git/commit/?id=f38f4aaad1dfa677918e417c9faa6e3286411378 .}}
  
UEFI utiliza barra diagonal invertida (\) como separador de ruta (similar a las rutas de Windows).
+
En la orden anterior {{ic|/boot/efi/EFI/refind/refind_x64.efi}} interpreta a {{ic|/boot/efi}} y a {{ic|/EFI/refind/refind_x64.efi}}, que, a su vez, lo interpretan como: disco: {{ic|/dev/sdX}} →  partición:  {{ic|Y}} →  archivo: {{ic|/EFI/refind/refind_x64.efi}}.
  
La «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] .
+
La «etiqueta» es el nombre de la entrada del menú que se muestra en el menú de inicio UEFI. Este nombre es elegido por el usuario y no afecta al arranque del sistema. Se puede obtener más información a partir de [http://linux.dell.com/cgi-bin/cgit.cgi/efibootmgr.git/plain/README efibootmgr GIT README].
  
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).
+
El sistema de archivos FAT32 no distingue entre mayúsculas y minúsculas, ya que no utiliza codificación UTF-8 de forma predeterminada. En este caso, el firmware utiliza  «EFI» en letra mayúscula, en lugar de minúsculas («efi»), por lo tanto, usando {{ic|\EFI\refind\refindx64.efi}} o {{ic|\efi\refind\refind_x64.efi}} no hay diferencia (esto cambia si la codificación del sistema de archivos es UTF-8).
  
 
== Gestores de arranque de Linux para UEFI ==
 
== Gestores de arranque de Linux para UEFI ==
Line 196: Line 371:
 
== Crear una ''«UEFI System Partition»'' en Linux ==
 
== Crear una ''«UEFI System Partition»'' en Linux ==
  
{{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 ser accesible por el firmware UEFI, el cual no puede leer LVM y sistemas RAID software.
 +
*Establecer el flag como «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 «UEFI System Partition».}}
 +
 
 +
La partición del sistema EFI (''«EFI System Partition»'') necesita ser formateada con un sistema de archivos FAT32 (sistemas de archivos distintos de FAT como ext2/3/4, reiserfs, NTFS, UDF etc. no son compatibles). Aunque las «EFI System Partition» (ESP) con tamaños de >=100 MiB y formateadas como FAT32 son permitidas por Microsoft Windows y algunas distribuciones Linux, la documentación de Microsoft especifica que  el tamaño mínimo de la partición/volumen para el sistema de archivos FAT32 es de 512 MiB. Por lo tanto, una ESP debe tener, al menos, 512 MiB de tamaño para garantizar una máxima compatibilidad. Si está utilizando el arranque EFISTUB en Linux, entonces necesitará asegurarse de que tiene suficiente espacio disponible para guardar los archivos del Kernel y de Initramfs en la ESP.
 +
 
 +
Es recomendable usar siempre GPT para arrancar UEFI, ya que algunos firmwares de UEFI no permiten el arranque UEFI desde particionado MBR.  
  
 
=== Discos particionados para GPT ===
 
=== Discos particionados para GPT ===
 
Dos opciones:
 
Dos opciones:
 
* Usar GNU Parted/GParted: Cree una partición FAT32. Ajuste la partición con el flag «boot» para marcarla como activa.
 
* 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>}}
+
* Usar GPT fdisk (conocido también como gdisk): Cree una partición con gdisk con el código tipo {{ic|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"'').}}
+
Si obtiene el mensaje  <code>WARNING: Not enough clusters for a 32 bit FAT!</code>, reduzca el tamaño del cluster con la orden <code>mkfs.vfat -s2 -F32 ...</code> o <code>-s1</code>, de lo contrario la partición puede ser ilegible para UEFI.
 
+
{{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).}}
+
  
 
=== Discos particionados para MBR ===
 
=== Discos particionados para MBR ===
 
Dos opciones:
 
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 GNU Parted/GParted: Cree una partición FAT32. Cambie el código del tipo de la partición a {{ic|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>}}
+
* Usar GPT fdisk Cree una partición con código {{ic|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.}}
+
  
 
== Shell de UEFI ==
 
== Shell de UEFI ==
Line 218: Line 395:
 
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.  
 
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.  
  
=== Enlaces de descarga de la shell de UEFI ===  
+
=== Obtener la shell de UEFI ===  
  
 
Puede descargar una Shell de UEFI con licencia BSD de Tianocore de Intel desde el proyecto Sourceforge.net UDK/EDK2.
 
Puede descargar una Shell de UEFI con licencia BSD de Tianocore de Intel desde el proyecto Sourceforge.net UDK/EDK2.
  
* [https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2/ShellBinPkg/UefiShell/X64/Shell.efi x86_64 UEFI Shell 2.0 (Beta)]
+
* Paquete '''{{AUR|uefi-shell-svn}}''' desde [[AUR]] (recomendado) - proporciona una Shell x86_64 para sistemas x86_64 y una Shell IA32 para sistemas i686 - compilado directamente desde la última fuente SVN EDK2 de Tianocore
* [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/X64/Shell.efi Precompiled x86_64 UEFI Shell v2 binary] (puede no estar actualizado)
* [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/X64/Shell_Full.efi Precompiled x86_64 UEFI Shell v1 binary] (no actualizado por los desarrolladores)
* [https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2/EdkShellBinPkg/FullShell/Ia32/Shell_Full.efi i386 UEFI Shell 1.0 (Old)]
+
* [https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2/ShellBinPkg/UefiShell/Ia32/Shell.efi Precompiled IA32 UEFI Shell v2 binary] (puede no estar actualizado)
 +
* [https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2/EdkShellBinPkg/FullShell/Ia32/Shell_Full.efi Precompiled IA32 UEFI Shell v1 binary] (no actualizado por los desarrolladores)
  
 
La versión 2.0 de la Shell únicamente funciona en sistemas UEFI 2.3 + y se recomienda su uso con preferencia a la Shell 1.0 en esos sistemas. La versión 1.3 de la Shell debería funcionar en todos los sistemas UEFI, independientemente de la especificación de la versión del firmware. Más información en [http://sourceforge.net/apps/mediawiki/tianocore/index.php?title=ShellPkg ShellPkg] y [http://sourceforge.net/mailarchive/message.php?msg_id=28690732 este correo].
 
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].
Line 238: Line 416:
  
 
=== Órdenes importantes de la shell de UEFI ===  
 
=== Órdenes importantes de la shell de UEFI ===  
 +
 +
Las órdenes de la Shell de UEFI generalmente dan soporte a la opción {{ic|-b}} que hace una pausa después de la salida de cada página. {{ic|map}} que lista los sistemas de archivos reconocidos ({{ic|fs0}}, ...) y los dispositivos de almacenamiento de datos ({{ic|blk0}}, ...). Ejecute {{ic|help -b}} para ver las órdenes disponibles.
  
 
Puede obtener más información en http://software.intel.com/en-us/articles/efi-shells-and-scripting/
 
Puede obtener más información en http://software.intel.com/en-us/articles/efi-shells-and-scripting/
Line 245: Line 425:
 
La orden BCFG se utiliza para modificar las entradas en la NVRAM de UEFI, lo que permite cambiar las entradas de arranque o las opciones del controlador. Esta orden se describe con detalle en la página 83 (sección 5.3) del documento pdf «UEFI Shell Specification 2.0».
 
La orden 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».
  
{{Nota|Se recomienda probar {{ic|bcfg}} únicamente si {{ic|efibootmgr}} no puede crear entradas de inicio que funcionen en el propio sistema.}}
+
{{Nota|
 
+
*Se recomienda probar {{ic|bcfg}} únicamente si {{ic|efibootmgr}} no puede crear entradas de inicio que funcionen en el propio sistema.
{{Nota| La Shell 1.0 de UEFI no es compatible con la orden {{ic|bcfg}}.}}
+
*La versión 1 del binario oficial de la Shell de UEFI no proporciona soporte para la orden {{ic|bcfg}}. Puede descargar una [http://dl.dropbox.com/u/17629062/Shell2.zip Shell de UEFI modificada] que puede trabajar con firmwares pre-2.3 de UEFI.}}
  
 
Para conocer una lista de entradas de arranque actuales:
 
Para conocer una lista de entradas de arranque actuales:
Line 255: Line 435:
 
Para añadir una entrada en el menú de inicio para rEFInd (por ejemplo) como cuarta (la numeración empieza desde cero) en el menú de arranque:
 
Para añadir una entrada en el menú de inicio para rEFInd (por ejemplo) como cuarta (la numeración empieza desde cero) en el menú de arranque:
  
  Shell> bcfg boot add 3 fs0:\EFI\arch\refind\refindx64.efi "Arch Linux (rEFInd)"
+
  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 \EFI\arch\refind\refindx64.efi es el archivo que se pondrá en marcha.
+
donde {{ic|fs0:}} es la asignación correspondiente a la partición del sistema UEFI y {{ic|\EFI\arch\refind\refindx64.efi}} es el archivo que se pondrá en marcha.
  
 
Para quitar la opción de arranque cuarta:
 
Para quitar la opción de arranque cuarta:
Line 267: Line 447:
 
  Shell> bcfg boot mv 3 0
 
  Shell> bcfg boot mv 3 0
  
Para mostrar el texto de ayuda bcfg:
+
Para mostrar el texto de ayuda de bcfg:
  
 
  Shell> help bcfg -v -b
 
  Shell> help bcfg -v -b
Line 279: Line 459:
 
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]].
 
La orden EDIT proporciona un editor de texto básico, con una interfaz similar al editor de textos nano, pero ligeramente menos funcional. Maneja codificación UTF-8 y se hace cargo del final de la línea LF frente a [[wikipedia:es:CRLF|CRLF]].
  
Para editar, por ejemplo refind.conf de rEFInd en la partición del sistema UEFI (fs0: en el firmware)
+
Para editar, por ejemplo, {{ic|refind.conf}} de rEFInd en la partición del sistema UEFI (fs0: en el firmware):
  
 
  Shell> fs0:
 
  Shell> fs0:
Line 285: Line 465:
 
  FS0:\EFI\arch\refind\> edit refind.conf
 
  FS0:\EFI\arch\refind\> edit refind.conf
  
== Compatibilidad de Hardware ==
+
Escriba {{ic|Ctrl-E}} para obtener ayuda.
  
Página principal [[HCL/Firmwares/UEFI]]
+
== Compatibilidad de hardware ==
  
== Crear un USB booteable de UEFI desde la ISO ==
+
Véase el artículo [[HCL/Firmwares/UEFI]]
  
{{Nota|Las siguientes instrucciones son específicas para el soporte oficial [[Archiso]]; la preparación de [[Archboot]] es idéntica, sin el requisito de la etiqueta del sistema de archivos}}
+
== Soporte para arrancar UEFI ==
 +
=== Crear un USB arrancable con UEFI desde la ISO ===
  
Debido a las insuficiencias en Archiso, es necesario reconstruir los medios de instalación con el fin de que sea UEFI la que pueda arrancar.
+
{{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 («label») del sistema de archivos.}}
  
La creación de una tabla de particiones MBR y un sistema de archivos FAT32 debe proporcionar la mayor compatibilidad con las implementaciones incompletas/deficientes de UEFI, sin tener que preocuparse por el tipo de partición.
+
* [[Beginners'_Guide_(Español)#Preparar_la_unidad_de_almacenamiento|Primero, cree una tabla de particiones MBR o GPT (recomendado) y, al menos, una partición en el USB]] (por lo que podría muy bien utilizar un USB ya particionado). {{Nota|Usar una tabla de particiones GPT es lo recomendado, ya que algunos firmwares no permiten arrancar desde dispositivos MBR en modalidad exclusivamente UEFI (por ejemplo, Gigabyte).}}
  
Monte el medio de instalación y cree un sistemas de archivos FAT con la etiqueta utilizada en la configuración de Archiso.
+
* Monte la imagen ISO obtenida desde la [https://www.archlinux.org/download/ página de descargas de Arch Linux]. {{bc|# mkdir -p /mnt/{usb,iso}<br># mount -o loop archlinux-2013.06.01-dual.iso /mnt/iso}}
  
{{bc|1=<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 de 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}}.{{Nota|El sistema de archivos debe ser FAT32 (recomendado), FAT16, o FAT12.}} {{bc|<nowiki># awk 'BEGIN {FS="="} /archisolabel/ {print $3}' /mnt/iso/loader/entries/archiso-x86_64.conf | xargs mkfs.vfat -F32 /dev/sdXY -n</nowiki>}}
# mkdir -p /mnt/{usb,iso}
+
# mount -o loop,ro archlinux-2012.12.01-dual.iso /mnt/iso
+
# awk -F"archisolabel=" 'NF>1{sub(/ .*/,"",$2);print $2}' /mnt/iso/loader/entries/archiso-x86_64.conf | xargs mkfs.vfat /dev/sdb1 -n</nowiki>}}
+
  
Monte el sistema de archivos FAT recién creado y copie los contenidos del soporte de instalación al dispositivo USB.
+
* Monte la partición FAT32 del USB recién creada y copie el contenido del soporte de instalación al dispositivo USB. {{bc|# mount /dev/sdXY /mnt/usb<br># cp -a /mnt/iso/* /mnt/usb<br># sync<br># umount /mnt/{usb,iso}
 +
}}
  
{{bc|1=<nowiki>
+
=== Eliminar el apoyo de arranque de UEFI desde la ISO ===
# mount /dev/sdb1 /mnt/usb
+
# cp -r /mnt/iso/* /mnt/usb
+
# umount /mnt/{usb,iso}
+
# sync</nowiki>}}
+
 
+
== Eliminar el apoyo de arranque de UEFI desde la ISO ==
+
  
 
{{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.}}
 
{{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.}}
Line 336: Line 509:
  
 
Grabe {{ic|~/archiso.iso}} en el disco óptico y continúe con la instalación normalmente.
 
Grabe {{ic|~/archiso.iso}} en el disco óptico y continúe con la instalación normalmente.
 +
 +
== Probar UEFI en sistemas sin soporte nativo ==
 +
 +
=== OVMF para máquinas virtuales  ===
 +
 +
OVMF [http://sourceforge.net/apps/mediawiki/tianocore/index.php?title=OVMF] es un proyecto para activar la compatibilidad de UEFI para máquinas virtuales. OVMF contiene una muestra de firmware UEFI para QEMU.
 +
 +
Se puede compilar OVMF (con el apoyo de Secure Boot) con {{AUR|ovmf-svn}} disponible en AUR y ejecutándolo como sigue:
 +
 +
qemu-system-x86_64 -enable-kvm -net none -m 1024 -bios /usr/share/ovmf/x86_64/bios.bin
 +
 +
=== DUET para sistemas únicamente BIOS ===
 +
 +
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 la BIOS UEFI está dando su apoyo CSM a este último (para arrancar particiones MBR) y por ello Windows no arranca. Para resolver este problema convierta el particionado de su disco MBR a GPT, o desactive el puerto SATA del disco duro cuando esté conectado, o bien, desenchufe el puerto SATA de este disco duro.
 +
 +
Placas base con este tipo de problema:
 +
 +
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.
  
 
== Véase también ==
 
== Véase también ==
  
* Página de Wikipedia en [http://en.wikipedia.org/wiki/UEFI UEFI]
+
* Página de Wikipedia sobre [http://en.wikipedia.org/wiki/UEFI UEFI]
* Página de Wikipedia en [http://en.wikipedia.org/wiki/EFI_System_partition UEFI SYSTEM Partition]
+
* Página de Wikipedia sobre [http://en.wikipedia.org/wiki/EFI_System_partition UEFI SYSTEM Partition]
 
* [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]
 
* [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]
 
* [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
 
* [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

Revision as of 10:02, 24 September 2013

Template:Article summary start Template:Article summary text Template:Article summary heading Template:Article summary text Template:Article summary heading Template:Article summary wiki Template:Article summary wiki Template:Article summary wiki Template: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 UEFI Forum, se hizo cargo de su desarrollo, a partir del cual se llamó EFI Unificado desde de la versión 2.0. Hasta el 24 de julio de 2012, la Especificación 2.4 de UEFI (liberada el 11 de julio de 2013) es la versión más reciente.

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.

Antes de entender UEFI, es importante entender cómo arrancan los sistemas pre-UEFI (BIOS). Esto se explica en las secciones siguientes.

BIOS

Una BIOS o «Basic Input-Output System» es el primer programa (firmware) que se ejecuta cuando el sistema está encendido. En la mayoría de los casos, este se almacena en una memoria flash en la propia placa base e independiente del almacenamiento del sistema.

Proceso de arranque bajo BIOS

  1. Encendido del sistema —Power On Self Test—, o proceso POST.
  2. Después del POST la BIOS inicializa el hardware necesario para el arranque del sistema (disco, controladores del teclado, etc.).
  3. La BIOS ejecuta el código de los primeros 440 bytes (la región del código de arranque del MBR) del primer disco de los que aparecen ordenados en la BIOS.
  4. El código de arranque del MBR entonces toma el control desde la BIOS y ejecuta el código de la siguiente etapa (en su caso) (normalmente, el código del gestor de arranque).
  5. El código lanzado (segunda etapa) (el gestor de arranque presente) entonces lee los archivos de configuración y apoyo.
  6. En base a los datos de los archivos de configuración, el gestor de arranque carga el kernel e initramfs en la memoria del sistema (RAM), e inicia el kernel.

Multiarranque en BIOS

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 GRUB, 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.

UEFI

UEFI tiene la capacidad de leer tanto la tabla de particiones, como de reconocer los sistemas de archivos. Por lo tanto, no está limitado por la limitación de código de 440 bytes (código de arranque MBR) como en los sistemas BIOS. No utiliza el código de arranque MBR en absoluto.

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.

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 (principalmente) o FAT16.

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 antiguos (anteriores a 2008) que funcionan utilizando EFI IA32 (32-bit), algunos ultrabooks recientes de Intel Cloverfield y algunas placas bases de Intel Servers, son conocidos por operar con un firmware EFI 1.10 de Intel.

Un firmware EFI x86_64 no incluye el soporte para lanzar aplicaciones de 32-bit (a diferencia del EFI de Linux y de Windows x86_64 que incluyen dicho apoyo). En definitiva, la aplicación UEFI (esto es, el gestor de arranque) debe ser compilada para la arquitectura correcta.

Proceso de arranque bajo UEFI

  1. Encendido del sistema —se inicia Power On Self Test— o el proceso POST.
  2. Se carga el firmware UEFI. El firmware inicializa el hardware necesario para el arranque.
  3. El firmware lee el gestor de arranque para determinar qué aplicación UEFI iniciar, y desde dónde (es decir, desde qué disco y partición).
  4. El firmware UEFI inicia la aplicación desde la partición UEFI definida en la entrada de arranque del gestor de arranque del firmware.
  5. La aplicación UEFI puede iniciar otra aplicación (como la shell de UEFI o un gestor de arranque como rEFInd), o el kernel y el initramfs (en el caso de un gestor de arranque como GRUB) en función de cómo se ha configurado la aplicación UEFI.
Nota: En algunos sistemas UEFI el único camino posible para iniciar la aplicación UEFI en el arranque (si no tiene una entrada personalizada en el menú de inicio de UEFI) es ponerlo en este lugar fijo: <EFI SYSTEM PARTITION>/EFI/boot/bootx64.efi (para sistemas x86 de 64-bit)

Multiarranque en UEFI

Debido a que cada sistema operativo o fabricante puede mantener sus propios archivos en la partición del sistema EFI («EFI System Partition») sin afectar a otros sistemas operativos, el multiarranque con UEFI consiste únicamente en lanzar una aplicación UEFI diferente, correspondiente al gestor de arrranque de un particular sistema operativo. Esto elimina la necesidad de recurrir a mecanismos de cargar los sistemas operativos en cadena con un gestor de arranque para iniciar uno u otro.

Arranque de Microsoft Windows

Las versiones de 64-bit de Windows Vista (SP1+), 7 y 8, permiten arrancar de forma nativa utilizando el firmware UEFI x86_64. Windows fuerza el tipo de partición en función del firmware utilizado, es decir, si Windows se inicia en el modo UEFI, es que viene instalado en un disco GPT. Si Windows se inicia en modo BIOS legacy, significa que solo se puede instalar en un disco MBR. Esta es una limitación impuesta por el instalador de Windows. Así Windows soporta bien el arranque UEFI-GPT o solo arranque BIOS-MBR, pero no el arranque UEFI-BIOS o MBR-GPT.

Estas limitaciones no existen en el kernel de Linux, sino que depende del gestor de arranque utilizado. Sin embargo, esta limitación de Windows se debe tener en cuenta si el usuario quiere arrancar Windows y Linux en el mismo disco, ya que la configuración del gestor de arranque en sí depende del tipo de firmware y de la partición del disco utilizada. En el caso de arranque dual de Windows y Linux en el mismo disco, es recomendable seguir el método utilizado por Windows, ya sea el arranque UEFI-GPT o solo arranque BIOS-MBR, no los otros dos casos.

Las versiones de Windows de 32-bit únicamente soportan el arranque en sistemas BIOS-MBR. Siga las instrucciones proporcionadas en el enlace del foro en las secciones apropiadas respecto a cómo hacer esto. Véase http://support.microsoft.com/default.aspx?scid=kb;EN-US;2581408 para más información.

Detectar la arquitectura del firmware UEFI

Sistemas UEFI que no son Mac

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

Mac de Apple

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

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

ioreg -l -p IODeviceTree | grep firmware-abi

Si la orden devuelve EFI32 entonces es un firmware EFI 1.x para i386. Si devuelve EFI64, entonces es un firmware EFI 1.x para x86_64. Mac no tiene un firmware 2.x UEFI, porque la implementación del firmware EFI de Apple no es totalmente compatible con la especificación UEFI 2.x.

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.

Listado de muestra de las variables de UEFI

Muestra de salida en un Lenovo Thinkpad E430 3254-DAQ (características: UEFI 2.3.1-x86_64, firmware x86_64, compatible con Secure Boot):

UEFI Variables List
 $ efivar -l
0b7646a4-6b44-4332-8588-c8998117f2ef-BmEssentialVariableNames
0ec1a7f5-4904-40a0-8eab-4bcc4666da45-PbaStatusVar
1054354b-b543-4dfe-558b-a7ad6351c9d8-DptfProtocolSetupVar
1827cfc7-4e61-4273-b796-d35f4b0c88fc-LenovoHiddenSetting
1bad711c-d451-4241-b1f3-8537812e0c70-MeBiosExtensionSetup
2a4dc6b7-41f5-45dd-b46f-2dd334c1cf65-LBC
2a4dc6b7-41f5-45dd-b46f-2dd334c1cf65-LBL
2a4dc6b7-41f5-45dd-b46f-2dd334c1cf65-LBOL
2a4dc6b7-41f5-45dd-b46f-2dd334c1cf65-LBOP0000
2a4dc6b7-41f5-45dd-b46f-2dd334c1cf65-LBOP0001
2a4dc6b7-41f5-45dd-b46f-2dd334c1cf65-LBOP0002
2a4dc6b7-41f5-45dd-b46f-2dd334c1cf65-LBOP0003
2a4dc6b7-41f5-45dd-b46f-2dd334c1cf65-LBOP0004
2a4dc6b7-41f5-45dd-b46f-2dd334c1cf65-LBOP0005
2a4dc6b7-41f5-45dd-b46f-2dd334c1cf65-LBOP0006
2a4dc6b7-41f5-45dd-b46f-2dd334c1cf65-LBOP0007
2a4dc6b7-41f5-45dd-b46f-2dd334c1cf65-LBOP0008
2a4dc6b7-41f5-45dd-b46f-2dd334c1cf65-LBOP0009
2a4dc6b7-41f5-45dd-b46f-2dd334c1cf65-LBOP000A
2a4dc6b7-41f5-45dd-b46f-2dd334c1cf65-LBOP000B
2a4dc6b7-41f5-45dd-b46f-2dd334c1cf65-LBOP000C
2a4dc6b7-41f5-45dd-b46f-2dd334c1cf65-LBOP000D
2a4dc6b7-41f5-45dd-b46f-2dd334c1cf65-LBOP000E
2a4dc6b7-41f5-45dd-b46f-2dd334c1cf65-LBOP000F
2a4dc6b7-41f5-45dd-b46f-2dd334c1cf65-LBOP0010
2a4dc6b7-41f5-45dd-b46f-2dd334c1cf65-LBOP0011
2a4dc6b7-41f5-45dd-b46f-2dd334c1cf65-LBOP0012
2a4dc6b7-41f5-45dd-b46f-2dd334c1cf65-LBOP0013
2a4dc6b7-41f5-45dd-b46f-2dd334c1cf65-LBOP0014
2a4dc6b7-41f5-45dd-b46f-2dd334c1cf65-LBOP0015
2a4dc6b7-41f5-45dd-b46f-2dd334c1cf65-LBOP0016
2a4dc6b7-41f5-45dd-b46f-2dd334c1cf65-LBOP0017
2a4dc6b7-41f5-45dd-b46f-2dd334c1cf65-LBOP0018
2a4dc6b7-41f5-45dd-b46f-2dd334c1cf65-LenovoConfig
2a4dc6b7-41f5-45dd-b46f-2dd334c1cf65-LenovoSystemConfig
2a4dc6b7-41f5-45dd-b46f-2dd334c1cf65-LKOP0000
2a4dc6b7-41f5-45dd-b46f-2dd334c1cf65-LKOP0001
2a4dc6b7-41f5-45dd-b46f-2dd334c1cf65-LKOP0002
2a4dc6b7-41f5-45dd-b46f-2dd334c1cf65-LKOP0003
2a4dc6b7-41f5-45dd-b46f-2dd334c1cf65-LKOP0004
2a4dc6b7-41f5-45dd-b46f-2dd334c1cf65-LKOP0005
2a4dc6b7-41f5-45dd-b46f-2dd334c1cf65-LKOP0006
2a4dc6b7-41f5-45dd-b46f-2dd334c1cf65-LWO
34f73d4d-963e-4c65-b3b3-515e720175d6-SaProtocolSetupVar
3e72b3ad-2b91-424a-ad73-c3270e91ed88-PwdStatusVar
4650c401-93f1-4aeb-b87d-c8204c047dec-SctHotkey
47355e9f-0857-45e1-8a6f-a4f5eda89a77-LocalSecurityVars
4a67b082-0a4c-41cf-b6c7-440b29bb8c4f-LoaderDeviceIdentifier
4a67b082-0a4c-41cf-b6c7-440b29bb8c4f-LoaderDevicePartUUID
4a67b082-0a4c-41cf-b6c7-440b29bb8c4f-LoaderEntriesAuto
4a67b082-0a4c-41cf-b6c7-440b29bb8c4f-LoaderEntrySelected
4a67b082-0a4c-41cf-b6c7-440b29bb8c4f-LoaderFirmwareInfo
4a67b082-0a4c-41cf-b6c7-440b29bb8c4f-LoaderFirmwareType
4a67b082-0a4c-41cf-b6c7-440b29bb8c4f-LoaderImageIdentifier
4a67b082-0a4c-41cf-b6c7-440b29bb8c4f-LoaderInfo
4a67b082-0a4c-41cf-b6c7-440b29bb8c4f-LoaderTimeExecUSec
4a67b082-0a4c-41cf-b6c7-440b29bb8c4f-LoaderTimeInitUSec
4a67b082-0a4c-41cf-b6c7-440b29bb8c4f-LoaderTimeMenuUSec
4c19049f-4137-4dd3-9c10-8b97a83ffdfa-MemoryTypeInformation
4c19049f-4137-4dd3-9c10-8b97a83ffdfa-MemoryTypeInformationBackup
4dfbbaab-1392-4fde-abb8-c41cc5ad7d5d-Setup
5e724c0c-5c03-4543-bcb6-c1e23de24136-TpmSaveState
608dc793-15de-4a7f-a0c5-6c29beaf5d23-MemRestoreVariable
6403753b-abde-4da2-aa11-6983ef2a7a69-TpmAcpiData
65827a61-99e2-4f07-a7aa-0b1f98edad39-PlatformOpRomSetup
67c3208e-4fcb-498f-9729-0760bb4109a7-LenovoFlashScratch1
67c3208e-4fcb-498f-9729-0760bb4109a7-LenovoScratchData
67c3208e-4fcb-498f-9729-0760bb4109a7-MailBoxQ
753ab903-444c-41f8-a235-569e8341147e-TcgSetup
7d4adce1-930d-40c7-9cd2-6d2148413dc7-CpuProtocolSetupVar
7da81437-866b-4143-8e08-a25c6ef0fa5b-SaPpiSetupVar
8be4df61-93ca-11d2-aa0d-00e098032b8c-Boot0000
8be4df61-93ca-11d2-aa0d-00e098032b8c-Boot0001
8be4df61-93ca-11d2-aa0d-00e098032b8c-Boot0002
8be4df61-93ca-11d2-aa0d-00e098032b8c-Boot0003
8be4df61-93ca-11d2-aa0d-00e098032b8c-Boot0004
8be4df61-93ca-11d2-aa0d-00e098032b8c-Boot0005
8be4df61-93ca-11d2-aa0d-00e098032b8c-Boot0006
8be4df61-93ca-11d2-aa0d-00e098032b8c-Boot0007
8be4df61-93ca-11d2-aa0d-00e098032b8c-Boot0008
8be4df61-93ca-11d2-aa0d-00e098032b8c-Boot0009
8be4df61-93ca-11d2-aa0d-00e098032b8c-Boot000A
8be4df61-93ca-11d2-aa0d-00e098032b8c-Boot000B
8be4df61-93ca-11d2-aa0d-00e098032b8c-Boot000C
8be4df61-93ca-11d2-aa0d-00e098032b8c-Boot000D
8be4df61-93ca-11d2-aa0d-00e098032b8c-Boot000E
8be4df61-93ca-11d2-aa0d-00e098032b8c-Boot000F
8be4df61-93ca-11d2-aa0d-00e098032b8c-Boot0010
8be4df61-93ca-11d2-aa0d-00e098032b8c-Boot0011
8be4df61-93ca-11d2-aa0d-00e098032b8c-Boot0012
8be4df61-93ca-11d2-aa0d-00e098032b8c-Boot0013
8be4df61-93ca-11d2-aa0d-00e098032b8c-Boot0014
8be4df61-93ca-11d2-aa0d-00e098032b8c-Boot0015
8be4df61-93ca-11d2-aa0d-00e098032b8c-Boot0016
8be4df61-93ca-11d2-aa0d-00e098032b8c-Boot0017
8be4df61-93ca-11d2-aa0d-00e098032b8c-Boot0018
8be4df61-93ca-11d2-aa0d-00e098032b8c-BootCurrent
8be4df61-93ca-11d2-aa0d-00e098032b8c-BootOptionSupport
8be4df61-93ca-11d2-aa0d-00e098032b8c-BootOrder
8be4df61-93ca-11d2-aa0d-00e098032b8c-BootOrderDefault
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-DIAGSPLSHSCRN
8be4df61-93ca-11d2-aa0d-00e098032b8c-ErrOutDev
8be4df61-93ca-11d2-aa0d-00e098032b8c-HDDPWD
8be4df61-93ca-11d2-aa0d-00e098032b8c-KEK
8be4df61-93ca-11d2-aa0d-00e098032b8c-Key0000
8be4df61-93ca-11d2-aa0d-00e098032b8c-Key0001
8be4df61-93ca-11d2-aa0d-00e098032b8c-Key0002
8be4df61-93ca-11d2-aa0d-00e098032b8c-Key0003
8be4df61-93ca-11d2-aa0d-00e098032b8c-Key0004
8be4df61-93ca-11d2-aa0d-00e098032b8c-Key0005
8be4df61-93ca-11d2-aa0d-00e098032b8c-Key0006
8be4df61-93ca-11d2-aa0d-00e098032b8c-LastBootCurrent
8be4df61-93ca-11d2-aa0d-00e098032b8c-OsIndications
8be4df61-93ca-11d2-aa0d-00e098032b8c-OsIndicationsSupported
8be4df61-93ca-11d2-aa0d-00e098032b8c-PlatformLang
8be4df61-93ca-11d2-aa0d-00e098032b8c-PlatformLangCodes
8be4df61-93ca-11d2-aa0d-00e098032b8c-ProtectedBootOptions
8be4df61-93ca-11d2-aa0d-00e098032b8c-SecureBoot
8be4df61-93ca-11d2-aa0d-00e098032b8c-SetupHotKey
8be4df61-93ca-11d2-aa0d-00e098032b8c-SetupMode
8be4df61-93ca-11d2-aa0d-00e098032b8c-SimpleBootFlag
8be4df61-93ca-11d2-aa0d-00e098032b8c-Timeout
955b9041-133a-4bcf-90d1-97e1693c0e30-IEIT
955b9041-133a-4bcf-90d1-97e1693c0e30-SecureBootOption
9da5909e-ef5e-4851-8715-bf9e22b7a600-BGRTLogoIndex
9dab39a4-3f8a-47ac-80c3-400729332c81-FirmwarePerformanceDataTable
a2c1808f-0d4f-4cc9-a619-d1e641d39d49-LenovoSecurityConfig
af9ffd67-ec10-488a-9dfc-6cbf5ee22c2e-AcpiGlobalVariable
c3eeae98-23bf-412b-ab60-efcbb48e1534-SMBIOSELOG000
c3eeae98-23bf-412b-ab60-efcbb48e1534-SMBIOSELOGNUMBER
c3eeae98-23bf-412b-ab60-efcbb48e1534-SMBIOSMEMSIZE
c4975200-64f1-4fb6-9773-f6a9f89d985e-SaPegData
d719b2cb-3d3a-4596-a3bc-dad00e67656f-db
d719b2cb-3d3a-4596-a3bc-dad00e67656f-dbx
e5bbf7be-2417-499b-97db-39f4896391bc-BuildDate
e5bbf7be-2417-499b-97db-39f4896391bc-BuildTime
e6c2f70a-b604-4877-85ba-deec89e117eb-PchInit
e6c2f70a-b604-4877-85ba-deec89e117eb-PchS3Peim
eb704011-1402-11d3-8e77-00a0c969723b-MTC
f9f0b131-f346-4f16-80dd-f941072b3a7d-iFfsData

Apoyo de UEFI en el Kernel de Linux

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_EFI=y
CONFIG_EFI_STUB=y
CONFIG_RELOCATABLE=y
CONFIG_FB_EFI=y
CONFIG_FRAMEBUFFER_CONSOLE=y
  • Soporte para las Variables Runtime de UEFI (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/gummiboot. 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 (interfaz efivars sysfs - /sys/firmware/efi/vars). Esta opción es importante, ya que es necesaria para manipular las Variables Runtime de UEFI usando herramientas compatibles con efivarfs:
    CONFIG_EFI_VARS=n
  • Opción de configuración de GUID Partition Table (GPT) - necesaria para dar soporte a UEFI:
    CONFIG_EFI_PARTITION=y
Nota: Todas las opciones anteriores son necesarias para arrancar Linux en UEFI, y están activadas en los kernels de ArchLinux presentes en los repositorios oficiales.

Obtenido de http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=blob_plain;f=Documentation/x86/x86_64/uefi.txt;hb=HEAD .

Apoyo de las Variables de UEFI en el Kernel

El Kernel de Linux expone los datos de las variables de EFI en el espacio de usuario a través de 2 interfaces:

  1. efivarfs (módulo del kernel efivarfs, /sys/firmware/efi/efivars) que fue diseñado para superar las limitaciones de la interfaz sysfs-efivars.
  2. Antigua interfaz sysfs-efivars (módulo del kernel efivarfs, /sys/firmware/efi/vars) que ha sido desactivado desde linux-3.11 (existe paquete en Arch)

efivarfs se introdujo en el kernel 3.8 y la mayoría de sus errores fueron subsanados en el kernel 3.10.

La ejecución de sysfs-efivars y efivarfs al mismo tiempo, puede dar lugar a inconsistencia de los datos de las variables de EFI en el kernel y es desaconsejable. Para el futuro, efivarfs será la forma recomendada para usar las herramientas de interacción de las variables de EFI con el kernel. Todas las herramientas relacionadas con las variables UEFI tienen el soporte efivarfs en los repositorios oficiales desde el 18-septiembre-2013.

Requisitos del soporte de las variables UEFI para que funcione correctamente

  1. El soporte para EFI Runtime Services debe estar presente en el kernel (CONFIG_EFI=y).
  2. La arquitectura del procesador del Kernel y del procesador de EFI deben coincidir.
  3. El kernel debe arrancar en modo EFI (a través de EFISTUB o de cualquier gestor de arranque EFI, no a través de BIOS/CSM o "bootcamp" de Apple que también es BIOS/CSM)
  4. Los EFI Runtime Services del kernel NO DEBEN ser desactivados a través de un terminal, por ejemplo, el parámetro «noefi» del kernel NO DEBE ser usado.
  5. 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.
  6. 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 de comprobación del espacio de almacenamiento que puede impedir la escritura/modificación de las variables de efi.
Nota: 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.

Inconsistencia entre efivarfs y sysfs-efivars

Tanto sysfs-efivars como efivarfs se pueden ejecutar al mismo tiempo, pero esto puede provocar incoherencias entre los datos de sysfs-efivars y los datos de efivarfs, especialmente si los datos en ambos se modifican simultáneamente. Véase https://lkml.org/lkml/2013/4/16/473 para más información. Por lo tanto, es aconsejable utilizar solo una interfaz a la vez y desactivar la otra.

Nota: De core/linux-3.11 en adelante efivars y los módulos efi_pstore ya no se compilan (este cambio solo afecta al kernel de Arch, los desarrolladores no han eliminado el código de sysfs-efivars). Únicamente efivarfs tiene el apoyo a partir de core/linux-3.11 en Arch.
Cambiar a efivarfs
Nota: Las siguientes órdenes deberían ejecutarse ANTES de efectuar chroot, si procede.
# umount /sys/firmware/efi/efivars
# modprobe -r efivars
# modprobe efivarfs
# mount -t efivarfs efivarfs /sys/firmware/efi/efivars

Verifique que todo ha ido bien ejecutando la orden efivars -l. Si efivar no puede enumerar las variables UEFI, compruebe si todas las condiciones descritas aquí se cumplen.

Cambiar a sysfs-efivars
Nota: Las siguientes órdenes deberían ejecutarse ANTES de efectuar chroot, si procede.
# umount /sys/firmware/efi/efivars
# modprobe -r efivars
# modprobe efivars

Verifique que todo ha ido bien ejecutando la orden efivars -l. Si efivar no puede enumerar las variables UEFI, compruebe si todas las condiciones descritas aquí se cumplen.

Herramientas en el espacio de usuario

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

  1. efivar - Herramienta y biblioteca para modificar las variables de UEFI (usado por efibootmgr de vathpela) - https://github.com/vathpela/efivar - efivar o efivar-gitAUR
  2. efibootmgr - Herramienta para modificar las configuraciones del gestor de arranque del firmware de UEFI. Los desarrolladores del código efibootmgr (linuxdell) no proporcionan soporte a efivarfs. Un fork de efibootmgr de Fedora por Peter Jones (vathpela) soporta tanto efivarfs y sysfs-efivars. Actualmente se utiliza en el repositorio oficial core el paquete efibootmgr y en AUR el paquete efibootmgr-pjones-gitAUR - https://github.com/vathpela/efibootmgr/tree/libefivars
  3. uefivars - Simplemente accede al listado de las variables de EFI con alguna información adicional sobre el PCI (utiliza el código de efibootmgr) - https://github.com/fpmurphy/Various/tree/master/uefivars-2.0 solo admite efivarfs y https://github.com/fpmurphy/Various/tree/master/uefivars-1.0 solo admite sysfs-efivars. Paquete de AUR uefivars-gitAUR
  4. efitools - Herramientas para crear y configura los propios Certificados Secure Boot de UEFI, Claves y Binarios Firmados (requiere efivarfs) - efitools-gitAUR
  5. Suite de comprobación de firmware, de Ubuntu - https://wiki.ubuntu.com/FirmwareTestSuite/ - fwtsAUR (junto con fwts-efi-runtime-dkmsAUR) o fwts-gitAUR

efibootmgr

Advertencia: Usar 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 - mactel-bootAUR.
Nota:
  • Si efibootmgr no funciona en absoluto en su sistema, puede reiniciar en la Shell v2 de UEFI y utilizar la orden bcfg para crear una entrada de arranque en el gestor de arranque.
  • Si no es posible usar 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 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-efi como ejemplo.
  • Los desarrolladores de efibootmgr http://linux.dell.com/git/efibootmgr.git no proporcionan soporte para efivarfs. Sin embargo, el efibootmgr de vathpela da apoyo a efivarfs y se utiliza actualmente en el paquete oficial de efibootmgr. sysfs-efivars también se desactiva por completo en el kernel de Arch y soporta solo efivarfs. En esta sección se parte del supuesto de que se está utilizando solo efivarfs y efibootmgr de vathpela.

Supongamos que el archivo boot-loader para ser lanzado es /boot/efi/EFI/refind/refind_x64.efi. El mismo /boot/efi/EFI/refind/refind_x64.efi puede ser dividido en /boot/efi y /EFI/refind/refind_x64.efi, donde /boot/efi es el punto de montaje de la partición del sistema UEFI, que se supone que es /dev/sdXY (en este caso X e Y son marcadores de posición para los valores reales - por ejemplo: - en /dev/sda1, X=a; Y=1).

Para determinar la ruta real del dispositivo para la partición del sistema UEFI (debe tener el formato /dev/sdXY), pruebe con la orden:

# findmnt /boot/efi
TARGET SOURCE  FSTYPE OPTIONS
/boot/efi  /dev/sdXY  vfat         rw,flush,tz=UTC

Compruebe que el soporte para las variables de UEFI en el kernel funciona correctamente ejecutando la orden:

# efivar -l

Si efivar enumera las variables UEFI sin ningún error, entonces se puede continuar. Si no es así, compruebe si todas las condiciones descritas aquí se cumplen.

A continuación, cree la entrada de arranque usando efibootmgr de la siguiente manera:

# efibootmgr -c -d /dev/sdX -p Y -l /EFI/refind/refind_x64.efi -L "rEFInd"
Nota: UEFI utiliza la barra invertida \ como separador de ruta (similar a las rutas de Windows), pero el paquete oficial efibootmgr proporciona soporte a las rutas de estilo unix con barras diagonales / como separador de ruta para la opción -l. Efibootmgr convierte internamente / a \ antes de codificar la ruta de acceso del cargador. Este importante comportamiento que añadió esta característica a efibootmgr está en http://linux.dell.com/cgi-bin/cgit.cgi/efibootmgr.git/commit/?id=f38f4aaad1dfa677918e417c9faa6e3286411378 .

En la orden anterior /boot/efi/EFI/refind/refind_x64.efi interpreta a /boot/efi y a /EFI/refind/refind_x64.efi, que, a su vez, lo interpretan como: disco: /dev/sdX → partición: Y → archivo: /EFI/refind/refind_x64.efi.

La «etiqueta» es el nombre de la entrada del menú que se muestra en el menú de inicio UEFI. Este nombre es elegido por el usuario y no afecta al arranque del sistema. Se puede obtener más información a partir de efibootmgr GIT README.

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 \EFI\refind\refindx64.efi o \efi\refind\refind_x64.efi no hay diferencia (esto cambia si la codificación del sistema de archivos es UTF-8).

Gestores de arranque de Linux para UEFI

Véase UEFI Bootloaders.

Crear una «UEFI System Partition» en Linux

Nota:
  • El ESP debe ser accesible por el firmware UEFI, el cual no puede leer LVM y sistemas RAID software.
  • Establecer el flag como «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 «UEFI System Partition».

La partición del sistema EFI («EFI System Partition») necesita ser formateada con un sistema de archivos FAT32 (sistemas de archivos distintos de FAT como ext2/3/4, reiserfs, NTFS, UDF etc. no son compatibles). Aunque las «EFI System Partition» (ESP) con tamaños de >=100 MiB y formateadas como FAT32 son permitidas por Microsoft Windows y algunas distribuciones Linux, la documentación de Microsoft especifica que el tamaño mínimo de la partición/volumen para el sistema de archivos FAT32 es de 512 MiB. Por lo tanto, una ESP debe tener, al menos, 512 MiB de tamaño para garantizar una máxima compatibilidad. Si está utilizando el arranque EFISTUB en Linux, entonces necesitará asegurarse de que tiene suficiente espacio disponible para guardar los archivos del Kernel y de Initramfs en la ESP.

Es recomendable usar siempre GPT para arrancar UEFI, ya que algunos firmwares de UEFI no permiten el arranque UEFI desde particionado MBR.

Discos particionados para GPT

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 mkfs.vfat -F32 /dev/<PARTICIÓN>

Si obtiene el mensaje WARNING: Not enough clusters for a 32 bit FAT!, reduzca el tamaño del cluster con la orden mkfs.vfat -s2 -F32 ... o -s1, de lo contrario la partición puede ser ilegible para UEFI.

Discos particionados para MBR

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 mkfs.vfat -F32 /dev/<PARTICIÓN>.

Shell de UEFI

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

Obtener la shell de UEFI

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

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

Lanzar la shell de UEFI

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

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

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

Órdenes importantes de la shell de UEFI

Las órdenes de la Shell de UEFI generalmente dan soporte a la opción -b que hace una pausa después de la salida de cada página. map que lista los sistemas de archivos reconocidos (fs0, ...) y los dispositivos de almacenamiento de datos (blk0, ...). 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 pdf «UEFI Shell Specification 2.0».

Nota:
  • Se recomienda probar bcfg únicamente si efibootmgr no puede crear entradas de inicio que funcionen en el propio sistema.
  • La versión 1 del binario oficial de la Shell de UEFI no proporciona soporte para la orden bcfg. Puede descargar una Shell de UEFI modificada que puede trabajar con firmwares pre-2.3 de UEFI.

Para conocer una lista de entradas de arranque actuales:

Shell> bcfg boot dump -v

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

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 \EFI\arch\refind\refindx64.efi es el archivo que se pondrá en marcha.

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, la primera 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

edit

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

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

Shell> fs0:
FS0:\> cd \EFI\arch\refind
FS0:\EFI\arch\refind\> edit refind.conf

Escriba Ctrl-E para obtener ayuda.

Compatibilidad de hardware

Véase el artículo HCL/Firmwares/UEFI

Soporte para arrancar UEFI

Crear un USB arrancable con UEFI desde la ISO

Nota: Las siguientes instrucciones son específicas para el soporte oficial Archiso; la preparación de Archboot es idéntica, con refind.conf, en lugar de la que se menciona a continuación (que es para Archiso) y sin el requisito de la etiqueta («label») del sistema de archivos.
  • 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 de Archiso. Obtener la etiqueta de /mnt/iso/loader/entries/archiso-x86_64.conf; esto es utilizado por el hook archiso en initramfs para identificar la ruta udev para el soporte de instalación. mkfs.vfat forma parte del paquete dosfstools.
    Nota: El sistema de archivos debe ser FAT32 (recomendado), FAT16, o FAT12.
    # awk 'BEGIN {FS="="} /archisolabel/ {print $3}' /mnt/iso/loader/entries/archiso-x86_64.conf | xargs mkfs.vfat -F32 /dev/sdXY -n
  • Monte la partición FAT32 del USB recién creada y copie el contenido del soporte de instalación al dispositivo USB.
    # mount /dev/sdXY /mnt/usb
    # cp -a /mnt/iso/* /mnt/usb
    # sync
    # umount /mnt/{usb,iso}

Eliminar el apoyo de arranque de UEFI desde la ISO

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.

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.

Monte el soporte de instalación oficial y obtenga la archisolabel como se muestra en la sección anterior.

Reconstruya la ISO usando xorriso desde libisoburn:

$ xorriso -as mkisofs -iso-level 3 \
    -full-iso9660-filenames\
    -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/"

Grabe ~/archiso.iso en el disco óptico y continúe con la instalación normalmente.

Probar UEFI en sistemas sin soporte nativo

OVMF para máquinas virtuales

OVMF [1] es un proyecto para activar la compatibilidad de UEFI para máquinas virtuales. OVMF contiene una muestra de firmware UEFI para QEMU.

Se puede compilar OVMF (con el apoyo de Secure Boot) con ovmf-svnAUR disponible en AUR y ejecutándolo como sigue:

qemu-system-x86_64 -enable-kvm -net none -m 1024 -bios /usr/share/ovmf/x86_64/bios.bin

DUET para sistemas únicamente BIOS

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 la BIOS UEFI está dando su apoyo CSM a este último (para arrancar particiones MBR) y por ello Windows no arranca. Para resolver este problema convierta el particionado de su disco MBR a GPT, o desactive el puerto SATA del disco duro cuando esté conectado, o bien, desenchufe el puerto SATA de este disco duro.

Placas base con este tipo de problema:

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.

Véase también