lunedì 7 dicembre 2020

OpenBSD 6.8 Sparc64

Ho due portatili RDI/Tadpole, uno SPARCLE e uno SparcBook 6500 e su entrambi è installato OpenBSD 6.7 che da molti anni ormai sembra essere l'unico sistema operativo, oltre al nativo Solaris 9/10, che funziona in maniera decente su queste macchine.

Sullo SPARCLE ho eseguito l'aggiornamento alla 6.8 partendo con il boot da CROM e tutto è andato liscio come l'olio. Fiducioso ho fatto la stessa cosa con lo SparcBook e l'installazione/aggiornamento da CD non ha dato il minimo problema, però al primo riavvio è arrivato un bel kernel panic con errori in lettura dal file system e questo ad ogni riavvio.

Quindi ho riavviato dal CD di installazione di OpenBSD e aperto una shell per fare il check del file system di root che è risultato gravemente corrotto, tanto da essere praticamente irrecuperabile. Poco male mi sono detto, per modo di dire .... reinstallo tutto da zero riformattando il disco.

Bene, l'installazione da zero va alla grande, nessun errore segnalato .... al riavvio solito kernel panic. Come è possibile mi chiedo ? .... forse il CD ? Rifaccio un nuovo CD e ripeto l'installazione, ancora una volta nessun problema fino al riavvio dove appare il solito kernel panic.

OK, a questo punto per non saper ne leggere ne scrivere deduco che c'è qualcosa che non va con la 6.8, cosa ? boh ? Sullo SPARCLE è andato tutto bene, OK ci sono differenze hardware tra i due modelli e una di queste è il disco fisso .... ma può essere questo il problema ? Quindi ripiego e reinstallo la 6.7 che ovviamente funziona perfettamente e mi permette di avere un sistema funzionante. Cosa devo pensare se non che con la 6.8 ci sia qualcosa che non fa con qualche specifica componente hardware dello SparcBook, qualche cosa che non c'era con la 6.7 .... ma purtroppo le mie competenze non mi permettono, al momento, di andare oltre.

Il fatto che sia il file system ad andare in crash non è che possa dire molto perché ricordo che anche con lo SPARCLE dopo un pò di utilizzo della macchina arrivavano una sfilza di errori che la mandavano in crash e sembravano legati all'attività del disco ma poi alla fine avevo scoperto che era il driver della scheda wireless ....una volta rimossa la connessione senza fili il problema è sparito.

Sarebbe un vero peccato se anche OpenBSD non fosse più aggiornabile su questa macchina.



Validare la IDPROM su uno Sparcbook

Tempo fa in questo post avevo descritto la procedura per aggiornare il contenuto della IDPROM su un portatile RDI/Tadpole, che è una macchina con CPU Sparc64 in formato notebook.

Purtroppo questo portatile ha presentato un problema con il display, ovvero non visualizzava più nulla, si vedeva che il display si illuminava ma oltre a questo nessun segno di vita.

Collegandovi un monitor ho potuto appurare che la scheda video era ancora integra infatti sul display LCD esterno funzionava tutto a dovere. Ho quindi pensato di smontare il display del portatile per controllare il cavo flat ma senza successo, ovvero sembrava tutto regolare ma non arrivava l'output video. Quando poi mi sono messo di buona lena ho smontato anche la base del portatile e rimosso anche la batteria NVRAM. 

A questo punto forse ho toccato anche qualche altro cavo perché riaccendendo il portatile l'output sul display del portatile è magicamente riapparso, anche se in maniera piuttosto sgranata, cioè i caratteri non sono ben definiti anche se abbastanza leggibili. Ovviamente è apparso anche il messaggio che indicava che il contenuto della IDPROM era invalido.

A questo giro ho deciso di usare il comando set-host-id che stando alla documentazione usa come parametro il numero di serie del portatile per ricostruire una serie di dati in modo che la IDPROM venga validata. Il numero di serie viene visualizzato al boot in alto a destra assieme ad altre informazioni. La procedura da seguire è questa, al prompt OK per prima cosa si indica il numero di serie e si preme INVIO, non succede nulla, o meglio il valore viene messo sullo "stack", ora si digita il comando set-host-id che preleva il valore immesso sullo stack e lo usa per "ricostruire" il contenuto della IDPROM, poi un bel reset-all ed il gioco è fatto.

Per quanto riguarda il display e la "sgranatura" sarà sempre qualche problema con qualche contatto ..... ma per ora lascio stare.

 

