¿Cómo instalar Ubuntu 14.04 / 16.04 de 64 bits con una partición RAID 1 de arranque dual en un sistema UEFI / GPT?

22

Actualización: las preguntas y respuestas a continuación también se aplican a Ubuntu 16.04

Tengo una computadora con SSD duales y Win (7) preinstalada en otro disco. La preinstalación utiliza (U) arranque EFI / GPT. Quiero instalar el escritorio Ubuntu 14.04 de 64 bits en una partición raíz RAID1 en mis SSD y aún así puedo iniciar mi sistema Win7 de doble arranque. es posible?

Esta guía que usa el instalador de escritorio no funcionó, probablemente porque (implícitamente) asume el arranque de MBR. Tampoco lo hizo instalar la distribución del servidor , probablemente por la misma razón.

Niclas Börlin
fuente

Respuestas:

36

ACTUALIZACIÓN: He verificado que la descripción a continuación también funciona para Ubuntu 16.04. Otros usuarios han informado que trabajan en 17.10 y 18.04.1.

NOTA: Este CÓMO no le dará LVM. Si también desea LVM, intente instalar el escritorio Ubuntu 18.04 con RAID 1 y LVM en la máquina con UEFI BIOS .

¡Después de días de intentarlo, ahora tengo un sistema que funciona! En resumen, la solución consistió en los siguientes pasos:

  1. Arrancar usando un Ubuntu Live CD / USB.
  2. Particiona los SSD según sea necesario.
  3. Instalar paquetes faltantes (mdadm y grub-efi).
  4. Crea las particiones RAID.
  5. Ejecute el instalador de Ubiquity (pero no arranque en el nuevo sistema).
  6. Parchee el sistema instalado (initramfs) para habilitar el arranque desde una raíz RAID.
  7. Rellene la partición EFI del primer SSD con GRUB e instálela en la cadena de arranque EFI.
  8. Clone la partición EFI a la otra SSD e instálela en la cadena de arranque.
  9. ¡Hecho! Su sistema ahora tendrá redundancia RAID 1. Tenga en cuenta que no se necesita hacer nada especial después de, por ejemplo, una actualización del núcleo, ya que las particiones UEFI no se han tocado.

Un componente clave del paso 6 de la solución fue un retraso en la secuencia de arranque que, de lo contrario, me arrojó directamente al indicador GRUB (¡sin teclado!) Si faltaba alguno de los SSD.

COMO detallado

1. Arranque

Arranque con EFI desde la memoria USB. Exactamente cómo variará según su sistema. Seleccione Probar ubuntu sin instalar .

Inicie un emulador de terminal, por ejemplo, xtermpara ejecutar los siguientes comandos.

1.1 Iniciar sesión desde otra computadora

Mientras intentaba esto, a menudo me resultaba más fácil iniciar sesión desde otra computadora ya configurada. Esto simplifica cortar y pegar comandos, etc. Si desea hacer lo mismo, puede iniciar sesión a través de ssh haciendo lo siguiente:

En la computadora a configurar, instale el servidor openssh:

sudo apt-get install openssh-server

Cambia la contraseña. La contraseña predeterminada para el usuario ubuntuestá en blanco. Probablemente pueda elegir una contraseña de seguridad media. Se olvidará tan pronto como reinicie su nueva computadora.

passwd

Ahora puede iniciar sesión en la sesión en vivo de ubuntu desde otra computadora. Las siguientes instrucciones son para Linux:

ssh -l ubuntu <your-new-computer>

Si recibe una advertencia sobre un presunto ataque de hombre en el medio, debe borrar las teclas ssh utilizadas para identificar la nueva computadora. Esto se debe a que openssh-servergenera nuevas claves de servidor cada vez que se instala. El comando a usar generalmente se imprime y debería verse como

ssh-keygen -f <path-to-.ssh/known_hosts> -R <your-new-computer>

Después de ejecutar ese comando, debería poder iniciar sesión en la sesión en vivo de ubuntu.

2. Discos de partición

Borre las particiones viejas y los bloques de arranque. ¡Advertencia! ¡Esto destruirá los datos en sus discos!

sudo sgdisk -z /dev/sda
sudo sgdisk -z /dev/sdb

Cree nuevas particiones en la unidad más pequeña: 100M para ESP, 32G para RAID SWAP, resto para RAID root. Si su unidad sda es más pequeña, siga la Sección 2.1, de lo contrario, Sección 2.2.

