Bananian Linux: il triste annuncio

E’ proprio di oggi l’annuncio sul sito ufficiale che Bananian Linux è giunto alla fine dello sviluppo.

https://www.bananian.org/news

Viene garantito almeno 1 anno di ulteriori patch di sicurezza ma la storia di Bananian Linux si conclude qui. Peccato, perché tra le varie schede che ho provato in questi ultimi anni nulla si è rilevato stabile, granitico e affidabile come il mio Banana Pro con installato proprio Bananian  come sistema operativo. Non c’è Raspberry che tenga, e poi quella porta SATA che gli altri non hanno ha fatto veramente la differenza. Gli sviluppatori del team passano idealmente il testimone alla distribuzione Armbian 

https://www.armbian.com/download/

che è in grado tra l’altro di gestire una moltitudine di schede attualmente in commercio. Non mi rimane che fare i complimenti al team di sviluppo per l’ottimo lavoro svolto su questa distribuzione, a mio parere la migliore Debian per ARM.

OpenSuse per Raspberry Pi3: perplessità

Una cosa mi ha lasciato molto perplesso: ho provato a fare in modo che la distribuzione partisse senza interfaccia grafica, per poterla utilizzare in modo molto più efficiente come server. Conosco la Suse da anni e so che da diverso tempo non gradisce in genere che si intervenga direttamente sui file di configurazione in /etc per cui ho utilizzato Yast (Gestione Servizi) per portare la distro a livello “Multi User”, ovvero con partenza in modo testuale senza desktop.

Alla ripartenza tutto appare bloccato, la console non dà segni di vita e il Raspberry non entra neanche in rete, negando un accesso remoto SSH che avrebbe aiutato ad investigare il problema. Come controprova ho creato un’altra microSD e fatto ripartire il sistema ho riprovato ad effettuare la stessa operazione da Yast, che dovrebbe risultare totalmente lecita (da una OpenSuse su piattaforma Intel effettua effettivamente il passaggio al runlevel Multi-User). Niente da fare, stesso risultato. Blocco completo della OpenSuse.

Non so se questa cosa sia riproducibile anche da altri che hanno installato questa distribuzione, ma nel mio caso mi dà senz’altro un’impressione di fragilità e instabilità intollerabile per l’utilizzo sul Raspberry. Francamente mi dispiace perché almeno su piattaforma Intel ritengo la OpenSuse una delle migliori distro in circolazione, ma sul Raspberry non me la sento proprio di utilizzarla in queste condizioni.

OpenSuse per Raspberry Pi3: un vero sistema operativo a 64 bit

E’ ora di mettere alla prova il nostro Raspberry Pi3 con un vero sistema operativo a 64 bit. Per ciò che mi risulta finora nessuno si è mosso tramite la Suse, che comunque in precedenza non mi aveva impressionato molto favorevolmente con la sua immagine per Raspberry. Da novembre 2016 Suse ha messo a disposizione sul suo sito la versione Enterprise (SLES) per Raspberry, ma trattandosi comunque di una release commerciale ha messo a disposizione degli utenti 1 anno di aggiornamenti gratuiti (previa registrazione) dopo di che si paga.

Quando l’ho letto mi è venuto un pò da ridere, pensavo a qualcuno che possa inserire un sistema Linux su un Raspberry per pagare una subscription annuale, cosa che su server professionali su piattaforme Xeon  ci può anche stare, ma su un Raspberry…… dai……… andiamo……… :)))

Comunque speravo che si muovesse anche la release OpenSuse, ed infatti dal mese di febbraio 2017 è stata aggiornata anche questa versione, completamente gratuita e quindi in linea con la filosofia di utilizzo di un Raspberry. Gli ultimi files immagine risalgono al 17 marzo, quindi tra l’altro sono stati aggiornati molto recentemente.

Innanzitutto dove scaricare le immagini “ready-to-use” per l’RPI3?

Da qui:

https://en.opensuse.org/HCL:Raspberry_Pi3

Consiglio di installare la Leap Image (quella più in alto nella pagina) e nel mio caso ho preferito quella con la grafica gestita da XFCE, semplice ma molto gradevole a vedersi.

