sabato 4 novembre 2017

Upgrade a Debian 9 su DELL Latitude D630

Ebbene sì, nonostante ormai Debian 9, alias Stretch, sia diventata stable già da un bel pò su questo portatile non mi sono deciso a fare l'aggiornamento fino ad oggi.
Il motivo è presto detto, sapevo che ci sarebbero stati  problemi, infatti in passato quando Stretch era ancora in testing avevo provato ad installarlo e subito ho avuto problemi con la scheda video Intel integrata.
Visto che Jessie ( Debian 8 ) invece funzionava benissimo ho prolungato il più possibile la sua installazione, tra l'altro Jessie verrà supportato fino ad aprile 2020 quindi mantenerlo installato non sarebbe stato certo un dramma.
Comunque dopo aver eseguito la solita e canonica procedura per l'aggiornamento il problema con la scheda video si è presentato nuovamente, questa volta però in maniera un pò meno drammatica. 
Quando Stretch era in testing il display restava sempre nero e non c'era verso di passare nemmeno alla console a caratteri, se ben ricordo, adesso invece arriva al login grafico, anche se ci mette troppo tempo, e una volta fatto il login ci impiega ancora una mezza eternità ad arrivare al desktop.
Dal log del kernel risultano una marea di messaggi di errore del tipo :
vblank wait timed out on crtc 1
più uno stack trace continuo, immagino che questo sia la causa della lentezza dell'avvio e del caricamento del desktop dopo il login.
Fortunatamente c'è una soluzione, basta aggiungere tra le opzioni da passare al kernel la seguente stringa :
video=SVIDEO-1:d
modificando il file di configurazione di grub con relativo aggiornamento.
Dal successivo riavvio i tempi sono tornati nella norma e il desktop si carica immediatamente dopo aver inserito utente/password.

Tutto ciò mi porta a qualche, inutile, osservazione.
Da una parte mi chiedo quale genere di modifiche possano esserci state tra il kernel 3.16 dove il problema non si presentava e il kernel 4.9 dove invece bisogna ricorrere a questo parametro per risolverlo, però allo stesso tempo penso anche che questo portatile ha quasi 8/9 anni, è ancora un Core2 Duo, e quindi gioco forza lo sviluppo del kernel, per quanta attenzione possa esserci nel mantenere la compatibilità anche con hardware datato, possa portare a questo genere di problemi, sicuramente legati a modifiche per il supporto ai chip grafici Intel più recenti.
Questo portatile era nato con Windows Vista, quindi certamente può far girare Windows 7 e forse anche Windows 10, in ogni caso dubito fortemente che uno di questi Windows possa girare bene quanto gira Debian, che da oggi è oltretutto aggiornato con l'attuale stable.
E quindi ? Viva linux e viva Debian.

domenica 24 settembre 2017

Avviare UnixWare 7.1.4 da Grub

Per la serie "macchissenefrega" ecco come configurare Grub per avviare SCO UnixWare, e forse anche SCO OpenServer.
Di suo update-grub, o meglio os-prober, non rilevano la presenza di questo sistema operativo, ma solo quella di Windows o altra distribuzione linux, quindi bisogna operare manualmente.
Io ho fatto così, se sia la soluzione migliore non lo so ma funziona quindi procediamo.
Nella directory /etc/grub.d si trova un file 40_custom in coda al quale ho aggiunto queste istruzioni :
menuentry "UnixWare 7.1.4" {
    insmod chain
    set root=(hd0,2)
    chainloader +1
}
poi ho aggiornato il grub e al riavvio ho trovato la nuova voce di menù che ha funzionato egregiamente.
Unica nota che faccio, sebbene sia ovvio, la cifra 2 che appare nel comando setroot indica la partizione di Unix, che si può desumere dall'output del comando :
fdisk -l /dev/sda

