Unified Extensible Firmware Interface (Español)

From ArchWiki
Revision as of 21:01, 17 March 2013 by Pedro (Talk | contribs) (Crear una «UEFI System Partition» en Linux)

Jump to: navigation, search

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

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

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.

Si la lista de dispositivos de arranque comienza con una unidad de CD/DVD, entonces la entrada de 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.

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.

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.

Arrancar un sistema operativo usando 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.

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.

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.

Nota: Algunas unidades antiguas de las placas Intel Server se sabe que operan en Intel EFI firmware 1.10, y requieren aplicaciones EFI i386.

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.

Multiarranque en 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.

Multiarranque de Linux/Windows x86_64 en UEFI con GPT

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

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.

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.
  3. 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).
  4. 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.
  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.

Detectar la arquitectura del firmware UEFI

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).

Algunos de los conocidos firmwares UEFI 2.x para la arquitectura x86_64 son Phoenix SecureCore Tiano, Aptio AMI, Insyde H2O.

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.

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 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 de Apple del firmware EFI no es totalmente compatible con la especificación UEFI.

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

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.

 CONFIG_EFI_VARS=m
Nota: Esta opción está compilada como módulo en el kernel core/testing de Arch.
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.
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.

Para la compatibilidad con UEFI es necesaria la opción GPT (GUID Partition Table) de configuración para la tabla de particiones:

 CONFIG_EFI_PARTITION=y
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.

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 .

Apoyo de las variables de UEFI

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.

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.

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 CONFIG_EFI_VAR=m de configuración del kernel. Con este módulo, una vez cargado, se garantiza el acceso a las variables presentes en el directorio /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 /sys/firmware/efi/vars con debería tener un contenido similar a este:

Muestra de salida (UEFI 2.3.1-x86_64 en Kernel x86_64):

# 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.

Herramientas del espacio de usuario

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

  1. efibootmgr - Utilizada para crear/modificar las entradas de inicio del gestor de arranque de UEFI - efibootmgr o efibootmgr-gitAUR
  2. uefivars - Simplemente accede a las variables - uefivars-gitAUR - utiliza la biblioteca efibootmgr.
  3. Firmware Test Suite de Ubuntu- fwts - fwts-gitAUR - la orden uefidump - fwts uefidump

Sistemas UEFI en no-Mac

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: La orden 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 Fatal: Couldn't open either sysfs or procfs directories for accessing EFI variables.
Nota: 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 tiene una opción llamada "Add New Boot Option" («Añadir nueva opción de arranque») que permite seleccionar una partición de sistema EFI local e introducir manualmente la ubicación del código de EFI (por ejemplo '\EFI\refind\refind_x64.efi')

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

Para utilizar efibootmgr, primero cargue el módulo del kernel «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?).

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» .

Si la carpeta /sys/firmware/efi/vars/ está vacía o no existe, entonces la orden 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 .

Nota: Las siguientes órdenes utilizan el cargador de arranque gummiboot como ejemplo.

Tango-view-refresh-red.pngThis article or section is out of date.Tango-view-refresh-red.png

Reason: Gummiboot tiene su propio instalador ahora, por lo que las instrucciones siguientes no se debe utilizar para instalar gummiboot. Este ejemplo debería ser cambiado para usar otro supuesto. (Discuss in Talk:Unified Extensible Firmware Interface (Español)#)

Suponga que el archivo boot-loader para ser lanzado es boot/efi/EFI/gummiboot/gummibootx64.efi. El mismo /boot/efi/EFI/gummiboot/gummibootx64.efi puede ser dividido en /boot/efi y /EFI/gummiboot/gummibootx64.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

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'

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

UEFI utiliza barra diagonal invertida (\) como separador de ruta (similar a las rutas de Windows).

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 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\gummiboot\gummibootx64.efi o \efi\gummiboot\gummibootx64.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: UEFI System Partition y EFI System Partition (ESP) es lo mismo, esta terminología se utiliza indistintamente en algunos lugares.
Nota: La partición UEFISYS puede ser de cualquier tamaño con el apoyo del sistema de archivos FAT32. Según la documentación de Microsoft, el tamaño mínimo de la partición/volumen para el sistema de archivos FAT32 es de 512 MiB. Por ello es recomendable que la partición UEFISYS sea, al menos, de 512 MiB. Tamaños mayores quizás sean más aconsejables, sobre todo si se utilizan varios gestores de arranque UEFI, o arranques de múltiples sistemas operativos a través de UEFI, a fin de que haya suficiente espacio en la partición para guardar todos los archivos relacionados. Si está utilizando el arranque EFISTUB en Linux, entonces necesita asegurarse que hay suficiente espacio disponible para mantener el Kernel y los archivos initramfs en la partición UEFISYS.
Nota: El ESP debe estar fuera de LVM o cualquier otro RAID software o sistemas RAID. ESP debe ser accesible por el firmware UEFI, el cual no puede leer LVM y sistemas similares.
Nota: Si utilizamos el arranque EFISTUB de Linux, entonces necesitaremos asegurarnos de que hay suficiente espacio disponible para mantener el Kernel y los archivos initramfs en la partición UEFISYS.

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>
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").
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

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>
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

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

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

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.
Nota: La Shell 1.0 de UEFI no es compatible con la orden bcfg.

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\arch\refind\refindx64.efi "Arch Linux (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 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

Compatibilidad de Hardware

Página principal HCL/Firmwares/UEFI

Crear un USB booteable de UEFI desde la ISO

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

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.

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.

Monte el medio de instalación y cree un sistemas de archivos FAT con la etiqueta utilizada en la configuración de Archiso.

# 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

Monte el sistema de archivos FAT recién creado y copie los contenidos del soporte de instalación al dispositivo USB.

# mount /dev/sdb1 /mnt/usb
# cp -r /mnt/iso/* /mnt/usb
# umount /mnt/{usb,iso}
# sync

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.

Véase también