Come installare Ubuntu 14.04 / 16.04 64-bit con una partizione RAID 1 dual-boot su un sistema UEFI / GPT?

20

Aggiornamento: le domande e le risposte di seguito si applicano anche a Ubuntu 16.04

Ho un computer con doppio SSD e Win (7) preinstallato su un altro disco. La pre-installazione utilizza l'avvio (U) EFI / GPT. Voglio installare il desktop a 64 bit di Ubuntu 14.04 su una partizione di root RAID1 sui miei SSD ed essere ancora in grado di riavviare il sistema Win7. È possibile?

Questa guida l'uso dell'installer desktop non ha funzionato, probabilmente perché (implicitamente) presuppone l'avvio di MBR. Neanche installa la distribuzione del server , probabilmente per lo stesso motivo.

    
posta Niclas Börlin 11.08.2015 - 07:58

2 risposte

32

AGGIORNAMENTO: ho verificato che la descrizione di seguito funzioni anche per Ubuntu 16.04

Dopo giorni di tentativi, ora ho un sistema funzionante! In breve, la soluzione consisteva dei seguenti passaggi:

  1. Avvio tramite un Live CD / USB di Ubuntu.
  2. Partiziona gli SSD come richiesto.
  3. Installa pacchetti mancanti (mdadm e grub-efi).
  4. Crea le partizioni RAID.
  5. Avvia il programma di installazione di Ubiquity (ma non avviare il nuovo sistema).
  6. Patch il sistema installato (initramfs) per abilitare l'avvio da una root RAIDed.
  7. Popolare la partizione EFI del primo SSD con GRUB e installala nella catena di avvio EFI.
  8. Clona la partizione EFI sull'altro SSD e installala nella catena di avvio.
  9. Fatto! Il sistema ora avrà ridondanza RAID 1. Tieni presente che non è necessario eseguire alcuna operazione speciale dopo, ad es. un aggiornamento del kernel, poiché le partizioni UEFI non sono state toccate.

Un componente chiave del passaggio 6 della soluzione è stato un ritardo nella sequenza di avvio che altrimenti mi ha scaricato al prompt GRUB (senza tastiera!) se mancava uno degli SSD.

HOWTO dettagliato

1. Boot

Avvio tramite EFI dalla penna USB. Esattamente come varierà il tuo sistema. Seleziona Prova ubuntu senza installare .

Avvia un emulatore di terminale, ad es. xterm per eseguire i comandi di seguito.

1.1 Accesso da un altro computer

Durante il tentativo, ho trovato spesso più facile accedere da un altro computer già configurato. Questo comando di copia e incolla semplificato, ecc. Se vuoi fare lo stesso, puoi effettuare il login tramite ssh effettuando le seguenti operazioni:

Sul computer da configurare, installare il server openssh:

sudo apt-get install openssh-server

Cambia 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 istruzioni seguenti sono per linux:

ssh -l ubuntu <your-new-computer>

Se ricevi un avvertimento su un sospetto man-in-the-middle-attack, devi cancellare le chiavi ssh usate per identificare il nuovo computer. Questo perché openssh-server genera nuove chiavi del server ogni volta che viene installato. Il comando da usare è tipicamente 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 della partizione

Cancella eventuali vecchie partizioni e blocchi di avvio. Attenzione! 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 la tua unità sda è la più piccola, segui la Sezione 2.1, altrimenti la Sezione 2.2.

2.1 Crea tabelle di partizione (/ dev / sda è più piccolo)

Effettua le seguenti operazioni:

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 UUID univoci (creerai effettivamente UUID per sda).

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

2.2 Crea tabelle di partizione (/ dev / sdb è più piccolo)

Effettua le seguenti operazioni:

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 UUID univoci (creerai effettivamente UUID per sdb).

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

2.3 Crea file system FAT32 su / dev / sda

Crea un 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 pacchetti mancanti

Il Live CD di Ubuntu arriva 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 l'installazione in arrivo, portatelo pure.)

sudo apt-get update
sudo apt-get -y install grub-efi-amd64 # (or grub-efi-amd64-signed)
sudo apt-get -y install mdadm

Potresti aver bisogno di grub-efi-amd64-signed invece di grub-efi-amd64 se hai il boot sicuro abilitato. (Vedi commento di Alecz.)

4. Creare le partizioni RAID

Crea i dispositivi RAID in modalità degradata. I dispositivi saranno completati in seguito. La creazione di un RAID1 completo a volte mi dava problemi durante l'installazione di ubiquity di seguito, non so perché. (montaggio / smontaggio? 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 del 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>

Partizione dei 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 l'installer ubiquity, escludendo il boot loader che fallirà comunque . ( Nota : se hai effettuato l'accesso tramite ssh, probabilmente vorrai eseguirlo sul tuo nuovo computer.)

sudo ubiquity -b

Scegli Qualcos'altro come tipo di installazione e modifica il tipo md1p1 in ext4 , format: yes e mount point / . La partizione md0p1 verrà automaticamente selezionata come swap.

