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

Actualización: la pregunta y la respuesta a continuación también se aplican a Ubuntu 16.04

Tengo una computadora con SSD dobles y Win (7) preinstalado en otro disco. La preinstalación utiliza (U) EFI / GPT boot. Quiero instalar el escritorio de Ubuntu 14.04 de 64 bits en una partición RAID1 en mis SSD y aún así poder iniciar de forma dual mi sistema Win7. es posible?

Esta guía que utiliza el instalador de escritorio no funcionó, probablemente porque (implícitamente) supone el inicio de MBR. Tampoco se instaló la distribución del servidor , probablemente por el mismo motivo.

ACTUALIZACIÓN: he verificado que la siguiente descripción también funciona para Ubuntu 16.04. Otros usuarios han reportado trabajar 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 BIOS UEFI en su lugar.

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

  1. Arranque usando un Ubuntu Live CD / USB.
  2. Particiones de los SSD según sea necesario.
  3. Instala los 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. Parche 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 es necesario hacer nada especial después de, por ejemplo, una actualización del kernel, ya que las particiones UEFI están intactas.

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

COMO detallado

1. Arrancar

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

Inicie un emulador de terminal, por ejemplo, xterm para ejecutar los comandos a continuación.

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 que ya estaba completamente configurada. Este comando simplificado para cortar y pegar de comandos, etc. Si desea hacer lo mismo, puede iniciar sesión a través de ssh haciendo lo siguiente:

En la computadora que se configurará, instale el servidor openssh:

 sudo apt-get install openssh-server 

Cambia la contraseña. La contraseña predeterminada para el usuario ubuntu está en blanco. Probablemente puede elegir una contraseña de fuerza media. Será olvidado tan pronto como reinicies tu nueva computadora.

 passwd 

Ahora puede iniciar sesión en la sesión en vivo de Ubuntu desde otra computadora. Las instrucciones a continuación son para linux:

 ssh -l ubuntu  

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

 ssh-keygen -f  -R  

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

Borrar cualquier partición antigua y bloques de arranque. ¡Advertencia! ¡Esto destruirá los datos en tus 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, rest para RAID root. Si su unidad sda es más pequeña, siga la Sección 2.1, de lo contrario, la Sección 2.2.

