¿Cómo reinstalar el EFI de GRUB2?

• Arranque su computadora con un USB/CD en vivo en modo UEFI. Tenía dos opciones de arranque <flash_drive> y UEFI: <flash_drive>, la segunda es necesaria para exponer las variables efi en /sys/firmware/efi/ para que efibootmgr no falle más tarde. Arrancar con la primera opción me da el siguiente error:

• chroot en el sistema roto (similar a la ayuda de ubuntu grub2 pero con especificidades de efi):

• Dependiendo de tu distribución de linux, ahora haces cosas diferentes.

• Ahora teclea Ctrl+D para salir del chroot, desmontar todo y reiniciar:

Puede que necesites adaptar esto a tus necesidades (diferente tabla de particiones, partición separada /boot, etc.) y puede que no sea la única opción pero esto funcionó muy bien para mí.

Un sistema en vivo adecuado para arreglar cosas es grml . También hay una extensa guía sobre cómo configurar un dispositivo USB de arranque, de la cual la sección de Mac es la más útil en realidad (sólo crea una partición FAT32, copia los archivos, reinicia, listo).

Como con Maxine, encontré que la configuración de mi UEFI en el BIOS se dañó y mi máquina no arrancaba.

En mi caso, es un Lenovo ThinkServer RD430 con Linux Mint Debian y parecía que cualquier cosa que hiciera sobre actualizar-grub o cambiar cualquier disco duro en el servidor haría que no arrancara. El sistema operativo en mi caso es linuxmint-201403-mate-dvd-64bit instalado vía USB. (ver más abajo una descripción completa de los eventos que causarían que la UEFI no funcionara)

Pasar exactamente por los mismos pasos en un ThinkServer TS140 no hizo que la UEFI perdiera la cabeza ni una sola vez. Miré la página del controlador RD430 y mi biografía tiene dos versiones antiguas. Nunca he tenido que actualizar la biografía de una placa base antes, así que no soy de los que actualizan automáticamente cuando hay nuevas versiones disponibles. Después de actualizar la bios, la respuesta de Maxine anterior funcionó, sólo que con un giro…

# efibootmgr -c --disk /dev/sdX --part Y
# efibootmgr -v
BootCurrent: 0004
Timeout: 1 seconds
BootOrder: 0002,0000,0003,0001,0004
Boot0000* linuxmint HD(1,800,1f4000,829f6cc9-5b17-479c-b3ea-61e43faecbf7)File(\EFI\linuxmint\grubx64.efi)
Boot0001* LMDE Linux Mint Debian HD(1,800,15d505800,934c598c-fe3c-fd43-84a1-fa38e4f72552)File(\EFI\linuxmint\grubx64.efi)
Boot0002* Linux HD(1,800,1f4000,829f6cc9-5b17-479c-b3ea-61e43faecbf7)File(\elilo.efi)
Boot0003* UEFI: Built-in EFI Shell Vendor(5023b95c-db26-429b-a648-bd47664c8012,)AMBO
Boot0004* UEFI: VerbatimSTORE N GO 1.00 ACPI(a0341d0,0)PCI(1a,0)USB(1,0)USB(4,0)HD(1,80,1d70780,00000000)AMBO
mint / #

El comando efibootmgr -c añadió dos entradas 0000 y 0002! La entrada Boot0002* Linux HD primera en el orden de arranque no es correcta. La entrada 0000 es correcta.

Para probar esto, intenté arrancar sin ninguna interrupción, que es la entrada 0002. Como era de esperar, no funcionó. Así que reinicié el servidor, presioné F12, y elegí linuxmint. Como era de esperar, arrancó en mi instalación LMDE.

La forma de eliminar las entradas no deseadas a través de efibootmgr es:

# efibootmgr -b 2 -B

Utilicé este comando para eliminar las entradas 0001 y 0002. La opción 0001 fue el último de mis muchos intentos de recuperar el sistema operativo.

Notas de UEFI

Si estás leyendo esto y estás tan frustrado con UEFI como yo lo estoy/estaba, aquí hay algunas notas y recursos: “ Arrancar a UEFI Shell es similar a usar un shell de DOS. ” Intel hizo un PDF manual de referencia para efi comandos de shell.
“ El UEFI_on_TS430 document de Lenovo es el único recurso que he visto que explica el uso del shell de efi. ” Otra referencia del shell de la UEFI de nGuía del Administrador de Particiones. “ Puedes intentar arrancar a una partición desde el shell de efi navegando hasta el cargador y ejecutándolo.
” La UEFI quiere que el disco tenga una tabla de particiones GPT, no una tabla de partes msdos. “ La UEFI quiere que la primera partición de tu disco sea formateada fat32 o vfat. ” Para un arranque “genérico” debe haber un directorio /EFI/boot en la raíz con bootx64.efi en él. “ Algunas personas copian su grubx64.efi desde donde fue instalado a /EFI/boot/bootx64.efi y este engaño funcionó para ellos.
” Cada vez que hagas cambios en el grub, usa efibootmgr -v antes y después para asegurarte de que tu reinicio está bien.

Mi experiencia con el RD430