Nel sito ci sono anche delle brevi istruzioni relative alla copia dell’immagine sul supporto microSD che utilizzeremo nel Raspberry quindi non mi dilungo. Alla partenza della distribuzione ci sarà un ridimensionamento automatico delle partizioni per cui non sarà necessario nessun adattamento manuale per poter utilizzare tutto lo spazio della microSD. Inoltre esiste solamente l’utente “root” a cui la Suse ha assegnato la password “linux”.

La scheda ethernet prenderà in DHCP un indirizzo sulla propria rete, quindi se è connesso un cavo  lan l’RPI3 sarà subito in rete, se abbiamo solo una connessione WI-FI……. non funzionerà. Ebbene sì, la scheda wi-fi non viene riconosciuta e bisogna modificare un file di configurazione per farla riconoscere e funzionare.

Apriamo il terminale.

Quindi entriamo nel file /etc/dracut.conf.d/raspberrypi_modules.conf con un editor come VI e togliamo dalla prima riga “sdhci_iproc” lasciando tutto il resto.

Lanciamo il comando < mkinitrd -f > e facciamo un reboot. Ora saremo in grado di sfogliare le reti wi-fi disponibili e collegarci alla nostra. Come dicevo l’aspetto del desktop è piuttosto gradevole.

Nei prossimi giorni cercherò di utilizzarla sia come ambiente desktop che server per vedere come si comporta rispetto alla “solita” Raspbian, tenendo conto che in questo caso si tratta di un vero ambiente a 64 bit.

 

Aggiornamento a PHP7

Ho aggiornato il blog tornando alla Raspbian Jessie ma portando la versione del PHP alla più recente 7, tanto decantata dai programmatori per la sua maggiore velocità ed efficienza nella gestione della memoria. In effetti mi sembra proprio che la navigazione sia più veloce di prima e finora WordPress non mi ha dato alcun problema.

Ho seguito le istruzioni, molto semplici, presenti in questo sito:

https://www.stewright.me/2016/03/turn-raspberry-pi-3-php-7-powered-web-server/

partendo da una Raspbian Jessie “pulita”, appena installata. Ripeto, almeno ad ora, la compatibilità con la versione più recente di WordPress mi sembra ottima.

ESP8266-12e l’indistruttibile!

Eccolo qua, il chip della mia stazione meteo, dopo circa 1 anno di onorato servizio esposto alle intemperie. L’umidità, lo smog, la polvere e qualche sporadica goccia d’acqua lo hanno pesantemente minato ma vi assicuro che funziona ancora perfettamente. Ancora lontano dall’andare in pensione nonostante la comparsa dell’ESP32 (che però costa 4 volte tanto).

CentOS 7.3 per Raspberry uscita il 14 dicembre

Dal 14/12 sono state rese disponibili le nuove immagini della CentOS 7 per Raspberry aggiornate alla versione 7.3. Ne ha dato annuncio Fabian Arrotin sulla mailing list dedicata al progetto. Le immagini sono reperibili alla URL:

http://mirror.centos.org/altarch/7/isos/armhfp/

insieme a quelle dedicate al Banana Pi, Cubieboard e Cubietrack.

Maggiori particolari reperibili alla URL:

https://wiki.centos.org/SpecialInterestGroup/AltArch/Arm32

Per chi avesse (come me) già installata la versione 7.2 uno [ yum update ] provocherà il passaggio alla nuova versione tramite aggiornamento di 191 pacchetti.

P.S.

Aggiungo come nota personale che è rimasto un fastidioso bug riguardante il servizio ntpd. Nonostante venga messo in stato “enabled” non parte automaticamente all’avvio del sistema. Al momento non ho trovato una soluzione, gli script di sistema sembrano a posto, per cui in caso di reboot del server farlo ripartire manualmente.

MacOS Sierra e driver CH340/41

Faccio brevemente il punto della situazione in base alla mia esperienza perché chi ha aggiornato a Sierra (come me) le sue macchine MacOS ha potuto sperimentare all’inizio una pletora di Kernel Panic ogni qual volta veniva collegata una scheda ESP8266 ai Mac.

