☰

Arrancar el kernel desde UEFI directamente

tag-icon • tag-icon arch-linux kernel boot uefi
Arrancar el kernel desde UEFI directamente

Quiero iniciar Arch Linux directamente desde UEFI.

Mi idea es crear una entrada de arranque usando la herramienta efibootmgr; Usé este comando:

efibootmgr --create --label "arch-test" --loader /vmlinuz-linux --unicode 'root=PARTUUID=f2083749-8bbc-570b-ab3b-e79d72fa08ac rw initrd=\initramfs-linux.img' --verbose

Seguíla página Arch Wiki en EFISTUBy creé la entrada, pero cuando intento arrancar desde allí, el sistema se atascó al arrancar en una etapa muy temprana con este mensaje:

VFS: unable to mount root fs on unknown-block(0,0)

PD: Quiero que esto funcione como herramienta de emergencia/rescate; es decir, la última systemdactualización interrumpe el administrador de arranque (systemd-boot) e inutiliza mi máquina; He podido recuperar mi sistema gracias a un USB externo en vivo. ¡Quiero EVITAR esto en el futuro!

ACTUALIZACIONES:
1. tener o no/barra o barra invertida, antes initrdno importa
2. intenté con ambos UUIDy PARTUUID, nada cambia
3. mi /bootestá encendido /dev/sda1mientrasraízen /dev/sda3
4. y /bootes ESP, también

    # fdisk -l /dev/sda
    [...]
    Disklabel type: gpt
    [...]

    Device         Start       End   Sectors   Size Type
    /dev/sda1       2048   2099199   2097152     1G EFI System
    /dev/sda2    2099200  18874367  16775168     8G Linux swap
    /dev/sda3   18874368 104857599  85983232    41G Linux filesystem
    [...]
    # minfo -i /dev/sda1 :: | grep 'disk type'
    disk type="FAT32   "

  1. siguiendo tus comentarios, lo intentéCarcasa UEFI. Dejé esta opción como más reciente ya que mi máquina no tiene un UEFI Shell interno (¿Es posible?). De todos modos tengo:

    • descargué uno detiancore
    • colocado Shell.efien/boot/EFI/Boot/

    • agregó una entrada con

      efibootmgr --create --label "TIANO-0" --loader /EFI/Boot/Shell.efi --verbose

    • reiniciado en este Shell, escribí fs0:yvmlinuz-linux root=/dev/sda3

    • resultando en el mismo error:

      VFS: unable to mount root fs on unknown-block(0,0)

  2. parece que initrdes obligatorio (al menos para Arch Linux);
    el comando vmlinuz-linux initrd=initramfs-linux.img root=/dev/sda3hace la magia

  3. Mi sistema es una computadora portátil Dell XPS 9343 y descubrí que sufre un error: no puedo iniciar EFISTUB, informado en ArchWikiaquí.
    Creo que explica elfalladel procedimiento correcto (primero mencionado)!
    La página de ArchWiki también sugiere una solución alternativa, pero por el momento la he probado.

Respuesta1

   -l | --loader NAME
              Specify a loader (defaults to \\elilo.efi)

Un kernel con EFI-stub todavía no es uncargador. Para arrancar desde BIOS tiene que ser un EFI-solicitud. Todos los cargadores de arranque tienen el sufijo .EFI. Creo que es posible convertir un kernel en un objeto de arranque directo, pero normalmente es uno de los cargadores de arranque el que se inicia (con o sin opción).

Pero puedes usarCarcasa UEFI(en sistemas modernos) como cargador de arranque interactivo. Esto es perfecto para realizar pruebas. Lo activas como un dispositivo de arranque en BIOS, cda fs0:, que es el ESP, y luego puedes

fs0:> bzImage root=/dev/sda3

Acabo de compilar un primer bzImage hace unos días. Primero olvidé CONFIG_EFI_STUB y el shell UEFI trató el kernel como no binario. Arrancó una segunda versión, sin ningún archivo initrd=. Además de EFI_STUB=y, simplemente desactivé algunas opciones y mantuve los valores predeterminados.

