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

From ArchWiki
Jump to: navigation, search
(Arrancar un sistema operativo usando UEFI)
(QEMU con OVMF: Actualizar)
(22 intermediate revisions by the same user not shown)
Line 36: Line 36:
 
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.
 +
 
 +
{{Nota| En algunos sistemas UEFI el único camino posible para lanzar la aplicación UEFI en el arranque (si no tiene una entrada personalizada en el menú de inicio de UEFI) es ponerlo en un emplazamiento fijo: {{ic|<EFI SYSTEM PARTITION>/EFI/boot/bootx64.efi}} (para el sistema x86 de 64-bit)}}
  
 
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 más antiguos utilizan el firmware EFI i386, mientras que un sistema UEFI que no sea Apple, soporta el uso del firmware EFI i386.
Line 92: Line 94:
 
  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 técnico a 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}}. '''Efivarfs''' es preferible a la interfaz '''efivars sysfs''' (descrita a continuación). La opción de configuración siguiente está añadida en el kernel 3.10 y posterior.
 
+
  CONFIG_EFI_VARS=m
+
  
{{Nota|Esta opción está compilada como módulo en el kernel core/testing de Arch.}}
+
CONFIG_EFIVAR_FS=y
  
{{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.}}
+
Soporte técnico a 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 como {{ic|efibootmgr}}.
  
{{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.}}
+
CONFIG_EFI_VARS=m
 +
CONFIG_EFI_VARS_PSTORE=m
 +