Aggiornare ASSOLUTAMENTE i driver CH34X alla versione 1.3. Le versioni precedenti produrranno reboot continui di Sierra finché non verrà staccato il cavo USB collegato ad un ESP8266. Esistono vari link dove procurarsi l’ultima versione. Eccone ad esempio uno:

https://github.com/adrianmihalko/ch340g-ch34g-ch34x-mac-os-x-driver

Rimuovere la versione precedente prima di installare i nuovi driver. In genere si tratta di rimuovere semplicemente da terminale il file usb.kext

Non è più necessario disabilitare la System Integrity Protection sul Mac per far sì che vengano viste le porte usb-serial di Arduino e degli ESP.

Quest’ultima è veramente una bella notizia. Si può ricominciare ad usare tranquillamente la IDE di Arduino senza abbassare la sicurezza del Sistema Operativo.

Linux Mint 18 sul MacBook Bianco

macbook_biancoMi serviva un portatile dedicato per Linux. Solo Linux, senza virtualizzazione né doppia partenza con un altro sistema operativo. Perché non riciclare il mio vecchio MacBook bianco fine 2009? E’ fornito “solamente” di una CPU Intel Core 2 Duo a 2.26 GHz, ma col passare del tempo l’ho dotato di 8 Gb di RAM e di un paio di SSD (rispettivamente 240 Gb e 480 Gb) al posto dell’HDD a piatto rotante originale e dell’ormai (quasi) inutile masterizzatore DVD. Si difende quindi molto bene, anche se confrontato con un attuale portatile di fascia media. Non ha certo le prestazioni di una game machine, ma per un uso “office” va più che bene.

Ho deciso di installarci l’ultima Linux Mint attualmente disponibile, la 18 Cinnamon, probabilmente una delle scelte più indicate per un’installazione desktop ma soprattutto perfetta per chi, come me, non ama molto Unity e tantomeno le ultime GUI Gnome. Come dicevo prima, volevo che la macchina facesse girare solamente Linux in modo nativo e che soprattutto non avesse problemi con l’hardware Apple, principalmente la scheda di rete wi-fi e la telecamera iSight.

Prima di procedere, quando ancora c’e ancora Mac OS installato (ora si chiama di nuovo così a partire da Sierra) è bene fare in modo che il “Dong” classico dei Mac emesso alla partenza venga regolato ad un volume piuttosto basso perché dopo, sotto Linux non sarà più possibile variarne il volume.

L’installazione della Mint è semplice: inserito il DVD della distro in un lettore esterno, nel mio caso, è stato sufficiente far ripartire il Mac con il tasto Alt premuto ed aspettare che il Bios proponesse se partire con Mac OS, la partizione di ripristino oppure Windows (!). Sì, proprio Windows. Ovviamente si trattava del DVD esterno con su Linux, ma tant’è…..

Finita l’installazione, arrivato il momento di far ripartire la distro installata, il Mac si bloccava. Ho dovuto spegnere e riaccendere il portatile e la Mint è partita correttamente. Chiaro però che c’era un problema a fare un “warm reboot” con Linux (reboot da GUI, da terminale che sia). Il problema si presentava molto fastidioso, perché tra l’altro impediva di riavviare in qualche modo da remoto il portatile. Probabilmente qualcosa che non andava tra la funzione del kernel in “reboot.c” e il Mac stesso. Fortunatamente il problema è risolvibile e richiede l’inserimento di un parametro nel file di configurazione di GRUB, il boot manager di Linux. Vediamo come.

Entriamo da terminale nella directory /etc/default ed apriamo con l’editor “vi” il file “grub”

ora modifichiamo la riga contenente GRUB_CMDLINE_LINUX_DEFAULT in modo che contenga:

aggiorniamo GRUB con il comando

e saremo in grado di far ripartire correttamente Linux. Devo dire che questo è un problema lamentato da molti che hanno deciso di togliere Mac OS dal portatile Apple a favore di una distro Linux (mi risulta che anche Linus Torvalds lo abbia fatto sul suo Mac Book Air 🙂 ) e che in alcuni casi viene riferito che il problema sia stato risolto con il parametro “reboot=bios”. Non è comunque il mio caso con questo modello di MacBook.

