RedSleeve 7: un clone RedHat 7 per i Raspberry

Stavo giusto notando che erano scomparsi da Internet i link che rimandavano ad immagini  ready-to-use di Fedora 21 per Raspberry quando mi sono imbattuto in un sito, http://www.redsleeve.org, che molto pretenziosamente esponeva una distro  Linux per Rpi chiamata RedSleeve (Manica Rossa, la citazione al Cappello Rosso di RedHat ci sta tutta, logo compreso). Versione 6, del tutto simile alla RedHat 6, quindi. L’ho scaricata e si tratta di un’immagine cosiddetta ready-to-use, quindi comprensiva della boot partition. Sono rimasto piuttosto deluso: c’è un fastidioso bug nella gestione del file etc/shadow che costringe chi si logga come root a cambiare la password ogni volta (!) e i repository Yum sono decisamente pessimi. Non ne vale la pena.

Ho voluto provare anche la RedSleeve 7, che nel sito non è menzionata ma che però esiste nell’ftp dove risiedono le immagini e stavolta mi sembra che ci siamo. Ecco il link:

http://www.mirrorservice.org/sites/ftp.redsleeve.org/pub/el7-devel/el7/rootfs/

Ci sono versioni per Rpi, Rpi2 e perfino delle immagini che faranno felici i possessori di schede Odroid. Si tratta anche qui di un clone della corrispondente versione di RedHat, quindi basata su systemd. Sostanziale differenza è che usa coraggiosamente il nuovo kernel 4.0.4. L’utente root predefinito ha come password “password”. Stavolta non ci sono i difetti che ho riscontrato sulla versione 6 ed è addirittura disponibile un repository EPEL dedicato. A un primo esame non ho notato difetti evidenti ma prima di utilizzarla stabilmente come server la terrò in test per qualche tempo. Consiglio di provarla, si tratta di una immagine adatta per server headless , e nell’attesa che esca fuori una CentOS ufficiale per RPi mi sembra un ottima alternativa a Fedora. Ricordo che non ha bisogno di ulteriori manipolazioni della boot partition, l’immagine parte subito. L’unico intervento che si può fare dopo la prima esecuzione è inserire nel config.txt la variabile gpu_mem=16 per portare la RAM disponibile per il server al massimo.

Banana Pro: Reboot e il led verde (rc.local)

La prima cosa che ho notato è che a differenza del Raspberry Pi2 il Banana Pro riesce a fare correttamente un reboot da remoto anche quando nulla è collegato alla porta HDMI. Sembra una cosa da niente ma è fondamentale quando si è fisicamente lontani dalla scheda e dopo aver ad esempio effettuato delle modifiche o degli aggiornamenti che coinvolgono il kernel si vuole riavviare il Banana che è in configurazione “headless”.

La seconda cosa è che durante il funzionamento il Banana Pro ha a bordo un piccolo led di colore verde che blinka ripetutamente. Se la scheda è montata dentro un contenitore trasparente vi assicuro che di notte avrete qualcosa che assomiglia ad un albero di Natale capace di disturbare chiunque dorma nello stesso ambiente in cui è installata la scheda. Come spegnere questo led?

Entriamo come utente root e digitiamo:

Questa modifica però verrà persa al prossimo reboot del server perché il sistema operativo in fase di avvio riscriverà di nuovo questo ed altri valori forzando sempre delle stringhe predefinite. L’unico sistema è quello di scrivere questo comando in un file che si chiama rc.local che viene messo a disposizione dell’utente proprio per dare comandi all’avvio dopo che sono state completate le fasi di inizializzazione. La cosa importante quindi è che l’rc.local viene eseguito all’ultimo appena prima la presentazione del prompt di comandi. Questo lo rende utile e necessario all’esecuzione di script utente, cosa per cui è nato.

Detto questo entriamo in edit con vi o nano del file /etc/rc.d/rc.local che in questa edizione di Fedora 21 tra l’altro non esiste ancora, quindi sarà un nuovo file.

Inseriamo al suo interno questi comandi:

e salviamo le modifiche. Diamo i permessi di esecuzione allo script altrimenti non partirà.

Dopo di che se il led verde sta lampeggiando proviamo lo script per vedere se è tutto a posto.

e se vedremo spegnersi il led verde significa che tutto è ok. Facendo un reboot verificheremo che il led verde si spenga alla fine del reboot stesso. A questo punto lo spegnimento del led verde in caso di server headless segnala che il Banana ha eseguito correttamente il boot ed è pronto a ricevere comandi via SSH. Oltre a togliere quel fastidioso lampeggiamento continuo direi che abbiamo dato anche un senso al nostro led verde 🙂

Banana Pro e BerryBoot

Dopo aver provato le varie distribuzioni presenti sul sito ufficiale di Lemaker sono giunto alla conclusione che il metodo migliore di dotare il Banana Pro di una buona distribuzione Linux è quello di scaricare BerryBoot e gestire il tutto tramite questo prodotto. Lo possiamo trovare a questo link:

http://www.lemaker.org/resources/9-131/berryboot.html

Si tratta della versione 1.0, che poi viene aggiornata non appena si è fatto il boot dalla scheda microSD. BerryBoot permette di gestire un comodo multiboot tra più distribuzioni, se si ha a disposizione un HDD o SSD collegato alla porta SATA dà l’interessantissima possibilità di spostare là il sistema operativo con indubbi vantaggi di spazio disponibile e infine mette a disposizione delle distro Linux più aggiornate rispetto a quelle presenti nel classico link di Lemaker.

berryboot01

Il concetto è molto simile al Noobs per il Raspberry, ma in effetti risulta essere molto più potente. C’è da dire che esistono versioni di BerryBoot sia per il vecchio Raspberry che per il Pi2, per cui lo consiglio caldamente.