He restablecido el sistema operativo más de 10 veces en la última semana tratando de resolver esto y configurar el servidor. Mi configuración es un SSD en este controlador RAID en la ranura PCIe 2.0 con LMDE instalado. AOC-S3008L-L8i Controlador RAID reflejado en modo IT ) en la ranura del 2º PCIe 3.0 con 6 unidades de 3TB. RAM: 12GB ECC (3x 4GB).

Estos son los cambios que haría que mi sistema no se inicie: “ Cambiar las ranuras pci S3008L-L8i (dejando la tarjeta SSD+ solo).
” Deshabilitar el LSi software raid bios prompt para el controlador de a bordo. “ Agregar mi vieja tarjeta HighPoint RocketRaid a una ranura PCIe abierta. ” Hacer un cambio a /etc/default/grub y luego ejecutar update-grub. (quizás grub-install necesita ser ejecutado también?)

Votaría a favor de esto, pero parece que no tengo suficiente reputación en el Superusuario. Me alegro de haber encontrado una respuesta a esto después de días de luchar contra los clones que funcionaron pero que no se iniciaron. Creo que todo se relaciona con la UEFI y algún tipo de mecanismo de “arranque seguro” o algo así.

Estoy trabajando fuera de línea, así que apt-get no era una opción. Lo que hice fue poner Ubuntu Desktop en una memoria USB, añadir los paquetes grub-efi y grub-efi-amd64 a la raíz de la memoria USB (grub-efi_1.99~rc1-13ubuntu3_amd64.deb y grub-efi-amd64_1.99~rc1-13ubuntu3_amd64.deb para Ubuntu 11. 04 - cambiar como sea apropiado para la distro y la arquitectura), y poner lo siguiente en un script en la memoria USB también:

#! /bin/bash
sudo mount /dev/sda2 /mnt
sudo mount /dev/sda1 /mnt/boot/efi
dir=`dirname $0`
sudo cp $dir/grub-efi*.deb /mnt/tmp
for i in /dev /dev/pts /proc /sys; do sudo mount -B $i /mnt$i; done
sudo chroot /mnt /bin/sh -c "dpkg -i /tmp/grub-efi*.deb"
sudo shutdown -r now

Arrancar la memoria USB en vivo, abrir un terminal, ejecutar el comando, y el trabajo es un buen ‘un! El único problema ocasional es que la UEFI a veces se movía hacia abajo en el orden de prioridad de arranque debajo del disco duro, en cuyo momento tienes que ir a la BIOS y cambiar el orden de arranque para que deje de intentar (y fallar) en SATA: drive.

También puedes usar dpkg-reconfigure en lugar de dpkg -i, pero eso hace un par de preguntas del cargador de arranque.

[editar] Tampoco tengo suficiente representante para comentar, así que lo que pensé que era un comentario sobre una respuesta resulta ser una respuesta.

En mi Ubuntu 14 de 32 bits. 10 en Lenovo Yoga 2 Pro, cambié a UEFI boot así:

• crear carpeta

• montar la partición “EFI System” en /etc/fstab

• instalar grub-efi-amd64-bin y desinstalar grub-efi-ia32-bin

• reiniciar Ubuntu en modo efi

• probar si arranca bien, luego instalé grub-efi-amd64 y desinstalé grub-pc grub-gfxpayload-lists con

Elijo no quitar /boot cuando se me pide.

• *

Tal vez lo compliqué y esto habría funcionado bien:

apt-get install --reinstall grub-efi
update-grub

Esta entrada es más bien una preparación de su ordenador para reinstalar las entradas efi. También es lo que podría ser una forma efectiva y simple de crear un disco de rescate después de la instalación del sistema en los medios internos (SSD, HDD).

Con Linux Mint Tara (una variante de Linux estrechamente relacionada con Ubuntu Bionic Beaver), el método tanto me fastidió la instalación, como hizo posible guardarla más tarde. Surgió de mi deseo de que un USB en vivo tuviera persistencia, y como el tiempo para instalar una utilidad como Unetbootin para una instalación persistente es más o menos el mismo que el de una instalación nueva, simplemente usé la misma distribución en vivo para hacer una instalación en el USB que se usó para instalar el SO en el SSD interno.

Por supuesto, nada de esto es RAID o cualquier otra configuración especializada, pero requería una partición de volumen preparada en la unidad USB, y una instalación hecha en ese USB usando el método disponible de la distro, eludiendo la unidad interna para una instalación en el montaje raíz (/) de una sola partición.

Aquí es donde la nueva instalación grub se enredó con la unidad interna. Cuando reinicié en el USB, las entradas internas de la UEFI grub parecían haber desaparecido, dejando sólo el menú grub al intentar seleccionar la unidad usando las entradas del menú de la BIOS.

En su lugar, el arranque desde el USB mostró que el método de la distro había producido un menú grub ya preparado, con un listado para el /dev/sda2, la partición que contiene el montaje /boot/efi. En la mayoría de las unidades internas primarias se instala el nombre de la partición grub es hd0, gpt1.

Al entrar en ‘avanzado’, había disponible más de un rescate de kernel. A partir de ahí, ejecuta la utilidad grub y luego arranca normalmente.

A partir de este punto, ejecutando el SO en la unidad interna que antes era inaccesible, desenchufa el USB, luego ejecuta sudo grub-install.

Cuando reinicies sin el USB, deberías poder volver a entrar. En este punto, el USB está configurado para lanzar la unidad interna en modo normal o de rescate, y la unidad tiene su propio menú.