GNU HURD or SysV indica proprio la partizione unix.
Nell'esempio si vede anche una partizione di Windows in quanto su questa VM ho installato prima Windows XP, poi UnixWare e infine Debian.
Bene, immagino che al 99% delle persone non interessi certo la possibilità di avviare UnixWare da grub e l'1% restante probabilmente sapeva già come fare.
 

venerdì 15 settembre 2017

CentOS 7 1708 e VMware Workstation 12.5.7

Pochi giorni fa è arrivato un cospicuo aggiornamento a CentOS 7, compreso un aggiornamento del kernel, ora in version 3.10.1-693.2.2.
Con mio grande disappunto con questo nuovo kernel la compilazione del modulo vmnet-only di VMware Workstation falliva miseramente in quanto sono state fatte delle modifiche ad una struttura dati del kernel che risulta incompatibile con le versioni precedenti.
Fortunatamente a questo link è possibile trovare una patch da applicare per risolvere il problema, in quanto lo setsso si è già presentato con RedHat 7.4, ed essendo CentOS praticamente la stessa cosa a livello di sorgenti, la soluzione si applica pure a questo OS.
Quindi tutto bene, problema risolto, però .....
Già c'è un però, infatti uno dei motivi per cui ho utilizzato CentOS come distribuzione su cui far girare VMWare Workstation è che è ufficialmente supportata, inoltre CentOS essendo indirizzata all'uso enterprise garantisce un supporto a lungo termine e quindi stabilità, cosa che dovrebbe significare che anche a livello di kernel non ci siano modifiche o variazioni tali da renderlo incompatibile con moduli di terze parti. Invece questa volta è andata diversamente.
Ma mi secca anche il fatto che un prodotto commerciale, non gratuito quindi, a distanza di un mese ormai non abbia ancora rilasciato un aggiornamento ufficiale per risolvere il problema.
Personalmente non sono mai stato un grande fan di VMware, ricordo che hai tempi, ormai lontani, in cui usavo Ubuntu c'erano sempre problemi con ogni aggiornamento del kernel che portava modifiche tali da impedire la compilazione dei moduli di VMware. 
Ho sempre preferito VirtualBox che, nella mia esperienza, risulta essere sempre aggiornato in maniera tempestiva anche con i kernel più recenti.
Infatti nel 99% dei casi è VirtualBox la soluzione di virtualizzazione che utilizzo, VMware solo per quei casi in cui mi serve la nested virtualization che manca in VirtualBox. A che serve ? In pratica permette di virtualizzare VMware ESX all'interno di VMware Workstation e di installare un altro OS virtualizzato all'interno della VM con ESX, oppure con altro sistema similare come ProxMox o XenServer.

 
 

domenica 9 luglio 2017

FreeBSD upgrade

Premetto che non sono mai stato un grande fan di BSD in nessuna delle sue incarnazioni anche se negli anni ogni tanto ci ho provato ad usarlo in maniera costante come desktop .... ma poi alla fine resto sempre su linux.
Fatta questa premessa mi ritrovo ad avviare una VM con FreeBSD 10.3 che non utilizzavo più chissà da quanto tempo e procedo prima con gli aggiornamenti dei pacchetti con la sequenza di comandi :
pkg update
pkg upgrade
e scarica una montagna di aggiornamenti, preciso che ho anche installato MATE come DE oltre a firefox e altri programmi.
Terminati gli aggiornamenti decido di aggiornare anche il sistema :
freebsd-update fetch
freebsd-update install
anche qui va tutto bene.
Ora non sono un esperto del mondo BSD ma credo che FreeBSD sia l'unico BSD che ha un sistema di aggiornamento e di passaggio ad una versione successiva, non so da quanto ci sia ma sicuramente è un qualcosa in più per renderlo maggiormente accessibile ad un'utenza un pò meno tecnica, o almeno questa è la mia opinione.
Fatti tutti gli aggiornamenti mi sono detto che visto che c'ero potevo anche provare l'upgrade a FreeBSD 11.
freebsd-update -r 11.0-RELEASE fetch
freebsd-update install
quest'ultimo passo lo ho dovuto ripetere più volte, non per via di errori ma perchè così mi istruiva a fare la procedura di installazione.
Aggiornato il sistema operativo alla nuova versione sono passato all'aggiornamento dei package e qui ho avuto un piccolo intoppo, in pratica il comando pkg non veniva eseguito per via della mancanza della libreria libssl.so.7.
Per fortuna sul sistema è presente anche il comando pkg-static che come si intuisce dal nome è la versione compilata con librerie statiche e che quindi non necessità di dipendenze. 
pkg-static update
pkg-static upgrade
anche in questo caso la mole di aggiornamenti scaricati è stata notevole e al termine anche il comando pkg risultava funzionante. 
In conclusione devo dire che le varie procedure di aggiornamento sia a livello di pacchetti che di sistema funzionano molto bene e rendono la gestione/manutenzione di FreeBSD semplice quasi quanto avviene con i gestori di pacchetto presenti nelle varie distribuzioni linux.
Il che è un'ottima cosa.