Per me è stato piacevole scoprire ad esempio che è disponibile una Fedora 21 con installato Mate, che a me non interessa, ma che risulta nettamente migliore della Fedora 20 proposta da Lemaker che ha secondo me qualche problema nel kernel (vedi le considerazioni sul carico sempre a circa 1 anche quando il server è idle che ho fatto nel precedente articolo). Con un buon lavoro di ripulitura dei pacchetti che non servono ad un uso “headless” penso si possa tirar fuori un ottimo OS adatto ad un server.

berryboot02

 

Per chi preferisce Debian c’è comunque una Raspian Wheezy che mi sembra più aggiornata rispetto alla classica proposta sempre nel sito Lemaker. Esiste una seconda pagina di distro (tab Others) dove si possono trovare anche un paio di distro Ubuntu e altri sistemi operativi meno “popolari”.

Concludo con l’inevitabile: il cavetto dell’antenna wifi in dotazione come prevedevo si è staccato. Basta muovere il contenitore con il Banana montato o usare i piccoli tasti di reset e accensione presenti sulla scheda e prima o poi si stacca, non c’è nulla da fare. Probabilmente, se proprio non si può fare a meno del modulo wifi onboard, è meglio far cadere una goccia di qualche resina sul connettore una volta installato per “inchiodarlo” saldamente alla motherboard. Tra l’altro sulle schede nuove non c’è speranza, è stato usato lo stesso sistema.

Banana Pro

bananapro01

Ho aggiunto alla scuderia anche un Banana Pro. E’ una scheda interessante, anche se da poco sostituita dalle nuove microschede di Lemaker. Non è un modello molto vecchio, è entrata in produzione nell’ottobre del 2014, ma il produttore ha appena inaugurato una nuova serie di schede (http://www.bananapi.com/index.php) tra cui un interessantissimo Smart Router. Ho voluto testare anche il Banana Pro perché, a differenza del Raspberry Pi2, monta una ethernet da 1 Gbit, più veloce quindi, e un connettore SATA2 a cui è possibile collegare hard disk a piatto rotante o SSD, con tempi di accesso notevolmente migliori delle microSD. Dispone infine di un modulo wifi incorporato, quindi non necessita di un dongle che va ad occupare una porta USB. Le prime due differenze rispetto al Raspberry (ethernet e SATA) lo rendono sulla carta più performante come home server in cui sia coinvolto un lavoro intenso di accesso allo storage, come nel caso di un cloud server, ad esempio.

Le note dolenti: il supporto su Internet sia sul sito ufficiale che sui forum è notevolmente inferiore rispetto ai Raspberry. Se ci troviamo di fronte ad un problema “strano” risulta più difficile trovare una soluzione “bella e pronta” già sperimentata da qualcuno. In qualche caso ho trovato riferimenti a file di configurazione che in realtà non esistono, anche perché oltretutto a livello di distribuzioni ci sono delle differenze tra Banana Pi e Banana Pro. Sulla rete quindi si trovano più informazioni sul modello precedente, il Banana Pi appunto, che sulla scheda Pro.

Una annotazione sull’hardware: il micro connettore dell’antenna wifi che va inserito sulla scheda è a dir poco detestabile. Microscopico, difficile da inserire e soprattutto instabile. Considerando il case in acrilico che viene spesso scelto (e così ho fatto anche io) e dove è piazzata l’antenna il minuscolo cavetto sicuramente darà fastidio o allo slot microSD o ai pulsanti di reset e accensione. Si stacca spesso, basta toccarlo, e questo specialmente quando la scheda è già chiusa nel case, è una cosa estremamente fastidiosa.

bananapro07

Ora si tratta di scegliere una immagine di un S.O. adatto a essere gestito in modalità headless. Ho scartato sia Raspbian che Bananian, che ho comunque provato, a causa della mia cordiale antipatia per Debian. Esiste sul sito ufficiale un’immagine di Fedora 20 dotata di Xfce4, che comunque presenta uno strano problema: anche con le cpu idle rilevo sempre un valore di carico compreso tra 1 e 1.20 e la cosa non mi piace molto. Sembrerebbe un problema di carico permanente sul bus I/O e comunque indica che la distribuzione non è “perfetta”. Su Bananian questo non succede, sintomo che almeno non è un problema di tipo hardware o dovuto alla microSD. L’alternativa sarebbe quella di provare le immagini ARM che sono disponibili sul sito di FedoraProject, che tra l’altro si riferiscono anche a Fedora 22, e quella è la direzione che intendo prendere. Staremo a vedere.

Fedora 22 (intel): non ci siamo….

L’ho provata sulla piattaforma di virtualizzazione VMware Fusion. Purtroppo il login manager gdm utilizza di default Wayland, e ho rilevato che puntualmente dopo qualche minuto che si è fatta la login Fedora “butta fuori” l’utente e torna  alla schermata di login. Come se non bastasse , essendo costretti a rifare di nuovo la login, e la cosa già sarebbe grave, troviamo il processo Xwayland che occupa stabilmente la cpu al 100%. Ora: passi il kernel 4, passi il nuovo gestore dei pacchetti dnf al posto di Yum, ma se una cosa non è stabile non mettetela, e per di più installata di default. Non ci siamo, non ci siamo proprio…… peggio di Windows!

Questo problema l’ho rilevato sulla versione principale che utilizza come gestore grafico Gnome. Provando le cosiddette “spin”, come quella Xfce ed anche Mate per fortuna tutto questo non succede. Oramai Gnome nella mia lista di preferenze dei Desktop Manager è veramente scivolata all’ultimo posto un po’ in tutte le distribuzioni.