2.1 Crear tablas de particiones (/ dev / sda es más pequeño)

Haz los siguientes pasos:

sudo sgdisk -n 1:0:+100M -t 1:ef00 -c 1:"EFI System" /dev/sda
sudo sgdisk -n 2:0:+32G -t 2:fd00 -c 2:"Linux RAID" /dev/sda
sudo sgdisk -n 3:0:0 -t 3:fd00 -c 3:"Linux RAID" /dev/sda

Copie la tabla de particiones a otro disco y regenere UUID únicos (en realidad regenerará UUID para sda).

sudo sgdisk /dev/sda -R /dev/sdb -G

2.2 Crear tablas de particiones (/ dev / sdb es más pequeño)

Haz los siguientes pasos:

sudo sgdisk -n 1:0:+100M -t 1:ef00 -c 1:"EFI System" /dev/sdb
sudo sgdisk -n 2:0:+32G -t 2:fd00 -c 2:"Linux RAID" /dev/sdb
sudo sgdisk -n 3:0:0 -t 3:fd00 -c 3:"Linux RAID" /dev/sdb

Copie la tabla de particiones a otro disco y regenere UUID únicos (en realidad regenerará UUID para sdb).

sudo sgdisk /dev/sdb -R /dev/sda -G

2.3 Crear sistema de archivos FAT32 en / dev / sda

Cree el sistema de archivos FAT32 para la partición EFI.

sudo mkfs.fat -F 32 /dev/sda1
mkdir /tmp/sda1
sudo mount /dev/sda1 /tmp/sda1
sudo mkdir /tmp/sda1/EFI
sudo umount /dev/sda1

3. Instalar paquetes faltantes

El Ubuntu Live CD viene sin dos paquetes clave; grub-efi y mdadm. Instalarlos (No estoy 100% seguro de que se necesite grub-efi aquí, pero para mantener la simetría con la próxima instalación, tráigalo también).

sudo apt-get update
sudo apt-get -y install grub-efi-amd64 # (or grub-efi-amd64-signed)
sudo apt-get -y install mdadm

Es posible que necesite en grub-efi-amd64-signedlugar de grub-efi-amd64si tiene habilitado el arranque seguro. (Ver comentario de Alecz.)

4. Crear las particiones RAID

Cree los dispositivos RAID en modo degradado. Los dispositivos se completarán más tarde. Crear un RAID1 completo a veces me dio problemas durante la ubiquityinstalación a continuación, no estoy seguro de por qué. (¿montar / desmontar? ¿formato?)

sudo mdadm --create /dev/md0 --bitmap=internal --level=1 --raid-disks=2 /dev/sda2 missing
sudo mdadm --create /dev/md1 --bitmap=internal --level=1 --raid-disks=2 /dev/sda3 missing

Verifique el estado de RAID.

cat /proc/mdstat

Personalities : [raid1] 
md1 : active raid1 sda3[0]
      216269952 blocks super 1.2 [2/1] [U_]
      bitmap: 0/2 pages [0KB], 65536KB chunk

md0 : active raid1 sda2[0]
      33537920 blocks super 1.2 [2/1] [U_]
      bitmap: 0/1 pages [0KB], 65536KB chunk

unused devices: <none>

Particionar los dispositivos md.

sudo sgdisk -z /dev/md0
sudo sgdisk -z /dev/md1
sudo sgdisk -N 1 -t 1:8200 -c 1:"Linux swap" /dev/md0
sudo sgdisk -N 1 -t 1:8300 -c 1:"Linux filesystem" /dev/md1

5. Ejecute el instalador

Ejecute el instalador ubicuo, excluyendo el gestor de arranque que fallará de todos modos . ( Nota : si ha iniciado sesión a través de ssh, es probable que desee ejecutar esto en su nueva computadora).

sudo ubiquity -b

Elija Algo más como el tipo de instalación y modifique el md1p1tipo ext4, formato: sí y punto de montaje /. La md0p1partición se seleccionará automáticamente como intercambio.

Tome una taza de café mientras termina la instalación.

Importante: Una vez que la instalación haya finalizado, seleccione Continuar probando ya que el sistema aún no está listo para arrancar.

Completa los dispositivos RAID

Adjunte las particiones sdb en espera al RAID.

sudo mdadm --add /dev/md0 /dev/sdb2
sudo mdadm --add /dev/md1 /dev/sdb3

Verifique que todos los dispositivos RAID estén bien (y opcionalmente sincronizados).