sabato 12 settembre 2020

FreeBSD : Mate Desktop non si avvia più

E' da qualche tempo che non avvio più FreeBSD e oggi ho pensato di fare anche gli aggiornamenti di rito con la classica sequenza :

pkg update

pkg upgrade

dopo aver aggiornato una serie di pacchetti al successivo riavvio non riesco più a loggarmi  dal display manager SLiM.

Allora provo a loggarmi da console ( Control+ALt+F1 ) e digito startx per vedere cosa succede e vedo un messaggio del genere :

mate-session - Glib-GIO-ERROE: Settings schema 'org.mate.interface' is not installed

Da una veloce ricerca in rete scopro che forzando un aggiornamento completo dovrei risolvere il problema, e quindi eseguo questi comandi in sequenza :

pkg autoremove -y

pkg update -f

pkg upgrade -f

L'ultimo comando mi fa scaricare e aggiornare una valanga di pacchetti per centinaia di megabyte e dopo un riavvio posso di nuovo loggarmi in Mate senza problemi .... o quasi. Ora non ho più la possibilità di spegnere e/o riavviare il computer dal menù di Mate.

Il problema è che con questo aggiornamento ho perso alcune modifiche fatte al tempo della prima installazione per attivare questa funzionalità in Mate.

Per risolvere bisogna modificare il file /usr/local/share/polkit-1/actions/org.freedesktop.consolekit.policy modificando la voce <allow_inactive> da "no" a "yes" per le azioni "stop" e "restart".

Adesso, o meglio, dal prossimo login le opzioni saranno attive.

Buon FreeBSD a tutti.


 


 

sabato 4 luglio 2020

Come sfuttare un vecchio Linksys NSlu2 nel 2020

Tempo fa recuperai un vecchio NSlu2 sul quale ora gira una "vecchia" Debian Wheezy.
Fino a qualche giorno fa lo usavo solo come piccolo server FTP, che tra l'altro usavo poco, in quanto ho già un altro paio di NAS che fanno da FTP dove salvo programmi e ISO di vari sistemi operativi, quindi mi sono detto che forse dovevo sfruttarlo in qualche altra maniera.
Ora io non sono proprio uno sfegatato di eMule, Torrent e compagnia bella ..... però ogni tanto qualche torrent mi capita di scaricarlo e con eMule si trova molto materiale quindi ho cercato una soluzione alternativa ad eMule che girasse su linux offrendo un'interfaccia di gestione remota via WEB.
E alla fine ho deciso di provare MLDonkey.
Ho scaricato i sorgenti e li ho copiati sullo NSLu2, ho installato una serie di dipendenze per poter compilare il pacchetto .... ebbene si su questo "mostro" con 32 mega di RAM e CPU a 266Mhz  si può persino compilare, se si ha un pò di pazienza.
La compilazione del pacchetto è molto semplice, l'unica accortezza che ho dovuto avere è stata in fase di configurazione :
./configure --enable-force-upnp-natpmp
in questo modo vengono scaricati e usati per la compilazione del supporto UPNP e NATPMP dei sorgenti aggiornati, questo perchè le librerie presenti in Wheezy sono troppo vecchie e non campatibili con MLDonkey.
Alla fine della compilazione mi sono trovato un unico file mlnet, un binario compilato staticamente, quindi senza dipendenze esterne, che ho copiato in /usr/local/bin.
Su come configurare MLDonkey si trovano in rete tutte le informazioni che servono, quindi non affronto l'argomento, per dovere di cronaca io sono partito da questa guida saltando ovviamente la parte di installazione che nella guida è fatta da repository mentre io ho compilato da sorgenti.
Come si evince dalla guida la configurazione si può fare via telnet o da browser, però se il programma non è in esecuzione è possibile intervenire anche direttamente sul file download.ini che viene creato nella cartella .mldonkey nella home dell'utente. Onestamente non ho idea di come sia organizzata l'installazione fatta direttamente da repository o da pacchetto deb se disponibile.
Più problematico invece è stato trovare una soluzione per avviare automaticamente il programma in maniera che girasse come utente non privilegiato e salvasse configurazione e download in una cartella utente poi accessibile anche via FTP.
Sono partito dalle informazioni e script riportate qui che però ho modificato in quanto non funzionanti sulla mia Wheezy.
La mia versione modificata :

#! /bin/sh
#
# mldonkey      init.d script to start MLDonkey
#

