AGGIORNAMENTO: ho verificato che la descrizione che segue funziona anche per Ubuntu 16.04. Altri utenti hanno riferito di lavorare su 17.10 e 18.04.1.
NOTA: questo HOWTO non ti darà LVM. Se vuoi anche LVM, prova invece a installare Ubuntu 18.04 desktop con RAID 1 e LVM sulla macchina con BIOS UEFI .
Dopo giorni di tentativi, ora ho un sistema funzionante! In breve, la soluzione consisteva nei seguenti passaggi:
- Avviare utilizzando un CD / USB Live di Ubuntu.
- Partiziona gli SSD come richiesto.
- Installa i pacchetti mancanti (mdadm e grub-efi).
- Creare le partizioni RAID.
- Esegui il programma di installazione di Ubiquity (ma non avviare il nuovo sistema).
- Patch il sistema installato (initramfs) per abilitare l'avvio da un root RAID.
- Popolare la partizione EFI del primo SSD con GRUB e installala nella catena di avvio EFI.
- Clonare la partizione EFI sull'altro SSD e installarla nella catena di avvio.
- Fatto! Il sistema ora avrà ridondanza RAID 1. Si noti che non è necessario fare nulla di speciale dopo, ad esempio, un aggiornamento del kernel, poiché le partizioni UEFI non vengono toccate.
Un componente chiave del passaggio 6 della soluzione è stato un ritardo nella sequenza di avvio che altrimenti mi ha scaricato direttamente al prompt di GRUB (senza tastiera!) Se mancasse uno degli SSD.
HOWTO dettagliato
1. Avvio
Avvio tramite EFI dalla chiavetta USB. Esattamente come varierà a seconda del sistema. Seleziona Prova Ubuntu senza installare .
Avviare un emulatore di terminale, ad esempio xtermper eseguire i comandi seguenti.
1.1 Accesso da un altro computer
Durante la prova, ho spesso trovato più facile accedere da un altro computer già completamente configurato. Questo comando incolla semplificato di comandi, ecc. Se si desidera fare lo stesso, è possibile accedere tramite ssh procedendo come segue:
Sul computer da configurare, installare il server openssh:
sudo apt-get install openssh-server
Cambia la password. La password predefinita per l'utente ubuntuè vuota. Probabilmente puoi scegliere una password di media potenza. Sarà dimenticato non appena riavvierai il tuo nuovo computer.
passwd
Ora puoi accedere alla sessione live di Ubuntu da un altro computer. Le seguenti istruzioni sono per linux:
ssh -l ubuntu <your-new-computer>
Se ricevi un avviso su un sospetto attacco man-in-the-middle, devi cancellare le chiavi ssh usate per identificare il nuovo computer. Questo perché openssh-servergenera nuove chiavi del server ogni volta che viene installato. Il comando da utilizzare è in genere stampato e dovrebbe apparire come
ssh-keygen -f <path-to-.ssh/known_hosts> -R <your-new-computer>
Dopo aver eseguito quel comando, dovresti essere in grado di accedere alla sessione live di Ubuntu.
2. Dischi di partizione
Cancella eventuali vecchie partizioni e blocchi di avvio. Avvertimento! Questo distruggerà i dati sui tuoi dischi!
sudo sgdisk -z /dev/sda
sudo sgdisk -z /dev/sdb
Crea nuove partizioni sul più piccolo dei tuoi dischi: 100M per ESP, 32G per RAID SWAP, resto per RAID root. Se l'unità sda è più piccola, seguire la Sezione 2.1, altrimenti la Sezione 2.2.
2.1 Creare tabelle delle partizioni (/ dev / sda è più piccolo)
Procedi come segue:
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
Copia la tabella delle partizioni su un altro disco e rigenera gli UUID univoci (in realtà rigenererà gli UUID per sda).
sudo sgdisk /dev/sda -R /dev/sdb -G
2.2 Creare tabelle delle partizioni (/ dev / sdb è più piccolo)
Procedi come segue:
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
Copia la tabella delle partizioni su un altro disco e rigenera gli UUID univoci (in realtà rigenererà gli UUID per sdb).
sudo sgdisk /dev/sdb -R /dev/sda -G
2.3 Creare il file system FAT32 su / dev / sda
Creare il file system FAT32 per la partizione 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. Installa i pacchetti mancanti
Ubuntu Live CD viene fornito senza due pacchetti chiave; grub-efi e mdadm. Installali. (Non sono sicuro al 100% che grub-efi sia necessario qui, ma per mantenere la simmetria con la prossima installazione, portalo anche tu.)
sudo apt-get update
sudo apt-get -y install grub-efi-amd64 # (or grub-efi-amd64-signed)
sudo apt-get -y install mdadm
Potrebbe essere necessario grub-efi-amd64-signedinvece grub-efi-amd64se hai l'avvio protetto abilitato. (Vedi commento di Alecz.)
4. Creare le partizioni RAID
Creare i dispositivi RAID in modalità degradata. I dispositivi saranno completati in seguito. La creazione di un RAID1 completo a volte mi ha dato problemi durante l' ubiquityinstallazione di seguito, non so perché. (montare / smontare? 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
Verifica lo stato 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>
Partiziona i dispositivi 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. Esegui il programma di installazione
Esegui il programma di installazione ubiquità, escluso il boot loader che non funzionerà comunque . ( Nota : se hai effettuato l'accesso tramite ssh, probabilmente vorrai invece eseguirlo sul tuo nuovo computer.)
sudo ubiquity -b
Scegli Qualcos'altro come tipo di installazione e modifica il md1p1tipo in ext4, formato: sì e punto di montaggio /. La md0p1partizione verrà automaticamente selezionata come swap.
Prendi una tazza di caffè al termine dell'installazione.
Importante: al termine dell'installazione, selezionare Continua test poiché il sistema non è ancora pronto per l'avvio.
Completa i dispositivi RAID
Collegare le partizioni SDB in attesa al RAID.
sudo mdadm --add /dev/md0 /dev/sdb2
sudo mdadm --add /dev/md1 /dev/sdb3
Verificare che tutti i dispositivi RAID siano ok (e facoltativamente la sincronizzazione).
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>
Il processo di seguito potrebbe continuare durante la sincronizzazione, inclusi i riavvii.
6. Configurare il sistema installato
Configurare per abilitare chroot nel sistema di installazione.
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
Configurare e installare i pacchetti.
apt-get install -y grub-efi-amd64 # (or grub-efi-amd64-signed; same as in step 3)
apt-get install -y mdadm
Se i tuoi dispositivi md stanno ancora eseguendo la sincronizzazione, potresti ricevere avvisi occasionali come:
/usr/sbin/grub-probe: warning: Couldn't find physical volume `(null)'. Some modules may be missing from core image..
Questo è normale e può essere ignorato (vedi risposta in fondo a
questa domanda ).
nano /etc/grub.d/10_linux
# change quick_boot and quiet_boot to 0
La disabilitazione quick_booteviterà che le scritture di Diskfilter non siano bug supportati . La disabilitazione quiet_bootè solo di preferenza personale.
Modifica /etc/mdadm/mdadm.conf per rimuovere eventuali riferimenti alle etichette, ad es. Modifica
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
Questo passaggio potrebbe non essere necessario, ma ho visto alcune pagine suggerire che gli schemi di denominazione potrebbero essere instabili (nome = ubuntu: 0/1) e questo potrebbe impedire l'assemblaggio di un dispositivo RAID perfettamente perfetto durante l'avvio.
Modifica le righe /etc/default/grubper leggere
#GRUB_CMDLINE_LINUX_DEFAULT="quiet splash"
GRUB_CMDLINE_LINUX=""
Ancora una volta, questo passaggio potrebbe non essere necessario, ma preferisco fare il boot con gli occhi aperti ...
6.1. Aggiungi lo script di sospensione
(È stato suggerito dalla comunità che questo passaggio potrebbe non essere necessario e può essere sostituito usando GRUB_CMDLINE_LINUX="rootdelay=30"in /etc/default/grub. Per ragioni spiegate in fondo a questo HOWTO, suggerisco di attenersi allo script sleep anche se è più brutto dell'uso di rootdelay. Pertanto, continuiamo con il nostro programma regolare ... )
Crea uno script in attesa che i dispositivi RAID si stabilizzino. Senza questo ritardo, il montaggio di root potrebbe non riuscire a causa dell'assemblaggio RAID non terminato in tempo . L'ho scoperto nel modo più duro: il problema non si è manifestato fino a quando non avevo disconnesso uno degli SSD per simulare un errore del disco! Potrebbe essere necessario regolare i tempi in base all'hardware disponibile, ad esempio dischi USB esterni lenti, ecc.
Inserisci il seguente codice in /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"
Rendi eseguibile lo script e installalo.
chmod a+x /usr/share/initramfs-tools/scripts/local-premount/sleepAwhile
update-grub
update-initramfs -u
7. Abilitare l'avvio dal primo SSD
Ora il sistema è quasi pronto, è necessario installare solo i parametri di avvio 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
Ciò installerà il boot loader in /boot/efi/EFI/Ubuntu(aka EFI/Ubuntuon /dev/sda1) e lo installerà prima nella catena di avvio UEFI sul computer.
8. Abilitare l'avvio dal secondo SSD
Abbiamo quasi finito. A questo punto, dovremmo essere in grado di riavviare sdasull'unità. Inoltre, mdadmdovrebbe essere in grado di gestire il guasto dell'unità sdao sdb. Tuttavia, EFI non è RAID, quindi è necessario clonarlo .
dd if=/dev/sda1 of=/dev/sdb1
Oltre all'installazione del boot loader sulla seconda unità, questo UUID del file system FAT32 sulla sdb1partizione (come riportato da blkid) corrisponderà a quello di sda1e /etc/fstab. (Si noti tuttavia che gli UUID per le partizioni /dev/sda1e /dev/sdb1saranno comunque diversi; confrontare ls -la /dev/disk/by-partuuid | grep sd[ab]1con blkid /dev/sd[ab]1dopo l'installazione per verificare da soli.)
Infine, dobbiamo inserire la sdb1partizione nell'ordine di avvio. (Nota: questo passaggio potrebbe non essere necessario, a seconda del BIOS. Ho ricevuto segnalazioni che alcuni BIOS 'generano automaticamente un elenco di ESP validi.)
efibootmgr -c -g -d /dev/sdb -p 1 -L "Ubuntu #2" -l '\EFI\ubuntu\grubx64.efi'
Non l'ho provato, ma probabilmente è necessario avere etichette univoche (-L) tra ESP sdae sdb.
Ciò genererà una stampa dell'ordine di avvio corrente, ad es
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
Nota che Ubuntu # 2 (sdb) e Ubuntu (sda) sono i primi nell'ordine di avvio.
Reboot
Ora siamo pronti per il riavvio.
exit # from chroot
exit # from sudo -s
sudo reboot
Il sistema ora dovrebbe riavviarsi in Ubuntu (potrebbe essere necessario rimuovere prima il supporto di installazione di Ubuntu Live.)
Dopo l'avvio, è possibile eseguire
sudo update-grub
per collegare il boot loader di Windows alla catena di avvio di grub.
Gotcha per macchine virtuali
Se vuoi provarlo prima in una macchina virtuale, ci sono alcuni avvertimenti: apparentemente, la NVRAM che contiene le informazioni UEFI viene ricordata tra i riavvii, ma non tra i cicli di spegnimento e riavvio. In tal caso, potresti finire sulla console Shell UEFI. I seguenti comandi dovrebbero avviarti nel tuo computer da /dev/sda1(usare FS1:per /dev/sdb1):
FS0:
\EFI\ubuntu\grubx64.efi
La prima soluzione nella risposta principale di avvio UEFI in virtualbox - Ubuntu 12.04 potrebbe anche essere utile.
Simulazione di un errore del disco
È possibile simulare il guasto di uno dei dispositivi componente RAID utilizzando mdadm. Tuttavia, per verificare che le cose di avvio sopravvivessero a un errore del disco, ho dovuto spegnere il computer e scollegare l'alimentazione da un disco. Se lo fai, assicurati innanzitutto che i dispositivi md siano sincronizzati .
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>
Nelle istruzioni seguenti, sdX è il dispositivo guasto (X = a o b) e sdY è il dispositivo ok.
Scollegare un'unità
Spegni il computer. Scollegare un'unità. Ricomincia. Ubuntu dovrebbe ora avviarsi con le unità RAID in modalità degradata. (Festeggia! Questo è quello che stavi cercando di ottenere!;)
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>
Ripristina da un disco guasto
Questo è il processo da seguire se è necessario sostituire un disco difettoso. Se si desidera emulare un sostituto, è possibile avviare una sessione Ubuntu Live e utilizzarlo
dd if=/dev/zero of=/dev/sdX
per pulire il disco prima di riavviare il sistema reale. Se hai appena testato la ridondanza di avvio / RAID nella sezione precedente, puoi saltare questo passaggio. Tuttavia, è necessario eseguire almeno i passaggi 2 e 4 seguenti per ripristinare la ridondanza di avvio / RAID completa per il sistema.
Il ripristino del sistema di avvio RAID + dopo la sostituzione del disco richiede i seguenti passaggi:
- Partiziona la nuova unità.
- Aggiungi partizioni ai dispositivi md.
- Clonare la partizione di avvio.
- Aggiungi un record EFI per il clone.
1. Partizionare la nuova unità
Copia la tabella delle partizioni dall'unità sana:
sudo sgdisk /dev/sdY -R /dev/sdX
Ri-randomizzare gli UUID sulla nuova unità.
sudo sgdisk /dev/sdX -G
2. Aggiungi ai dispositivi md
sudo mdadm --add /dev/md0 /dev/sdX2
sudo mdadm --add /dev/md1 /dev/sdX3
3. Clonare la partizione di avvio
Clonare l'ESP dall'unità sana. (Attento, forse esegui prima un dump-file su entrambi gli ESP per abilitare il recupero se lo rovini davvero.)
sudo dd if=/dev/sdY1 of=/dev/sdX1
4. Inserire il disco appena ripristinato nell'ordine di avvio
Aggiungi un record EFI per il clone. Modificare l'etichetta -L come richiesto.
sudo efibootmgr -c -g -d /dev/sdX -p 1 -L "Ubuntu #2" -l '\EFI\ubuntu\grubx64.efi'
Ora, il riavvio del sistema dovrebbe riportarlo alla normalità (i dispositivi RAID potrebbero ancora essere sincronizzati)!
Perché la sceneggiatura del sonno?
È stato suggerito dalla community che l'aggiunta di uno script sleep potrebbe non essere necessaria e potrebbe essere sostituita usando GRUB_CMDLINE_LINUX="rootdelay=30"in /etc/default/grubseguito da sudo update-grub. Questo suggerimento è sicuramente più pulito e funziona in uno scenario di errore / sostituzione del disco. Tuttavia, c'è un avvertimento ...
Ho disconnesso il mio secondo SSD e ho scoperto che con rootdelay=30, ecc. Invece dello script sleep:
1) Il sistema si avvia in modalità degradata senza l'unità "guasta".
2) In avvio non degradato (entrambe le unità presenti), il tempo di avvio è ridotto. Il ritardo è percepibile solo con la seconda unità mancante.
1) e 2) suonavano alla grande fino a quando non ho aggiunto nuovamente la mia seconda unità. All'avvio, l'array RAID non è riuscito a riunirsi e mi ha lasciato al initramfsprompt senza sapere cosa fare. Potrebbe essere stato possibile salvare la situazione a) avviando la chiavetta USB Live di Ubuntu, b) installando mdadmec) riassemblando l'array manualmente ma ... Ho fatto un casino da qualche parte. Invece, quando ho eseguito nuovamente questo test con lo script sleep (sì, ho avviato l'HOWTO dall'alto per l'ennesima volta ...), il sistema si è avviato. Gli array erano in modalità degradata e ho potuto aggiungere nuovamente manualmente le /dev/sdb[23]partizioni senza alcuna chiavetta USB aggiuntiva. Non so perché lo script sleep funzioni mentre rootdelaynon lo è. Forse mdadmviene confuso da due dispositivi componenti leggermente non sincronizzati, ma ho pensatomdadmè stato progettato per gestirlo. Ad ogni modo, dato che la sceneggiatura del sonno funziona, mi sto attenendo ad essa.
Si potrebbe sostenere che rimuovere un dispositivo componente RAID perfettamente integro, riavviare il RAID in modalità degradata e quindi aggiungere nuovamente il dispositivo componente è uno scenario non realistico: lo scenario realistico è piuttosto che un dispositivo si guasta e viene sostituito da uno nuovo , lasciando meno opportunità mdadmdi confondersi. Sono d'accordo con tale argomento. Tuttavia, non so come testare il modo in cui il sistema tollera un guasto hardware se non per disabilitare effettivamente un po 'di hardware! E dopo i test, voglio tornare a un sistema funzionante e ridondante. (Beh, potrei collegare il mio secondo SSD a un altro computer e scorrere prima di aggiungerlo di nuovo, ma non è possibile.)
In sintesi: per quanto ne so, la rootdelaysoluzione è pulita, più veloce dello script di sospensione per gli stivali non degradati e dovrebbe funzionare in caso di guasto / sostituzione dell'unità reale. Tuttavia, non conosco un modo fattibile per testarlo. Quindi, per il momento, mi atterrò al brutto copione del sonno.