giovedì 1 giugno 2017

KDE su OpenServer 5.0.7

Continuano i miei esperimenti su questo vecchio sistema operativo Unix.
Ho deciso di provare a installare KDE, che viene fornito pacchettizzato solo in versione 1.1.2, roba antica ma sicuramente meglio dell'ambiente grafico standard di SCO.
Purtroppo anche in questo caso le cose non vanno lisce come dovrebbero, ma procediamo con calma.
Sul sito di SCO, a questo link, è possibile scaricare un buon numero di pacchetti per SCO OpenServer 5.0.7, purtroppo sono quasi tutte vecchi versioni, ma è sempre meglio di nulla.
Per prima cosa bisogna scaricare e installare i seguenti pacchetti :
  1. Glib-1.3-VOLS.tar
  2. Qt-1.44-VOLS.tar
  3. kde-1.22-VOLS.tar
per comodità li salviamo in /tmp e uno ad uno provvediamo a scompattare i file con il classico tar xvf e li installiamo con il comando custom oppure usando scoadmin, più comodo.

Al termine si potrebbe pensare che sia già possibile usare KDE, magari attraverso una scelta in più in fase di login grafico .... ovviamente non è così, e magari fosse solo questo.

Uno dei problemi è che i binari di KDE caricano una serie di librerie da posizione fissa che, ma guarda un pò, non corrisponde per nulla a quella dove sono effettivamente installate le librerie. In pratica sotto /usr/lib ci sono i seguenti files :
  1. libjpeg.so.62
  2. libtiff.so.3
  3. libz.so.1
  4. libpng.so.2
ma vengono cercati in /usr/local/lib, quindi bisogna creare una serie di link con il seguente comando :
ln -s /usr/lib/libjpeg.so.62 /usr/local/lib/libjpeg.so.62
questo per tutti e quattro i files.
Ma come lo avviamo KDE ? Normalmente si avvia attraverso KDM, ma questo non è presente, bisogna quindi operare diversamente.
Prima però aggiungiamo nel .profile nella nostra home directory queste righe.
PATH=$PATH:/usr/local/bin:/usr/local/kde/bin:.
KDEDIR=/usr/local/kde
export KDEDIR PATH
poi la documentazione ci dice di modificare il file .xinitrc, sempre nella nostra home, aggiungendo la riga startkde, se siete pratici di linux/unix penserete che non fa una grinza .... e, guarda un pò, tanto per cambiare, invece non funziona. 
Infatti scologin, il login grafico di SCO, usa il file .startxrc come file di configurazione a livello utente.
Adesso finalmente facciamo il login ed entriamo in KDE, in tutta la sua gloria ...
o quasi, sfortunatamente alcune applicazioni presenti a menù poi non risultano installate, la sfiga vuole poi che Konsole, l'emulatore di terminale di KDE, si avvia ma non accetta nessun input da tastiera risultando quindi inutilizzabile, l'altra applicazione Kvt invece non è proprio presente.
Con ALT+F2 è possibile digitare il programma da avviare e indicando l'intramontabile xterm è possibile avere un terminale usabile.
In conclusione la pacchettizzazione di KDE per SCO 5.0.7 è proprio fatta molto alla buona, per essere gentili, tanto da farmi dubitare del fatto che possa pensare di usarlo.
KDE 1.1.2, non ricordo più nemmeno sua quale distribuzione linux lo abbia visto, forse Red Hat 6 ?