### BEGIN INIT INFO
# Provides:          MLDonkey
# Required-Start:    $syslog $local_fs $network
# Required-Stop:     $syslog $local_fs $network
# Should-Start:      $named
# Should-Stop:       $named
# Default-Start:     2 3 4 5
# Default-Stop:      0 1 6
# Short-Description: Starts MLDonkey
# Description:       MLDonkey, multinet peer-to-peer server/client
### END INIT INFO

PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin
DAEMON=/usr/local/bin/mlnet
NAME=MLDonkey
MLDIR=/home/nslu/.mldonkey
DESC="MLDonkey, multinet peer-to-peer server/client"

test -x $DAEMON || exit 0

set -e

case "$1" in
  start)
        echo -n "Starting $DESC: $NAME"
        start-stop-daemon --start --chuid nslu --chdir $MLDIR \
                --make-pidfile --pidfile /var/run/$NAME.pid --exec $DAEMON > /dev/null 2>&1 &
        echo "."
        ;;
  stop)
        echo -n "Stopping $DESC: $NAME "
        start-stop-daemon --stop --quiet --pidfile /var/run/$NAME.pid
        echo "."
        ;;
  restart|force-reload)
        #
        #       If the "reload" option is implemented, move the "force-reload"
        #       option to the "reload" entry above. If not, "force-reload" is
        #       just the same as "restart".
        #
        echo -n "Restarting $DESC: $NAME"
        start-stop-daemon --stop --quiet --pidfile /var/run/$NAME.pid
        sleep 1
        start-stop-daemon --start --chuid nslu --chdir $MLDIR \
                --make-pidfile --pidfile /var/run/$NAME.pid --exec $DAEMON > /dev/null 2>&1 &
        echo "."
        ;;
  *)
        N=/etc/init.d/$NAME
        echo "Usage: $N {start|stop|restart|force-reload}" >&2
        exit 1
        ;;
esac

exit 0

poi ho eseguito questi comandi per attivare lo script al boot.
chmod +x /etc/init.d/mldonkey
update-rc.d mldonkey start 98 2 3 4 5 . stop 20 0 1 6 .
La configurazione viene creata nella cartella .mldonkey nella home dell'utente, nel mio caso l'utente nslu2, così come in specifiche sottocartelle vengono salvati i file in fase di download.

Per accedere alla pagina WEB dall'esterno è sufficiente indicare l'indirizzo IP dello NSlu2 seguito dalla porta TCP su cui il server è in ascolto, quindi qualcosa tipo :
http://192.168.1.222:4080
ovviamente prima di poter accedere da remoto bisogna impostare MLDonkey in modo che accetti connessioni diverse da localhost.

Ecco un altro modo per riutilizzare vecchio hardware e questo sempre grazie a linux.
 

giovedì 23 aprile 2020

ReactOS

ReactOS è un progetto software che mira a creare una sorta di clone di Windows 2000, esiste da molti anni ed è ormai alla versione 0.4.13, giusto per capire con cosa abbiamo a che fare.
Ad ogni nuova versione provo a vedere se si installa su uno dei miei vecchi PC .... ma fino ad oggi non c'è stato nulla da fare perché appena dopo il boot quando veniva chiesto di impostare la lingua per l'installazione la tastiera non rispondeva in nessun modo rendendo impossibile proseguire.
Ma con quest'ultima release la tastiera funziona !!!
Ho quindi installato ReactOS su un vecchio portatile Pentium III ..... ma con risultati tutt'altro che incoraggianti.
Infatti al primo riavvio l'opzione di default per l'avvio del sistema porta solo ad un blocco a 3/4 del caricamento del sistema operativo .... senza nessun messaggio che indichi su cosa si sia bloccato.
Avviando e scegliendo l'opzione debug il sistema si avvia correttamente e la prima volta procede con la rilevazione dell'hardware .... nel mio caso, anche se si tratta di un portatile con ormai 20 anni sul groppone, ci sono parecchie componenti per le quali mancano driver nell'installazione di ReactOS.
Fortunatamente il driver per la scheda di rete integrata, una Realtek, ci sono e quindi è possibile collegarsi in rete in maniera automatica con il DHCP e usare lo strumento di gestione pacchetti software fornito con ReactOS, che pare essere anche ben fornito.
La risoluzione dello schermo del portatile è di 1400x1050 ed è possibile impostarla fino a 24bit di colore, non c'è un driver specifico ( è una ATI Rage 128 ) e quindi è di una lentezza spaventosa.
Ho provato ad installare, dal CD originale a supporto del portatile, i driver VIA per la scheda madre e quelli ATI per la scheda grafica, purtroppo entrambi i programmi di setup sono in realtà applicazioni windows a 16 bit che non sono supportate su ReactOS.
Magari con qualche magheggio è pure possibile riuscire a installare questi driver e avere prestazioni da rendere utilizzabile il sistema, perché adesso la reattività è pari a zero .... ma non penso ne valga la pena, magari farò delle prove installando ReactOS su VirtualBox giusto per curiosità.

