ho acquisito la piattaforma HW col chipset PCH Intel X79 supportante anche il Trim in Raid, così mi sono avventurato nell’esperienza d’installare Linux trovandomi ad essere uno dei tanti utenti che non è riuscito, inizialmente, ad installare Ubuntu in FakeRaid sull’array.
Fin dall’inizio non ho minimamente preso in considerazione l’opzione del Raid SW per la semplice ragione che la scelta di prendere la piattaforma X79 in combinato con SSD Sata3 e supporto Trim, è quella che offre le massime performance possibili (780Mb/s in scrittura e 1,06Gb/s in lettura su una banda totale di 1,2Gb/s) con nessun decadimento delle prestazioni degli SSD.
Dal marzo 2012 anche Linux supporta il Trim su Raid , non di meno resta il vincolo del PCH, ufficialmente solo i PCH Intel Z77 e X79 fanno passare il Trim sul Raid, ufficiosamente con modding del Bios ne è capace anche il PCH Intel 67.
Si tratta d’installazione di Linux Ubuntu come unico sistema operativo di un PC con FakeRaid.
In giro per la rete ho trovato molti problemi come il mio ed anche molte dichiarazioni d’impossibilità di scrivere il Grub2 nel MBR dell’array, alcuni workaround, la maggioranza dei quali non funzionanti, gli unici funzionanti usano il bootloader di windows (BCD), opportunamente modificato con EasyBCD per lanciare linux dopo l’installazione di linux senza Grub2 e successiva installazione manuale di Grub2 da live CD senza metterlo in MBR: http://wiki.ubuntu-it.org/Installazione ... id0Windows .
E' una soluzione workaround per i dual boot Windows Linux con MBR in gestione a Windows su FakeRaid.
Non c’è alcun workaround che permetta l’installazione esclusiva di linux quando si hanno problemi con l’array in FakeRaid.
Con un po’ di pazienza combinata ad ostinazione e caso fortuito, sono riuscito dove finora non riuscivano in tanti.
Ad uso della comunità Ubuntu ho deciso di scrivere la mia esperienza con una testimonianza cronologico tecnica (insomma un pippone
).Partiamo col PC di un mio amico.
Installazione di Ubuntu 12.04 x64 in FakeRaid0 su SSD OCZ Vertex3 con mainboard Asus M4A89TD PRO, CPU AMD Phenom II x4 e 1 HDD Western Digital Green Caviar Sata2.
Nessun problema, tutto liscio come l’olio, confortante.
Dettaglio: prestazioni impressionanti
.Smontiamo l’array dagli SSD perché il chipset AMD non supporta il trim con raid e pertanto le prestazioni degli SSD andrebbero in rapido deterioramento.
Stessa piattaforma HW ma singolo SSD OCZ Vertex3 ed array FakeRaid0 su 2 HDD Seagate Barracuda ST1000DM003 per un totale di 420Mb/s in scrittura (come un singolo SSD di buona tecnologia), fallimento dell’installazione del Grub2.
E’ evidente che non è il chipset South Bridge della mainboard ma è il controller dell’HDD e forse (un forse politically correctly) il combinato di controller HDD e suo firmware.
Ora la mia piattaforma.
AsRock X79 Extreme 4, PCH Intel X79 (Waimea Bay), 2 Samsung 840 PRO, 2 HDD Western Digital Black Caviar, doppio array, uno per gli SSD ed uno per gli HDD, entrambi Fakeraid0.
Ubuntu 12.04 x64 fallisce la scrittura del Grub2 sull’array, sia sugli SSD, quanto sugli HDD.
Ubuntu 12.10 x64 idem come prima.
Ubuntu 10.04 x64 riesce a completare correttamente l’installazione, peccato che non riesca ad attivare la connessione di rete della mainboard che risulta troppo recente per quella versione di distro: in sostanza non ha i driver per la scheda ethernet, per l’audio HD, etc. .
Durante i ripetuti tentativi con le distro serie 12 (una trentina ed ogni volta con scioglimento dell’array dato che ad un successivo tentativo d'installazione senza scioglimento Ubiquity vedeva 2 volte le partizioni sull’array e non c’era modo di eliminare le doppie in fase d’installazione), tra le ultime installazioni delle 30 su citate faccio ripetere l’installazione del Grub2 una ventina di volte di seguito durante la stessa sessione d’installazione, cambiando anche la posizione dello stesso, provando tutte le combinazioni possibili e finalmente l’installer stressato manda un ulteriore messaggio oltre a quello solito e ripetitivo di errore fatale, eccolo: scritto grub senza comunicazione col kernel che risulta impegnato con la partizione.
Il percorso è quello dell’array e non le partizioni nell’array, è la sua radice dove ci deve essere l’MBR.
In sostanza Grub2 viene scritto nel MBR dell’array ma non viene configurato e neppure dato il suo punto di ingresso al kernel, questo è evidente anche al riavvio, il Bios non manda alcun messaggio al monitor e allo stesso tempo non c'è alcun boot.
Quindi è falso, ovvero è errato, quanto scritto e letto in diversi forum, cioè che l’errore della mancata installazione del Grub2 sia dovuta ad una sua impossibilità di scrittura nel settore MBR dell’array.
Questo era già evidente con il successo ottenuto con la 10.04 x64 sullo stesso mix di HW, il bootloader è sempre il Grub2 e questa è la prova del 9, rivelatrice la reale natura del problema: il kernel.
Pertanto dove c’è il problema e coestensivamente su pc con l’installazione del solo linux, non risulta possibile scrivere Grub2 nelle partizioni (neppure in quella di root / o /boot) ma solo, e solo, nell’array principale e, comunque, la sua scrittura non genera il boot al successivo riavvio.
Questo messaggio sarà il filo conduttore della semplice soluzione al problema.
Analisi: è un problema di compatibilità di kernel col combinato controller/firmware dei dischi dell’array, non dipende dal chipset della mainboard e, sostanzialmente, non dipende neppure dal controller/firmware dei dischi, ma sempre e solo dalla compatibilità del kernel con tale combinato, come ha dimostrato l’installazione della distro 10.04 x64.
Ultime info:
l'array dei 2 SSD l'ho chiamato SSD, ovviamente è stato partizionato e formattato in ext4 con journaling ( file system che garantisce il Trim ), l'array è, e deve essere, formato con stripe size da 64Kb (con gli altri formati si riesce ad installare Grub2 ma poi fallisce il boot e si corrompe il bootloader), in esso ho creato la partizione di root / e quella di swap (quindi solo 2 partizioni), l'array dei 2 HDD l'ho chiamato WD, non l'ho partizionato, non l'ho formattato, ciò genererà qualche errore ma non è influente.
Le fonti utilizzate per la soluzione sono 2.
1) http://wiki.ubuntu-it.org/Installazione ... id0Windows
2) http://wiki.ubuntu-it.org/Amministrazio ... Ripristino
How To
Installiamo Ubuntu sull’array scegliendo di fare il partizionamento manuale e alla fine, quando fallisce l’installazione di Grub2, chiudiamo il messaggio di errore fatale e dalla finestra d’installazione del bootloader selezioniamo la casella di controllo non installare il bootloader, poi facciamo riavvia lasciando il CD live nel lettore ottico.
Una volta avviata la live premiamo ctrl + alt + t aprendo il terminale.
A questo punto prendiamo il primo comando della prima fonte (è l'unico comando che useremo di tale fonte): sudo parted -l, di cui segue l’output.
Codice: Seleziona tutto
ubuntu@ubuntu:~$ sudo parted -l
Error: Can't have a partition outside the disk!
Error: /dev/sdb: unrecognised disk label
Error: /dev/sdc: unrecognised disk label
Error: /dev/sdd: unrecognised disk label
Error: /dev/mapper/isw_fjdfjjea_WD: unrecognised disk label
Model: Linux device-mapper (linear) (dm)
Disk /dev/mapper/isw_iiddagifc_SSD1: 238GB
Sector size (logical/physical): 512B/512B
Partition Table: loop
Number Start End Size File system Flags
1 0,00B 238GB 238GB ext4
Model: Linux device-mapper (linear) (dm)
Disk /dev/mapper/isw_iiddagifc_SSD2: 5000MB
Sector size (logical/physical): 512B/512B
Partition Table: msdos
Number Start End Size Type File system Flags
1 1024B 5000MB 5000MB primary linux-swap(v1)
Model: Linux device-mapper (linear) (dm)
Disk /dev/mapper/isw_iiddagifc_SSD5: 5000MB
Sector size (logical/physical): 512B/512B
Partition Table: loop
Number Start End Size File system Flags
1 0,00B 5000MB 5000MB linux-swap(v1)
Model: Linux device-mapper (striped) (dm)
Disk /dev/mapper/isw_iiddagifc_SSD: 243GB
Sector size (logical/physical): 512B/512B
Partition Table: msdos
Number Start End Size Type File system Flags
1 65,5kB 238GB 238GB primary ext4
2 238GB 243GB 5000MB extended
5 238GB 243GB 5000MB logical linux-swap(v1)1 /dev/mapper/isw_iiddagifc_SSD
2 /dev/mapper/isw_iiddagifc_SSD1
(avvertenza: queste sono le mie path, le vostre saranno inevitabilmente diverse e dovrete metterci quelle)
La prima è la radice dell’array dove dobbiamo generare l’MBR con l'installazione del Grub2, la seconda è la root / dove finirà la configurazione del Grub2.
Andiamo alla fonte 2 e saltiamo il primo comando che non ci serve, pertanto lo integriamo con quei 2 percorsi e digitiamo:
Codice: Seleziona tutto
sudo mount /dev/mapper/isw_iiddagifc_SSD1 /mnt
sudo mount --bind /dev /mnt/dev
sudo mount --bind /proc /mnt/proc
sudo mount --bind /sys /mnt/sys
sudo chroot /mnt
grub-install /dev/mapper/isw_iiddagifc_SSD
update-grub2
exit
cd ~
sudo umount /mnt/dev
sudo umount /mnt/proc
sudo umount /mnt/sys
sudo umount /mnt/Col riavvio avremo Ubuntu che parte regolare.
Piesse
In realtà a me il pc parte regolare in 6 secondi dopo il post ma ho un lungo lag d’attesa (circa 1 minuto) prima che keyboard e mouse Logitech wireless, modello MK 250, partano diventando attivi, ma questo è un altro problema: loses-keyboard-and-mouse
Banale a dirsi che sulla 10.04 x64 mouse e tastiera andavano benissimo... .
Colgo l’occasione per invitare Canonical ad intervenire tanto sul Kernel per il Grub2 su array, quanto sulle tastiere e mouse wireless, prima di curare l’aspetto grafico del prodotto curino la compatibilità HW del loro S.O. .