Atualização: As perguntas e respostas abaixo também se aplicam ao Ubuntu 16.04

Eu tenho um computador com dois SSDs e o Win (7) pré-instalado em outro disco. A pré-instalação usa a inicialização (U) EFI / GPT. Quero instalar o Ubuntu 14.04 desktop de 64 bits em uma partição raiz RAID1 nos meus SSDs e ainda ser capaz de inicializar duas vezes meu sistema Win7. Isso é possível?

Este guia usando o instalador da área de trabalho não funcionou, provavelmente porque (implicitamente) assume a inicialização do MBR. Nem instalou a distribuição do servidor , provavelmente pelo mesmo motivo.

ATUALIZAÇÃO: Verifiquei que a descrição abaixo também funciona para o Ubuntu 16.04. Outros usuários relataram trabalhar em 17.10 e 18.04.1.

NOTA: Este HOWTO não fornecerá a você LVM. Se você quiser o LVM também, tente Instalar o Ubuntu 18.04 desktop com RAID 1 e LVM na máquina com UEFI BIOS .

Depois de dias de tentativas, agora tenho um sistema em funcionamento! Em resumo, a solução consistiu nas seguintes etapas:

1. Inicialize usando um CD / USB do Ubuntu Live.
2. Particiona os SSDs conforme necessário.
3. Instale os pacotes ausentes (mdadm e grub-efi).
4. Crie as partições RAID.
5. Execute o instalador do Ubiquity (mas não inicialize no novo sistema).
6. Corrija o sistema instalado (initramfs) para permitir a inicialização de uma raiz RAID.
7. Preencha a partição EFI do primeiro SSD com o GRUB e instale-a na cadeia de inicialização EFI.
8. Clone a partição EFI no outro SSD e instale-a na cadeia de inicialização.
9. Feito! Seu sistema agora terá redundância RAID 1. Observe que nada de especial precisa ser feito após, por exemplo, uma atualização do kernel, pois as partições UEFI são intocadas.

Um componente-chave da etapa 6 da solução foi um atraso na sequência de inicialização que, de outra forma, me levaria diretamente ao prompt do GRUB (sem teclado!) Se algum dos SSDs estivesse ausente.

HOWTO detalhado

1. Inicialização

Inicialize usando EFI a partir do pen drive. Exatamente como isso varia de acordo com o seu sistema. Selecione Experimente o ubuntu sem instalar .

Inicie um emulador de terminal, por exemplo, xtermpara executar os comandos abaixo.

1.1 Login de outro computador

Ao tentar isso, geralmente achei mais fácil fazer login em outro computador já totalmente configurado. Isso simplifica o copiar e colar de comandos, etc. Se você quiser fazer o mesmo, poderá fazer o login via ssh fazendo o seguinte:

No computador a ser configurado, instale o servidor openssh:

sudo apt-get install openssh-server

Mudar senha. A senha padrão do usuário ubuntuestá em branco. Você provavelmente pode escolher uma senha de força média. Será esquecido assim que você reiniciar o seu novo computador.

passwd

Agora você pode fazer login na sessão ao vivo do ubuntu a partir de outro computador. As instruções abaixo são para linux:

ssh -l ubuntu <your-new-computer>

Se você receber um aviso sobre uma suspeita de ataque do tipo intermediário, precisará limpar as teclas ssh usadas para identificar o novo computador. Isso ocorre porque openssh-servergera novas chaves de servidor sempre que é instalado. O comando a ser usado geralmente é impresso e deve se parecer com

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

Após executar esse comando, você poderá fazer login na sessão ao vivo do ubuntu.

2. Discos de partição

Limpe todas as partições e blocos de inicialização antigos. Atenção! Isso destruirá os dados em 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, restante para RAID root. Se a sua unidade sda ​​for menor, siga a Seção 2.1, caso contrário, a Seção 2.2.

2.1 Criar tabelas de partição (/ dev / sda é menor)

Execute os seguintes passos:

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ção para outro disco e gere novamente UUIDs exclusivos (na verdade, gere novamente UUIDs para sda).

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

2.2 Criar tabelas de partição (/ dev / sdb é menor)

Execute os seguintes passos:

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ção para outro disco e gere novamente UUIDs exclusivos (na verdade, gere novamente UUIDs para sdb).

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

2.3 Criar 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. Instale pacotes ausentes