mercoledì 22 aprile 2020

NetBSD 9.2 - “Of course it runs NetBSD”

Sicuramente è colpa mia, della mia ignoranza o sfiga, ma io e NetBSD proprio non ci troviamo in nessuna maniera.
“Of course it runs NetBSD”
a tutto il mondo meno che a me a quanto pare.
Avevo già scritto che su un vecchio portatile Pentium III l'installazione di NetBSD aveva talmente tanti problemi in relazione all'ACPI da non rilevare nemmeno la scheda di rete integrata e da essere praticamente inutilizzabile.
Vabbé è un vecchio catorcio .... colpa dell'hardware .... anche se
“Of course it runs NetBSD”
Avevo già anche scritto dei vari tentativi fatti con la versione sparc64 su un portatile TADPOLE SPARCBook .... dove solo la versione 7.0 di NetBSD si installa, quelle precedenti non rilevano la tastiera del portatile e quelle successive mandano in blank screen il monitor.
Vabbé è un portatile molto raro, nato per Solaris .... colpa dell'hardware .... anche se
“Of course it runs NetBSD”
L'installazione su di un Thinkpad X60 funziona abbastanza bene, se tralasciamo il fatto che al termine dell'installazione quando viene richiesto il riavvio si "blocca" per tanto di quel tempo che all'inizio credevo fosse proprio bloccato ... bisogna avere solo molta pazienza. 
Ma di un sistema operativo senza software cosa me ne faccio ? Voglio un desktop, anche se so che in generale BSD e desktop non sono proprio un buon connubio. Peccato che per l'architettura i386, il Thinkpad X60 monta una CPU a 32 bit, non ci sono ne XFCE ne MATE.
Vabbè ma nel 2020 chi usa più hardware a 32 bit ? Anche se 
“Of course it runs NetBSD”
e comunque sia con OpenBSD che FreeBSD su questo stesso portatile ho installato MATE.
Ma proviamo con un Thinkpad X61, questo ha una CPU a 64bit, una Intel T7500 e 4 giga di RAM con un bell'hard disk da 320 giga e 7200rpm.
Terminata l'installazione vado a installare MATE che è presente per l'architettura amd64, così come è presente anche XFCE.
Installo MATE, configuro la localizzazione in italiano, e creo la configurazione di Xorg per avere il layout della tastiera in italiano ... configuro .xinitrc e .xsession per avviare MATE e provo l'avvio con startx .... sembra tutto a posto.
Anzi ho pure l'impressione che MATE funzioni meglio in NetBSD che non in OpenBSD, almeno nella versione amd64, dove su OpenBSD da errore l'esecuzione di Caja, il file manager.
Resta solo da installare e configurare Slim per il login grafico.
E qui NetBSD getta la maschera dichiarando che mi odia .... non ci sono altre spiegazioni. Mi odia.
Infatti riavviato il portatile appare la maschera di login .... senza cursore del mouse. Mi azzardo a scrivere qualcosa e i caratteri digitati per il nome utente non appaiono nel box relativo .... però qualche carattere salta fuori sulla sinistra.
Non va un cavolo. E' bloccato. Spengo di brutto e lascio perdere.
A distanza di qualche giorno ci riprovo e questa volta con un po di fortuna riesco a fare Control+Alt+F1 per accedere alla console .... dove sopra la riga di login vedo una file di numeri che  non hanno senso.
Provo a fare un dmesg ma l'unico risultato è una colonna infinita di numeri .. indirizzi e valori ? Boh chi lo sa .....non sarà sempre il solito inteldrm che come su OpenBSD da problemi ?
Comunque decido di rimuovere slim per provare xdm.
Il gestore di pacchetti pkgin mi dice che non c'è più il repository da cui scaricare i pacchetti ..... però.
Infatti il repository che puntava a ....9.0 non c'è più ed è diventato .... 9.0_current.
No comment.
Aggiorno la configurazione di pkgin per usare il nuovo repository, faccio un bel pkgin update seguito da pkgin upgrade e vedo che ci sono una valanga di pacchetti da aggiornare. Confermo e vado avanti pensando che forse un tale aggiornamento risolverà il problema riscontrato anche con il login manager.
Durante il download mi segnala per certi pacchetti che la dimensione scaricata non corrisponde a quella contenuta nel file pkg_summary.tgz.
E qui io fatto la fesseria di forzare e andare avanti ma al termine mi sono ritrovato con una serie di pacchetti non aggiornati ... così almeno mi sembrava, e non riuscivo più a installare slim.
Ancora una volta intervengo sulla configurazione del repository scegliendone un altro, solito giro di update e upgrade e questa volta si aggiorna tutto.
Manco per il c.... avviando MATE con startx viene fuori un casino allucinante, c'è mezza roba che manca e quello che c'è non funziona.
Provo a reinstallare MATE e infatti mi dice che sebbene non ci sia nulla da scaricare ci sono una sfilza di pacchetti da installare, così è anche per firefox e libreoffice.
Alla fine sembra tutto a posto ... a parte slim che si blocca, oppure si comporta in maniera imprevedibile, appare e scompare la videata, a volte appare il mouse, a volte quello che digiti viene visualizzato in maniera corretta .... ma in soldoni è inutilizzabile.
Purtroppo anche xdm si comporta nella stessa maniera.
Avviando con startx dopo il login da console sembra funzionare.
In conclusione, per quella che è la mia esperienza fino ad oggi, NetBSD è il peggiore tra i vari BSD per quanto riguarda l'esperienza desktop, OpenBSD ha i suoi bei problemi e FreeBSD è l'unico con il quale sia riuscito a realizzare un sistema desktop usabile sia nella versione i386 che in quella amd64.
Ovviamente continuerò a usare FreeBSD, quasi certamente anche OpenBSD ... NetBSD dubito fortemente.
“Of course it runs NetBSD”
Ma pare proprio di no sui miei portatili.