CONFIG_EFI_VARS_PSTORE_DEFAULT_DISABLE=y
 +
 
 +
{{Nota|
 +
*Para que Linux pueda acceder a los servicios Runtime de UEFI, las arquitecturas del kernel de Linux y del Firmware de UEFI deben coincidir. Esto es independiente del gestor de arranque que se use.
 +
*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 [[GUID Partition Table (Español)|GPT]] (GUID Partition Table) de configuración para la tabla de particiones:  
 
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:  
Line 116: Line 122:
 
{{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.}}
 
{{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 {{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 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_VARS=y</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}} (para kernels >=3.8 a través de {{ic|/sys/firmware/efi/efivars}}). 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:
  
Muestra de salida (UEFI 2.3.1-x86_64 en Kernel x86_64):
+
Muestra de salida (UEFI 2.3.1-x86_64,firmware x86_64, volcado efivarfs):
 
   
 
   
  # ls -1 /sys/firmware/efi/vars/
+
  # ls -1 /sys/firmware/efi/efivars
  Boot0000-8be4df61-93ca-11d2-aa0d-00e098032b8c/
+
  AcpiGlobalVariable-af9ffd67-ec10-488a-9dfc-6cbf5ee22c2e
  BootCurrent-8be4df61-93ca-11d2-aa0d-00e098032b8c/
+
BGRTLogoIndex-9da5909e-ef5e-4851-8715-bf9e22b7a600
  BootOptionSupport-8be4df61-93ca-11d2-aa0d-00e098032b8c/
+
BmEssentialVariableNames-0b7646a4-6b44-4332-8588-c8998117f2ef
  BootOrder-8be4df61-93ca-11d2-aa0d-00e098032b8c/
+
Boot0001-8be4df61-93ca-11d2-aa0d-00e098032b8c
  ConIn-8be4df61-93ca-11d2-aa0d-00e098032b8c/
+
Boot0002-8be4df61-93ca-11d2-aa0d-00e098032b8c
  ConInDev-8be4df61-93ca-11d2-aa0d-00e098032b8c/
+
Boot0003-8be4df61-93ca-11d2-aa0d-00e098032b8c
  ConOut-8be4df61-93ca-11d2-aa0d-00e098032b8c/
+
Boot0004-8be4df61-93ca-11d2-aa0d-00e098032b8c
  ConOutDev-8be4df61-93ca-11d2-aa0d-00e098032b8c/
+
Boot0005-8be4df61-93ca-11d2-aa0d-00e098032b8c
  ErrOutDev-8be4df61-93ca-11d2-aa0d-00e098032b8c/
+
Boot0006-8be4df61-93ca-11d2-aa0d-00e098032b8c
  Lang-8be4df61-93ca-11d2-aa0d-00e098032b8c/
+
Boot0007-8be4df61-93ca-11d2-aa0d-00e098032b8c
  LangCodes-8be4df61-93ca-11d2-aa0d-00e098032b8c/
+
Boot0008-8be4df61-93ca-11d2-aa0d-00e098032b8c
  MTC-eb704011-1402-11d3-8e77-00a0c969723b/
+
Boot0009-8be4df61-93ca-11d2-aa0d-00e098032b8c
  MemoryTypeInformation-4c19049f-4137-4dd3-9c10-8b97a83ffdfa/
+
Boot000A-8be4df61-93ca-11d2-aa0d-00e098032b8c
  PlatformLang-8be4df61-93ca-11d2-aa0d-00e098032b8c/
+
Boot000B-8be4df61-93ca-11d2-aa0d-00e098032b8c
  PlatformLangCodes-8be4df61-93ca-11d2-aa0d-00e098032b8c/
+
Boot000C-8be4df61-93ca-11d2-aa0d-00e098032b8c
  RTC-378d7b65-8da9-4773-b6e4-a47826a833e1/
+
Boot000D-8be4df61-93ca-11d2-aa0d-00e098032b8c
  del_var
+
Boot000E-8be4df61-93ca-11d2-aa0d-00e098032b8c
  new_var
+
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
 +
BuildDate-e5bbf7be-2417-499b-97db-39f4896391bc
 +
BuildTime-e5bbf7be-2417-499b-97db-39f4896391bc
 +
  ConIn-8be4df61-93ca-11d2-aa0d-00e098032b8c
 +
  ConInDev-8be4df61-93ca-11d2-aa0d-00e098032b8c
 +
  ConOut-8be4df61-93ca-11d2-aa0d-00e098032b8c
 +
  ConOutDev-8be4df61-93ca-11d2-aa0d-00e098032b8c
 +
CpuProtocolSetupVar-7d4adce1-930d-40c7-9cd2-6d2148413dc7
 +
db-d719b2cb-3d3a-4596-a3bc-dad00e67656f
 +
dbx-d719b2cb-3d3a-4596-a3bc-dad00e67656f
 +
DIAGSPLSHSCRN-8be4df61-93ca-11d2-aa0d-00e098032b8c
 +
DptfProtocolSetupVar-1054354b-b543-4dfe-558b-a7ad6351c9d8
 +
  ErrOutDev-8be4df61-93ca-11d2-aa0d-00e098032b8c
 +
  FirmwarePerformanceDataTable-9dab39a4-3f8a-47ac-80c3-400729332c81
 +
HDDPWD-8be4df61-93ca-11d2-aa0d-00e098032b8c
 +
  iFfsData-f9f0b131-f346-4f16-80dd-f941072b3a7d
 +
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
 +
LBC-2a4dc6b7-41f5-45dd-b46f-2dd334c1cf65
 +
LBL-2a4dc6b7-41f5-45dd-b46f-2dd334c1cf65
 +
LBOL-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
 +
LenovoFlashScratch1-67c3208e-4fcb-498f-9729-0760bb4109a7
 +
LenovoHiddenSetting-1827cfc7-4e61-4273-b796-d35f4b0c88fc
 +
LenovoScratchData-67c3208e-4fcb-498f-9729-0760bb4109a7
 +
LenovoSecurityConfig-a2c1808f-0d4f-4cc9-a619-d1e641d39d49
 +
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
 +
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-4a67b082-0a4c-41cf-b6c7-440b29bb8c4f
 +
LocalSecurityVars-47355e9f-0857-45e1-8a6f-a4f5eda89a77
 +
LWO-2a4dc6b7-41f5-45dd-b46f-2dd334c1cf65
 +
MailBoxQ-67c3208e-4fcb-498f-9729-0760bb4109a7
 +
MeBiosExtensionSetup-1bad711c-d451-4241-b1f3-8537812e0c70
 +
  MemoryTypeInformation-4c19049f-4137-4dd3-9c10-8b97a83ffdfa
 +
MemoryTypeInformationBackup-4c19049f-4137-4dd3-9c10-8b97a83ffdfa
 +
MemRestoreVariable-608dc793-15de-4a7f-a0c5-6c29beaf5d23
 +
MTC-eb704011-1402-11d3-8e77-00a0c969723b
 +
OsIndications-8be4df61-93ca-11d2-aa0d-00e098032b8c
 +
OsIndicationsSupported-8be4df61-93ca-11d2-aa0d-00e098032b8c
 +
PbaStatusVar-0ec1a7f5-4904-40a0-8eab-4bcc4666da45
 +
PchInit-e6c2f70a-b604-4877-85ba-deec89e117eb
 +
PchS3Peim-e6c2f70a-b604-4877-85ba-deec89e117eb
 +
  PlatformLang-8be4df61-93ca-11d2-aa0d-00e098032b8c
 +
  PlatformLangCodes-8be4df61-93ca-11d2-aa0d-00e098032b8c
 +
  PlatformOpRomSetup-65827a61-99e2-4f07-a7aa-0b1f98edad39
 +
  ProtectedBootOptions-8be4df61-93ca-11d2-aa0d-00e098032b8c
 +
  PwdStatusVar-3e72b3ad-2b91-424a-ad73-c3270e91ed88
 +
SaPegData-c4975200-64f1-4fb6-9773-f6a9f89d985e
 +
SaPpiSetupVar-7da81437-866b-4143-8e08-a25c6ef0fa5b
 +
SaProtocolSetupVar-34f73d4d-963e-4c65-b3b3-515e720175d6
 +
SctHotkey-4650c401-93f1-4aeb-b87d-c8204c047dec
 +
SecureBoot-8be4df61-93ca-11d2-aa0d-00e098032b8c
 +
SecureBootOption-955b9041-133a-4bcf-90d1-97e1693c0e30
 +
Setup-4dfbbaab-1392-4fde-abb8-c41cc5ad7d5d
 +
SetupHotKey-8be4df61-93ca-11d2-aa0d-00e098032b8c
 +
SetupMode-8be4df61-93ca-11d2-aa0d-00e098032b8c
 +
SimpleBootFlag-8be4df61-93ca-11d2-aa0d-00e098032b8c
 +
SMBIOSELOG000-c3eeae98-23bf-412b-ab60-efcbb48e1534
 +
SMBIOSELOGNUMBER-c3eeae98-23bf-412b-ab60-efcbb48e1534
 +
SMBIOSMEMSIZE-c3eeae98-23bf-412b-ab60-efcbb48e1534
 +
TcgSetup-753ab903-444c-41f8-a235-569e8341147e
 +
Timeout-8be4df61-93ca-11d2-aa0d-00e098032b8c
 +
TpmAcpiData-6403753b-abde-4da2-aa11-6983ef2a7a69
 +
TpmSaveState-5e724c0c-5c03-4543-bcb6-c1e23de24136
  
 
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.
 
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 ===
+
=== Herramientas en el espacio de usuario ===
  
Existen algunas herramientas que permiten acceder/modificar las variables UEFI, como:
+
Existen algunas herramientas que permiten acceder/modificar las variables UEFI, como:  
  
# efibootmgr - Utilizada para crear/modificar las entradas de inicio del gestor de arranque de UEFI - {{Pkg|efibootmgr}} o {{AUR|efibootmgr-git}}
+
# efibootmgr - Herramienta para modificar las configuraciones del gestor de arranque del firmware de UEFI (actualmente solo admite sysfs-efivars) - {{Pkg|efibootmgr}} o {{AUR|efibootmgr-git}}
# uefivars - Simplemente accede a las variables - {{AUR|uefivars-git}} - utiliza la biblioteca efibootmgr.
+
# efivar - Herramienta y biblioteca para modificar las variables de UEFI (soporta tanto efivarfs como sysfs-efivars) - {{Pkg|efivar}} o {{AUR|efivar-git}}
# Firmware Test Suite de Ubuntu- fwts - {{AUR|fwts-git}} - la orden uefidump - {{ic|fwts uefidump}}  
+
# efitools - Herramientas para crear y configura los propios Certificados Secure Boot de UEFI, Claves y Binarios Firmados (requiere efivarfs) - {{AUR|efitools-git}}
 +
# uefivars - Simplemente accede al listado de las variables de EFI con alguna información adicional - utiliza la biblioteca de efibootmgr - {{AUR|uefivars-git}}
 +
# Suite de comprobación de firmware de Ubuntu - Ejecuta algunas pruebas relacionadas con el firmware, incluyendo códigos de prueba de variables de efi - {{AUR|fwts}} o {{AUR|fwts-git}}
  
 
=== Sistemas UEFI en no-Mac  ===
 
=== Sistemas UEFI en no-Mac  ===
Line 156: Line 287:
 
{{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}}.}}
 
{{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| 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}}.}}
+
{{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}}
 +