Ricevi una tazza di caffè mentre l'installazione è finita.

Importante: al termine dell'installazione, seleziona Continua test poiché il sistema non è ancora pronto per l'avvio.

Completa i dispositivi RAID

Collega 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 opzionalmente sincronizzati).

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 seguente potrebbe continuare durante la sincronizzazione, inclusi i riavvii.

6. Configura 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

Configura e installa 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 dispositivi MD stanno ancora eseguendo la sincronizzazione, è possibile che vengano visualizzati 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 (vedere la risposta in fondo a questa domanda ).

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

Disabilitare quick_boot eviterà Le scritture Diskfilter non sono supportati bug. La disattivazione di quiet_boot è solo di preferenza personale.

Modifica /etc/mdadm/mdadm.conf per rimuovere qualsiasi riferimento all'etichetta, ovvero cambiare

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 suggeriscono che gli schemi di denominazione potrebbero essere instabili (name = ubuntu: 0/1) e questo potrebbe impedire il montaggio di un dispositivo RAID perfettamente fine durante l'avvio.

Modifica le linee in /etc/default/grub per leggere

#GRUB_CMDLINE_LINUX_DEFAULT="quiet splash"
GRUB_CMDLINE_LINUX=""

Ancora una volta, questo passaggio potrebbe non essere necessario, ma preferisco l'avvio con gli occhi aperti ...

6.1. Aggiungi script di sonno

(È 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 seguire lo script di sonno anche se è più brutto che usare rootdelay. Quindi, continuiamo con il nostro programma regolare ... )

Crea uno script che attenderà che i dispositivi RAID si stabilizzino. Senza questo ritardo, il montaggio di root potrebbe fallire a causa dell'assemblaggio RAID non terminato in tempo . Ho trovato questo fuori nel modo più duro - il problema non si è verificato fino a quando non ho disconnesso uno degli SSD per simulare l'errore del disco! Potrebbe essere necessario regolare i tempi a seconda dell'hardware disponibile, ad es. 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 lo script eseguibile e installalo.

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

7. Abilita 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

Questo installerà il boot loader in /boot/efi/EFI/Ubuntu (a.k.a. EFI/Ubuntu su /dev/sda1 ) e installarlo prima nella catena di avvio UEFI sul computer.

8. Abilita avvio dal secondo SSD

Abbiamo quasi finito. A questo punto, dovremmo riuscire a riavviarlo sull'unità sda . Inoltre, mdadm dovrebbe essere in grado di gestire il fallimento dell'unità sda o sdb . Tuttavia, l'EFI non è RAIDed, quindi è necessario clonalo .

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

Oltre a installare il boot loader sulla seconda unità, questo renderà l'UUID del file system FAT32 sulla partizione sdb1 (come riportato da blkid ) che corrisponde a% di co_de% e sda1 . (Nota comunque che gli UUID per le partizioni /etc/fstab e /dev/sda1 saranno ancora diversi - confronta /dev/sdb1 con ls -la /dev/disk/by-partuuid | grep sd[ab]1 dopo l'installazione per verificare da soli.)

Infine, dobbiamo inserire la partizione blkid /dev/sd[ab]1 nell'ordine di avvio. (Nota: questo passaggio potrebbe non essere necessario, a seconda del BIOS. Ho ricevuto rapporti sul fatto 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 l'ESP su sdb1 e sda .

Questo 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 dovrebbe ora riavviarsi in Ubuntu (potrebbe essere necessario rimuovere prima il supporto di installazione di Ubuntu Live.)

Dopo l'avvio, puoi eseguire

sudo update-grub

per collegare il boot loader di Windows alla catena di avvio di grub.

Trucchi della macchina virtuale

Se vuoi provare questo in una macchina virtuale, ci sono alcune avvertenze: Apparentemente, la NVRAM che contiene le informazioni UEFI viene memorizzata tra i riavvii, ma non tra i cicli di riavvio-arresto. In tal caso, è possibile finire nella console UEFI Shell. I seguenti comandi dovrebbero avviarti nella tua macchina da sdb (usa /dev/sda1 per FS1: ):

FS0:
\EFI\ubuntu\grubx64.efi

La prima soluzione nella risposta più alta di avvio UEFI in virtualbox - Ubuntu 12.04 potrebbe anche essere utile.

Simulazione di un errore del disco

Il guasto di entrambi i dispositivi del componente RAID può essere simulato utilizzando /dev/sdb1 . Tuttavia, per verificare che la roba di avvio sopravvivesse a un guasto del disco, ho dovuto spegnere il computer e scollegare l'alimentazione da un disco.In tal caso, prima assicurati 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.

Disconnetti un'unità

Spegni il computer. Disconnettere un'unità. Ricomincia. Ubuntu dovrebbe ora avviare 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