Per il resto sono piuttosto soddisfatto. I tasti relativi alla luminosità dello schermo funzionano, quelli di regolazione volume idem, la scheda di rete wi-fi ha funzionato al primo colpo e così ha fatto anche la iSight con Skype. Rimane da vedere quanto sarà ottimizzato il consumo della batteria, che dopo 6.5 anni di onorato servizio durava sotto Mac OS ancora circa 3 ore e mezza. Vedremo.

Non mi risulta che Linux, nonostante la Mint utilizzi un kernel molto recente, gestisca in automatico il trim degli SSD (ma potrei sbagliarmi) quindi nel dubbio provvederò a mettere nella crontab utente le chiamate periodiche all’eseguibile “fstrim”.

Mi manca il trascinamento a 3 dita delle finestre presente in Mac OS nel menu Accessibilità che trovo comodissimo quando si usa solo il trackpad; quindi è necessario tenere il dito schiacciato sul pad e muovere per spostare una finestra sullo schermo. Questo mi dà un pò fastidio, ma non è un problema insormontabile.

Inutile dire che con la IDE di Arduino tutto funziona perfettamente 🙂

 

Nel caso si voglia installare una distribuzione più adatta ad agire come server, una RedHat o CentOS 6.x, la versione di Grub è differente (la 1, più vecchia di quella usata dalla Mint) per cui lo stesso comando va inserito nel file /etc/grub.conf in tutte le voci di menu (come da figura). Non esiste un comando update-grub quindi va fatto il poweroff del notebook per poi ripartire. Quando si aggiorna il kernel e quindi viene creata una nuova voce nel menu va aggiunto di nuovo l’opzione reboot=pci.

centos

RedHat / CentOS 7 – Far ripartire automaticamente un processo dopo un crash

Ci sono dei processi su un server che abbiamo necessità siano sempre up, ovvero funzionanti. Può accadere che a causa di un crash questi cadano e purtroppo, tranne alcuni casi, siamo costretti a controllare manualmente e  a intervenire per riavviarli da console. Vedremo come fare in modo da impostare un processo in modo tale che in caso di caduta riparta da solo in automatico. Va da sé che se il nostro processo ha delle problematiche tali che cade in continuazione anche se riavviato dobbiamo capire perché questo succede ed eliminare la causa del malfunzionamento. Ma per fortuna la maggior parte delle volte un processo può essere fatto ripartire senza problemi. Farò l’esempio del demone “ntpd” (l’aggiornamento dell’ora esatta) perché mi capita, specialmente sui Raspberry, di trovarlo qualche volta “caduto” misteriosamente.

Premetto che questa procedura funziona esclusivamente sulle distribuzioni di Linux che utilizzano “systemd” come controllore di processi, quindi Raspbian Jessie e Centos 7 nel caso dei Raspberry. Nelle distro precedenti, basate su “initd” si interveniva all’interno del file /etc/inittab o con l’upstart e non mi dilungherò su queste procedure.

Innanzitutto avremo fatto in modo che il nostro servizio sia in grado di ripartire automaticamente al reboot del server, tramite il comando:

Fatto questo entreremo nella directory sotto indicata e cercheremo il file .service associato al nostro servizio:

Eccolo qui, evidenziato (ntpd.service). Apriamo un editor e aggiungiamo nella sezione Service la riga contenente Restart=always

Salviamo il file, ricarichiamo i demoni e facciamo ripartire il nostro servizio.

A questo punto per testare se effettivamente funziona la ripartenza automatica NON useremo un comando systemctl stop, che essendo uno stop volontario non causerà una ripartenza ma dovremo fare un kill del processo, simulando un crash. Facciamo ad esempio un systemctl status ntpd e leggiamo il Main PID del processo. Supponendo sia 8382 diamo poi un comando:

Chiedendo di nuovo lo status del processo vedremo che è stato immediatamente fatto ripartire, ovvero lo troveremo in stato active running.

 

 