O Ubuntu Live CD vem sem dois pacotes principais; grub-efi e mdadm. Instale-os. (Não tenho 100% de certeza de que o grub-efi é necessário aqui, mas para manter a simetria com a próxima instalação, leve-a 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 em grub-efi-amd64-signedvez de grub-efi-amd64se tiver a inicialização segura ativada. (Veja o comentário de 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 ubiquityinstalação 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ê efetuou login via ssh, provavelmente desejará executar isso no seu novo computador.)

sudo ubiquity -b

Escolha Algo mais como o tipo de instalação e modifique o md1p1tipo para ext4, format: yes e ponto de montagem /. A md0p1partição será selecionada automaticamente como swap.

Tome uma xícara de café enquanto a instalação termina.

Importante: Após a conclusão da instalação, selecione Continuar teste, pois o sistema ainda não está pronto para inicialização.

Complete os dispositivos RAID

Anexe as partições 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. Configure 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 você ainda estiver sincronizando dispositivos, poderá receber 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 (consulte a resposta na parte inferior desta pergunta ).

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

Desabilitar quick_bootevitará que as gravações do Diskfilter não sejam suportadas . Desativar quiet_booté apenas de preferência pessoal.

Modifique /etc/mdadm/mdadm.conf para remover qualquer referência de etiqueta, 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

Esta etapa pode ser desnecessária, mas vi algumas páginas sugerirem que os esquemas de nomenclatura podem ser instáveis ​​(nome = ubuntu: 0/1) e isso pode impedir a montagem perfeita de um dispositivo RAID perfeitamente durante a inicialização.

Modifique as linhas /etc/default/grubpara ler

#GRUB_CMDLINE_LINUX_DEFAULT="quiet splash"
GRUB_CMDLINE_LINUX=""

Novamente, essa etapa pode ser desnecessária, mas eu prefiro inicializar com os olhos abertos ...

6.1 Adicionar script de suspensão

(Tem sido sugerido pela comunidade que este passo pode ser desnecessário e pode ser substituído usando GRUB_CMDLINE_LINUX="rootdelay=30"no /etc/default/grub. Por razões explicadas na parte inferior deste HOWTO, eu sugiro ficar com o script de sono, embora seja mais feio do que usando rootdelay. Assim, continuamos com nosso programa regular ... )

Crie um script que espere a instalação dos dispositivos RAID. Sem esse atraso, a montagem da raiz pode falhar devido ao conjunto do RAID não ter sido concluído a tempo . Descobri isso da maneira mais difícil - o problema não apareceu até eu desconectar um dos SSDs para simular falha no disco! O tempo pode precisar ser ajustado dependendo do hardware disponível, por exemplo, 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. Ative a inicialização a partir do primeiro SSD

Agora o sistema está quase pronto, apenas 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 inicialização no /boot/efi/EFI/Ubuntu(aka EFI/Ubuntuon /dev/sda1) e o instalará primeiro na cadeia de inicialização UEFI no computador.

8. Ative a inicialização a partir do segundo SSD

Estamos quase terminando. Neste ponto, devemos poder reiniciar na sdaunidade. Além disso, mdadmdeve ser capaz de lidar com falhas da unidade sdaou sdb. No entanto, o EFI não é RAIDed, por isso precisamos cloná-lo .

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

Além de instalar o carregador de inicialização na segunda unidade, isso fará com que o UUID do sistema de arquivos FAT32 na sdb1partição (conforme relatado por blkid) corresponda ao de sda1e /etc/fstab. (Observe, no entanto, que os UUIDs para as partições /dev/sda1e /dev/sdb1ainda serão diferentes - compare ls -la /dev/disk/by-partuuid | grep sd[ab]1com blkid /dev/sd[ab]1após a instalação para verificar por si mesmo.)

Finalmente, devemos inserir a sdb1partição na ordem de inicialização. (Observação: essa etapa pode ser desnecessária, dependendo do BIOS. Recebi relatórios de que alguns BIOS 'geram automaticamente 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 sdae 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

Observe 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 agora deve reiniciar no Ubuntu (pode ser necessário remover primeiro a mídia de instalação do Ubuntu Live.)

Após a inicialização, você pode executar

sudo update-grub

para conectar o carregador de inicialização do Windows à cadeia de inicialização do grub.

Dicas da máquina virtual

Se você quiser testar isso primeiro em uma máquina virtual, existem algumas ressalvas: Aparentemente, a NVRAM que contém as informações UEFI é lembrada entre as reinicializações, mas não entre os ciclos de desligamento e reinicialização. Nesse caso, você pode acabar no console UEFI Shell. Os seguintes comandos devem inicializar você em sua máquina a partir de /dev/sda1(use FS1:for /dev/sdb1):

FS0:
\EFI\ubuntu\grubx64.efi

A primeira solução na resposta superior da inicialização do UEFI no virtualbox - Ubuntu 12.04 também pode ser útil.

Simulando uma falha no disco

A falha de qualquer dispositivo componente RAID pode ser simulada usando mdadm. No entanto, para verificar se o material de inicialização sobreviveria a uma falha no 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

Desligar o computador. Desconecte uma unidade. Reiniciar. O Ubuntu agora deve 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 com defeito. Se você deseja emular uma substituição, você pode inicializar em uma sessão do Ubuntu Live e usar

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

para limpar o disco antes de reiniciar o sistema real. Se você acabou de testar a redundância de inicialização / RAID na seção acima, poderá pular esta etapa. No entanto, você deve pelo menos executar as etapas 2 e 4 abaixo para recuperar a redundância completa de inicialização / RAID para o seu sistema.

A restauração do sistema de inicialização RAID + após a substituição do disco requer as seguintes etapas:

1. Particione a nova unidade.
2. Adicione partições aos dispositivos md.
3. Clone a partição de inicialização.
4. Adicione um registro EFI para o clone.

1. Particione a nova unidade

Copie a tabela de partição da unidade íntegra:

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

Re-randomize UUIDs na nova unidade.

sudo sgdisk /dev/sdX -G

2. Adicione 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 íntegra. (Cuidado, talvez faça um despejo para arquivo 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-reativado 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, reiniciar 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 pelo uso GRUB_CMDLINE_LINUX="rootdelay=30"de /etc/default/grubseguido 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 ...

Desconectei meu segundo SSD e descobri que com rootdelay=30etc., 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 é perceptível apenas com a segunda unidade ausente.

1) e 2) pareciam excelentes até eu adicionar novamente a minha segunda unidade. Na inicialização, a matriz RAID falhou ao montar e me deixou no initramfsprompt sem saber o que fazer. Pode ter sido possível salvar a situação: a) inicializando no Ubuntu Live USB stick, b) instalando mdadmec) remontando a matriz manualmente, mas ... eu errei em algum lugar. Em vez disso, quando refiz esse teste com o script sleep (sim, iniciei o HOWTO de cima pela enésima vez ...), o sistema foi inicializado. As matrizes estavam no modo degradado e eu podia adicionar manualmente novamente as /dev/sdb[23]partições sem nenhum dispositivo USB extra. Não sei por que o script do sono funciona, enquanto o rootdelaynão. Talvez mdadmfique confuso com dois dispositivos componentes levemente fora de sincronia, mas penseimdadmfoi projetado para lidar com isso. De qualquer forma, já que o script do sono funciona, eu continuo com ele.