cat /proc/mdstat

Personalities : [raid1] 
md1 : active raid1 sdb3[1] sda3[0]
      216269952 blocks super 1.2 [2/1] [U_]
      [>....................]  recovery =  0.2% (465536/216269952)  finish=17.9min speed=200000K/sec
      bitmap: 2/2 pages [8KB], 65536KB chunk

md0 : active raid1 sdb2[1] sda2[0]
      33537920 blocks super 1.2 [2/2] [UU]
      bitmap: 0/1 pages [0KB], 65536KB chunk

unused devices: <none>

El proceso a continuación puede continuar durante la sincronización, incluidos los reinicios.

6. Configure el sistema instalado

Configure para habilitar chroot en el sistema de instalación.

sudo -s
mount /dev/md1p1 /mnt
mount -o bind /dev /mnt/dev
mount -o bind /dev/pts /mnt/dev/pts
mount -o bind /sys /mnt/sys
mount -o bind /proc /mnt/proc
cat /etc/resolv.conf >> /mnt/etc/resolv.conf
chroot /mnt

Configurar e instalar paquetes.

apt-get install -y grub-efi-amd64 # (or grub-efi-amd64-signed; same as in step 3)
apt-get install -y mdadm

Si sus dispositivos md aún se están sincronizando, es posible que vea advertencias ocasionales como:

/usr/sbin/grub-probe: warning: Couldn't find physical volume `(null)'. Some modules may be missing from core image..

Esto es normal y puede ignorarse (vea la respuesta al final de esta pregunta ).

nano /etc/grub.d/10_linux
# change quick_boot and quiet_boot to 0

La desactivación quick_bootevitará que las escrituras de Diskfilter no sean errores admitidos . La desactivación quiet_bootes solo de preferencia personal.

Modifique /etc/mdadm/mdadm.conf para eliminar cualquier referencia de etiqueta, es decir, cambiar

ARRAY /dev/md/0 metadata=1.2 name=ubuntu:0 UUID=f0e36215:7232c9e1:2800002e:e80a5599
ARRAY /dev/md/1 metadata=1.2 name=ubuntu:1 UUID=4b42f85c:46b93d8e:f7ed9920:42ea4623

a

ARRAY /dev/md/0 UUID=f0e36215:7232c9e1:2800002e:e80a5599
ARRAY /dev/md/1 UUID=4b42f85c:46b93d8e:f7ed9920:42ea4623

Este paso puede ser innecesario, pero he visto algunas páginas que sugieren que los esquemas de nomenclatura pueden ser inestables (name = ubuntu: 0/1) y esto puede evitar que un dispositivo RAID perfectamente fino se ensamble durante el arranque.

Modificar líneas /etc/default/grubpara leer

#GRUB_CMDLINE_LINUX_DEFAULT="quiet splash"
GRUB_CMDLINE_LINUX=""

De nuevo, este paso puede ser innecesario, pero prefiero arrancar con los ojos abiertos ...

6.1. Agregar script de sueño

(Se ha sugerido por la comunidad que este paso podría ser innecesario y puede ser reemplazado usando GRUB_CMDLINE_LINUX="rootdelay=30"en /etc/default/grub. Por razones que se explican en la parte inferior de este COMO, sugiero al palo con el guión del sueño a pesar de que es más feo que el uso de rootdelay. Por lo tanto, continuamos con nuestro programa regular ... )

Cree una secuencia de comandos que espere a que se instalen los dispositivos RAID. Sin este retraso, el montaje de la raíz puede fallar debido a que el ensamblado RAID no está terminado a tiempo . Descubrí esto de la manera difícil: ¡el problema no apareció hasta que desconecté uno de los SSD para simular la falla del disco! Puede que sea necesario ajustar el tiempo según el hardware disponible, por ejemplo, discos USB externos lentos, etc.

Ingrese el siguiente código en /usr/share/initramfs-tools/scripts/local-premount/sleepAwhile:

#!/bin/sh
echo
echo "sleeping for 30 seconds while udevd and mdadm settle down"
sleep 5
echo "sleeping for 25 seconds while udevd and mdadm settle down"
sleep 5
echo "sleeping for 20 seconds while udevd and mdadm settle down"
sleep 5
echo "sleeping for 15 seconds while udevd and mdadm settle down"
sleep 5
echo "sleeping for 10 seconds while udevd and mdadm settle down"
sleep 5
echo "sleeping for 5 seconds while udevd and mdadm settle down"
sleep 5
echo "done sleeping"