martedì 7 aprile 2020

Debian Wheezy repository

Debian Wheezy ? Nel 2020 ?
Ebbene sì, avendo un vecchio Linksys NSLU2 su cui è installato proprio Debian Wheezy, mi sono imbattuto in uno strano problema.
Questa versione di Debian è archiviata già da parecchio tempo quindi nel file sources.list avevo queste righe :
deb http://archive.debian.org/debian/ wheezy main contrib non-free
deb http://archive.debian.org/debian/ wheezy-backports main contrib non-free
deb http://archive.debian.org/debian/ wheezy-backports-sloppy main contrib non-free
il sistema è completamente aggiornato e funzionante, quindi tutto a posto ?
Quasi, perchè l'altro giorno ho pensato bene di installare il compilatore C e il debugger GDB, sebbene sia ben conscio che l'hardware non sia certo il più indicato per la compilazione ..... ma per qualche piccolo progetto potrebbe pure andare.
Ebbene eseguendo il comando apt-get per l'intallazione dei pacchetti mi venivano segnalati dei problemi con le dipendenze che non potevano essere risolti.
Mi è sembrata una cosa molto strana perché anche se Wheezy è una versione archiviata e non più mantenuta da un pezzo i repository dovrebbero essere comunque ancora funzionanti e non avere problemi di dipendenze.
Da una prima ricerca in rete le uniche informazioni che ho trovato dicevano semplicemente che Wheezy è troppo vecchia, non mantenuta e quindi di aggiornare.
Nel mio caso con quest'hardware aggiornare a Jessie non mi pare un'opzione, ho trovato in rete poche informazioni e nessuna che indicasse che l'aggiornamento sia fattibile e/o indolore.
Ho continuato le mie ricerche finché ho scoperto dell'esistenza di un altro repository per Wheezy, questo :
deb http://archive.debian.org/debian-security/ wheezy/updates main contrib non-free
quindi lo ho prontamente aggiunto, fatto un bel apt-get update e mi salta fuori questo bel messaggio :
E: Il file Release per http://archive.debian.org/debian-security/dists/wheezy/updates/Release è scaduto (non valido dal 362g 21h 29min 11s). Gli aggiornamenti per questo repository non verranno applicati.
e siamo punto e a capo.
Però mi dice da quanti giorni è scaduto e quindi provo a impostare la data al 31/12/2018, giusto per stare tranquillo, ed ecco che sia l'update che la successiva installazione dei pacchetti che mi interessano avviene in modo del tutto regolare.
Ripristino la data a quella odierna e posso compilare in tutta tranquillità .... e tanta pazienza.
 
 
 