Pode-se argumentar que remover um dispositivo componente RAID perfeitamente saudável, reinicializar o RAID no modo degradado e depois adicionar novamente o dispositivo componente é um cenário irreal: O cenário realista é que um dispositivo falha e é substituído por um novo. , deixando menos oportunidade para mdadmficar confuso. Eu concordo com esse argumento. No entanto, não sei como testar como o sistema tolera uma falha de hardware, exceto para realmente desativar algum hardware! E após o teste, quero voltar para um sistema de trabalho redundante. (Bem, eu poderia conectar meu segundo SSD a outra máquina e deslizá-lo antes de adicioná-lo novamente, mas isso não é possível.)

Em resumo: que eu saiba, a rootdelaysolução é limpa, mais rápida que o script de suspensão para botas não degradadas e deve funcionar para um cenário real de falha / substituição de unidade. No entanto, não conheço uma maneira viável de testá-lo. Então, por enquanto, continuarei com o feio roteiro do sono.

Minha sugestão é para o sistema operacional Debian, mas acho que funcionaria também para o Ubuntu e outros.

Uma maneira possível de resolver um problema que ocorre com muitas placas-mãe que não lidam corretamente com as entradas UEFI (o Debian não inicializa mesmo que você tenha feito a entrada correta efibootmgr -c -g -d /dev/sda -p 1 -w -L "debian" -l /EFI/debian/grubx64.efi, o UEFI BIOS mostra um disco inicializável "debian", mas não inicializa a partir dele ), é usar a entrada genérica /boot/efi/EFI/boot/bootx4.efi.

Por exemplo, o Asus Z87C não gosta /EFI/debian/grubx64.efi.

Portanto, se você montou a partição efi /dev/sda1no /boot/eficaminho:

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

Então reinicie.

O UEFI BIOS verá um disco genérico "UEFI OS" e também qualquer outra entrada criada anteriormente com efibootmgr, mas inicializaria a partir do genérico "UEFI OS" sem nenhum problema.