martedì 18 aprile 2017

Windows 95 e SCO OpenServer 5.0.7 su stesso PC

Per prima cosa devo dire che l'unico modo per usare decentemente SCO OpenServer è quello di installarlo in una macchina virtuale ( VirtualBox o VMWare ).
Io ho avuto la bella idea di installarlo su di un vecchio portatile che non ha nemmeno la scheda di rete, e questo sistema operativo del c.... non supporta nessuna scheda PCMCIA, anche se dovrebbe, ma non riconosce il bus PCMCIA del portatile ( conflitto di indirizzi o qualcosa del genere ), quindi è isolato dal resto del mondo. L'unico modo per copiare file da e per l'esterno è attraverso il floppy disk .... peccato che è l'unico PC con il lettore di floppy che mi è rimasto ormai. 
Quindi ho avuto un'altra delle mie brillanti idee, e ho pensato di formattare tutto e installare Windows 95, sì il PC è vecchio e amo il vintage informatico.
Una partizione di circa 6 giga per Windows 95 bastano e avanzano, ma Windows 95 è in una partizione FAT32 e non c'è da sperare che SCO vi possa accedere, infatti questo Unix supporta solo la FAT16, quindi ho creato una partizione da 1 giga in tale formato e nello spazio restante ho installato SCO, il tutto facendo attenzione che la partizione Unix fosse nel fatidico limite degli 8 giga, perchè c'è poco da farsi illusioni che il boot loader di SCO possa avviarsi oltre tale limite.
Una volta installato SCO al riavvio trovo il boot loader di quest'ultimo e per avviare Windows 95 dovrei usare il comando :
bootos N° partizione di Windows 95
quindi :
bootos 1
che, guarda un pò, ovviamente da errore e si avvia SCO. L'arcano è presto scoperto, avviato SCO eseguo il comando fdisk e visualizzo le partizioni, e scopro che SCO le vede in un ordine tutto suo :
  • partizione 1 SCO Unix
  • partizione 3 FAT16
  • partizione 4 Windows 95
mentre da Windows 95 il comando fdisk visualizza :
  • partizione 1 Windows 95
  • partizione 2 estesa
  • partizione 3 sconosciuta ( SCO Unix )
quindi il comando per avviare Windows 95 dal prompt di boot è :
bootos 4
in realtà dalla documentazione si evince che ci sono dei nomi di default che sono gestiti in automatico per l'avvio di altri sistemi operativi, senza quindi dover sapere in quale partizione sono installati.
Per semplicità io ho aggiunto al file /etc/default/boot la seguente voce :
win95=bootos 4
in questo modo al prompt basta digitare :
win95
ma probabilmente andrò a installare un boot manager alternativo, più flessibile e amichevole.

Come ho detto all'inizio ho creato una partizione FAT16 da usare per lo scambio di file, anche se ovviamente non è una soluzione ottimale in quanto necessità di riavviare il PC per usare uno o l'altro dei sistemi operativi, ma visto che Windows 95 può usare la scheda di rete PCMCIA userò questo OS per scaricare i files nella partizione di scambio, poi riavvio e faccio il boot in SCO e copio i files, stessa cosa se devo portare fuori dei files.
Per montare la partizione FAT16 il comando da eseguire è questo :
mount -f DOS /dev/dsk/0sD /mnt
da dove arriva /dev/dsk/0sD ? Da qui ..... ma non fidatevi, perchè questo link indica /dev/dsk/0sC come disco C ma sul mio PC da errore, non solo perchè essendo FAT32 non sia possibile montarlo ma proprio perchè non risulta come device.
Onestamente non mi è chiara la logica con cui sono  identificate le partizioni ma riassumendo sul mio sistema :
  • /dev/dsk/0s4 partizione FAT32 con Windows 95
  • /dev/dsk/0sD partizione FAT16 di scambio