Haga que el script sea ejecutable e instálelo.

chmod a+x /usr/share/initramfs-tools/scripts/local-premount/sleepAwhile
update-grub
update-initramfs -u

7. Habilite el arranque desde el primer SSD

Ahora el sistema está casi listo, solo es necesario instalar los parámetros de arranque UEFI.

mount /dev/sda1 /boot/efi
grub-install --boot-directory=/boot --bootloader-id=Ubuntu --target=x86_64-efi --efi-directory=/boot/efi --recheck
update-grub
umount /dev/sda1

Esto instalará el gestor de arranque en /boot/efi/EFI/Ubuntu(también conocido como EFI/Ubuntuel /dev/sda1) e instalarlo por primera vez en la cadena de inicio UEFI en el equipo.

8. Habilite el arranque desde el segundo SSD

Ya casi hemos terminado. En este punto, deberíamos poder reiniciar en la sdaunidad. Además, mdadmdebería ser capaz de manejar la falla de la unidad sdao sdb. Sin embargo, el EFI no está RAID, por lo que debemos clonarlo .

dd if=/dev/sda1 of=/dev/sdb1

Además de instalar el cargador de arranque en la segunda unidad, esto hará que el UUID del sistema de archivos FAT32 en la sdb1partición (según lo informado por blkid) coincida con el de sda1y /etc/fstab. (Nota sin embargo, que los UUID para el /dev/sda1y /dev/sdb1particiones todavía será diferente - comparar ls -la /dev/disk/by-partuuid | grep sd[ab]1con blkid /dev/sd[ab]1después de la instalación para comprobar por sí mismo.)