Pero es cierto que la mayoría de las distribuciones tienen núcleos que no lo hacen.notienen los controladores de dispositivo de bloque básicos; necesitan la initrd=IMAGEopción.

Utilizo Uefi Shell como mi cargador de arranque. Esto no es muy elegante, pero sí muy simple y flexible. Y como opción de emergencia creo que es perfecta, porque Uefi Shell está integrado, mientras que se puede eliminar un cargador de arranque en una partición.

Esto es deDocumentación/efi-stub.txt

> Passing kernel parameters from the EFI shell
> --------------------------------------------
> 
> Arguments to the kernel can be passed after bzImage.efi, e.g.::
> 
>     fs0:> bzImage.efi console=ttyS0 root=/dev/sda4

Tengo el mismo mensaje de Uefi Shell fs0:>, pero descubrí que todas las distribuciones habituales tienen núcleos EFI_STUB y el nombre no importa en absoluto. El más común es "vmlinuz" (= cargador alrededor de un vmlinux comprimido).

Si dejas de lado la opción ".efi" y "console=", queda esto:

fs0:> bzImage root=/dev/sda4

Que es el mismo comando de arranque mínimo, excepto que tengo sda3: Uefi Shell inicia bzImage mediante stub, el kernel se descomprime y se inicia y los módulos integrados reconocen el disco SATA. Si el root=dispositivo no es válido, te entra el VFS: unable to mountpánico.

No pude iniciar bzImage (o vmlinuz, o ...) directamente desde BIOS, como grub64.EFI.

UEFI - Aplicaciones (wikipedia):

Más allá de cargar un sistema operativo, UEFI puede ejecutar aplicaciones UEFI, que residen como archivos en la partición del sistema EFI. Se pueden ejecutar desde el shell de comandos UEFI,por el administrador de arranque del firmware, o por otras aplicaciones UEFI. Las aplicaciones UEFI se pueden desarrollar e instalar independientemente del fabricante del sistema.

Un tipo de aplicación UEFI es un cargador de sistema operativo como GRUB, rEFInd, Gummiboot y Windows Boot Manager; que carga un archivo del sistema operativo en la memoria y lo ejecuta. Además, un cargador de sistema operativo puede proporcionar una interfaz de usuario para permitir la selección de otra aplicación UEFI para ejecutar. Utilidades como el shell UEFI también son aplicaciones UEFI..

Esto confirma mi opinión de que UEFI Shell se encuentra entre el cargador de arranque del firmware y el kernel.

Gentoo tiene ejemplos similares; insisten en nombrar el kernel con el sufijo .EFI.

Si por alguna razón se necesita un initramfs, puede integrarse en el kernel o usarse como un archivo separado.

...

Sin embargo, algunas implementaciones UEFIParece que no admite el paso de parámetros.desde la NVRAM al kernel stub de EFI.

Respuesta2

Parece que algunas máquinas más antiguas con firmware UEFI más antiguo no pasan argumentos de línea de comando a los archivos binarios de EFI (como un kernel de Linux habilitado para EFISTUB). Esto hace que sea imposible pasar parámetros importantes como root=y initrd=al kernel en el momento del arranque.

He utilizado exactamente el mismo procedimiento para iniciar el kernel directamente desde UEFI (específicamente, el que se describe enhttps://wiki.debian.org/EFIStub, pero en realidad lo estaba haciendo en Ubuntu) en dos máquinas diferentes. En mi placa base ASrock de tres años, funcionó perfectamente. En mi computadora portátil Dell de once años, simplemente ignora los argumentos de la línea de comando del kernel.

Entonces, si su firmware no admite argumentos de línea de comando, es posible que no tenga suerte. Seguiré intentándolo y publicaré un seguimiento si encuentro una solución.

información relacionada