Senza montare la partizione si possono usare i comandi doscmd dopo aver configurato in maniera corretta il file /etc/default/msdos impostando la device per la partizione D:
D=/dev/dsk/0sD
 ora si può copiare un file con :
doscp /unix/path/to/file.txt D:
oppure :
doscp D:archivio.dat /tmp
c'è da considerare che i files copiati da UNIX a DOS verranno troncati se non in formato 8+3.
Sul sito SCO, e comunque sul CD Skunkware, c'è anche il pacchetto MTOOLS che dovrebbe fare le stesse cose di doscmd ma con il supporto per FAT32, purtroppo dalle mie prove supporta solo i nomi di file lunghi, tipici di FAT32, ma non mi permette di accedere al disco C: di Windows 95.
Dopo questa disamina ribadisco che la soluzione migliore per usare SCO OpenServer è una macchina virtuale, dove il supporto per la scheda di rete è gestito, almeno con una banale AMD PCNet.



 

mercoledì 8 marzo 2017

GCC su SCO OpenServer 5.0.7

E' passato un pò di tempo dall'ultima volta che ho scritto qualche programma in C su questo sistema operativo, abbastanza da non ricordarmi che non compilavo di certo con il GCC.
Infatti al primo tentativo di compilazione di un semplice programma ottengo un errore di undefined symbol per la funzione _fini in /usr/ccs/lib/ctr1.o, e la cosa mi ha mandato in panico perchè ero certo di avere già compilato programmi scritti in C in precedenza.
Per riepilogare il sistema operativo è aggiornato con il maintenance pack 5, l'ultimo disponibile, e il compilatore GCC arriva dal CD Skunkware del 2000, una vecchia versione 2.95.2. Ma sul sistema ho anche installato il compilatore C nativo di SCO ed è quello con cui ho compilato i vecchi programmi, lo si vede dal fatto che gli eseguibili sono in formato COFF mentre il GCC gli genera in formato ELF.
Quindi problema risolto ? No, perchè ora volevo compilare i sorgenti della vecchia e mitica libreria Turbo Vision, quella usata dagli IDE Borland in ambiente DOS. Questi sorgenti sono compilabili anche su linux e bsd quindi probabilmente anche sotto SCO con il GCC dovrei avere più probabilità di successo che non con il compilatore nativo.
Fortunatamente sul sito FTP di SCO si trova una cartella con i files del pacchetto GNU Tools 5.0.7 che dovrebbero fare al caso mio.
Sono una serie di files in formato VOL, il formato dei pacchetti specifico per SCO OpenServer, ma tentando di installare il pacchetto il sistema si lamenta che devo avere precedentemente installato il maintenance pack 1, che non ho visto che ho il 5 che ingloba tutti i precedenti.
Anche in questo caso c'è una soluzione piuttosto semplice, basta creare un certo file prima di installare attraverso scoadmin software :
touch /tmp/gnutools.nocheck
in questo modo non viene eseguito il controllo di eventuali dipendenze software e il pacchetto si installa, ovviamente il nome gnutools vale per questo specifico pacchetto non in senso generale.
Adesso ho il compilatore GNU C in versione 2.95.3, quindi non molto più recente dell'altro, ma almeno compila senza errori.
Questo pacchetto, poi si installa in /usr/gnu/bin a differenza di quello installato dal CD Skunkware che si trova in /usr/local/bin e che comunque non serve a nulla e andrò a rimuovere.
Adesso che ho il compilatore GNU C ( e C++ ) funzionanti su SCO, anche se in una versione molto vecchia, vediamo di compilare questa libreria Turbo Vision. Ma ve la ricordate ? Non è meravigliosa ? Che nostalgia, che tempi !!!