Questa è la procedura da seguire se è necessario sostituire un disco difettoso. Se si desidera emulare una sostituzione, è possibile eseguire l'avvio in una sessione di Ubuntu Live e utilizzare

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

per pulire il disco pulito prima di riavviare nuovamente nel 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 di seguito per ripristinare la piena ridondanza di avvio / RAID per il proprio sistema.

Il ripristino del sistema di avvio RAID + dopo la sostituzione del disco richiede i seguenti passaggi:

  1. Partiziona la nuova unità.
  2. Aggiungi partizioni ai dispositivi md.
  3. Clona la partizione di avvio.
  4. Aggiungi un record EFI per il clone.

1. Partiziona il nuovo disco

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 a dispositivi md

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

3. Clona la partizione di avvio

Clona l'ESP dall'unità sana. (Attento, forse fai prima un dump-to-file di entrambi gli ESP per abilitare il recupero se davvero rovini tutto.)

sudo dd if=/dev/sdY1 of=/dev/sdX1

4. Inserisci il disco appena riattivato nell'ordine di avvio

Aggiungi un record EFI per il clone. Modifica 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 tornare alla normalità (i dispositivi RAID potrebbero ancora sincronizzarsi)!

Perché lo script di sospensione?

È stato suggerito dalla comunità che l'aggiunta di uno script di sospensione potrebbe non essere necessaria e potrebbe essere sostituita utilizzando mdadm in GRUB_CMDLINE_LINUX="rootdelay=30" seguito da /etc/default/grub . Questo suggerimento è certamente 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 sudo update-grub , ecc. invece dello script di sospensione:
1) Il sistema si avvia in modalità degradata senza l'unità "non riuscita".
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 ho aggiunto di nuovo la mia seconda unità. All'avvio, l'array RAID non è riuscito a riunirsi e mi ha lasciato al prompt rootdelay=30 senza sapere cosa fare. Potrebbe essere stato possibile salvare la situazione a) avviando la chiavetta USB Ubuntu Live, b) installando initramfs ec) riassemblando manualmente l'array ma ... Ho fatto un incasinato da qualche parte. Invece, quando ho ripetuto questo test con lo script sleep (sì, ho fatto partire l'HOWTO dall'alto per l'ennesima volta ...), il sistema ha avvio. Gli array erano in modalità degradata e potevo aggiungere manualmente le partizioni mdadm senza alcuna chiavetta USB aggiuntiva. Non so perché lo script sleep funzioni mentre il /dev/sdb[23] no. Forse rootdelay viene confuso da due dispositivi componenti leggermente fuori sincrono, ma ho pensato che mdadm sia stato progettato per gestirli. Ad ogni modo, dal momento che la sceneggiatura del sonno funziona, mi ci sto attenendo.

Si potrebbe sostenere che la rimozione di un dispositivo RAID perfettamente funzionante, il riavvio del RAID in modalità degradata e la successiva aggiunta del dispositivo componente è uno scenario irrealistico: lo scenario realistico è piuttosto che un dispositivo fallisce e viene sostituito da uno nuovo, lasciando meno possibilità per mdadm di confondersi. Sono d'accordo con questo argomento. Tuttavia, non so come testare il modo in cui il sistema tollera un errore hardware tranne che per disabilitare effettivamente alcuni componenti hardware! E dopo aver provato, voglio tornare a un sistema ridondante e funzionante. (Beh, potrei collegare il mio secondo SSD a un altro computer e farlo scorrere prima di aggiungerlo nuovamente, ma non è fattibile.)

In breve: per quanto ne so, la soluzione mdadm è pulita, più veloce dello script sleep per gli stivali non degradati e dovrebbe funzionare per uno scenario di guasto / sostituzione di un'unità reale. Tuttavia, non conosco un modo fattibile per testarlo. Quindi, per il momento, seguirò il brutto script del sonno.

    
risposta data Niclas Börlin 11.08.2015 - 08:52
0

Il mio suggerimento è per Debian OS, ma penso che funzionerebbe anche per Ubuntu e altri.

Un possibile modo per risolvere un problema che si verifica con molte schede madri che non gestiscono correttamente le voci UEFI (Debian non si avvia anche se hai fatto la voce corretta efibootmgr -c -g -d /dev/sda -p 1 -w -L "debian" -l /EFI/debian/grubx64.efi , UEFI BIOS mostra un disco di avvio "debian" ma non si avvia da esso), deve utilizzare invece la voce generica /boot/efi/EFI/boot/bootx4.efi .

Ad esempio, Asus Z87C non piace /EFI/debian/grubx64.efi .

Quindi, se hai montato la partizione efi /dev/sda1 in /boot/efi path:

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

Quindi riavvia.

UEFI BIOS vedrà un disco generico "UEFI OS" e anche qualsiasi altra voce precedentemente creata con efibootmgr, ma si avvierà genericamente dal "UEFI OS" senza problemi.

    
risposta data Nicola Giampietro 06.01.2017 - 20:01

Leggi altre domande sui tag