Finalmente, debemos insertar la sdb1partición en el orden de arranque. (Nota: este paso puede ser innecesario, dependiendo de su BIOS. He recibido informes de que algunos BIOS 'generan automáticamente una lista de ESP válidos).

efibootmgr -c -g -d /dev/sdb -p 1 -L "Ubuntu #2" -l '\EFI\ubuntu\grubx64.efi'

No lo probé, pero probablemente sea necesario tener etiquetas únicas (-L) entre el ESP sday sdb.

Esto generará una copia impresa del orden de arranque actual, p. Ej.

Timeout: 0 seconds
BootOrder: 0009,0008,0000,0001,0002,000B,0003,0004,0005,0006,0007
Boot0000  Windows Boot Manager
Boot0001  DTO UEFI USB Floppy/CD
Boot0002  DTO UEFI USB Hard Drive
Boot0003* DTO UEFI ATAPI CD-ROM Drive
Boot0004  CD/DVD Drive 
Boot0005  DTO Legacy USB Floppy/CD
Boot0006* Hard Drive
Boot0007* IBA GE Slot 00C8 v1550
Boot0008* Ubuntu
Boot000B  KingstonDT 101 II PMAP
Boot0009* Ubuntu #2

Tenga en cuenta que Ubuntu # 2 (sdb) y Ubuntu (sda) son los primeros en el orden de arranque.

Reiniciar

Ahora estamos listos para reiniciar.

exit # from chroot
exit # from sudo -s
sudo reboot

El sistema ahora debería reiniciarse en Ubuntu (es posible que primero deba eliminar los medios de instalación de Ubuntu Live).

Después del arranque, puede ejecutar

sudo update-grub

para conectar el cargador de arranque de Windows a la cadena de arranque de grub.

Gotchas de máquinas virtuales

Si primero quiere probar esto en una máquina virtual, hay algunas advertencias: Aparentemente, la NVRAM que contiene la información UEFI se recuerda entre reinicios, pero no entre ciclos de apagado y reinicio. En ese caso, puede terminar en la consola UEFI Shell. Los siguientes comandos deberían iniciarlo en su máquina desde /dev/sda1(use FS1:for /dev/sdb1):

FS0:
\EFI\ubuntu\grubx64.efi

La primera solución en la respuesta superior del arranque UEFI en virtualbox: Ubuntu 12.04 también podría ser útil.

Simulando una falla de disco

Se puede simular la falla de cualquiera de los dispositivos de componentes RAID mdadm. Sin embargo, para verificar que las cosas de arranque sobrevivirían a una falla de disco, tuve que apagar la computadora y desconectar la alimentación de un disco. Si lo hace, primero asegúrese de que los dispositivos md estén sincronizados .

cat /proc/mdstat 

Personalities : [linear] [multipath] [raid0] [raid1] [raid6] [raid5] [raid4] [raid10] 
md1 : active raid1 sdb3[2] sda3[0]
      216269952 blocks super 1.2 [2/2] [UU]
      bitmap: 2/2 pages [8KB], 65536KB chunk

md0 : active raid1 sda2[0] sdb2[2]
      33537920 blocks super 1.2 [2/2] [UU]
      bitmap: 0/1 pages [0KB], 65536KB chunk

unused devices: <none>

En las instrucciones a continuación, sdX es el dispositivo fallido (X = aob) y sdY es el dispositivo correcto.

Desconectar una unidad

Apagar el equipo. Desconecte una unidad. Reiniciar. Ubuntu ahora debería arrancar con las unidades RAID en modo degradado. (¡Celebra! ¡Esto es lo que estabas tratando de lograr!;)

cat /proc/mdstat 

Personalities : [linear] [multipath] [raid0] [raid1] [raid6] [raid5] [raid4] [raid10] 
md1 : active raid1 sda3[0]
      216269952 blocks super 1.2 [2/1] [U_]
      bitmap: 2/2 pages [8KB], 65536KB chunk

md0 : active raid1 sda2[0]
      33537920 blocks super 1.2 [2/1] [U_]
      bitmap: 0/1 pages [0KB], 65536KB chunk

unused devices: <none>

Recuperarse de un disco fallido

Este es el proceso a seguir si ha necesitado reemplazar un disco defectuoso. Si desea emular un reemplazo, puede iniciar en una sesión de Ubuntu Live y usar

dd if=/dev/zero of=/dev/sdX

para limpiar el disco antes de reiniciar en el sistema real. Si acaba de probar la redundancia de arranque / RAID en la sección anterior, puede omitir este paso. Sin embargo, al menos debe realizar los pasos 2 y 4 a continuación para recuperar la redundancia de arranque / RAID completa para su sistema.

La restauración del sistema de arranque RAID + después de un reemplazo del disco requiere los siguientes pasos:

  1. Particionar el nuevo disco.
  2. Agregar particiones a dispositivos md.
  3. Clonar la partición de arranque.
  4. Agregue un registro EFI para el clon.

1. Particionar el nuevo disco

Copie la tabla de particiones de la unidad en buen estado:

sudo sgdisk /dev/sdY -R /dev/sdX

Vuelva a aleatorizar los UUID en la nueva unidad.

sudo sgdisk /dev/sdX -G

2. Agregar a dispositivos md

sudo mdadm --add /dev/md0 /dev/sdX2
sudo mdadm --add /dev/md1 /dev/sdX3

3. Clonar la partición de arranque

Clone el ESP del disco saludable. (Cuidado, tal vez primero haga un volcado a archivo de ambos ESP para permitir la recuperación si realmente lo arruina).

sudo dd if=/dev/sdY1 of=/dev/sdX1

4. Inserte el disco recién revivido en el orden de arranque

Agregue un registro EFI para el clon. Modifique la etiqueta -L según sea necesario.

sudo efibootmgr -c -g -d /dev/sdX -p 1 -L "Ubuntu #2" -l '\EFI\ubuntu\grubx64.efi'

¡Ahora, reiniciar el sistema debería volver a la normalidad (los dispositivos RAID aún pueden estar sincronizados)!

¿Por qué el script de sueño?

La comunidad ha sugerido que agregar un script de suspensión podría ser innecesario y podría reemplazarse usando GRUB_CMDLINE_LINUX="rootdelay=30"in /etc/default/grubseguido de sudo update-grub. Esta sugerencia es ciertamente más limpia y funciona en un escenario de falla / reemplazo del disco. Sin embargo, hay una advertencia ...

Desconecté mi segundo SSD y descubrí que con rootdelay=30, etc. en lugar del script de suspensión:
1) El sistema se inicia en modo degradado sin la unidad "fallida".
2) En el arranque no degradado (ambas unidades presentes), el tiempo de arranque se reduce. El retraso solo es perceptible si falta la segunda unidad.