ESP8266 – Collegare più sensori analogici

Usando ormai da svariato tempo schede basate su ESP8266-12 ho imparato a convivere con i due limiti operativi di questi controller, ovvero il non indifferente consumo di corrente, il che ne rende problematica l’alimentazione con batterie e la presenza di una sola entrata analogica.

Il primo problema è in qualche modo aggirabile ricorrendo alla gestione in Deep Sleep di un nodo, quando però non è richiesto che il nodo debba essere sempre “sveglio” e vigile, in attesa di eventi estemporanei. Nel secondo caso invece è invece necessario ricorrere a chip esterni, tipo l’MCP3008 o MCP3208, che mettono a disposizione un certo numero di entrate analogiche da gestire ad esempio sul bus SPI. D’altronde è lo stesso problema che hanno i Raspberry, che di entrate analogiche non ne hanno proprio.

Esistono comunque in giro degli schemi semplificati che permettono agli ESP8266 di lavorare con più sensori analogici contemporaneamente effettuando una sorta di multiplexing via software. Ho realizzato un circuito di test composto da un controller Wemos D1 mini (ma anche una qualsiasi altra scheda basata sull’8266 va benissimo) e tre fotoresistori GL5539, a rappresentare genericamente 3 sensori analogici.

a0_multipli

Nella parte superiore della breadboard ci sono i soliti rail di alimentazione, 3.3V in questo caso, tensione che costituisce anche la Vref per i sensori. Questo perché nonostante il datasheet di Espressif citi come voltaggio di riferimento per l’entrata analogica A0 i valori da 0 a 1V, nelle schede commerciali in genere un partitore di tensione interno riporta il Vref ai più comodi valori compresi tra 0 e 3.3V.

Ogni sensore ha la sua resistenza di pull-down di 10K, che può variare a seconda di cosa stiamo usando e, cosa molto importante, ogni singolo circuito relativo ad un sensore analogico è isolato dagli altri tramite un comune diodo. In questo modo i sensori non si influenzeranno tra loro quando attiveremo di volta in volta i rispettivi pin digitali a cui sono connessi. Senza i diodi avremo comunque letture scombinate, provare per credere.

a0_multipli_2

In basso ho creato un common rail per convogliare i segnali analogici provenienti dai sensori e indirizzati all’entrata A0 del controller. Sarà quindi lo sketch, prima di effettuare la lettura sul singolo sensore, a portare a livello alto il relativo pin digitale e a portare a 0V gli altri 2.

Ecco lo sketch di esempio:

La cosa sembra funzionare. Dov’è il problema? I diodi, naturalmente. Questi provocano per loro natura una certa caduta di tensione nel circuito. Nel mio caso è esattamente di 0.5V, il che significa che il voltaggio di riferimento viene abbassato da 3.3V a 2.8V e avremo letture raw che non vanno da 0 a 1023, ma da 0 a 870 sballando tra l’altro la formula che uso per il GL5539 che dovrebbe diventare:

Insomma, se vogliamo convivere con questa situazione, una volta dedotto il valore massimo che otteniamo dopo la caduta di tensione (es. 870) possiamo rimappare le nostre entrate analogiche “virtuali” con una istruzione del tipo:

val = map(val,0,870,0,1023);

tenendo conto però che stiamo perdendo risoluzione sulle letture analogiche, e quindi qualità sul valore ritornato. Se tutto questo è per noi accettabile va bene, altrimenti è decisamente meglio passare a veri multiplexer, quindi chip esterni del tipo MCP3008 che sono comunque gestibili molto facilmente e che occupano sempre e comunque 4 pin digitali. In questo caso i valori letti saranno accurati al 100% (10 bit).

Una scheda che però mi intriga ancora di più e che ho intenzione di provare è la ADS1015 di Adafruit, che mette a disposizione 4 entrate analogiche ad alta risoluzione (12 bit, ovvero non più 1024 valori ma 4096) a guadagno variabile, anche se al costo di circa 10$. Il massimo della flessibilità insomma visto che veicola i dati sul bus I2C, impegnando solo 2 pin per i segnali.