martedì 17 marzo 2020

OpenBSD 6.6 su Tadpole SPARCle 500X


Tra i tanti "catorci" di computer che ho in giro c'è anche questo portatile con processore SPARC ( UltraSPARC IIe a 500mHZ ) fratello minore dell'altro Tadpole SparcBook 6500.
Sfortunatamente questo PC ha cominciato a dare una serie di problemi, primo tra i quali il display che non visualizza più nulla, si accende ma resta tutto nero. Nella sfiga c'è da dire che collegando un monitor esterno sull'uscita VGA si ottiene l'output video. Dalle prove fatte non è ne il cavo flat ne l'inverter, ne il display .... quindi resta fuori qualche contatto sulla scheda madre, non però il chip video, altrimenti anche su monitor esterno non andrebbe.
Detto questo c'è anche da dire che, pure su questo portatile, solo OpenBSD è utilizzabile, forse anche NetBSD ma SOLO nella versione 7.1, quelle precedenti e successive per un motivo o per l'altro nemmeno si installano.
OpenBSD quindi ..... ma anche qui ho avuto qualche problema, la cui natura mi è rimasta misteriosa fino ad un lampo di genio in una nottata insonne.
In pratica il portatile andava in kernel panic in continuazione lamentanto errori non correggibili di DMA, spegnere di brutto e poi avvio con controllo e correzione del file system.
La prima cosa a cui ho pensato è stato il disco e dopo averlo rimosso e ripulito i contatti del connettore IDE lo ho reinstallato. Niente da fare.
Allora penso che possa essere la RAM, presente con 2 diversi banchi da 512 mega per un totale di 1 giga, rimuovo prima un modulo, provo e niente ... ancora kernel panic. Per rimuovere il modulo principale che era bloccato dalle clip del modulo secondario ho finito per dover forzare e quindi si sono rotte le clip ..... pace, cambio il modulo di RAM e non risolvo una cippa.
Ormai temo sia la scheda madre prossima alla fine.
Poi l'illuminazione.
Questo portatile monta anche una scheda di rete wireless RALINK, che è supportata da OpenBSD e che infatti avevo configurato per non usare il cavo di rete. Quindi disabilito il wireless e vado di cavo e guarda un pò il problema sparisce, niente più kernel panic.
A questo punto decido di configurare un IP statico per la scheda di rete in modo da poter poi usare questo portatile a mò di server, quindi lo accendo e poi mi ci collego da un altro PC dato che usarlo con il monitor esterno è un pò scomodo.

Per i posteri, più per me stesso che ho la memoria di un criceto, questi i passi da fare per avere un IP statico con OpenBSD.
Creare il seguente file con il relativo contenuto per assegnare lÍP statico.

/etc/hostname.dc0 

inet 192.168.1.76 255.255.255.0 NONE 

Ovviamente il file hostname va modificato in base alla scheda di rete presente sul proprio sistema, nel mio caso è identificata come dc0, stesso discorso per líndirizzo IP che si vuole assegnare al computer.

Creare il seguente file con il relativo contenuto per abilitare la risoluzione dei nomi.
/etc/resolv.conf

nameserver 8.8.8.8
nameserver 8.8.1.1
lookup bind file

Io uso i DNS di Google.

Creare il seguente file con il relativo contenuto per abilitare il default gateway.
/etc/mygate

192.168.1.1

Qui va indicato l'indirizzo  IP del router.
Ora, dopo un riavvio per controllare che tutto sia funzionante, mi posso collegare via ssh da altro PC.

Per ora questa portatile SPARC lo ho recuperato in questa maniera, è tutto meno che veloce, ma ancora funzionante e quindi sfruttabile in qualche maniera, col tempo vedrò meglio in che modo.




mercoledì 11 marzo 2020

Linksys NSLU2