2.1 Crear tablas de partición (/ 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 los UUID únicos (en realidad regenerará los UUID para sda).

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

2.2 Crear tablas de partición (/ 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 los UUID únicos (en realidad regenerará los UUID para sdb).

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

2.3 Crear un sistema de archivos FAT32 en / dev / sda

Crear 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 los paquetes que faltan

El Ubuntu Live CD viene sin dos paquetes clave; grub-efi y mdadm. Instalarlos (No estoy 100% seguro de que se necesita grub-efi aquí, pero para mantener la simetría con la próxima instalación, tráigala 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 grub-efi-amd64-signed lugar de grub-efi-amd64 si tiene habilitado el inicio seguro. (Ver comentario de Alecz.)

4. Crea las particiones RAID

Crea 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 instalación de ubiquity continuación, sin saber 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 

Verificar 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:  

Partición de 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. Ejecuta el instalador

Ejecute el instalador de ubicuidad, excluyendo el cargador 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 Otra cosa como el tipo de instalación y modifique el tipo md1p1 a ext4 , format: yes, y mount point / . La partición md0p1 se seleccionará automáticamente como intercambio.

Consiga una taza de café mientras finaliza la instalación.

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

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 se estén sincronizando).

 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:  

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

6. Configurar el sistema instalado.

Configurar 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 todavía están sincronizados, 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 

Deshabilitar quick_boot evitará que las escrituras de Diskfilter no sean errores admitidos . Deshabilitar quiet_boot es de preferencia personal solamente.

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 que algunas páginas sugieren que los esquemas de nombres pueden ser inestables (nombre = ubuntu: 0/1) y esto puede impedir que un dispositivo RAID perfectamente perfecto se monte durante el inicio.

Modificar líneas en /etc/default/grub para leer

 #GRUB_CMDLINE_LINUX_DEFAULT="quiet splash" GRUB_CMDLINE_LINUX="" 

Una vez más, este paso puede ser innecesario, pero prefiero arrancar con los ojos abiertos …

6.1. Añadir script de sueño

(La comunidad ha sugerido que este paso podría ser innecesario y se puede reemplazar usando GRUB_CMDLINE_LINUX="rootdelay=30" en /etc/default/grub . Por razones explicadas al final de este CÓMO, sugiero que se mantenga el script de sueño aunque es más feo que usar rootdelay. Por lo tanto, continuamos con nuestro progtwig regular … )

Cree un script que espere a que los dispositivos RAID se estabilicen. Sin este retraso, el assembly de la raíz puede fallar debido a que el ensamblaje RAID no se finaliza a tiempo . Descubrí esto de la manera más difícil: ¡el problema no se presentó hasta que desconecté uno de los SSD para simular una falla de disco! Es posible que deba ajustarse el tiempo dependiendo del 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 el script ejecutable e instálelo.

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

7. Habilitar el arranque desde el primer SSD

Ahora que 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 cargador de arranque en /boot/efi/EFI/Ubuntu (también conocido como EFI/Ubuntu en /dev/sda1 ) y lo instalará primero en la cadena de arranque UEFI en la computadora.

8. Habilitar el arranque desde el segundo SSD

Ya casi hemos terminado. En este punto, deberíamos poder reiniciar en la unidad sda . Además, mdadm debería poder manejar el error de la unidad sda o sdb . Sin embargo, el EFI no es RAID, por lo que necesitamos 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 partición sdb1 (según lo informado por blkid ) coincida con el de sda1 y /etc/fstab . (Sin embargo, tenga en cuenta que los UUID para las particiones /dev/sda1 y /dev/sdb1 seguirán siendo diferentes; compare ls -la /dev/disk/by-partuuid | grep sd[ab]1 con blkid /dev/sd[ab]1 después de la instalación para comprobar por ti mismo.)

Finalmente, debemos insertar la partición sdb1 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 tags únicas (-L) entre el ESP en sda y sdb .

Esto generará una impresión del orden de arranque actual, por ejemplo,

 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 tenga que 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.

Máquina virtual gotchas

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

 FS0: \EFI\ubuntu\grubx64.efi 

La primera solución en la respuesta principal de arranque UEFI en virtualbox – Ubuntu 12.04 también podría ser útil.

Simulando una falla de disco

El fallo de cualquiera de los dispositivos componentes RAID se puede simular utilizando mdadm . Sin embargo, para verificar que las cosas de arranque sobrevivirían a una falla del 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:  

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

Desconectar un disco

Apaga el ordenador. Desconecta un disco. 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:  

Recuperar de un disco fallido

Este es el proceso a seguir si ha necesitado reemplazar un disco defectuoso. Si desea emular un reemplazo, puede iniciar 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 la sustitución de un disco requiere los siguientes pasos:

  1. Partición de la nueva unidad.
  2. Añadir particiones a dispositivos md.
  3. Clona la partición de arranque.
  4. Añadir un registro EFI para el clon.

1. Partición de la nueva unidad

Copie la tabla de partición del disco sano:

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

Re-aleatorizar UUIDs en la nueva unidad.

 sudo sgdisk /dev/sdX -G 

2. Añadir a dispositivos md

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

3. Clona la partición de arranque

Clona el ESP del disco sano. (Cuidado, tal vez primero haga un volcado en archivo de ambos ESP para habilitar 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

Añadir 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 (es posible que los dispositivos RAID aún estén sincronizados)!

¿Por qué el script de sueño?

La comunidad ha sugerido que agregar una secuencia de comandos de suspensión podría ser innecesario y podría reemplazarse utilizando GRUB_CMDLINE_LINUX="rootdelay=30" en /etc/default/grub seguido de sudo update-grub . Esta sugerencia es ciertamente más clara y funciona en un escenario de disco / reemplazo de 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 arranca en modo degradado sin la unidad “fallida”.
2) En el arranque no degradado (ambas unidades presentes), el tiempo de arranque se reduce. El retraso es solo perceptible con la segunda unidad faltante.

1) y 2) sonaba bien hasta que volví a agregar mi segundo disco. En el arranque, la matriz RAID no se pudo ensamblar y me dejó en el indicador de initramfs sin saber qué hacer. Podría haber sido posible salvar la situación al a) arrancar desde la memoria USB de Ubuntu Live, b) instalar mdadm yc) volver a ensamblar la matriz de forma manual, pero … lo estropeé en alguna parte. En cambio, cuando volví a ejecutar esta prueba con el script de suspensión (sí, inicié el HOWTO desde la parte superior por enésima vez …), el sistema se inició. Las matrices estaban en modo degradado y pude volver a agregar manualmente las particiones /dev/sdb[23] sin ningún dispositivo USB extra. No sé por qué funciona el script de suspensión, mientras que el rootdelay no funciona. Tal vez mdadm se confunda con dos dispositivos de componentes ligeramente desincronizados, pero pensé que mdadm estaba diseñado para manejar eso. De todos modos, ya que el script de sueño funciona, me atengo a él.

Se podría argumentar que eliminar un dispositivo de 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 oportunidad para que mdadm se confunda. Estoy de acuerdo con ese argumento. Sin embargo, no sé cómo probar cómo el sistema tolera una falla de hardware, ¡excepto para deshabilitar realmente algo de hardware! Y después de las pruebas, quiero volver a un sistema redundante que funcione. (Bueno, podría adjuntar mi segundo SSD a otra máquina y deslizarlo antes de volver a agregarlo, pero eso no es posible).

En resumen: que yo sepa, la solución rootdelay es limpia, más rápida que la secuencia de comandos de suspensión para los arranques no degradados, y debería funcionar para un escenario real de falla / reemplazo de unidad. Sin embargo, no conozco una forma viable de probarlo. Así que, por el momento, me quedo con el script de sueño feo.

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 se produce con muchas placas base que no manejan correctamente las entradas de UEFI (Debian no se inicia 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/sda1 en la ruta /boot/efi :

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

Luego reinicie.

UEFI BIOS verá un disco genérico de “UEFI OS” y también cualquier otra entrada creada previamente con efibootmgr, pero arrancaría desde el genérico de “UEFI OS” sin ningún problema.