*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').
 +
*Si {{ic|efibootmgr}} no consigue crear la entrada de arranque, compruebe la existencia de archivos en {{ic|/sys/firmware/efi/efivars/dump-*}}; si existen, elimínelos, reinicie y vuelva a ejecutar {{ic|efibootmgr}} de nuevo. Si aún así no funciona, reintente {{ic|efibootmgr}} después de arrancar con {{ic|efi_no_storage_paranoia}} en los parámetros del kernel.
 +
*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.}}
  
 
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.
 
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.
Line 166: Line 301:
 
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?).
 
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» .
+
Compruebe si hay archivos en la carpeta ''/sys/firmware/efi/vars/'' (y /sys/firmware/efi/efivars/ para los kernel >=3.8). 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 {{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 ]].
 
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 ]].
  
{{Nota|Las siguientes órdenes utilizan el cargador de arranque {{pkg |gummiboot}} como ejemplo.}}
+
{{Nota|Las siguientes órdenes utilizan el cargador de arranque {{Pkg|refind-efi}} como ejemplo.}}
  
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).
+
Suponga 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}} and {{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 182: Line 317:
 
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 los paquetes {{Pkg|efibootmgr}}-0.6.0-3 y anteriores proporcionan 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 el 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 198: Line 333:
 
== 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|
 +
*UEFI System Partition y EFI System Partition (ESP) es lo mismo, esta terminología se utiliza indistintamente en algunos lugares.
 +
*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.
 +
*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 «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"'').}}
+
 
+
{{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 224: Line 360:
 
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 286: Line 423:
 
  FS0:\> cd \EFI\arch\refind
 
  FS0:\> cd \EFI\arch\refind
 
  FS0:\EFI\arch\refind\> edit refind.conf
 
  FS0:\EFI\arch\refind\> edit refind.conf
 +
 +
Escriba {{ic|Ctrl-E}} para obtener ayuda.
  
 
== Compatibilidad de Hardware ==
 
== Compatibilidad de Hardware ==
Line 293: Line 432:
 
== Crear un USB booteable de UEFI desde la ISO ==
 
== 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}}
+
{{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.}}
  
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.
+
* [[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).}}
  
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 la imagen ISO obtenida desde la [https://www.archlinux.org/download/ página de descargas de Arch Linux].
  
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 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.}}
# 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.
+
# mkfs.vfat -F32 /dev/sdXY -n ''label'' #Por ejemplo ARCH_201306
  
