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:
- Arrancar usando un Ubuntu Live CD / USB.
- Particiona los SSD según sea necesario.
- Instalar paquetes faltantes (mdadm y grub-efi).
- Crea las particiones RAID.
- Ejecute el instalador de Ubiquity (pero no arranque en el nuevo sistema).
- Parchee el sistema instalado (initramfs) para habilitar el arranque desde una raíz RAID.
- Rellene la partición EFI del primer SSD con GRUB e instálela en la cadena de arranque EFI.
- Clone la partición EFI a la otra SSD e instálela en la cadena de arranque.
- ¡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:
- Particionar el nuevo disco.
- Agregar particiones a dispositivos md.
- Clonar la partición de arranque.
- 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.