1) y 2) sonaba genial hasta que volví a agregar mi segundo disco. En el arranque, la matriz RAID no pudo ensamblarse y me dejó en el initramfsindicador sin saber qué hacer. Podría haber sido posible salvar la situación a) iniciando en el dispositivo USB Live de Ubuntu, b) instalando mdadmyc) volviendo a ensamblar la matriz manualmente, pero ... Me equivoqué en alguna parte. En cambio, cuando me re-corrió esta prueba con el guión del sueño (sí, lo hice empezar el COMO de la parte superior, por enésima vez ...), el sistema hizo arranque. Los arreglos estaban en modo degradado y podía volver a agregar manualmente las /dev/sdb[23]particiones sin ninguna memoria USB adicional. No sé por qué funciona el script de sueño, mientras que el script rootdelayno funciona. Quizás mdadmse confunde con dos dispositivos de componentes ligeramente fuera de sincronización, pero pensémdadmfue diseñado para manejar eso. De todos modos, dado que el script de sueño funciona, me quedo con él.

Se podría argumentar que quitar un dispositivo componente RAID perfectamente sano, reiniciar el RAID en modo degradado y luego volver a agregar el dispositivo componente es un escenario poco realista: el escenario realista es más bien que un dispositivo falla y se reemplaza por uno nuevo , dejando menos oportunidades para mdadmconfundirse. Estoy de acuerdo con ese argumento. Sin embargo, no sé cómo probar cómo el sistema tolera una falla de hardware, ¡excepto para desactivar algo de hardware! Y después de las pruebas, quiero volver a un sistema redundante que funcione. (Bueno, podría conectar mi segundo SSD a otra máquina y deslizarlo antes de volver a agregarlo, pero eso no es factible).

En resumen: que yo sepa, la rootdelaysolución es limpia, más rápida que la secuencia de comandos de suspensión para botas no degradadas, y debería funcionar para un escenario real de falla / reemplazo de la unidad. Sin embargo, no conozco una forma factible de probarlo. Entonces, por el momento, me atendré al script de sueño feo.

Niclas Börlin
fuente
Nota 1: en caso de que accidentalmente inicie Windows durante su instalación y luego DHCP falle misteriosamente (me pasó a mí) cuando reinicia Ubuntu (en vivo o de otro modo), el apagado + reinicio de la computadora + enrutadores puede ayudar. Aparentemente, algunos enrutadores intentan ser "inteligentes" con respecto a las solicitudes recurrentes de DHCP que, por alguna razón, afectan a Ubuntu pero no a Windows ... suspiro
Niclas Börlin
1
Nota 2: aunque la secuencia de arranque instalada anteriormente sugiere que se usa el cargador de arranque en sdb, es posible que / boot / efi todavía esté montado desde sda ​​( mount | grep efi). Aparentemente, Linux monta la primera partición cuyos blkid coinciden /etc/fstab. Sin embargo, esto no debería ser un problema.
Niclas Börlin
Nota 3: Si por algún motivo terminara sin poder iniciar desde sus dispositivos md (por ejemplo, al estropear la recuperación de la partición de inicio en el paso 3 anterior), pude recuperar el acceso mediante el inicio utilizando los medios de Ubuntu Live seguidos de apt-get install mdadmy mdadm -A /dev/md0 mdadm -A /dev/md1.
Niclas Börlin
3
Sí. :) Así es como he configurado mi sistema.
Niclas Börlin
1
Tuve que instalarlo; de lo grub-efi-amd64-signedcontrario, obtengo un error efi de "firma no válida" si el arranque seguro estaba habilitado.
Alecz
0

Mi sugerencia es para el sistema operativo Debian, pero creo que funcionaría también para Ubuntu y otros.

Una posible forma de resolver un problema que ocurre con muchas placas base que no manejan correctamente las entradas UEFI (Debian no arranca incluso si realizó la entrada correcta efibootmgr -c -g -d /dev/sda -p 1 -w -L "debian" -l /EFI/debian/grubx64.efi, UEFI BIOS muestra un disco de arranque "debian" pero no arranca desde él ), es utilizar en su lugar la entrada genérica /boot/efi/EFI/boot/bootx4.efi.

Por ejemplo, a Asus Z87C no le gusta /EFI/debian/grubx64.efi.

Entonces, si montó la partición efi /dev/sda1en la /boot/efiruta:

mkdir /boot/efi/EFI/boot
cp /boot/efi/EFI/debian/grubx64.efi /boot/efi/EFI/boot/bootx4.efi

Luego reiniciar.

UEFI BIOS verá un disco genérico "UEFI OS", y también cualquier otra entrada creada previamente con efibootmgr, pero se iniciará desde el genérico "UEFI OS" sin ningún problema.

Nicola Giampietro
fuente