{{bc|1=<nowiki>
+
* Monte la partición FAT32 del USB recién creada y copie el contenido del soporte de instalación al dispositivo USB.
# mount /dev/sdb1 /mnt/usb
+
 
# cp -r /mnt/iso/* /mnt/usb
+
# mount /dev/sdXY /mnt/usb
# umount /mnt/{usb,iso}
+
# cp -a /mnt/iso/* /mnt/usb
# sync</nowiki>}}
+
# sync
 +
# umount /mnt/{usb,iso}
 +
 
 +
=== Reparar errores ===
 +
 
 +
Podemos encontrarnos el error: ''"No loader found. Configuration files in /loader/entries/*.conf are needed."'' Una posible solución es usar un gestor de arranque UEFI diferente al incluido, gummiboot.
 +
 
 +
Descargaremos [https://www.archlinux.org/packages/extra/any/refind-efi/download/ refind-efi pkg] y extraeremos el archivo {{ic|/usr/lib/refind/refind_x64.efi}} de dicho paquete para {{ic|(USB)/EFI/boot/bootx64.efi}} (sobrescribir o cambiar el nombre de cualquier archivo {{ic|(USB)/EFI/boot/bootx64.efi}} existente).
 +
 
 +
A continuación, copiaremos este texto a {{ic|EFI/boot/refind.conf}}. Nos aseguraremos de que la etiqueta (''label'') en la sección del menú de Arch ({{ic|ARCH_201302}} en este caso) coincide con el de su usb.
 +
 
 +
{{hc|refind.conf|<nowiki>
 +
timeout 5
 +
textonly
 +
 
 +
showtools about,reboot,shutdown,exit
 +
# scan_driver_dirs EFI/tools/drivers_x64
 +
scanfor manual,internal,external,optical
 +
 
 +
scan_delay 1
 +
dont_scan_dirs EFI/boot
 +
 
 +
max_tags 0
 +
default_selection "Arch Linux Archiso x86_64 UEFI USB"
 +
 
 +
menuentry "Arch Linux Archiso x86_64 UEFI USB" {
 +
  loader /arch/boot/x86_64/vmlinuz
 +
  initrd /arch/boot/x86_64/archiso.img
 +
  ostype Linux
 +
  graphics off
 +
  options "archisobasedir=arch archisolabel=ARCH_201302 add_efi_memmap"
 +
}
 +
 
 +
menuentry "UEFI x86_64 Shell v2" {
 +
  loader /EFI/shellx64_v2.efi
 +
  graphics off
 +
}
 +
 
 +
menuentry "UEFI x86_64 Shell v1" {
 +
  loader /EFI/shellx64_v1.efi
 +
  graphics off
 +
}
 +
</nowiki>}}
 +
 
 +
Ahora debería ser capaz de arrancar con éxito, y poder elegir qué EFI desea cargar.
  
 
== Eliminar el apoyo de arranque de UEFI desde la ISO ==
 
== Eliminar el apoyo de arranque de UEFI desde la ISO ==
Line 338: Line 519:
  
 
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.
 +
 +
== QEMU con OVMF ==
 +
 +
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 y KVM.
 +
 +
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
 +
 +
==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 14:49, 24 July 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 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.

Nota: En algunos sistemas UEFI el único camino posible para lanzar la aplicación UEFI en el arranque (si no tiene una entrada personalizada en el menú de inicio de UEFI) es ponerlo en un emplazamiento fijo: <EFI SYSTEM PARTITION>/EFI/boot/bootx64.efi (para el sistema x86 de 64-bit)

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

Soporte técnico a 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. Efivarfs es preferible a la interfaz efivars sysfs (descrita a continuación). La opción de configuración siguiente está añadida en el kernel 3.10 y posterior.

CONFIG_EFIVAR_FS=y

Soporte técnico a 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 como efibootmgr.

CONFIG_EFI_VARS=m
CONFIG_EFI_VARS_PSTORE=m
CONFIG_EFI_VARS_PSTORE_DEFAULT_DISABLE=y
Nota:
  • Para que Linux pueda acceder a los servicios Runtime de UEFI, las arquitecturas del kernel de Linux y del Firmware de UEFI deben coincidir. Esto es independiente del gestor de arranque que se use.
  • 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_VARS=y 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 (para kernels >=3.8 a través de /sys/firmware/efi/efivars). 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,firmware x86_64, volcado efivarfs):

# ls -1 /sys/firmware/efi/efivars
AcpiGlobalVariable-af9ffd67-ec10-488a-9dfc-6cbf5ee22c2e
BGRTLogoIndex-9da5909e-ef5e-4851-8715-bf9e22b7a600
BmEssentialVariableNames-0b7646a4-6b44-4332-8588-c8998117f2ef
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
BuildDate-e5bbf7be-2417-499b-97db-39f4896391bc
BuildTime-e5bbf7be-2417-499b-97db-39f4896391bc
ConIn-8be4df61-93ca-11d2-aa0d-00e098032b8c
ConInDev-8be4df61-93ca-11d2-aa0d-00e098032b8c
ConOut-8be4df61-93ca-11d2-aa0d-00e098032b8c
ConOutDev-8be4df61-93ca-11d2-aa0d-00e098032b8c
CpuProtocolSetupVar-7d4adce1-930d-40c7-9cd2-6d2148413dc7
db-d719b2cb-3d3a-4596-a3bc-dad00e67656f
dbx-d719b2cb-3d3a-4596-a3bc-dad00e67656f
DIAGSPLSHSCRN-8be4df61-93ca-11d2-aa0d-00e098032b8c
DptfProtocolSetupVar-1054354b-b543-4dfe-558b-a7ad6351c9d8
ErrOutDev-8be4df61-93ca-11d2-aa0d-00e098032b8c
FirmwarePerformanceDataTable-9dab39a4-3f8a-47ac-80c3-400729332c81
HDDPWD-8be4df61-93ca-11d2-aa0d-00e098032b8c
iFfsData-f9f0b131-f346-4f16-80dd-f941072b3a7d
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
LBC-2a4dc6b7-41f5-45dd-b46f-2dd334c1cf65
LBL-2a4dc6b7-41f5-45dd-b46f-2dd334c1cf65
LBOL-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
LenovoFlashScratch1-67c3208e-4fcb-498f-9729-0760bb4109a7
LenovoHiddenSetting-1827cfc7-4e61-4273-b796-d35f4b0c88fc
LenovoScratchData-67c3208e-4fcb-498f-9729-0760bb4109a7
LenovoSecurityConfig-a2c1808f-0d4f-4cc9-a619-d1e641d39d49
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
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-4a67b082-0a4c-41cf-b6c7-440b29bb8c4f
LocalSecurityVars-47355e9f-0857-45e1-8a6f-a4f5eda89a77
LWO-2a4dc6b7-41f5-45dd-b46f-2dd334c1cf65
MailBoxQ-67c3208e-4fcb-498f-9729-0760bb4109a7
MeBiosExtensionSetup-1bad711c-d451-4241-b1f3-8537812e0c70
MemoryTypeInformation-4c19049f-4137-4dd3-9c10-8b97a83ffdfa
MemoryTypeInformationBackup-4c19049f-4137-4dd3-9c10-8b97a83ffdfa
MemRestoreVariable-608dc793-15de-4a7f-a0c5-6c29beaf5d23
MTC-eb704011-1402-11d3-8e77-00a0c969723b
OsIndications-8be4df61-93ca-11d2-aa0d-00e098032b8c
OsIndicationsSupported-8be4df61-93ca-11d2-aa0d-00e098032b8c
PbaStatusVar-0ec1a7f5-4904-40a0-8eab-4bcc4666da45
PchInit-e6c2f70a-b604-4877-85ba-deec89e117eb
PchS3Peim-e6c2f70a-b604-4877-85ba-deec89e117eb
PlatformLang-8be4df61-93ca-11d2-aa0d-00e098032b8c
PlatformLangCodes-8be4df61-93ca-11d2-aa0d-00e098032b8c
PlatformOpRomSetup-65827a61-99e2-4f07-a7aa-0b1f98edad39
ProtectedBootOptions-8be4df61-93ca-11d2-aa0d-00e098032b8c
PwdStatusVar-3e72b3ad-2b91-424a-ad73-c3270e91ed88
SaPegData-c4975200-64f1-4fb6-9773-f6a9f89d985e
SaPpiSetupVar-7da81437-866b-4143-8e08-a25c6ef0fa5b
SaProtocolSetupVar-34f73d4d-963e-4c65-b3b3-515e720175d6
SctHotkey-4650c401-93f1-4aeb-b87d-c8204c047dec
SecureBoot-8be4df61-93ca-11d2-aa0d-00e098032b8c
SecureBootOption-955b9041-133a-4bcf-90d1-97e1693c0e30
Setup-4dfbbaab-1392-4fde-abb8-c41cc5ad7d5d
SetupHotKey-8be4df61-93ca-11d2-aa0d-00e098032b8c
SetupMode-8be4df61-93ca-11d2-aa0d-00e098032b8c
SimpleBootFlag-8be4df61-93ca-11d2-aa0d-00e098032b8c
SMBIOSELOG000-c3eeae98-23bf-412b-ab60-efcbb48e1534
SMBIOSELOGNUMBER-c3eeae98-23bf-412b-ab60-efcbb48e1534
SMBIOSMEMSIZE-c3eeae98-23bf-412b-ab60-efcbb48e1534
TcgSetup-753ab903-444c-41f8-a235-569e8341147e
Timeout-8be4df61-93ca-11d2-aa0d-00e098032b8c
TpmAcpiData-6403753b-abde-4da2-aa11-6983ef2a7a69
TpmSaveState-5e724c0c-5c03-4543-bcb6-c1e23de24136

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 en el espacio de usuario

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

  1. efibootmgr - Herramienta para modificar las configuraciones del gestor de arranque del firmware de UEFI (actualmente solo admite sysfs-efivars) - efibootmgr o efibootmgr-gitAUR
  2. efivar - Herramienta y biblioteca para modificar las variables de UEFI (soporta tanto efivarfs como sysfs-efivars) - efivar o efivar-gitAUR
  3. efitools - Herramientas para crear y configura los propios Certificados Secure Boot de UEFI, Claves y Binarios Firmados (requiere efivarfs) - efitools-gitAUR
  4. uefivars - Simplemente accede al listado de las variables de EFI con alguna información adicional - utiliza la biblioteca de efibootmgr - uefivars-gitAUR
  5. Suite de comprobación de firmware de Ubuntu - Ejecuta algunas pruebas relacionadas con el firmware, incluyendo códigos de prueba de variables de efi - fwtsAUR o fwts-gitAUR

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
  • 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').
  • Si efibootmgr no consigue crear la entrada de arranque, compruebe la existencia de archivos en /sys/firmware/efi/efivars/dump-*; si existen, elimínelos, reinicie y vuelva a ejecutar efibootmgr de nuevo. Si aún así no funciona, reintente efibootmgr después de arrancar con efi_no_storage_paranoia en los parámetros del kernel.
  • 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.

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/ (y /sys/firmware/efi/efivars/ para los kernel >=3.8). 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 refind-efi como ejemplo.

Suponga 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 and /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

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 los paquetes efibootmgr-0.6.0-3 y anteriores proporcionan 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 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\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:
  • UEFI System Partition y EFI System Partition (ESP) es lo mismo, esta terminología se utiliza indistintamente en algunos lugares.
  • 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.
  • 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 «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>

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.

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

Escriba Ctrl-E para obtener ayuda.

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, 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.
# mkdir -p /mnt/{usb,iso}
# mount -o loop archlinux-2013.06.01-dual.iso /mnt/iso
  • 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.
# mkfs.vfat -F32 /dev/sdXY -n label #Por ejemplo ARCH_201306
  • 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}

Reparar errores

Podemos encontrarnos el error: "No loader found. Configuration files in /loader/entries/*.conf are needed." Una posible solución es usar un gestor de arranque UEFI diferente al incluido, gummiboot.

Descargaremos refind-efi pkg y extraeremos el archivo /usr/lib/refind/refind_x64.efi de dicho paquete para (USB)/EFI/boot/bootx64.efi (sobrescribir o cambiar el nombre de cualquier archivo (USB)/EFI/boot/bootx64.efi existente).

A continuación, copiaremos este texto a EFI/boot/refind.conf. Nos aseguraremos de que la etiqueta (label) en la sección del menú de Arch (ARCH_201302 en este caso) coincide con el de su usb.

refind.conf
timeout 5
textonly

showtools about,reboot,shutdown,exit
# scan_driver_dirs EFI/tools/drivers_x64
scanfor manual,internal,external,optical

scan_delay 1
dont_scan_dirs EFI/boot

max_tags 0
default_selection "Arch Linux Archiso x86_64 UEFI USB"

menuentry "Arch Linux Archiso x86_64 UEFI USB" {
  loader /arch/boot/x86_64/vmlinuz
  initrd /arch/boot/x86_64/archiso.img
  ostype Linux
  graphics off
  options "archisobasedir=arch archisolabel=ARCH_201302 add_efi_memmap"
}

menuentry "UEFI x86_64 Shell v2" {
  loader /EFI/shellx64_v2.efi
  graphics off
}

menuentry "UEFI x86_64 Shell v1" {
  loader /EFI/shellx64_v1.efi
  graphics off
}

Ahora debería ser capaz de arrancar con éxito, y poder elegir qué EFI desea cargar.

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.

QEMU con OVMF

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

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

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