Già da qualche anno ho questo piccolo device sul quale ho installato debian wheezy e che con disco USB esterno da soli 16 gigabyte funge da piccolo server ftp.
L'hardware è molto limitato, 32 mega di RAM e CPU a 133Mhz, infatti il modello che acquistai usato è stato prodotto prima del 2006 in quanto quelli successivi hanno la CPU a 266Mhz.
Con queste caratteristiche ho pensato di utilizzare come disco esterno una scheda di memoria compact flash da 16 giga montata su un adattatore IDE/PATA inserito in un case USB.
Inutile dire che è lento da morire.
In rete ci sono una fila di tutorial che spiegano come questo device sia in grado di operare a 266Mhz, come i modelli prodotti dopo il 2006, solo attraverso una semplice modifica hardware che consiste nella rimozione di un piccolo resistore identificato dalla sigla R83.
Io, purtroppo, non ho molta dimestichezza con lavori sull'hardware che richiedano l'uso di saldatore o altro, ma pare che questo resistore possa essere rimosso anche con l'uso di una clip o altro attrezzo simile dotato di una punta sottile .... però io non ci ho mai voluto provare, anche perchè nonostante abbia più di 10 anni e sia tutt'altro che performante su EBAY viene venduto usato a non meno di 40/50 euro e quindi rischiare di buttarlo mi sembra un crimine.
Però ieri ho deciso di provarci.
E ci sono pure riuscito !!! Adesso funziona a 266Mhz e la differenza si vede, rispetto a prima si intende.
Adesso dovrei trovare il tempo e il coraggio di fare l'upgrade a debian jessie che dovrebbe essere l'ultima versione di questo OS a supportare il Linksys NSLU2, purtroppo in rete si trova poca roba e, quel che è peggio, sembra che l'upgrade blocchi il device costringendo a reinstallare il firmware partendo da wheezy, infatti non esiste una procedura per installare direttamente jessie.
In passato avevo anche io provato l'upgrade con lo stesso risultato, pensando che forse la lentezza della CPU e la poca RAM impedissero un corretto aggiornamento.
Ma forse è meglio lasciare perdere .... fino al prossimo attacco di follia.

mercoledì 4 marzo 2020

Ancora con MATE su OpenBSD

Tempo fa ho installato OpenBSD 6.5 con MATE come ambiente desktop su un Thinkpad X60s e di cui ho scritto le mie impressioni d'uso di questo OS come sistema desktop.
Adesso il portatile è aggiornato con OpenBSD 6.6 e MATE 1.22, non è un mostro di velocità dato l'hardware piuttosto vecchio.
  • cpu INTEL L2400 1,66Ghz
  • grafica INTEL 945GM
  • RAM 2 giga
  • HD 160 giga 5400 rpm
oltretutto la CPU non è a 64 bit, quindi ho deciso di provare OpenBSD con MATE su un altro portatile ben più dotato ( si fa per dire ), un Acer TM 6292.
  • cpu INTEL T7300 2,00Ghz
  • grafica INTEL 965GM
  • RAM 4 giga
  • HD 500 giga 7200 rpm
che dire con un tale mostro di potenza chissà cosa viene fuori, oltretutto installando la versione a 64 bit ho pensato che magari i problemi incontrati con la versione a 32 bit non si presentassero, anche presupponendo che ormai l'attenzione verso i 32 bit sia di gran lunga inferiore rispetto a quella verso i 64 bit.

Invece ? Grande tristezza e delusione .... se il Thinkpad impiega ben 1 minuto e 25 secondi dall'accensione ad arrivare al desktop l'Acer impiega ben 3 minuti e 23 secondi, come è possibile ?
Due cose si notano subito.
Durante il boot sull'Acer escono messaggi di errore relativi al drm, CRTC pipe ecc ecc che ne rallentano l'avvio.
Una volta arrivato al login, gestito da SLiM, inserito utente e password passa un bel pò di tempo prima che appaia il desktop.
Sembra un problema della versione 6.6 ( rif ).
Una volta avviato MATE il problema principale sembra essere il file manager CAJA che ad ogni avvio fa un dump core e quindi è inutilizzabile, o quasi, perchè se clicco sull'icona "Home" si avvia CAJA senza errori.
Anche di questo problema ho trovato solo un riferimento in un messaggio sulla mailing list di OpenBSD .... messaggio a cui non segue nessuna risposta.
Quindi che dire ? Pensavo che la versione a 64 bit si presentasse più stabile rispetto a quella a 32 bit, o almeno lo speravo ed invece sembra andare persino peggio .... certamente dipenderà anche dall'hardware, forse il reparto grafico anche se più recente è peggio supportato ... chi lo sa ?