Deseamos compartirte la mejor información que hemos encontrado en internet. Nuestro deseo es que te sea útil y si quieres comentarnos cualquier detalle que nos pueda ayudar a perfeccionar nuestra información hazlo con total libertad.
Solución:
En EFI, los cargadores de arranque se almacenan como archivos en la partición del sistema EFI (ESP). Por lo general, estos archivos tienen nombres que son exclusivos del sistema operativo, como EFI/ubuntu/grubx64.efi para Ubuntu. Por este hecho, los cargadores de arranque deben registrarse en la NVRAM del firmware. El instalador de Ubuntu hace esto cuando el sistema operativo está instalado, pero cuando mueve el disco a otra computadora, su NVRAM tiene no ha sido modificado, por lo que la computadora no arrancará. El uso de Boot Repair instalará una copia nueva de GRUB y la registrará con el firmware, solucionando así el problema. Supongo que el propio administrador de arranque de su firmware hace un escaneo y también registra el cargador de arranque, pero podría ser que algo más esté sucediendo.
Una posible solución a este problema es copiar GRUB de EFI/ubuntu/grubx64.efi a EFI/BOOT/bootx64.efi. Este último es un nombre alternativo: la computadora arranca desde ese nombre si no puede encontrar ningún cargador de arranque registrado. Los medios extraíbles también usan el mismo nombre de archivo, ya que obviamente, un disco de instalación del sistema operativo no puede registrarse previamente a menos que use un nombre común acordado. Es posible que Ubuntu y / o Boot Repair también hayan copiado GRUB a este nombre, que su firmware no lo detectó inicialmente por alguna razón, y que el uso del administrador de arranque del firmware hizo que notara la presencia de este archivo, lo que explica la capacidad de arranque después de usaste esa herramienta. De hecho, parece más probable que su firmware haya escaneado el nombre de archivo del cargador de arranque predeterminado de Ubuntu.
Curiosamente, el problema se resolvió solo cuando abrí el administrador de arranque UEFI (F2 durante el arranque) y restablecí los valores predeterminados de fábrica.
Supongo que en algún momento habilité el “arranque rápido” o alguna característica similar que deshabilitó la búsqueda de particiones de arranque UEFI “no registradas”. Corriendo grub-update (que invoca efibootmgr) esencialmente registra GRUB con el administrador de arranque UEFI para que no tenga que buscarlo, pero dado que este comando aún no se ha ejecutado en las máquinas clonadas, efibootmgr no se ha ejecutado y, por lo tanto, la instalación de GRUB no estará en la lista del administrador de arranque.
La respuesta de Jon Gjensget dice amablemente:
Corriendo
grub-update(que invocaefibootmgr) esencialmente registra GRUB con el administrador de arranque UEFI
Pero luego omite cómo ejecutar realmente efibootmgr. No quiero tener que desbloquear el disco encriptado, montar todas las cosas correctas como / dev, / boot, / boot / efi. etc., chroot, y finalmente poder ejecutar grub-update, si puedo ejecutar efibootmgr, especialmente porque el disco está ahora en un buen estado conocido (restaurado desde la copia de seguridad) y no quiero esperar otras dos horas para volver a crear una imagen si estropeo el arranque.
Corriendo cd /boot/efi/EFI; cp -r ubuntu BOOT como se sugirió en los comentarios no funcionó para mí, aunque también me encuentro con el problema en un Intel NUC.
Boot-repair tampoco funcionó para mí: el botón de reparación como se muestra en las capturas de pantalla no está allí, y en las opciones avanzadas no hay ninguna opción para ejecutar efibootmgr, parece que es solo un botón de GUI para ejecutar grub-update (y muchas otras herramientas como fsck) en lugar de arreglar el arranque por sí mismo.
Este es el comando que funcionó para mí (ejecutar desde un dispositivo de arranque en vivo):
efibootmgr -c -g -d /dev/sda -p 1 -w -L "myboot" -l 'EFIubuntugrubx64.efi'
efibootmgr # to verify it's in the boot options list
efibootmgr -n [ID HERE] # to make sure it boots that option next time
El -n [ID] no resultó ser necesario, arrancó esa opción cada vez después de crearla (no había otras opciones de arranque que funcionen de todos modos, por lo que estoy confundido por qué no intenta arrancar desde la única opción de arranque posible en primer lugar….).
Las opciones utilizadas son:
-ccrear una nueva opción de arranque-gforzarlo a tratar el disco como GPT (no estoy seguro de si esto es necesario, no lo probé sin esta opción)-dque dispositivo usar, en mi caso/dev/sda-pel número de partición que contiene su carpeta de arranque EFI y.efiarchivo de arranque, en mi caso el dispositivo fue/dev/sda1(aFAT32partición) por lo que el número de partición es1-w“escriba una firma única en el MBR si es necesario” (no sé si es necesario)-Lun nombre de su elección, elegí un nombre que es único para mí para poder reconocerlo más tarde-lcamino a tu.efiarchivo que desea usar para arrancar, supongo que para grub en x86_64 esto siempre esEFI...grubx64.efiy el...depende de su distribución. Puede encontrar la ruta correcta en la partición (previamente especificada por-dy-p), y normalmente se monta en/boot/efipara que puedas mirar adentro/boot/efi/EFIcuál es el nombre del directorio dondegrubx64.efise encuentra.
Fuente: https://bbs.archlinux.org/viewtopic.php?id=160757 – este es simplemente el primer comando en el hilo. Las respuestas dan más sugerencias, pero el primer comando funcionó para mí.
Comentarios y puntuaciones del artículo
Recuerda difundir esta reseña si lograste el éxito.