UPDATE: Eu verifiquei que a descrição abaixo também funciona para o Ubuntu 16.04
Após dias de tentativas, agora tenho um sistema em funcionamento! Em resumo, a solução consistiu nos seguintes passos:
- Inicialize usando um Live CD / USB do Ubuntu.
- Particiona os SSDs conforme necessário.
- Instale os pacotes ausentes (mdadm e grub-efi).
- Crie as partições RAID.
- Execute o instalador do Ubiquity (mas não inicialize no novo sistema).
- Corrigir o sistema instalado (initramfs) para ativar a inicialização a partir de uma raiz RAID.
- Preencha a partição EFI do primeiro SSD com o GRUB e instale-o na cadeia de inicialização EFI.
- Clone a partição EFI para o outro SSD e instale-a na cadeia de inicialização.
- Feito! Seu sistema agora terá redundância de RAID 1. Note que nada de especial precisa ser feito após, e. uma atualização do kernel, já que as partições UEFI não são alteradas.
Um componente chave da etapa 6 da solução foi um atraso na seqüência de inicialização que, de outra forma, me jogou diretamente no prompt do GRUB (sem teclado!) se algum dos SSDs estivesse faltando.
COMO FAZER Detalhado
1. Inicializar
Inicialize usando o EFI do pendrive. Exatamente como irá variar de acordo com o seu sistema. Selecione Tente o ubuntu sem instalar .
Iniciar um emulador de terminal, por exemplo xterm para executar os comandos abaixo.
1.1 Login de outro computador
Enquanto tentava isso, muitas vezes achei mais fácil fazer o login de outro computador já totalmente configurado. Este simplificado cortar e colar de comandos, etc Se você quiser fazer o mesmo, você pode fazer o login via ssh, fazendo o seguinte:
No computador a ser configurado, instale o servidor openssh:
sudo apt-get install openssh-server
Alterar senha. A senha padrão para o usuário ubuntu está em branco. Você provavelmente pode escolher uma senha de força média. Ele será esquecido assim que você reiniciar seu novo computador.
passwd
Agora você pode entrar na sessão ao vivo do Ubuntu a partir de outro computador. As instruções abaixo são para o linux:
ssh -l ubuntu <your-new-computer>
Se você receber um aviso sobre uma suspeita de ataque man-in-the-middle, precisará limpar as chaves ssh usadas para identificar o novo computador. Isso ocorre porque openssh-server gera novas chaves do servidor sempre que é instalado. O comando a ser usado normalmente é impresso e deve se parecer com
ssh-keygen -f <path-to-.ssh/known_hosts> -R <your-new-computer>
Depois de executar esse comando, você deve poder fazer o login na sessão ao vivo do Ubuntu.
2. Discos de partição
Limpe todas as partições antigas e blocos de inicialização. Atenção! Isso destruirá os dados nos seus discos!
sudo sgdisk -z /dev/sda
sudo sgdisk -z /dev/sdb
Crie novas partições na menor das suas unidades: 100M para ESP, 32G para RAID SWAP, descanso para raiz RAID. Se a sua unidade sda for menor, siga a Seção 2.1, caso contrário, Seção 2.2.
2.1 Criar tabelas de partição (/ dev / sda é menor)
Siga os passos abaixo:
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 a tabela de partições para outro disco e gere novamente UUIDs exclusivos (na verdade, ela regenera os UUIDs para sda).
sudo sgdisk /dev/sda -R /dev/sdb -G
2.2 Criar tabelas de partição (/ dev / sdb é menor)
Siga os passos abaixo:
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 a tabela de partições para outro disco e gere novamente UUIDs exclusivos (na verdade, irá regenerar os UUIDs para sdb).
sudo sgdisk /dev/sdb -R /dev/sda -G
2.3 Crie o sistema de arquivos FAT32 em / dev / sda
Crie o sistema de arquivos FAT32 para a partição 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 pacotes ausentes
O Ubuntu Live CD vem sem dois pacotes de chaves; grub-efi e mdadm. Instale-os. (Eu não tenho 100% de certeza que o grub-efi é necessário aqui, mas para manter a simetria com a próxima instalação, traga-o também.)
sudo apt-get update
sudo apt-get -y install grub-efi-amd64 # (or grub-efi-amd64-signed)
sudo apt-get -y install mdadm
Você pode precisar de grub-efi-amd64-signed em vez de grub-efi-amd64 se tiver uma inicialização segura ativada. (Veja comentário por Alecz.)
4. Crie as partições RAID
Crie os dispositivos RAID no modo degradado. Os dispositivos serão concluídos mais tarde. A criação de um RAID1 completo às vezes me dava problemas durante a instalação de ubiquity abaixo, sem 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
Verifique o status do 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>
Particione os 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. Execute o instalador
Execute o instalador de onipresença, excluindo o carregador de inicialização que falhará de qualquer maneira . ( Nota : Se você tiver logado via ssh, você provavelmente desejará executar isto no seu novo computador).
sudo ubiquity -b
Escolha Outra como o tipo de instalação e modifique o md1p1 type para ext4 , format: yes e mount point / . A partição md0p1 será selecionada automaticamente como swap.
Pegue uma xícara de café enquanto a instalação termina.
Importante: Após a conclusão da instalação, selecione Continuar o teste porque o sistema ainda não está pronto para inicialização.
Complete os dispositivos RAID
Anexe as partições do sdb em espera ao RAID.
sudo mdadm --add /dev/md0 /dev/sdb2
sudo mdadm --add /dev/md1 /dev/sdb3
Verifique se todos os dispositivos RAID estão ok (e, opcionalmente, 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: <none>
O processo abaixo pode continuar durante a sincronização, incluindo as reinicializações.
6. Configurar o sistema instalado
Configure para ativar o chroot no sistema de instalação.
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
Configure e instale pacotes.
apt-get install -y grub-efi-amd64 # (or grub-efi-amd64-signed; same as in step 3)
apt-get install -y mdadm
Se os dispositivos md ainda estiverem sendo sincronizados, você poderá ver avisos ocasionais como:
/usr/sbin/grub-probe: warning: Couldn't find physical volume '(null)'. Some modules may be missing from core image..
Isso é normal e pode ser ignorado (veja a resposta na parte inferior esta questão ).
nano /etc/grub.d/10_linux
# change quick_boot and quiet_boot to 0
Desativar quick_boot evitará as As gravações do filtro de disco não são apoiado erros. A desativação de quiet_boot é apenas de preferência pessoal.
Modifique /etc/mdadm/mdadm.conf para remover quaisquer referências de rótulo, ou seja, altere
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
para
ARRAY /dev/md/0 UUID=f0e36215:7232c9e1:2800002e:e80a5599
ARRAY /dev/md/1 UUID=4b42f85c:46b93d8e:f7ed9920:42ea4623
Este passo pode ser desnecessário, mas eu vi algumas páginas sugerirem que os esquemas de nomeação podem ser instáveis (name = ubuntu: 0/1) e isso pode impedir que um dispositivo RAID perfeitamente fino seja montado durante a inicialização.
Modifique as linhas em /etc/default/grub para ler
#GRUB_CMDLINE_LINUX_DEFAULT="quiet splash"
GRUB_CMDLINE_LINUX=""
Novamente, essa etapa pode ser desnecessária, mas eu prefiro começar de olhos abertos ...
6.1. Adicione o script de sono
(Foi sugerido pela comunidade que este passo pode ser desnecessário e pode ser substituído usando GRUB_CMDLINE_LINUX="rootdelay=30" em /etc/default/grub . Por razões explicadas na parte inferior deste HOWTO, eu sugiro manter o script do sono é mais feio do que usar rootdelay. Assim, continuamos com nosso programa regular ... )
Crie um script que aguardará o encerramento dos dispositivos RAID. Sem esse atraso, a montagem do root pode falhar devido à montagem do RAID não estar concluída no tempo . Eu descobri isso da maneira mais difícil - o problema não apareceu até que eu desconectei um dos SSDs para simular a falha do disco! O tempo pode precisar de ser ajustado dependendo do hardware disponível, e. discos USB externos lentos, etc.
Digite o seguinte código em /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"
Torne o script executável e instale-o.
chmod a+x /usr/share/initramfs-tools/scripts/local-premount/sleepAwhile
update-grub
update-initramfs -u
7. Ativar a inicialização a partir do primeiro SSD
Agora o sistema está quase pronto, somente os parâmetros de inicialização UEFI precisam ser instalados.
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
Isso instalará o carregador de boot em /boot/efi/EFI/Ubuntu (a.k.a. EFI/Ubuntu on /dev/sda1 ) e o instalará primeiro na cadeia de inicialização UEFI no computador.
8. Ativar boot a partir do segundo SSD
Estamos quase terminando. Neste ponto, devemos poder reinicializar na unidade sda . Além disso, mdadm deve conseguir lidar com a falha da unidade sda ou sdb . No entanto, o EFI não é RAIDed, então precisamos clonar .
dd if=/dev/sda1 of=/dev/sdb1
Além de instalar o carregador de boot na segunda unidade, isso fará com que o UUID do sistema de arquivos FAT32 na partição sdb1 (conforme relatado por blkid ) corresponda ao de sda1 e /etc/fstab . (Observe, no entanto, que os UUIDs das partições /dev/sda1 e /dev/sdb1 ainda serão diferentes - compare ls -la /dev/disk/by-partuuid | grep sd[ab]1 com blkid /dev/sd[ab]1 após a instalação para verificar você mesmo).
Finalmente, devemos inserir a partição sdb1 na ordem de inicialização. (Nota: Este passo pode ser desnecessário, dependendo do seu BIOS. Eu recebi relatórios que alguns BIOS 'automaticamente gera uma lista de ESPs válidos.)
efibootmgr -c -g -d /dev/sdb -p 1 -L "Ubuntu #2" -l '\EFI\ubuntu\grubx64.efi'
Eu não testei, mas provavelmente é necessário ter rótulos exclusivos (-L) entre o ESP em sda e sdb .
Isso gerará uma impressão da ordem de inicialização atual, por exemplo,
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
Note que o Ubuntu # 2 (sdb) e o Ubuntu (sda) são os primeiros na ordem de inicialização.
Reiniciar
Agora estamos prontos para reiniciar.
exit # from chroot
exit # from sudo -s
sudo reboot
O sistema deve agora reiniciar no Ubuntu (você pode ter que remover a mídia de instalação do Ubuntu Live primeiro.)
Após o boot, você pode executar
sudo update-grub
para conectar o carregador de inicialização do Windows à cadeia de inicialização do grub.
Pegadinhas de máquinas virtuais
Se você quiser testar isso em uma máquina virtual primeiro, há algumas ressalvas: aparentemente, a NVRAM que contém as informações de UEFI é lembrada entre as reinicializações, mas não entre os ciclos de reinicialização de desligamento. Nesse caso, você pode acabar no console do UEFI Shell. Os comandos a seguir devem inicializar você em sua máquina a partir de /dev/sda1 (use FS1: para /dev/sdb1 ):
FS0:
\EFI\ubuntu\grubx64.efi
A primeira solução na resposta principal de boot UEFI no virtualbox - Ubuntu 12.04 também pode ser útil.
Simulando uma falha no disco
A falha do dispositivo componente RAID pode ser simulada usando mdadm . No entanto, para verificar se o material de inicialização sobreviveria a uma falha de disco, tive que desligar o computador e desconectar a energia de um disco.Se você fizer isso, primeiro verifique se os dispositivos md estão 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>
Nas instruções abaixo, sdX é o dispositivo com falha (X = a ou b) e sdY é o dispositivo ok.
Desconectar uma unidade
Desligue o computador. Desconecte uma unidade. Reiniciar. O Ubuntu deve agora inicializar com as unidades RAID no modo degradado. (Comemore! Isto é o que você estava tentando alcançar!);
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>
Recuperar de um disco com falha
Este é o processo a seguir se você precisar substituir um disco defeituoso. Se você quiser emular uma substituição, você pode iniciar uma sessão do Ubuntu Live e usar
dd if=/dev/zero of=/dev/sdX
para limpar o disco antes de reinicializar no sistema real. Se você acabou de testar a redundância de inicialização / RAID na seção acima, você pode pular esta etapa. No entanto, você deve pelo menos executar as etapas 2 e 4 abaixo para recuperar a redundância total de inicialização / RAID para o sistema.
A restauração do sistema de inicialização RAID + após uma substituição de disco requer as seguintes etapas:
- Particione a nova unidade.
- Adicione partições aos dispositivos md.
- Clone a partição de inicialização.
- Adicione um registro EFI para o clone.
1. Particionar a nova unidade
Copie a tabela de partições da unidade em funcionamento:
sudo sgdisk /dev/sdY -R /dev/sdX
Reordene aleatoriamente os UUIDs na nova unidade.
sudo sgdisk /dev/sdX -G
2. Adicionar aos dispositivos md
sudo mdadm --add /dev/md0 /dev/sdX2
sudo mdadm --add /dev/md1 /dev/sdX3
3. Clone a partição de inicialização
Clone o ESP da unidade saudável. (Cuidado, talvez faça um dump-to-file de ambos os ESPs primeiro para ativar a recuperação se você realmente estragar tudo.)
sudo dd if=/dev/sdY1 of=/dev/sdX1
4. Insira o disco recém revivido na ordem de inicialização
Adicione um registro EFI para o clone. Modifique o rótulo -L conforme necessário.
sudo efibootmgr -c -g -d /dev/sdX -p 1 -L "Ubuntu #2" -l '\EFI\ubuntu\grubx64.efi'
Agora, reinicializar o sistema deve voltar ao normal (os dispositivos RAID ainda podem estar sincronizando)!
Por que o script do sono?
Foi sugerido pela comunidade que adicionar um script de suspensão pode ser desnecessário e pode ser substituído usando GRUB_CMDLINE_LINUX="rootdelay=30" em /etc/default/grub seguido de sudo update-grub . Essa sugestão é certamente mais limpa e funciona em um cenário de falha / substituição de disco. No entanto, há uma ressalva ...
Eu desconectei meu segundo SSD e descobri que com rootdelay=30 , etc., em vez do script de suspensão:
1) O sistema inicializa no modo degradado sem a unidade "com falha".
2) Na inicialização não degradada (ambas as unidades presentes), o tempo de inicialização é reduzido. O atraso só é perceptível com a segunda unidade ausente.
1) e 2) soou ótimo até que eu re-adicionado meu segundo disco. Na inicialização, a matriz RAID falhou ao montar e me deixou no prompt initramfs sem saber o que fazer. Poderia ter sido possível salvar a situação com a) inicialização do Ubuntu Live USB stick, b) instalando mdadm e c) remontando o array manualmente, mas ... eu baguncei algum lugar. Em vez disso, quando eu corri novamente este teste com o script de suspensão (sim, eu iniciei o HOWTO de cima pela enésima vez ...), o sistema fez boot. As matrizes estavam em modo degradado e eu poderia adicionar novamente as partições /dev/sdb[23] manualmente sem nenhum pen drive extra. Eu não sei porque o script sleep funciona enquanto o rootdelay não funciona. Talvez mdadm fique confuso com dois dispositivos de componente ligeiramente fora de sincronia, mas achei que mdadm foi projetado para lidar com isso. De qualquer forma, desde que o script do sono funciona, eu estou aderindo a ele.
Pode-se argumentar que remover um dispositivo de componente RAID perfeitamente saudável, reinicializar o RAID no modo degradado e adicionar novamente o dispositivo de componente é um cenário irreal: o cenário realista é que um dispositivo falha e é substituído por um novo, deixando menos oportunidade para mdadm ficar confuso. Eu concordo com esse argumento. No entanto, eu não sei como testar como o sistema tolera uma falha de hardware, exceto para realmente desabilitar algum hardware! E após o teste, quero voltar a um sistema redundante em funcionamento. (Bem, eu poderia anexar meu segundo SSD a outra máquina e passá-lo antes de adicioná-lo novamente, mas isso não é viável.)
Em resumo: De acordo com o meu conhecimento, a solução rootdelay é limpa, mais rápida que o script de hibernação para inicializações não degradadas e deve funcionar para um cenário de falha / substituição real da unidade. No entanto, não conheço uma maneira viável de testá-lo. Então, por enquanto, vou me ater ao roteiro de sono feio.