Home Articoli Guida: Linux Fedora su IBM/Lenovo ThinkPad Z60t

Guida: Linux Fedora su IBM/Lenovo ThinkPad Z60t

ImageUna guida che descrive l'installazione e la configurazione di Fedora Linux su un ThinkPad Z60t. Gli IBM ThinkPad sono da sempre sinonimo di affidabilità, robustezza e sicurezza. Lo Z60t si propone di continuare questa tradizione ma con una novità: lo schermo in formato wide. 

Indice

        1.1. Un bell'oggetto
        1.2. Perché questo e non un altro

        2.1. Lo stato iniziale
        2.2. Liberare lo spazio

        3.1. Finalmente l'installazione
        3.2. La configurazione di Xorg
        3.3. Il primo avvio, ed i primi problemi
        3.4. Aggiornamento del sistema
        3.5. La console a 160x48? Eccola!
        3.6. Il chipset grafico 915
        3.7. Il wireless
        3.8. Il disco S-ATA e i problemi con il DVD

        4.1. Raffinatezze
        4.2. Siamo a buon punto
        4.3. Cosa rimane ancora
        4.4. Link per chi ha tempo e coraggio
        4.5. Conclusioni

        5.1. Avvertenze e modalità d'uso
        5.2. Preparazione
        5.3. Una pezza per il lettore SD
        5.4. Una pezza per proteggere l'hard disk
        5.5. La configurazione del kernel
        5.6. La compilazione
        5.7. L'installazione del nuovo kernel
        5.8. Active Protection System... GO!
        5.9. Lettore di SD... GO!
        5.10. Aspettarsi il peggio...

        6.1. Contributi
        6.2. Ringraziamenti
        6.3. Strumenti utilizzati
        6.4. Versioni aggiornate
        6.5. Licenza e Copyright 

Aggiornamento 3/12/2006:

Dopo la dura battaglia per far funzionare quasi tutto nel mio computer con Fedora Core 4, avevo deciso di non cambiare, anche perché col computer ci lavoro e non posso rimanere troppo tempo “disarmato”.

Poi a metà di ottobre è uscita Fedora Core 6. Ho letto un po’ di note e di commenti sulle varie mailing list di Fedora a cui sono iscritto, e visto che nessuno lamentava problemi seri, ho deciso di fare un aggiornamento. Scaricata l’immagine via Bittorrent, anche perché il sito di Fedora era irraggiungibile per il sovraccarico, il 27 ottobre ho installato.

Che dire… sono rimasto senza parole. Il lavoro del team di Fedora si vede, e i miglioramenti ci sono.

Per prima cosa, niente più parametri da passare prima dell’installazione, l’accoppiata schermo/chipset video viene riconosciuta e tutta l’installazione fila via liscia senza problemi. Al termine il sistema è pronto per l’uso immediatamente.

Senza ricompilazioni e pezze al kernel, funziona tutto, compreso il lettore di memorie SD: basta inserirne una nello slot e compare una icona sul desktop con la forma di una SD appunto.

Il chipset video viene riconosciuto in tutto e (finalmente) OpenGL usa il Direct Rendering. Fra le voci del menu “Sistema/Preferenze” ce n’è una con la scritta “Desktop Effects”. Attivandola si passa al window manager Compiz, che funziona sfruttando l’OpenGL. Il risultato è veramente d’effetto: passando da un desktop all’altro con Ctrl-Alt-Sinistra o Ctrl-Alt-Destra si vedono ruotare come sulle facce di un cubo; prendendo una finestra dalla barra del titolo e trascinandola si deforma come se fosse elastica; lo stesso quando si massimizza, rimbalzando sui bordi dello schermo; portando la freccia del mouse in alto a destra del desktop, le finestre aperte si dispongono in parata, e basta cliccare su quella voluta per portarla in primo piano; usando Alt-Tab, il desktop arretra leggermente, scurendosi, e le varie finestre appaiono in miniatura con il contenuto “vivo”; i bordi delle finestre sono semitrasparenti. Non sono un fanatico degli effetti speciali, ma in questo caso devo ammettere che l’effetto è degno di nota. Senza contare che alcune delle funzioni sono veramente comode.

Ovviamente, non tutto è rose e fiori. Il dispositivo APS (l’accelerometro) non è ancora riconosciuto, e, da quanto leggo in alcuni messaggi nella mailing list del progetto, pare che al momento non sia pronta una patch per parcheggiare le testine del disco al volo, o meglio, c’è ma presenta problemi di stabilità, per cui preferisco che sia qualcun altro a rischiare dati ed hardware per i test.

Altro problema piuttosto ostico è con l’interfaccia di rete wireless. Per qualche motivo che non sono riuscito ad appurare, il driver MadWifi dalla versione r1611 ha smesso di funzionare quasi del tutto: solo se sono a meno di un metro dal mio access point riesco ad acquisire l’indirizzo di rete, ed in ogni caso se mi allontano a due metri il collegamento cade.

Ho scritto un bug report agli sviluppatori del driver, e pare che non sia il solo ad avere questo problema, ma per ora nessuna risposta.

Per non rimanere “scollegato”, ho preso la versione r1605 del driver ed ho provato a compilarla, ma l’operazione non va a buon fine, anche perché sono cambiate parecchie cose nel kernel nel frattempo. Pasticciando con make e con il poco linguaggio C che conosco, sono riuscito a compilare con successo il driver, ed ora vado senza problemi con la mia scheda wireless.

Per chi volesse fare un po’ di bricolage, qui trovate la patch da applicare alla versione r1605 dei driver MadWifi per compilarli con successo su Fedora Core 6. La versione r1605 del driver si può prelevare direttamente dal sito MadWifi.

Insomma, se avete un ThinkPad Z60t e state pensando di passare a Fedora Core, non indugiate oltre: ne rimarrete più che soddisfatti.

Un ultimo consiglio: se potete installate sempre la directory /home su una partizione separata. Quando vi troverete a cambiare distribuzione Linux potrete sempre fare una installazione ex-novo, invece di essere costretti a fare un upgrade, portandovi poi appresso configurazioni obsolete e problemi vari. I vostri dati saranno al sicuro sulla partizione /home, e per di più conservate le vostre impostazioni: nel mio caso i bottoni aggiuntivi che mi ero configurato nei pannelli e le applet di Gnome erano tutte al loro posto, come pure tutta la posta di Evolution con i filtri e gli indirizzi. 

1. Il notebook

1.1. Un bell'oggetto

Questa è la definizione di un mio caro amico quando lo ha visto. Per inciso è un convinto sostenitore di Apple™, per cui, se conoscete i melomani, saprete che per loro bello riferito ad un computer è indice che l'oggetto ha un certo fascino.

In effetti, se avete mai avuto per le mani un Thinkpad™, hanno tutti un aspetto peculiare: il colore nero, il mouse a joystick e non ultimo l'aspetto essenziale e serio.

Questo modello è uno dei primi con display widescreen, anche se appartiene alla categoria business.

La dotazione del mio modello comprende:

  • per la parte elaborazione: CPU Pentium M™, velocità 1,86GHz con bus a 533MHz, 512M di RAM a 533MHz DDR2, 2M di cache. Non possiede il logo Centrino™ semplicemente perché l'uso del logo è permesso solo se sul notebook è installata la tripletta CPU/chipset/wireless Intel™. Qui il wireless è basato su un chip Atheros, quindi niente logo. Ma la differenza è solo questa.

  • per la parte storage: HD interno SATA da 60G, combo lettore DVD-masterizzatore CD-RW.

  • grafica: chipset Intel 915 con memoria condivisa, display widescreen con risoluzione 1280x768

  • comunicazioni: Gigabit ethernet integrata, modem analogico, IrDA, Bluetooth.

  • porte di I/O: 3 USB2, 1 Firewire (con connettore miniaturizzato), VGA per monitor esterno, TV-out (S-video), 1 slot PCMCIA, 1 slot per memorie flash SD.

  • nella categoria gadget: lettore impronte digitali, luce di tastiera integrata nella parte superiore del coperchio del display.

Fra le altre cose degne di nota, il fatto che pesa due chilogrammi in assetto normale, cosa da non trascurare, e che è di dimensioni ridotte, come potete verificare sul sito del produttore. Inoltre l'interno è composto da uno scheletro di lega di magnesio, leggerissima e resistentissima, indice della cura con cui è stato realizzato pensando alla portabilità ed alla protezione dei dati.

Il sistema operativo fornito di serie è Windows™ XP™ Professional con Service Pack 2 già installato. Unica nota negativa, se così si può dire, è che non vengono forniti i supporti originali per l'installazione del software. Poco male, c'è una partizione nascosta da quattro gigabyte con un software che provvede alla reinstallazione completa dell'immagine del sistema operativo e di tutti i software, ripristinando lo stato del notebook come alla prima accensione. Inoltre c'è una utility che permette di masterizzare un DVD, nel mio caso 8 CD, con tutto il necessario per ricostruire questa partizione nascosta e da lì ricostruire il sistema operativo ed i software. Laborioso, ed anche una scocciatura: per fare il set di CD occorre tenere conto che ci vogliono oltre due ore e mezza, quindi non iniziate come me alle dieci di sera. All'una ero ancora lì a cambiare CD...

Questo è l'unico appunto.

1.2. Perché questo e non un altro

I miei parametri di scelta erano piuttosto semplici: leggero, piccolo ma utilizzabile, con una tastiera decente, potente quanto basta, senza gadget inutili che alzano il prezzo e il peso.

Ecco perché niente masterizzatore DVD, processore non troppo veloce, RAM e disco quanto basta. In fondo i miei dati attuali ammontano a circa 200M, fra sorgenti, documentazione e file di lavoro, a cui si aggiungono circa 600M di archivio di posta elettronica, comprese le mailing list a cui sono iscritto.

Avevo preso in considerazione altre marche e modelli, ma costavano troppo, oppure erano troppo pesanti o troppo ingombranti. Inoltre ho capito, sempre grazie al mio amico melomane, la differenza tra la linea consumer e quella business. Di solito i primi sembrano includere una ricca dotazione, che fa sembrare i secondi piuttosto costosi, ma quello che fa la differenza spesso non si vede: chassis rinforzati in magnesio, cerniere del display in metallo, avvitate sul metallo. Poi c'è la parte elettronica che riserva delle sorprese nascoste: il bus della RAM è a 533MHz, come pure la RAM che è DDR2; il disco interno è Serial-ATA; ventole e disco interno silenziosi e privi di vibrazioni; l'antenna WiFi ha una sensibilità mai vista su un portatile.

Insomma, come diceva mia nonna: più spendi, meno spendi.

2. Prima dell'installazione

2.1. Lo stato iniziale

Alla prima accensione parte la conversione della partizione di Windows™ XP™ in NTFS. Finita questa operazione, della durata di una decina di minuti, si ottiene la consueta sequenza di configurazione, con il nome del computer, i dati dell'utente e altre cose come l'accettazione della licenza.

Il disco è diviso in sole due partizioni: la prima di 56G con il sistema operativo, la seconda nascosta e contenente il ripristino d'emergenza. Per dirla alla maniera di Linux, sono /dev/sda1 e /dev/sda2, consecutive anche nella tabella delle partizioni.

2.2. Liberare lo spazio

Ve lo dico subito: la partizione di Windows™ ha i dati sparsi per tutto il disco, ed il defrag non sortisce alcun effetto. Quindi, faremo la deframmentazione, ma non ci preoccuperemo se rimangono pezzi in giro per il disco.

Vi consiglio di fare queste modifiche, prima di fare la deframmentazione, sarà più veloce e le operazioni successive avranno maggiori possibilità di successo:

  • Disabilitate il ripristino della configurazione di XP.

  • Mettete la dimensione della memoria virtuale a zero, in modo da avere un file bello grande in meno da spostare (nel mio era di oltre 700M).

  • Se volete, eliminate i programmi che sono in versione lite o dimostrativo per pochi giorni, non è vincolante, ma sono più rapide le operazioni successive e il computer sarà più veloce. L'antivirus, il firewall, l'ottimizzazione del disco tanto per citarne qualcuno. C'è già il firewall di XP che fa quello che deve, e l'antivirus mi risultava già scaduto il periodo di prova, per cui non aggiornava le firme: in sostanza era inutile.

Queste operazioni comporteranno una serie di riavvii di Windows: li faremo tutti diligentemente, fino ad arrivare alla condizione che non chiede più di riavviare (non per sfinimento...): a questo punto siamo pronti per il passo successivo.

Ci procuriamo il System Rescue CD, sul sito http://www.sysresccd.org, una distribuzione Linux che contiene tutto il necessario per il nostro trapianto di sistema operativo: QtParted, un programma di gestione delle partizioni; partimage, per salvare immagini di partizioni in modo da poterle ripristinare direttamente dal supporto, e masterizza direttamente CD e DVD; fdisk, per manipolare la tabella delle partizioni, e molti altri. QtParted si appoggia ad un altro programma dal nome ntfsresize, che come dice il nome serve a cambiare la dimensione delle partizioni con filesystem NTFS senza perdere i dati, cosa fondamentale.

Una volta procurato il CD con dentro SysRescCD, lo inseriamo nel lettore e avviamo il notebook. Otterremo alla fine del processo di avvio una shell a riga di comando. Niente paura, è proprio quello che serve. Lanciamo il comando run_qtparted che avvia il programma che useremo per primo. L'interfaccia è grafica ed usa il mouse, quindi non è complicata da usare. Puntiamo alla partizione NTFS di Windows™ e ridimensioniamola a piacere.

Viene fatta un'analisi del filesystem e se non ci sono problemi possiamo applicare le modifiche. L'operazione è lunga, nel mio caso ha impiegato quasi mezzora, con il mouse che non risponde e la barra di progresso ferma al 100%.

NON VA SPENTO PER NESSUN MOTIVO

Durante questa fase non toccare nulla, mettere l'alimentatore, non riavviare, non mettere periferiche: insomma non ci avviciniamo neanche, pena la perdita completa non solo dei dati della partizione del sistema operativo, ma c'è il rischio di perdere anche quella di ripristino.

Al termine dell'operazione, usciamo dal programma e torniamo a Windows™. Partirà con uno scandisk come se fosse stato spento malamente, ma niente paura: al termine si avvia con una partizione di dimensione più ragionevole, ed avremo tutto lo spazio necessario per Fedora.

Occorre ancora una volta avviare con il SysRescCD e lanciare fdisk per risolvere un problema banale ma quanto mai rognoso: le due partizioni adesso hanno dello spazio fra loro, ma la tabella delle partizioni le riporta una in prima posizione ed una in seconda. Se si crea una nuova partizione sarà ovviamente posizionata fisicamente fra le prime due, ma nella tabella sarà la terza, e questo potrebbe causare parecchi problemi. Niente panico, c'è la soluzione anche qui: creare una partizione primaria estesa, che occupi tutto lo spazio libero fra la partizione di Windows e quella di ripristino. Nel mio caso la situazione dopo la riduzione di spazio per Windows era questa:

[root@defiant ~]# fdisk -l /dev/sda Disk /dev/sda: 60.0 GB, 60011642880 bytes
255 heads, 63 sectors/track, 7296 cylinders
Units = cilindri of 16065 * 512 = 8225280 bytes

Dispositivo Boot Start End Blocks Id System
/dev/sda1 * 1 1275 10241406 7 HPFS/NTFS
/dev/sda2 6759 7296 4316760 12 Diagnostica Compaq

Notare che dal cilindro 1276 al 6758 è tutto spazio vuoto. Dopo aver creato la partizione estesa la situazione è questa:

[root@defiant ~]# fdisk -l /dev/sda

Disk /dev/sda: 60.0 GB, 60011642880 bytes
255 heads, 63 sectors/track, 7296 cylinders
Units = cilindri of 16065 * 512 = 8225280 bytes

Dispositivo Boot Start End Blocks Id System
/dev/sda1 * 1 1275 10241406 7 HPFS/NTFS
/dev/sda2 6759 7296 4316760 12 Diagnostica Compaq
/dev/sda3 1276 6758 44042197+ 5 Esteso

Come vedete lo spazio vuoto è stato occupato dalla partizione estesa, ma l'ordine delle partizioni è errato. Dal prompt di fdisk passare ai comandi estesi con il comando x, poi dare il comando f, che sta per fix partition order. Questo comando sistema l'ordine nella tabella, senza toccare niente nelle partizioni. Alla fine la situazione è questa:

[root@defiant ~]# fdisk -l /dev/sda

Disk /dev/sda: 60.0 GB, 60011642880 bytes
255 heads, 63 sectors/track, 7296 cylinders
Units = cilindri of 16065 * 512 = 8225280 bytes

Dispositivo Boot Start End Blocks Id System
/dev/sda1 * 1 1275 10241406 7 HPFS/NTFS
/dev/sda2 1276 6758 44042197+ 5 Esteso
/dev/sda3 6759 7296 4316760 12 Diagnostica Compaq

Uscendo da fdisk ricordiamoci di scrivere prima le modifiche, altrimenti il programma uscirà senza toccare nulla. Siamo pronti per inserire il DVD di installazione di Fedora.

3. Installazione e configurazione di Linux Fedora

3.1. Finalmente l'installazione

Inserito il DVD, o il primo CD, della distribuzione, occorre una prima regolazione: se si parte con l'installazione senza alcun parametro d'avvio lo schermo andrà ad una risoluzione di 800x600 con un fastidiosissimo sfarfallìo per tutta la durata dell'operazione. Il problema sarà lo stesso che incontreremo più avanti con il server X, per cui tanto vale parlarne ora. La ragione è molto semplice: il display ha una geometria che non è compresa fra quelle conosciute, per cui in mancanza di corrispondenza e di specifiche istruzioni, giustamente, il programma di installazione si imposta su una risoluzione che ragionevolmente sia funzionante su praticamente tutto l'hardware esistente oggi.

Occorre quindi suggerire la corretta dimensione dello schermo, usando il parametro apposito sulla riga di comando:

boot: linux resolution=1280x768

che fa appunto quello che serve. Da questo punto in poi la strada è tutta in discesa, fino al riavvio.

Non riporto qui tutta la procedura di installazione di Fedora, anche perché ci sono i manuali ufficiali e comunque è un'operazione abbastanza tranquilla per chi conosce Linux. Inoltre non richiede operazioni particolari con questo notebook, al di là di quanto detto fino ad ora. Unica accortezza: se pensiamo di eseguire i passi che richiedono la compilazione di driver (es. Sezione 3.7, «Il wireless» ) o del kernel, occorre installare i gruppi di applicazioni che vanno sotto la voce "Strumenti di sviluppo", in particolare proprio "Strumenti di sviluppo", "Sviluppo del software per X" e "Sviluppo del software di Gnome" o "Sviluppo software KDE", in funzione di quale tipo di desktop abbiamo scelto, o entrambi se vogliamo sfruttare sia Gnome che KDE. Questo per evitare problemi di dipendenze di librerie successivamente, molto complesse da risolvere. Non c'è bisogno di andare a scegliere i pacchetti nel dettaglio, quelli preselezionati che ci vengono proposti vanno benissimo.

3.2. La configurazione di Xorg

La configurazione di Xorg non pone problemi se non per il fatto che non vengono riconosciuti né il tipo di monitor né il tipo di chipset grafico.

Per quanto possa sembrare strano, il problema è quello detto poco sopra: la risoluzione in pixel non è fra quelle conosciute. Sceglieremo quindi un Generic LCD Panel con una risoluzione vicina, tipo 1024x768 o 1280x800, per avere almeno la partenza di Xorg senza troppi problemi. Ovviamente il risultato farà veramente pena, ma lo risolveremo fra poco.

Per ora non cambiamo il tipo di chipset grafico, che non viene riconosciuto anche se è fra quelli in teoria noti (Intel 915), ma ha un numero di identificazione PCI sconosciuto e non viene abilitato. Quindi lasciamo Vesa, o quello che propone il configuratore Xorg di Fedora.

3.3. Il primo avvio, ed i primi problemi

Alla prima partenza ci troviamo con lo stesso problema di cui parlavo prima, lo sfarfallìo ed una risoluzione penosa. Passiamo ad una console di testo con la solita sequenza Ctrl-Alt-F1, ci autentichiamo come root e apriamo in modifica il file /etc/X11/xorg.conf, dopo averne creato un backup per maggiore praticità. Cercare la sezione Screen, che dovrebbe avere un aspetto simile a questo, se ad esempio abbiamo scelto come monitor Generic LCD Panel 1024x768:

Section "Screen"
Identifier "Screen0"
Device "Videocard0"
Monitor "Monitor0"
DefaultDepth 24
SubSection "Display"
Viewport 0 0
Depth 16
Modes "1024x768" "800x600" "640x480"
EndSubSection
SubSection "Display"
Viewport 0 0
Depth 24
Modes "1024x768" "800x600" "640x480"
EndSubSection
EndSection

Puntiamo le righe Modes e le cambiamo in questo modo:

Section "Screen"
Identifier "Screen0"
Device "Videocard0"
Monitor "Monitor0"
DefaultDepth 24
SubSection "Display"
Viewport 0 0
Depth 16
Modes "1280x768"
EndSubSection
SubSection "Display"
Viewport 0 0
Depth 24
Modes "1280x768"
EndSubSection
EndSection

Salvate le modifiche, sempre da root causeremo il riavvio del demone gdm-binary con il comando:

[root@defiant ~]# killall gdm-binary

Entro pochi secondi dovrebbe avviarsi il nuovo server X, senza toccare altro, alla risoluzione voluta.

Rimane da configurare il servizio kudzu per impedirgli di fare danni: viene di solito incluso ad ogni avvio e fa il riconoscimento automatico e la configurazione di una serie di periferiche. Il problema è che include anche il monitor, e non riconoscendolo, riporta la configurazione di Xorg in modo 800x600, con il temuto sfarfallìo. Abbiamo due possibilità: disabilitare del tutto il servizio, o configurarlo in modo safe, in cui non fa il riconoscimento del monitor, dei dispositivi seriali e di quelli PS/2. Dato che il notebook non ha seriali e non ha porte PS/2, possiamo andare tranquilli.

Per disabilitare del tutto il servizio, da root chiamiamo l'utility ntsysv specifica di Fedora, che mostra un elenco di servizi disponibili in ordine alfabetico con nomi criptici. Cerchiamo quello col nome kudzu e lo disabilitiamo, togliendo l'asterisco. Al prossimo avvio il servizio non verrà più avviato, ed il monitor rimarrà con le impostazioni volute.

Per metterlo in modo safe senza disabilitarlo del tutto, modificare il file /etc/sysconfig/kudzu che originariamente è così:

# Set to anything other than 'no' to force a 'safe' probe on startup.
# 'safe' probe disables:
# - serial port probing
# - DDC monitor probing
# - PS/2 probing
SAFE=no
 
Come si può vedere non è nulla di complicato, e nei commenti è spiegato chiaramente;lo cambiamo così:
 
# Set to anything other than 'no' to force a 'safe' probe on startup.
# 'safe' probe disables:
# - serial port probing
# - DDC monitor probing
# - PS/2 probing
SAFE=yes

Adesso il servizio non toccherà più la configurazione di Xorg. Se dovesse servire per configurare nuove periferiche si può eseguire a mano all'occorrenza. Notare che se usiamo periferiche USB, continueranno a funzionare anche se il servizio kudzu è disabilitato. Il mio mouse di riserva, USB, funziona perfettamente senza problemi, anche collegato a caldo, con Xorg avviato.

Potrebbe anche succedere che all'avvio kudzu abbia pensato bene di cambiare la mappa di tastiera, mettendola americana. Controllare nella sezione InputDevice relativa alla tastiera che vi sia riportato alla riga XkbLayout il valore "it". Nel mio caso lo aveva messo come "us".

3.4. Aggiornamento del sistema

Arrivati ad una installazione utilizzabile, possiamo pensare di fare un aggiornamento generale, per avere kernel ed applicazioni all'ultima versione disponibile. Per far questo possiamo usare yum, un programma di installazione ed aggiornamento intelligente molto semplice da usare. Per aggiornare il sistema, apriamo un terminale e diventiamo root:

[mario@defiant ~]$ su -
Password: digitare la password di root
[root@defiant ~]#
 
poi possiamo dare il comando di aggiornamento:
 
[root@defiant ~]# yum -y update
Setting up Update Process
Setting up repositories
extras 100% |=========================| 1.1 kB 00:00
updates-released 100% |=========================| 951 B 00:00
base 100% |=========================| 1.1 kB 00:00
Reading repository metadata in from local files
primary.xml.gz 100% |=========================| 1.3 MB 00:00
extras : ################################################## 3728/3728
Added 81 new packages, deleted 117 old in 6.61 seconds
...

Il processo è completamente automatico e non dobbiamo fare altro che aspettare il completamento. Se installiamo oggi (maggio 2006) Fedora Core 4, il totale di aggiornamenti potrebbe superare molto facilmente i 600M, molto dipende anche dalle applicazioni che abbiamo installato: OpenOffice da solo supera abbondantemente i 250M. Quindi appare evidente che occorra una connessione veloce ad Internet.

Questa parte non è obbligatoria, se però abbiamo intenzione di ricompilare il kernel per attivare le periferiche che non funzionano con l'installazione base, è necessario aggiornare, per avere l'ultima versione di kernel.

3.5. La console a 160x48? Eccola!

Questa parte è opzionale. Se usiamo molto la console virtuale, quella che si ottiene con la sequenza Ctrl-Alt-F1 (o un altro tasto funzione fino a F6, per ritornare al desktop grafico si usa Ctrl-Alt-F7), potrà interessare la possibilità di impostarla dal solito 80 caratteri per 24 righe, alla rispettabile dimensione di 160 caratteri per 48 righe. Questa cosa è piuttosto difficile da trovare in Internet, dato che per prima cosa non si sa cosa esattamente cercare, e quando si trova ci si riferisce alle risoluzioni standard 1024x768 pixel, o simili, per cui vengono forniti i numeri, ma nessuno fornisce il metodo per sapere come calcolarli. Nei documenti che accompagnano il kernel di Linux, installati con il pacchetto kernel-doc, in una directory con nome fb c'è il file vesafb.txt che spiega come calcolare il numero magico da mettere nella riga di avvio del kernel per avere la console nella risoluzione voluta. In breve occorre aggiungere il numero 0x200 esadecimale all'indentificativo VESA del modo grafico voluto, che nel nostro caso sarà 1280x768 a 16 o 24 bit, cioè a 65000 o 16 milioni di colori. Il problema è trovare il modo VESA. Io ho fatto così, magari ci sono sistemi più semplici:

  • Aprire il file /var/log/Xorg.0.log. Se non c'è, può darsi che ci sia il file Xorg.9.log o con un altro numero, basta che sia il log di Xorg.

  • Cercare la stringa ddc in minuscolo. Si trova una serie di righe che mostrano il caricamento del modulo in questione e poco dopo l'elenco dei modi supportati dal monitor.

  • Ogni modo VESA parte con una riga con il numero esadecimale che lo identifica e con la risoluzione in pixel. Poco sotto ci deve essere una riga con il termine BitsPerPixel seguito da un numero. Per avere 65000 colori deve essere 16, mentre per 16 milioni di colori deve essere 24 o 32. Conviene scegliere lo stesso modo usato dal desktop, per evitare fastidiosi disturbi quando si passa dalla console al desktop e viceversa, ma non è obbligatorio.

Ad esempio la risoluzione che ho scelto io è elencata in questo modo:

Mode: 168 (1280x768)
ModeAttributes: 0x9b
WinAAttributes: 0x7
WinBAttributes: 0x0
WinGranularity: 64
WinSize: 64
WinASegment: 0xa000
WinBSegment: 0x0
WinFuncPtr: 0xc000720f
BytesPerScanline: 5120
XResolution: 1280
YResolution: 768
XCharSize: 8
YCharSize: 16
NumberOfPlanes: 1
BitsPerPixel: 32
...
...

ed è corrispondente al modo usato per il desktop. Applicando la regola riportata sopra, il numero magico diventa 0x368, per cui apriamo il file di configurazione del boot loader Grub, in Fedora /etc/grub.conf, e cambiamo la riga kernel originale aggiungendo in fondo vga=0x368. La riga originale è simile a questa:

title Fedora Core (2.6.14-1.1644_FC4)
root (hd0,4)
kernel /vmlinuz-2.6.14-1.1644_FC4 ro root=LABEL=/ rhgb quiet
initrd /initrd-2.6.14-1.1644_FC4.img

e quella cambiata invece è simile a questa:

title Fedora Core (2.6.14-1.1644_FC4)
root (hd0,4)
kernel /vmlinuz-2.6.14-1.1644_FC4 ro root=LABEL=/ rhgb quiet vga=0x368
initrd /initrd-2.6.14-1.1644_FC4.img

Al prossimo avvio avremo la console testo a 160x48, a colori.

3.6. Il chipset grafico 915

Passiamo ora ad attivare il chip grafico, visto che il configuratore non ci riesce. E' importante che questa operazione venga eseguita dopo l'impostazione della console in modo 160x48, cioè dopo le operazioni fatte nel paragrafo precedente. I modi grafici elencati dal driver specifico del chip hanno valore differente da quello usato nel modo VESA, e quindi non funzioneranno. In questo caso la cosa è piuttosto semplice, dato che il modo specifico del chipset identico al modo VESA ha lo stesso numero meno 0x100 esadecimale, cioè il modo scelto da me, 0x168 in VESA, secondo il chip ha identificativo 0x68. Ma, per evitare problemi, prima imposteremo il modo console come detto nel paragrafo precedente, poi faremo le impostazioni che seguono.

Apriamo il file di configurazione di Xorg, il solito /etc/X11/xorg.conf, e cerchiamo la sezione Device, che dovrebbe apparire come questa:

Section "Device"
Identifier "Videocard0"
Driver "vesa"
VendorName "Videocard vendor"
BoardName "VESA driver (generic)"
EndSection

Puntiamo la riga Driver e cambiamo vesa in i810. Salviamo e riavviamo il server X con il comando:

[root@defiant ~]# killall gdm-binary

Al riapparire del desktop, sarà attiva l'accelerazione del chipset. Non c'è da aspettarsi grandi differenze, ma almeno ora il disegno di alcuni effetti grafici è un po' più veloce.

3.7. Il wireless

Il chipset usato per il wireless non è quello Intel, ma Atheros, come dicevo sopra. Il problema è che il supporto non è presente nel kernel installato con Fedora, e quindi il chip non viene attivato, né usato. Dopo un paio di colpi di Google, ho trovato il sito giusto: http://madwifi.org/. Seguendo i link per il download si arriva a vari depositi di pacchetti RPM con il modulo pronto per Fedora Core 4. Attenzione che la versione del pacchetto deve corrispondere esattamente alla versione del kernel che abbiamo installato, altrimenti i moduli contenuti del pacchetto non si avvieranno, e non ci sarà verso di attivare la scheda wireless. In particolare, se il kernel installato è:

[root@defiant ~]# uname -r
2.6.16-1.2108_FC4

la versione dei pacchetti da installare deve essere ad esempio: madwifi-ng-kmdl-2.6.16-1.2108_FC4-blabla.i686.rpm. Attenzione alle versioni smp, o quelle per x86_64, che vanno installate solo da chi ha i corrispondenti kernel. Per il Thinkpad Z60t la versione da installare è quella non smp e per architettura i686. Se nelle operazioni di configurazione successive otteniamo errori di versione dei moduli del kernel, vuol dire che abbiamo installato il pacchetto sbagliato.

Altra possibilità, molto più semplice, è di usare il deposito di pacchetti RPM Livna, http://rpm.livna.org/, che contiene una nutrita riserva di driver precompilati per Linux Fedora, fra cui quelli per schede grafiche Nvidia e Ati. Per utilizzare questo deposito basta scaricare ed installare un particolare pacchetto RPM, con un unico comando:

[root@defiant ~]# rpm -ivh http://rpm.livna.org/livna-release4.rpm

che in un colpo solo installa e configura il deposito Livna. Ovviamente occorre essere connessi in rete per eseguire correttamente il comando. Appena installato il deposito, basta dare il comando:

[root@defiant ~]# yum install madwifi kernel-module-madwifi

che fa tutto quello che serve, individuando il modulo corretto ed installando i programmi di supporto. 

Se usiamo un kernel compilato da noi

Quanto detto sopra non vale se il kernel lo abbiamo compilato noi. In questo caso tutto il necessario per la compilazione dei moduli è già presente nelle directory che saranno usate per la creazione del kernel.

E' invece importante che tutte le operazioni siano effettuate con il nuovo kernel attivo, cioè dopo aver riavviato il computer usando il nuovo kernel, altrimenti compileremo per il kernel sbagliato, ed all'installazione dei pacchetti RPM riceveremo messaggi di errore.

 Se non vogliamo usare i pacchetti RPM, o nel caso di kernel compilato da noi, possiamo operare nel classico modo dei pacchetti sorgente in formato .tar.gz, con la sequenza make e make install, il risultato è lo stesso. 

Per il kernel compilato da noi

La procedura preferita è di scaricare il pacchetto dei sorgenti in formato .tar.gz, scompattarlo in una directory di comodo con il comando tar xzf madwifi-ng-rNNNN-YYYYMMDD.tar.gz, che crea una directory dal nome madwifi-ng-rNNNN-YYYYMMDD/ con tutti i file necessari. Con l'utente root si entra in questa directory e si impartisce il comando make, seguito al termine da make install. In questo modo si installa sia il gruppo di moduli kernel che il gruppo di comandi di gestione dell'interfaccia wireless.

E' assolutamente importante che questa operazione venga eseguita senza toccare o modificare la directory ed i file in essa contenuti dove abbiamo compilato il kernel, /usr/src/redhat/BUILD/kernel-2.6.16/linux-2.6.16/, altrimenti non funzionerà.

 Per impostare la connessione wireless seguiremo attentamente le istruzioni sul sito citato sopra. Tanto per fare di testa mia (vedi http://ismprofessional.net/pascucci/documenti/why-linux-HOWNOTTO/), non avevo letto, pensando che fosse come l'altra scheda wireless che avevo prima, e non riuscivo a farla funzionare. Ho letto le istruzioni ed ho risolto in pochi minuti. Come volevasi dimostrare. 

La procedura di configurazione è cambiata

Dalla versione r1407 in poi dei driver per la scheda wireless la procedura è quella riportata sotto: chi aveva già installato una versione precedente deve cambiare il solo file /etc/modprobe.conf, il resto è rimasto identico.

La procedura è di inserire nel file /etc/modprobe.conf le due righe:

alias ath0 ath_pci
options ath_pci autocreate=sta

che indicano al driver di creare automaticamente il dispositivo ath0 al caricamento.

Arriva la parte più complicata. Per far vedere la nuova scheda al sistema di networking, occorre creare un profilo nella directory /etc/sysconfig/network-scripts con nome ifcfg-ath0, usando lo stesso nome di interfaccia indicato nelle due righe di configurazione precedenti. La manovra più semplice è di copiare il profilo che appartiene all'interfaccia eth0 che dovrebbe essere già stato creato in automatico durante l'installazione. Quindi:

[root@defiant ~]# cp ifcfg-eth0 ifcfg-ath0

dato dalla directory indicata sopra. Apriamo il file con un editor, il contenuto iniziale dovrebbe essere simile a questo:

DEVICE=eth0
BOOTPROTO=dhcp
HWADDR=00:C0:9F:EB:53:A4
ONBOOT=yes
TYPE=Ethernet
DHCP_HOSTNAME=defiant

Lo cambiamo secondo le nostre esigenze, alla fine dovrebbe assomigliare a questo:

ONBOOT=yes
USERCTL=no
TYPE=Wireless
DEVICE=ath0
BOOTPROTO=dhcp
DHCP_HOSTNAME=defiant
ESSID=miawifi
WIRELESS_CARD_MODE=3
IWPRIV="authmode 2"
CHANNEL=10
MODE=Managed
RATE=Auto
 
I parametri fondamentali sono:
  • TYPE - tipo di interfaccia, in questo caso Wireless. Serve a indirizzare verso l'appropriato script di avvio nella stessa directory, in questo caso ifup-wireless. Guardando dentro questo script possiamo trovare tutte le informazioni sui parametri specifici.

  • MODE - il tipo di configurazione wireless, in questo caso, Managed indica la presenza di un access point.

  • ESSID - il nome della rete wireless

  • DEVICE - deve corrispondere al nome usato in tutti gli altri file, in questo caso ath0

  • IWPRIV - serve per passare configurazioni particolari alla scheda. In questo caso serve a impostare il metodo di cifratura WEP shared key.

Il significato di tutti gli altri valori si trova sia in testa allo script ifup-wireless che nelle pagine di manuale di wlanconfig, athkey, iwconfig, iwpriv e athchans, oltre che sul sito del driver.

Se la rete wireless ha un chiave WEP, va inserita in un altro file, sempre nella stessa directory, dal nome keys-nomeinterfaccia, nel caso in esame keys-ath0 il cui contenuto sarà:

KEY=la_vostra_chiave

Se è un valore esadecimale, possiamo inserirlo direttamente, se invece è una stringa, potrebbe essere necessario convertirla in codice esadecimale, usando il valore ASCII dei singoli caratteri, mi sono capitati un paio di access point che usavano questo metodo.

Sperimentiamo un po' senza perderci d'animo. La scheda funziona, e funziona bene. Speriamo solo che presto integrino il supporto per il chipset Atheros nel kernel.

3.8. Il disco S-ATA e i problemi con il DVD

Con la configurazione di base del kernel all'avvio abbiamo due problemi: il lettore di DVD/masterizzatore CD non usa il DMA; il supporto SMART non funziona, quindi il demone smartd non si avvia e l'utility smartctl ritorna un errore.

Il problema è dovuto al bus misto S-ATA per il disco interno e IDE per il DVD. Alla partenza il driver IDE prende il sopravvento e prende il controllo del DVD, ma non riesce ad abilitare il DMA perché il driver S-ATA blocca i comandi ed impedisce al driver IDE di modificare il comportamento del controller.

La soluzione è di aggiungere alla riga di avvio del kernel, come visto nella parte della console a 160x48, le opzioni per disabilitare il driver IDE sui primi due canali, in modo che gestisca tutto il driver S-ATA di nuova generazione. 

Occorre un kernel versione 2.6.15 o successiva

Perché si possa usare questo metodo occorre un kernel di versione uguale o superiore alla 2.6.15, perché solo a partire da questa è attiva la nuova versione del driver che permette di risolvere tutti i problemi.

Le modifiche alla riga di avvio del kernel si inseriscono aprendo il file /etc/grub.conf e modificando la riga che inizia con la parola kernel in questo modo:

...
title Fedora Core (2.6.16-prep-sd-aps-2108)
root (hd0,4)
kernel /vmlinuz-2.6.16-prep-sd-aps-2108 ro root=LABEL=/ quiet vga=0x368 ide0=noprobe ide1=noprobe
initrd /initrd-2.6.16-prep-sd-aps-2108.img
...

In questo modo comunichiamo al kernel di dare precedenza al driver di nuova generazione. Il cambiamento principale è che il lettore di DVD non sarà più riconosciuto come device /dev/hdc ma come device /dev/scd0, ossia come se fosse un dispositivo SCSI.

Per il problema del demone SMART, occorre modificare il file /etc/smartd.conf il cui contenuto è:

/dev/sda -H -m root@localhost.localdomain
 
per indicare al demone smartd che deve usare il driver ATA con le nuove funzioni incluso nel kernel, in questo modo:
 
/dev/sda -H -d ata -m root@localhost.localdomain

A questo punto si può riabilitare il demone di controllo all'avvio, usando l'utility da console ntsysv o quella grafica system-config-services.

Per l'utility smartctl, usata per controllare al volo lo stato del disco, se viene usata normalmente si ottiene un errore:

[root@defiant ~]# smartctl -H /dev/sda
smartctl version 5.33 [i386-redhat-linux-gnu] Copyright (C) 2002-4 Bruce Allen
Home page is http://smartmontools.sourceforge.netRequest Sense failed, [Input/output error]

Aggiungendo l'opzione -d ata al comando invece si ottiene:

[root@defiant ~]# smartctl -d ata -H /dev/sda
smartctl version 5.33 [i386-redhat-linux-gnu] Copyright (C) 2002-4 Bruce Allen
Home page is http://smartmontools.sourceforge.net/

=== START OF READ SMART DATA SECTION ===
SMART overall-health self-assessment test result: PASSED

che è il comportamento atteso. A titolo di notizia, il comando che abbiamo appena usato serve a chiedere lo stato di salute del disco: se la risposta è PASSED possiamo stare tranquilli.

4. Ultimi ritocchi

4.1. Raffinatezze

Possiamo correggere l'antialiasing predefinito, che rende i caratteri sullo schermo un po' sfocati, e quando sono piccoli quasi illeggibili, usando le impostazioni nel menù Desktop, Preferenze, Tipi di carattere, scegliendo la voce Sfumatura subpixel (LCD), il miglioramento è notevole.

Personalmente odio il boot grafico, contenuto nel pacchetto RPM rhgb, per cui l'ho tolto, e ho eliminato la corrispondente voce nella configurazione di Grub, ma è un fatto assolutamente personale.

4.2. Siamo a buon punto

Dopo qualche settimana di uso normale, i problemi sono veramente pochi, in particolare la ventola del processore va ad una velocità leggermente superiore, risultando un poco più rumorosa rispetto a Windows, e in teoria diminuendo la durata della batteria in Linux.

Non è detto che questo problema sia risolto in versioni successive del kernel, perché è un problema dovuto alla gestione ACPI, per motivi che non è facile spiegare. Ci sono metodi alternativi, anche se un po' laboriosi, spiegati sul sito dedicato all'installazione ed all'uso di Linux sui Thinkpad: http://www.thinkwiki.org/wiki/Patch_for_controlling_fan_speed. Se non abbiamo dimestichezza con pasticciamenti vari con il proc filesystem, possiamo lasciar perdere, non è fondamentale.

4.3. Cosa rimane ancora

Rimangono ancora alcune cose non utilizzabili: il modem (prevedibile), il lettore di impronte digitali ed il sottosistema di crittografia hardware, usato anche per il Trusted Platform Computing (TPC), che tanto fa discutere in questi ultimi tempi.

Ci sono però buone notizie: il lettore di impronte digitali è connesso al bus USB interno, ed infatti viene riconosciuto:

[root@defiant ~]# lsusb
Bus 005 Device 001: ID 0000:0000
Bus 004 Device 002: ID 0483:2016 SGS Thomson Microelectronics
Bus 004 Device 001: ID 0000:0000

Il sito http://linuxbiometrics.com/ è al momento vuoto, ma sul sito http://www.thinkwiki.org/wiki/Integrated_Fingerprint_Reader ci sono tutte le notizie che servono. Personalmente ritengo che un sistema di identificazione che non funzioni con una risposta binaria SI/NO sia poco affidabile. O sono io o non sono io. Sembro io non mi pare il massimo della sicurezza, e dato che i lettori biometrici funzionano su un principio probabilistico, rimango piuttosto scettico. Ma, ripeto, è una opinione assolutamente personale.

Il chip crittografico è al momento disabilitato nel mio notebook, ma è presente fra quelli riconosciuti dal kernel, solo che al momento non è incluso nella configurazione ufficiale di Fedora, nel senso che ci sono tutti i sorgenti ma non vengono compilati ed installati. Appena troverò un uso pratico del chip vedrò di scrivere qualcosa.

4.4. Link per chi ha tempo e coraggio

Molti dispositivi del notebook sono caratteristici di altri modelli dello stesso produttore, e c'è qualcuno che si è dato da fare. Oltre ai link segnalati sopra, segnalo questi altri relativi a sottosistemi o periferiche che al momento non sono sfruttati dal kernel ufficiale e dalle principali distribuzioni di Linux:

  • http://trousers.sourceforge.net/ Una implementazione Opensource del Trusted Computing Software Stack, un parente del sistema ex Palladium, o TCPA, o DRM, insomma ci siamo capiti. Presentato come uno standard che prometteva immunità da virus, spyware ed a tutta la genìa dei malware, si è invece rivelato come uno strumento antipirateria prima, poi un modo per decidere cosa possiamo fare col nostro computer. Se vi interessa sapere la storia, in Rete trovate tutto, fino alla nausea. Nel nostro Thinkpad abbiamo un chip per il supporto crittografico a questo standard. Come possiamo sfruttarlo in un sistema operativo aperto? Beh, sul sito ci sono alcuni esempi, uno dei quali è il trusted Grub, una versione del noto bootloader che prima di effettuare l'avvio del sistema operativo controlla che non sia stato manomesso il bootloader stesso, ed abbiamo la possibilità di far controllare una serie di file prima dell'avvio. Tenete presente che al di là dell'uso per cui è pensato in origine, è come avere una smartcard integrata nel computer. Niente di più. Non è un acceleratore crittografico, anche perché è molto più lento in queste operazioni di qualsiasi processore attuale, e di molto. Puo' però essere utilizzato come "portachiavi". Non mi dilungo oltre, chi vuole saperne di più può leggere tutto sul sito indicato, e varie informazioni sul Trusted Computing sul sito http://www.no1984.org/.

  • http://tpctl.sourceforge.net/ Una collezione di utility per impostare alcune funzioni del notebook come i timer di spegnimento del display ed il resume ad orario. C'è anche una interfaccia grafica per GNOME.

C'è dell'altro, ma piuttosto che elencare i singoli link, preferisco dare i siti che li riportano con tanto di commenti ed aggiornamenti:

  • http://www.thinkwiki.org/ Una collezione notevole e continuamente aggiornata di notizie sui Thinkpad presenti e passati. Moltissimo materiale per l'installazione di Linux e sulla gestione delle particolari caratteristiche di ogni modello. Si trovano anche tantissimi link a siti che trattano problemi specifici e offrono software aggiuntivi.

  • http://www.tuxmobil.org/ Linux sui dispositivi portatili. C'è elencato di tutto, dai palmari ai cellulari, ai navigatori GPS. Ovviamente c'è una nutrita sezione dedicata ai notebook, elencati per marca e modello. Nella pagina dedicata ai Thinkpad in fondo c'è una collezione di link da non perdere. Ospita anche una mailing list.

  • http://www.linux-laptop.net/ Sito molto simile al precedente. Non contiene link specifici per modello o produttore, ma ha un forum.

  • http://www.linux-thinkpad.org/ Il sito sembra abbandonato da un po', ma ha una mailing list molto attiva.

Insomma, c'è di che leggere per mesi. E di che "smanettare" per anni.

4.5. Conclusioni

C'è tutto quello che serve per lavorare. Per quanto riguarda quello che ancora non funziona o non viene riconosciuto, probabilmente basterà attendere, in fondo è lo stesso con tutto l'hardware troppo nuovo, con Linux. Ma, ripeto, basta aver pazienza. A titolo di curiosità includo un paio di screenshot con tutto incluso. Il primo con un desktop "cattivello", che purtroppo non mi ricordo dove ho preso (mi pare da http://www.kde-look.org/, ma non ne sono sicuro).

Figura 1. Il desktop "liscio"

Il desktop "liscio"

Dimensione originale

Il secondo con una scena ispirata ad uno dei film della trilogia di Star Wars™, dal titolo "Vola disinvolto" (in inglese "Fly casual"), preso dal sito http://www.desktopstarships.com/ che ha una collezione impressionante di wallpaper di ottima qualità.

Figura 2. Le applicazioni in categoria "office"

Le applicazioni in categoria "office"

Dimensione originale

In alto a destra potete notare da destra verso sinistra le applet: controllo volume, orologio, batteria, rete wireless (non attiva), rete ethernet (attiva), controllo frequenza CPU, carico processore e le "note adesive", il Post-It™ elettronico.

5. Compilo? OK, compilo...

5.1. Avvertenze e modalità d'uso

Per prima cosa è importante capire che le procedure qui descritte non sono alla portata di un utente alle prime armi con Linux. Con Linux, per cui anche il massimo esperto di tutti i sistemi operativi esistenti che non conosca Linux deve considerarsi alle prime armi.

Secondariamente, il successo di queste procedure può variare in funzione di un numero pressoché infinito di variabili. Quindi quello che a me ha funzionato al primo colpo a voi potrebbe non funzionare affatto. O viceversa. Per questo conto molto sul vostro aiuto: segnalatemi discrepanze, omissioni, soluzioni ed errori che doveste trovare, ne avremo tutti da guadagnare.

Per quanto riguarda l'efficacia ed i risultati ottenuti, il sistema APS funziona al 100% e dopo il lavoro iniziale per attivarlo poi andrà da solo senza altre modifiche. Mentre il lettore di SD, pur funzionante, ha ancora qualcosa che non va. E' sì utilizzabile, ma è un po' capriccioso, e non sempre reagisce come dovrebbe. In un paio di casi ho avuto un blocco totale del computer, per fortuna senza perdita di dati (avevo comunque fatto un backup). Pierre Ossman, lo sviluppatore del driver, sta praticamente riscrivendo tutto il driver, oltre a lavorare su altre anomalie minori. 

Il kernel di riferimento è il 2.6.16-1.2108_FC4

Tutte le procedure elencate di seguito riguardano questa versione di kernel, rilasciato ai primi di maggio 2006. Non ho avuto il tempo di provare su altre versioni o varianti, quindi, per favore, se volete avere una possibilità di successo, usate la stessa versione.

Ultima cosa, le operazioni che seguono sono ad alto rischio di perdita dati, per cui prima di proseguire faremo un backup di tutto.

Chiedo scusa per la franchezza, ma non sono e non sarò responsabile della perdita dei vostri dati. La procedura è ad alto rischio e se non siete coscienti del pericolo sono problemi vostri: non l'ha ordinato il dottore di imbarcarvi in questa impresa. Chiarito questo, possiamo andare avanti.

5.2. Preparazione

Prima di qualsiasi altra cosa, controlleremo di avere tutto l'occorrente per la compilazione, cosa che è sicuramente vera se al momento dell'installazione di Fedora abbiamo selezionato il gruppo di programmi per lo sviluppo del software. Se così non è, occorre provvedere avviando l'utility in Desktop, Impostazioni di sistema, Aggiungere/Rimuovere le applicazioni.

Per comodità di tutti, e per evitare di girare per siti web alla disperata ricerca di file e patch, ho riunito i file sul mio sito, in varie directory, indicate al momento opportuno. Per aumentare la sicurezza, ho calcolato gli hash MD5 e firmato i file risultanti con la mia chiave GnuPG (chi non di cosa parlo, può trovare tutte le informazioni necessarie sul sito di GnuPG), che per la cronaca trovate qui.

Dal sito di Fedora (http://download.fedora.redhat.com/) prendiamo il sorgente del kernel nella versione ultima disponibile, che troviamo nella directory /pub/fedora/linux/core/updates/4/SRPMS/ del server. Attenzione a non prendere una versione più vecchia, quella che useremo è nel pacchetto kernel-2.6.16-1.2108_FC4.src.rpm.

Per comodità, e per chi si fida, ne trovate qui trovate i file più importanti:

il file di configurazione originale: config-2.6.16-1.2108_FC4
il file di configurazione con lettore SD e APS: config-2.6.16-prep-sd-aps-2108
il file di controllo firmato con la mia chiave: md5sums.asc

Per installarlo:

[root@defiant ~]# rpm -Uvh kernel-2.6.16-1.2108_FC4.src.rpm
1:kernel ########################################### [100%]

Non lo troveremo installato fra i pacchetti, ma i file vengono posizionati nella directory /usr/src/redhat/SOURCES. Se andiamo a curiosare, vi troveremo un file di poco meno di 40M che contiene i sorgenti del kernel, ed un centinaio di file di patch. Niente panico, non dovremo applicarle a mano. Nella directory /usr/src/redhat/SPECS/ c'è il file di definizione per la generazione dei pacchetti RPM. Per quello che serve a noi, dobbiamo istruire il programma di generazione dei pacchetti per eseguire solo la fase definita prep, cioè la preparazione dei sorgenti per la successiva compilazione, senza procedere alla compilazione vera e propria, usando questo comando:

[root@defiant ~]# rpmbuild -bp --target i686 /usr/src/redhat/SPECS/kernel-2.6.spec
Building target platforms: i686
Building for target i686
Executing(%prep): /bin/sh -e /var/tmp/rpm-tmp.92442
+ umask 022
+ cd /usr/src/redhat/BUILD
+ LANG=C
+ export LANG
+ unset DISPLAY
+ '[' '!' -d kernel-2.6.16/vanilla ']'
+ cd kernel-2.6.16
+ mv linux-2.6.16 deleteme
+ rm -rf deleteme
+ cp -rl vanilla linux-2.6.16
...
+ echo 'Patch #1680 (linux-2.6-pwc-powerup-by-default.patch):'
Patch #1680 (linux-2.6-pwc-powerup-by-default.patch):
+ patch -p1 -s
+ echo 'Patch #1690 (linux-2.6-smsc-ircc2-pnp.patch):'
Patch #1690 (linux-2.6-smsc-ircc2-pnp.patch):
+ patch -p1 -s
+ echo 'Patch #1700 (linux-2.6-w1-hush-debug.patch):'
Patch #1700 (linux-2.6-w1-hush-debug.patch):
+ patch -p1 -s
...
.config:2988:warning: trying to reassign symbol HIGHMEM64G
+ echo '# i386'
+ cat .config
+ perl -p -i -e 's/^SUBLEVEL.*/SUBLEVEL = 16/' Makefile
+ perl -p -i -e 's/^EXTRAVERSION.*/EXTRAVERSION = -prep/' Makefile
+ find . -name '*.orig' -o -name '*~' -exec rm -f '{}' ';'
+ exit 0

la procedura stampa un bel po' di righe, un nutrito elenco di warning, e ci vuole un minuto circa per arrivare al termine.

Siamo pronti per la fase successiva, l'applicazione delle patch per le cose che mancano. Ho preferito fare un paragrafo per ogni singolo componente da attivare, così se il componente non interessa basta saltare il paragrafo.

5.3. Una pezza per il lettore SD

Le patch per il kernel 2.6.16 non sono disponibili sul sito riportato nella versione precedente di questo documento, anche perché gli sviluppatori stanno lavorando per integrare il driver all'interno del kernel 2.6.17. Per semplificare la vita a tutti ho raccolto le patch qui di seguito, da dove potete prelevarle salvando i file:

il file mmc-multi-sector-writes.patch
il file mmc-sdhci-build-fix.patch
il file mmc-secure-digital-host-controller-interface-driver-fix.patch
il file mmc-secure-digital-host-controller-interface-driver.patch
il file della mia patch pci-sdhc-mario.patch
il file di controllo firmato con la mia chiave: md5sums.asc

Se invece volete prelevarle alla fonte il sito è questo: ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.16/2.6.16-mm1/broken-out/ ed i file da scaricare sono:

mmc-multi-sector-writes.patch
mmc-sdhci-build-fix.patch
mmc-secure-digital-host-controller-interface-driver-fix.patch
mmc-secure-digital-host-controller-interface-driver.patch

Inoltre, per evitare problemi alla compilazione, occorre usare anche la patch ricavata da me in base alle vecchie, che trovate elencata sopra, insieme alle altre, col nome pci-sdhc-mario.patch.

Vediamo ora la procedura di applicazione delle patch, che in realtà sono file di testo rappresentanti le modifiche. Salviamoli da qualche parte, per esempio in /tmp, con estensione .patch. Al termine in /tmp avremo cinque file: mmc-multi-sector-writes.patch di circa 4k, mmc-sdhci-build-fix.patch di 800 byte, mmc-secure-digital-host-controller-interface-driver-fix.patch, meno di 5k, mmc-secure-digital-host-controller-interface-driver.patch di 40k ed infine pci-sdhc-mario.patch di poco più di 1k. L'ordine in cui vanno aplicate le patch è critico, quindi occorre seguire esattamente la procedura.

Spostiamoci dentro l'albero dei sorgenti del kernel, già preparato prima e posizionato in /usr/src/redhat/BUILD/kernel-2.6.16/linux-2.6.16/. Da qui dentro diamo prima il seguente comando:

[root@defiant linux-2.6.16]# patch -p1 \
--dry-run < /tmp/mmc-secure-digital-host-controller-interface-driver.patch

patching file drivers/mmc/Kconfig
patching file drivers/mmc/Makefile
patching file drivers/mmc/sdhci.c
patching file drivers/mmc/sdhci.h
missing header for unified diff at line 1482 of patch
patching file MAINTAINERS
Hunk #1 succeeded at 2490 (offset 1 line).

che esegue una simulazione del processo, senza effettivamente modificare i file. Controlleremo che non siano restituiti errori. Gli eventuali avvisi Hunk #n succeeded at xxx sono normali, dato che il kernel di serie su Fedora è già abbondantemente rappezzato (non in senso negativo). L'importante è che non riceviamo messaggi di rifiuto.

Visto che la simulazione per il primo file è andata bene, possiamo provare i file successivi (attenzione al -p0 solo per il primo comando):

[root@defiant linux-2.6.16]# patch -p0 --dry-run < /tmp/pci-sdhc-mario.patch
patching file include/linux/pci_ids.h
 
[root@defiant linux-2.6.16]# patch -p1 --dry-run < /tmp/mmc-multi-sector-writes.patch
patching file drivers/mmc/Kconfig
patching file drivers/mmc/mmc_block.c

A quanto pare è tutto a posto, e prima di poter provare le due ultime patch occorre applicare prima le tre appena verificate, dato che le altre due sono correzioni successive.

Se all'applicazione di una patch otteniamo un messaggio come questo:

can't find file to patch at input line 3
Perhaps you used the wrong -p or --strip option?
The text leading up to this was:
--------------------------
|--- include/linux/pci_ids.h.orig 2006-03-04 15:33:10.000000000 +0100
|+++ include/linux/pci_ids.h 2006-03-08 12:16:24.000000000 +0100
--------------------------
File to patch
 
vuol dire che abbiamo confuso un -p0 con un -p1 o viceversa: basta interrompere il comando con un Ctrl-C, e ricontrollare.

Applichiamo quindi le tre appena viste, rieseguendo i comandi senza l'opzione --dry-run (anche qui attenzione al -p0 nel secondo comando):

[root@defiant linux-2.6.16]# patch \
-p1 < /tmp/mmc-secure-digital-host-controller-interface-driver.patch

patching file drivers/mmc/Kconfig
patching file drivers/mmc/Makefile
patching file drivers/mmc/sdhci.c
patching file drivers/mmc/sdhci.h
missing header for unified diff at line 1482 of patch
patching file MAINTAINERS
Hunk #1 succeeded at 2490 (offset 1 line).

 
[root@defiant linux-2.6.16]# patch -p0 < /tmp/pci-sdhc-mario.patch
patching file include/linux/pci_ids.h
 
[root@defiant linux-2.6.16]# patch -p1 < /tmp/mmc-multi-sector-writes.patch
patching file drivers/mmc/Kconfig
patching file drivers/mmc/mmc_block.c
 
Passiamo a provare le due ultime patch:
 

[root@defiant linux-2.6.16]# patch -p1 \
--dry-run < /tmp/mmc-secure-digital-host-controller-interface-driver-fix.patch

patching file drivers/mmc/sdhci.c
patching file drivers/mmc/sdhci.h

 
[root@defiant linux-2.6.16]# patch -p1 --dry-run < /tmp/mmc-sdhci-build-fix.patch
patching file drivers/mmc/sdhci.c

Se, come sembra, è tutto a posto, passiamo ad applicarle definitivamente:

[root@defiant linux-2.6.16]# patch \
-p1 < /tmp/mmc-secure-digital-host-controller-interface-driver-fix.patch

patching file drivers/mmc/sdhci.c
patching file drivers/mmc/sdhci.h

 
[root@defiant linux-2.6.16]# patch -p1 < /tmp/mmc-sdhci-build-fix.patch
patching file drivers/mmc/sdhci.c

Se otteniamo risultati differenti, o abbiamo preso una diversa versione di kernel, o abbiamo saltato qualche passaggio. A differenza delle situazioni precedenti, questa procedura è specifica e garantita solo su questa versione del kernel, dato che gli sviluppatori stanno lavorando pesantemente sul codice. Niente ci impedisce di provare anche su altre versioni di kernel, l'importante è che non ci siano errori o patch rejected, rifiutate, che indicano il non poter usare le patch con la versione di kernel scelta, ma per quanto mi riguarda la procedura è stata provata solo sulla versione di kernel 2.6.16-1.2108_FC4.

La procedura applicata permette di avere il lettore di SD funzionante, con qualche limitazione che vedremo nel paragrafo in cui andremo a vedere le operazioni per attivarlo.

5.4. Una pezza per proteggere l'hard disk

Passiamo ora all'accelerometro, base per l'Active Protection System. Non basta applicare la modifica di cui abbiamo già parlato nel capitolo precedente, occorre anche attivare una specifica funzione che permette di parcheggiare di corsa le testine del disco senza compromettere le operazioni in corso del sistema, e senza rompere nulla.

Per fare questo avremo bisogno di quattro elementi: una patch ai sorgenti del kernel, la modifica a mano di un file nei sorgenti stessi, il demone che controlla gli urti ed eventualmente parcheggia il disco, ed infine una applet per GNOME che mostra lo stato del disco. Anche qui, per nostra comodità tutti i file li troveremo di seguito, dove ho raggruppato tutto il necessario per attivare questa funzione, ma in ogni caso elencherò i link originali per ogni file più avanti:

i sorgenti dell'applet per Gnome: gnome-hdaps-applet-20060120.tar.gz
lo script di avvio del demone hdaps
il file di configurazione del demone hdapsconf
il sorgente del demone hdapsd-20060409.c
la patch per il kernel hdaps_protect.20060326.patch
la patch per far riconoscere il nostro notebook hdaps-z60-mario.patch
il file di controllo firmato con la mia chiave: md5sums.asc
 

Questa procedura è specifica

E' applicabile solo al modello Z60t, con disco interno da 60G. Con altri modelli di notebook e di disco non solo non è detto che funzioni, ma con alcuni modelli di hard disk che non prevedono il "parcheggio al volo" potrebbe portare alla morte prematura. Questi dischi infatti per "parcheggiare" eseguono uno stop del motore (tecnicamente uno spin down): il continuo start-stop rovina motore ed elettronica, accorciando drammaticamente la vita del disco. Per cui se il vostro disco invece di parcheggiare, cosa che non fa rumori particolari, lo sentite fermarsi e ripartire, smettete immediatamente di usare il demone che ne gestisce la protezione. Non è necessario rimuovere le modifiche al kernel, basta non usare il demone che impartisce i comandi di stop al momento dell'urto.

La patch originale si può prelevare dal sito http://www.zen24593.zen.co.uk/hdaps/, sotto forma di file dal nome hdaps_protect.20060326.patch, in alternativa si può usare la copia fornita sul mio sito. Salveremo il file al solito nella directory /tmp. Le patch più recenti non funzionano, quindi è inutile provarle.

Per applicare la patch useremo lo stesso metodo usato per il lettore di schede SD visto al paragrafo precedente, provando prima con l'opzione --dry-run, applicando la patch solo in caso di successo del test. Quindi:

[root@defiant linux-2.6.16]# patch -p1 --dry-run < /tmp/hdaps_protect.20060326.patch
patching file block/ll_rw_blk.c
patching file drivers/ide/ide-disk.c
patching file drivers/ide/ide-io.c
patching file drivers/scsi/libata-scsi.c
Hunk #1 succeeded at 659 (offset -3 lines).
patching file drivers/scsi/scsi_lib.c
patching file include/linux/ata.h
patching file include/linux/blkdev.h
patching file include/linux/ide.h
 
tutto ok, si applica effettivamente la patch
 
[root@defiant linux-2.6.16]# patch -p1 < /tmp/hdaps_protect.20060326.patch
patching file block/ll_rw_blk.c
patching file drivers/ide/ide-disk.c
patching file drivers/ide/ide-io.c
patching file drivers/scsi/libata-scsi.c
Hunk #1 succeeded at 659 (offset -3 lines).
patching file drivers/scsi/scsi_lib.c
patching file include/linux/ata.h
patching file include/linux/blkdev.h
patching file include/linux/ide.h
 
Passiamo a modificare a mano un file. Apriamo nel nostro editor preferito il file /usr/src/redhat/BUILD/kernel-2.6.16/linux-2.6.16/drivers/hwmon/hdaps.c.Andiamo alla riga 529 che è così:
 
529: HDAPS_DMI_MATCH_NORMAL("ThinkPad X41"),
530: { .ident = NULL }

ed aggiungiamo una riga in questo modo:

529: HDAPS_DMI_MATCH_NORMAL("ThinkPad X41"),
530: HDAPS_DMI_MATCH_NORMAL("ThinkPad Z60"),
531: { .ident = NULL }

ovviamente dobbiamo omettere i numeri di riga, sono lì come riferimento al file sorgente. Il tutto dobbiamo digitarlo senza saltare nessun carattere, rispettando le lettere maiuscole e minuscole. La procedura consente il riconoscimento dell'accelerometro anche sul modello Z60m, come risulta da messaggi presenti nella mailing list degli sviluppatori del driver. Possiamo salvare ed uscire, la modifica è pronta.

Per chi non se la sente di modificare a mano, ho preparato una patch specifica, che trovate elencata sopra insieme alle altre, nel file hdaps-z60-mario.patch. Va applicata nel modo solito, dopo averla scaricata nella directory /tmp (attenzione al -p0):

[root@defiant linux-2.6.16]# patch -p0 --dry-run < /tmp/hdaps-z60-mario.patch
patching file drivers/hwmon/hdaps.c

e con questo siamo a posto per le patch.

Del demone e dell'applet ce ne occuperemo dopo aver compilato ed installato con successo il nuovo kernel.

5.5. La configurazione del kernel

Questa sarebbe la parte più complicata per un normale utente, ma ci limiteremo alle sole modifiche necessarie per attivare le nuove funzioni, e non partiremo da zero, ma dalla configurazione usata dal kernel installato da Fedora, che possiamo affermare funzioni correttamente.

Come utente root, andiamo nella directory /usr/src/redhat/BUILD/kernel-2.6.16/linux-2.6.16/, la radice dei sorgenti del kernel, e lanciamo questo comando (attenzione al punto prima del nome del secondo file):

[root@defiant linux-2.6.16]# cp /boot/config-2.6.16-1.2108_FC4 .config

che copia la configurazione usata dal kernel attivo in questo momento nel file che viene letto sia dalle utility di configurazione, che adesso andremo ad usare, sia durante la fase di compilazione per la generazione vera e propria del kernel (al solito, chi non l'avesse ne trova una copia sopra insieme ai sorgenti, Sezione 5.2, «Preparazione» ). Fatto questo abbiamo una base solida da cui partire, anche perché questa configurazione è sicuramente funzionante, la stiamo usando!

Il passo successivo è di chiamare l'utility di configurazione, che può essere in versione solo testo, o in versione grafica, a nostro gusto. Per usare la versione solo testo, utile se non abbiamo a disposizione un desktop come GNOME, lanciamo questo comando:

[root@defiant linux-2.6.16]# make menuconfig
HOSTLD scripts/kconfig/mconf
HOSTCC scripts/lxdialog/checklist.o
HOSTCC scripts/lxdialog/inputbox.o
HOSTCC scripts/lxdialog/lxdialog.o
HOSTCC scripts/lxdialog/menubox.o
HOSTCC scripts/lxdialog/msgbox.o
HOSTCC scripts/lxdialog/textbox.o
HOSTCC scripts/lxdialog/util.o
HOSTCC scripts/lxdialog/yesno.o
HOSTLD scripts/lxdialog/lxdialog
scripts/kconfig/mconf arch/i386/Kconfig
#
# using defaults found in .config
#

al termine del quale ci troviamo un menù disegnato in modalità testo (Figura 3, «Configurazione kernel con "make menuconfig"» ). Se invece abbiamo preferenza per la versione grafica, possiamo usare il comando:

[root@defiant linux-2.6.16]# make gconfig
scripts/kconfig/gconf arch/i386/Kconfig
#
# using defaults found in .config
#

con cui otteniamo una finestra grafica (Figura 4, «Configurazione con "make gconfig"» ). Notare che le voci sono identiche, ed hanno lo stesso ordine.

Figura 3. Configurazione kernel con "make menuconfig"

Image

Figura 4. Configurazione con "make gconfig"

Image 

Passiamo a configurare il nostro kernel, supponendo di usare la versione testo, quella ottenuta con make menuconfig. Selezioniamo la voce General setup, poi la voce Local version - append to kernel release. Questa opzione serve a dare un nome personalizzato alla versione di kernel che andiamo a generare. Non è importante, ma serve per ricordare a noi stessi che cosa aveva di particolare quella versione. Non esiste il pericolo, come spesso capita le prime volte quando si pasticcia con queste cose, di dare al kernel che si va a generare lo stesso nome del kernel già installato, con il disastroso risultato di cancellare la versione funzionante e sostituirla con una versione a dir poco instabile, e per di più mentre è in funzione. Non succede perché Fedora aggiunge in coda sempre la stringa -prep alla versione che va a generare. Se non mettiamo nulla, il nostro nuovo kernel si chiamerà in questo caso 2.6.16-prep, un nome poco descrittivo, in effetti. Una variante utile potrebbe essere di mettere i nomi di quello che vogliamo attivare, ad esempio -sd-aps-2108: in questo caso il nostro kernel si chiamerà 2.6.16-prep-sd-aps-2108, rendendo un po' più agevole ricordare perché lo abbiamo generato, e da quale versione del kernel di Fedora.

Il punto successivo è alla voce Device Drivers, Hardware Monitoring support, alla penultima riga controllare che la voce IBM Hard Drive Active Protection System (hdaps) sia impostata come modulo (<M>), come dovrebbe già essere.

Per abilitare il lettore di SD, sempre nella sezione Device Drivers, selezionare MMC/SD Card support, ed attivare come modulo la voce Secure Digital Host Controller Interface support.

Ultima cosa, disabilitare la generazione delle informazioni di debug nel kernel, che lo rendono di dimensioni elefantiache, almeno come spazio occupato su disco. Andiamo nella voce Kernel hacking, e togliamo la voce Compile the kernel with debug info.

Selezionare <Exit> più volte fino alla domanda per il salvataggio della nuova configurazione, dove risponderemo affermativamente. Siamo pronti per la compilazione.

5.6. La compilazione

Dal terminale dove abbiamo configurato il kernel, e nella stessa directory, come utente root possiamo avviare la compilazione:

[root@defiant linux-2.6.16]# nice make
CHK include/linux/version.h
UPD include/linux/version.h
SPLIT include/linux/autoconf.h -> include/config/*
CHK include/linux/compile.h
CC init/version.o
LD init/built-in.o
CHK usr/initramfs_list
CC arch/i386/kernel/ptrace.o
CC arch/i386/kernel/time.o
CC arch/i386/kernel/ioport.o
CC arch/i386/kernel/ldt.o
CC arch/i386/kernel/setup.o
...

non resta che attendere. 

Armiamoci di pazienza

Il processo di compilazione è piuttosto lungo, da quaranta minuti a oltre un'ora. Usando il nice viene eseguito con priorità minore, per cui durante la compilazione possiamo fare altre cose, senza paura di compromettere l'operazione. Inutile dire che non è il caso di andare a batteria, con il processore che lavora al 100% durerebbe molto poco.

La visualizzazione di alcuni warning durante la compilazione è normale, quello che non è normale è la terminazione con un errore. Se dovesse accadere, proveremo a capire dal messaggio di errore e dalle righe precedenti quale sia il problema. Si può tentare di nuovo, dopo aver ricontrollato attentamente tutti i passaggi, ma se dovesse accadere di nuovo, c'è proprio qualcosa che non va. Dovrebbe essere piuttosto improbabile, ma si sa che la sfortuna è sempre in agguato.

5.7. L'installazione del nuovo kernel

L'installazione è piuttosto semplice, occorre solo rispettare la sequenza giusta. Per primi installeremo i moduli del kernel:

[root@defiant linux-2.6.16]# make modules_install
INSTALL arch/i386/crypto/aes-i586.ko
INSTALL arch/i386/kernel/cpu/cpufreq/acpi-cpufreq.ko
INSTALL arch/i386/kernel/cpu/cpufreq/p4-clockmod.ko
INSTALL arch/i386/kernel/cpu/cpufreq/powernow-k8.ko
INSTALL arch/i386/kernel/cpu/cpufreq/speedstep-smi.ko
INSTALL arch/i386/kernel/cpuid.ko
INSTALL arch/i386/kernel/microcode.ko
INSTALL arch/i386/kernel/msr.ko
INSTALL arch/i386/oprofile/oprofile.ko
INSTALL crypto/aes.ko
INSTALL crypto/anubis.ko
INSTALL crypto/arc4.ko
INSTALL crypto/blowfish.ko
INSTALL crypto/cast5.ko
INSTALL crypto/cast6.ko
INSTALL crypto/crc32c.ko
INSTALL crypto/crypto_null.ko
INSTALL crypto/deflate.ko
...

la lista è piuttosto lunga, occorre un po' di pazienza.

Subito dopo passiamo ad installare il kernel vero e proprio:

[root@defiant linux-2.6.16]# make install
sh /usr/src/redhat/BUILD/kernel-2.6.16/linux-2.6.16/arch/i386/boot/install.sh
2.6.16-prep-sd-aps-2108 arch/i386/boot/bzImage System.map "/boot"

E' importante non invertire le due operazioni, se proviamo ad installare prima il kernel otterremo un messaggio di errore. Non c'è bisogno di andare a cambiare la configurazione di Grub, il bootloader, perché viene fatto automaticamente. Il nuovo kernel è pronto. 

Non cancellare il kernel ufficiale

Per la semplice ragione che qualcosa potrebbe andare storto col nuovo kernel, mai, mai e poi mai cancellare il kernel con cui siamo partiti e con cui lavoriamo: possiamo sempre riavviare e tornare al kernel funzionante.

Siamo pronti per il debutto del nuovo kernel, che avverrà con un riavvio: al comparire del messaggio di avvio di Grub possiamo selezionare il nuovo kernel e partire con quello.

5.8. Active Protection System... GO!

Per controllare che l'accelerometro sia riconosciuto, da un terminale dove siamo root daremo il comando:

[root@defiant ~]# modprobe hdaps

seguito da:

[root@defiant ~]# dmesg
...
hdaps: IBM ThinkPad Z60 detected.
hdaps: initial latch check good (0x01).
hdaps: device successfully initialized.
input: hdaps as /class/input/input4
hdaps: driver successfully loaded.

se le ultime righe sono come queste, l'accelerometro è riconosciuto ed attivato. Ora... il problema è che così ci facciamo poco, finché non aggiungiamo qualcosa che legga i dati dell'accelerometro e in caso di necessità metta le testine del disco al sicuro, e magari anche qualcosa che faccia un po' di coreografia, mostrando lo stato del disco. 

Pericolo di formattazione!

La procedura è piuttosto complicata per un utente normale, e non la applicheremo comunque se prima non avremo fatto un backup totale del nostro computer, in quanto un errore potrebbe compromettere l'integrità del filesystem: se il demone, per un errore nei parametri di avvio o per un errore nel software (sempre possibile) dovesse bloccare in permanenza il disco, nessuna delle ultime operazioni sui file verrebbe trasferita, con conseguente totale perdita dei dati, e forse anche del sistema operativo installato.

Quindi, coscienti del rischio, andiamo avanti. Il sorgente del demone lo troviamo sul sito http://www.zen24593.zen.co.uk/hdaps/, oltre che sul mio sito (Sezione 5.4, «Una pezza per proteggere l'hard disk» ). Ci si arriva anche passando dal sito http://www.thinkwiki.org/wiki/How_to_protect_the_harddisk_through_APS, ormai diventato il nostro riferimento per tutto quanto riguarda il nostro notebook. Il file di riferimento è hdapsd-20060409.c. In una directory a piacere mettiamo il sorgente del demone, dopodiché passiamo a compilarlo:

[mario@defiant ~]$ gcc -o hdapsd hdapsd-20060409.c

Al termine ci troveremo con un file in più dal nome hdapsd, che copieremo come utente root in una directory dove normalmente risiedono i programmi. Per motivi di ordine conviene usare /usr/local/sbin, usata di solito per i demoni ed i servizi installati che non fanno parte della distribuzione ufficiale, anche perché i file che seguono fanno riferimento a questa posizione.

Di seguito, preleveremo lo script hdaps , che inseriremo nella directory /etc/init.d, dove sono tutti gli script di avvio dei vari demoni, e il file hdapsconf di configurazione dello script, che metteremo nella directory /etc/sysconfig.

Controlleremo che lo script di avvio del demone, posizionato in /etc/init.d/hdaps abbia i permessi di esecuzione:

[root@defiant ~]# ls -l /etc/init.d/hdaps
-rwxr-xr-x 1 root root 1398 13 mar 09:53 /etc/init.d/hdaps

Se così non fosse, li assegneremo con il comando:

[root@defiant ~]# chmod a+x /etc/init.d/hdaps

Altro problema che potremmo avere, scaricando i file hdaps e hdapsconf con Windows™, è che vengano modificati i caratteri di fine riga, che in Linux/Unix corrispondono al solo carattere LineFeed, mentre in Windows™ corrispondono alla coppia CarriageReturn-LineFeed. In questo caso al lancio dello script di avvio del demone avremmo il messaggio:

[root@defiant ~]# /etc/init.d/hdaps start
bad interpreter: No such file or directory
 
In questo caso occorre trasformare i file dal formato Windows™ al formato Unix/Linux. Supponendo che i due file siano nella directory /tmp i comandi da dare sono:
 
[root@defiant ~]# cat /tmp/hdaps | dos2unix > /etc/init.d/hdaps
 
[root@defiant ~]# cat /tmp/hdapsconf | dos2unix > /etc/sysconfig/hdapsconf

Il comando dos2unix fa esattamente questo, trasformando le sequenze CarriageReturn-LineFeed in Linefeed.

Siamo pronti per avviare il demone di controllo, ma prima di fare qualsiasi altra cosa... 

Abbiamo fatto il backup?

E' arrivato il momento di fare un backup di tutti i dati: file, posta, ecc. Uomo avvisato...

Per verificare il funzionamento del demone, prima di avviarlo in modo stabile, in un terminale dove siamo root, dopo aver caricato il modulo kernel come visto sopra, lanciamo a mano il demone:

[root@defiant ~]# hdapsd -d sda -s 15

che rimane in attesa. Se vediamo il messaggio:

open("/sys/devices/platform/hdaps/position"): No such file or directory

non abbiamo caricato il modulo.

Prendiamo in mano il notebook delicatamente ed incliniamolo da un lato, il risultato dovrebbe essere qualcosa del genere:

Thu Mar 9 17:24:45 2006: parking
Thu Mar 9 17:24:48 2006: un-parking
Thu Mar 9 17:24:48 2006: parking
Thu Mar 9 17:24:51 2006: un-parking
 
segno che sta facendo il suo dovere. Per sicurezza diamo il comando:
 
[root@defiant ~]# dmesg
...
ata_scsi_issue_protect_fn(): unload support reported..
scsi_protect_queue(): head parked!..
queue_protect_store(): freeze = 5
queue_protect_store(): freeze = 5
...

dobbiamo trovare fra le altre righe queste, indice che il disco gestisce correttamente il comando di "parcheggia". Se invece dovessimo trovare righe come queste:

...
ata_scsi_issue_protect_fn(): unload support NOT reported..
scsi_protect_queue(): head park not requested, used standby!..
oppure, se il disco è IDE invece di SATA
idedisk_issue_protect_fn(): unload support NOT reported..
ide_protect_queue(): head park not requested, used standby!..

vuol dire che il disco non gestisce correttamente il comando di unload, cioè il "parcheggia", e dobbiamo rinunciare ad usare questa versione di hdapsd. Potrebbe essere un problema di firmware del disco, aggiornabile come si fa per il BIOS, ma è una operazione che non ho mai tentato e che non è proprio banale. Sul sito del produttore e su ThinkWiki ci sono tutte le informazioni necessarie.

Se invece va tutto per il verso giusto, possiamo rendere automatico l'avvio del demone quando accendiamo il computer, usando la consueta utility ntsysv. Prima però occorre aggiungere il servizio hdaps (il nome esatto dello script inserito nella directory /etc/init.d) fra quelli conosciuti:

[root@defiant ~]# chkconfig --add hdaps

fatto questo, con l'utility ntsysv o con la sua controparte in grafica system-config-services possiamo attivare il servizio hdaps.

Ultima "finezza", l'applet in GNOME. Dal mio sito, o dal sito http://www.zen24593.zen.co.uk/hdaps/ preleviamo il file gnome-hdaps-applet-20060120.tar.gz che contiene i sorgenti e le istruzioni per l'installazione.

Decomprimere il tutto in una directory di appoggio, e da dentro la directory dare il comando:

[mario@defiant varie]$ gcc $(pkg-config --cflags --libs libpanelapplet-2.0) \
 -o gnome-hdaps-applet gnome-hdaps-applet.c

che deve terminare senza errori o messaggi. Otterremo un file dal nome gnome-hdaps-applet grande poco meno di nove kilobyte. Questo file va installato nella directory /usr/bin, dando questo comando da utente root:

[root@defiant varie]# install gnome-hdaps-applet /usr/bin/

di seguito occorre copiare le immagini in formato PNG nella directory /usr/share/pixmaps/gnome-hdaps-applet/ creata per questo scopo:

[root@defiant varie]# mkdir /usr/share/pixmaps/gnome-hdaps-applet/
 
[root@defiant varie]# cp *.png /usr/share/pixmaps/gnome-hdaps-applet/

mentre il file GNOME_HDAPS_StatusApplet.server va copiato dentro la directory /usr/lib/bonobo/servers/. Per rendere effettive le modifiche occorre riavviare GNOME, basta uscire dalla sessione e rientrare.

Figura 5. Lista delle applet di GNOME, con HDAPS mostrata

Lista delle applet di GNOME, con HDAPS mostrata

Per vedere l'applet, fare clic col tasto destro del mouse in uno spazio vuoto del pannello superiore, quello dove c'è l'orologio ed il controllo volume in GNOME, selezionare nel menù la voce Aggiungi al pannello, compare una lista di scelte (Figura 5, «Lista delle applet di GNOME, con HDAPS mostrata» ), da cui prenderemo HDAPS Status Applet. L'applet compare segnalando lo stato del disco, nel caso normale con un simbolo "in esecuzione" (Figura 6, «L'applet mostra il disco nello stato normale» ), se invece spostiamo il computer mostra un simbolo di "pausa" (Figura 7, «Ferma tutto!» ).

Figura 6. L'applet mostra il disco nello stato normale

L'applet mostra il disco nello stato normale

Figura 7. Ferma tutto!

Ferma tutto!

Per chi preferisce KDE come desktop, l'applet corrispondente è su questo sito: http://www.kde-apps.org/content/show.php?content=34134, e si chiama khdapsmon. Non l'ho provata, quindi non so aiutarvi.

E' stata dura, ma ce l'abbiamo fatta: il nostro disco è al sicuro. Ovviamente questo non vuol dire che possiamo sbattere il notebook a destra e a manca...

5.9. Lettore di SD... GO!

...o quasi. Ci sono dei problemi che al momento non sono stato in grado di risolvere. In particolare, non vengono caricati automaticamente tutti i moduli necessari, e comunque il lettore rimane inattivo se al momento del caricamento dei moduli non c'è una scheda SD inserita. Quindi non me ne vogliate se la procedura è un po' complicata e non sempre funziona.

Per prima cosa scegliamo dove far montare la scheda SD una volta inserita. Come tutti i dispositivi removibili di questo tipo, normalmente sono nella directory /media, come il lettore CD o i pen drive USB. Quindi creeremo una directory con nome a piacere, per esempio:

[root@defiant ~]# mkdir /media/sdcard

poi andremo a modificare il file che tiene traccia di tutti i dispositivi di memorizzazione, /etc/fstab. Nel mio caso è così:

# This file is edited by fstab-sync - see 'man fstab-sync' for details
LABEL=/ / ext3 defaults 1 1
LABEL=/boot /boot ext3 defaults 1 2
/dev/devpts /dev/pts devpts gid=5,mode=620 0 0
/dev/shm /dev/shm tmpfs defaults 0 0
LABEL=/home /home ext3 defaults 1 2
/dev/proc /proc proc defaults 0 0
/dev/sda6 /stiva vfat defaults,gid=users,umask=002 0 0
/dev/sys /sys sysfs defaults 0 0
LABEL=SWAP-sda8 swap swap defaults 0 0
/dev/scd0 /media/cdrecorder auto pamconsole,exec,noauto,managed 0 0

Per rendere le schede SD inseribili con un normale utente senza privilegi, ed anche scrivibili, aggiungiamo una riga in questo modo:

# This file is edited by fstab-sync - see 'man fstab-sync' for details
LABEL=/ / ext3 defaults 1 1
LABEL=/boot /boot ext3 defaults 1 2
/dev/devpts /dev/pts devpts gid=5,mode=620 0 0
/dev/shm /dev/shm tmpfs defaults 0 0
LABEL=/home /home ext3 defaults 1 2
/dev/proc /proc proc defaults 0 0
/dev/sda6 /stiva vfat defaults,gid=users,umask=002 0 0
/dev/sys /sys sysfs defaults 0 0
LABEL=SWAP-sda8 swap swap defaults 0 0
/dev/mmcblk0p1 /media/sdcard auto defaults,noauto,users,gid=users,umask=002,async 0 0
/dev/scd0 /media/cdrecorder auto pamconsole,exec,noauto,managed 0 0
 
i cui parametri hanno questo significato:
  • /dev/mmcblk0p1 - è la prima partizione della SD card. Per essere sicuri che sia quella vedremo fra poco come si ricava e perché.

  • /media/sdcard - è la directory sotto la quale viene montata la SD, quella che abbiamo appena creato.

  • auto - in questa colonna indica che il tipo di filesystem deve essere rilevato automaticamente. Potremmo anche mettere vfat, visto che la totalità di queste memorie è preformattata in modo FAT.

  • defaults - indica che le opzioni di mount sono quelle standard. Le opzioni che seguono questa prendono il sopravvento, ma intanto definiamo tutta una serie di comportamenti di base. Per chi volesse approfondire, la guida di mount è molto completa.

  • noauto - specifica che questo filesystem, anche se esistente, non deve essere automaticamente montato all'avvio. Verrà montato lo stesso all'avvio se una scheda SD è inserita nel lettore in quel momento, ma se non mettiamo questo parametro otteniamo un antiestetico errore all'avvio che informa che non può montare questo filesystem tutte le volte che il lettore SD è vuoto.

  • users - indica che chiunque può montare e smontare questo punto del filesystem. Se mettevamo user, solo chi aveva montato la scheda SD poteva smontarla. Volendo un po' più di flessibilità teniamo users.

  • gid=users - questa è una modalità che permette di assegnare come gruppo proprietario del dispositivo il gruppo users a cui assegneremo tutti gli utenti che vogliamo siano in grado di accedere dopo l'operazioe di mount. E' parzialmente ridondante per la presenza dell'opzione users, ma ci tornerà utile quando la scheda SD è inserita nel lettore all'avvio e viene montata dall'utente root: senza questo parametro il dispositivo viene assegnato appunto a root, e tutti gli altri utenti non potrebbero scrivere.

  • umask=002 - va in coppia col parametro precedente e definisce quali permessi vengono tolti dal dispositivo. In questo caso il risultato è che il proprietario (chi lo monta) e tutti gli utenti appartenenti al gruppo users hanno tutti i diritti (lettura/scrittura/esecuzione), mentre tutti gli altri non possono scrivere. Ricordiamo che questi sono i permessi da togliere.

  • async - questo è necessario per il particolare tipo di supporto costituito dalle memorie flash, cuore delle schede SD. Queste memorie hanno una vita relativamente limitata, determinata dal numero di scritture che sopportano durante la loro vita. Sono numeri piuttosto consistenti, normalmente oltre le 10.000 scritture, ma c'è un problema: il supporto per il filesystem FAT di Linux opera in modo sincrono, nel senso che ogni modifica al disco viene immediatamente scritta, col risultato che ad esempio la scrittura di dieci file sulla memoria comporta una singola scrittura per ogni file, fatta ognuna in un settore differente, alternate a dieci scritture per aggiornare la directory, fatte tutte nello stesso settore, situazione che accorcia notevolmente la vita della memoria. Per eliminare questo comportamento, ed allungare la vita della memoria, si istruisce il kernel di Linux ad usare invece il metodo asincrono, in cui le scritture vengono fatte in maniera differente e se ne accumulano un certo numero prima di scrivere effettivamente. Dato che la struttura delle directory viene tenuta in memoria, nel caso visto prima di dieci file da scrivere l'aggiornamento della directory viene fatto una sola volta alla fine della scrittura di tutti i file. Il prezzo da pagare è che se dovessimo per errore sfilare la scheda SD dal lettore senza smontare il filesystem perderemmo tutti i dati scritti, e sicuramente il filesystem avrebbe bisogno di una riparazione con un fsck.

Con queste modifiche dovremmo essere a posto per quello che riguarda l'accesso alla memoria SD come filesystem.

Ultima modifica necessaria ai file di sistema è nel file /etc/modprobe.conf, per aggiungere una specifica istruzione sul caricamento dei moduli necessari. Per funzionare, il lettore SD ha bisogno di tre moduli: mmc_core, mmc_block e sdhci. Per motivi che sono al di là delle mie conoscenze il modulo mmc_block non viene caricato automaticamente, ed il lettore SD non funziona. Per ovviare modificheremo il file in questo modo:

...
alias usb-controller ehci-hcd
alias usb-controller1 uhci-hcd
alias ieee1394-controller ohci1394# per sdhci
install sdhci /sbin/modprobe mmc_block; /sbin/modprobe --ignore-install sdhci

...
 
Il risultato è che quando il kernel chiede il caricamento del modulo sdhci vengono eseguiti i comandi:
 
/sbin/modprobe mmc_block
/sbin/modprobe --ignore-install sdhci

che caricano prima il modulo mmc_block, poi il modulo sdhci. Il parametro --ignore-install serve ad evitare che il secondo comando rilegga la riga install sdhci nel file modprobe.conf, andando in loop.

Per rendere effettive le modifiche necessita il comando:

[root@defiant ~]# depmod -a

che rileggendo il file /etc/modprobe.conf aggiorna le dipendenze fra i moduli del kernel. Ora il modulo sdhci nel momento in cui viene caricato causa automaticamente il caricamento del modulo mmc_block.

Il problema è che per qualche oscuro motivo se quando il modulo sdhci viene caricato non c'è una scheda SD nel lettore, quando la inseriamo non c'è verso di farla rilevare, e quindi non compare il dispositivo /dev/mmcblk0 che la rappresenta. Unica strada è di forzare lo scaricamento del modulo sdhci e poi ricaricarlo con una scheda inserita nel lettore. Da una console dove siamo root diamo questo comando:

[root@defiant ~]# rmmod sdhci

e dopo aver inserito la scheda:

[root@defiant ~]# modprobe sdhci

Per avere conferma dell'avvenuto riconoscimento della scheda SD possiamo vedere con il comando:

[mario@defiant ~]$ dmesg
...
mmc0: SDHCI at 0xb0001800 irq 10 PIO
mmcblk0: mmc0:b734 SD256 249088KiB <NULL>
mmcblk0: p1

che mostra come lettore e scheda sono riconosciuti, con il nome mmc0 e mmcblk0. Nella directory /dev/ devono comparire dei device aggiuntivi, uno per la scheda in totale, ed uno per ogni partizione in cui è suddivisa la scheda. Nel mio caso ha una sola partizione di tipo vfat, per cui i device saranno:

[mario@defiant ~]$ ls -l /dev/mmc*
brw-r----- 1 root disk 253, 0 13 mar 11:29 /dev/mmcblk0
brw-r----- 1 root disk 253, 1 13 mar 11:29 /dev/mmcblk0p1

Ecco mostrato come trovare il nome del device di cui parlavamo prima. In qualche caso la scheda SD potrebbe non avere partizioni ed essere usata come una sorta di superfloppy. In questo caso nel file fstab non potremo mettere auto sotto la terza colonna, ma occorrerà specificare il tipo di filesystem, quasi sicuramente vfat, ed il nome del device sarà /dev/mmcblk0, invece di /dev/mmcblk0p1. Come indicazione che le cose sono andate per il verso giusto, basta dare il comando:

[mario@defiant ~]$ mount
/dev/sda7 on / type ext3 (rw)
/dev/proc on /proc type proc (rw)
/dev/sys on /sys type sysfs (rw)
/dev/devpts on /dev/pts type devpts (rw,gid=5,mode=620)
/dev/sda5 on /boot type ext3 (rw)
/dev/shm on /dev/shm type tmpfs (rw)
/dev/sda9 on /home type ext3 (rw)
/dev/sda6 on /stiva type vfat (rw,gid=100,umask=002)
none on /proc/sys/fs/binfmt_misc type binfmt_misc (rw)
/dev/mmcblk0p1 on /media/sdcard type vfat (rw,noexec,nosuid,nodev,gid=100,umask=002)

dove l'ultima riga mostra la scheda SD disponibile sotto la directory /media/sdcard. Fra parentesi possiamo vedere i parametri che abbiamo assegnato, ed il primo ci dice che possiamo scrivere sulla scheda. Dato che nelle schede SD è disponibile un piccolo switch che blocca la scrittura, se lo mettiamo sulla posizione di lock invece di rw troveremo scritto ro per read only.

Per evitare danni (e gastriti...) ricordiamoci sempre di smontare la scheda SD con il comando:

[mario@defiant ~]$ umount /media/sdcard

prima di sfilarla dal lettore. Un altro modo può essere di proteggerla da scrittura con l'apposito switch, così se per caso dovessimo sfilarla inavvertitamente non causeremmo troppi danni. Oppure ancora usare l'applet Montadischi di GNOME, che ci permette di controllare ogni momento lo stato della scheda SD.

5.10. Aspettarsi il peggio...

Il nuovo kernel si comporta bene, per quanto possibile, considerate le patch in gran parte provenienti da driver sperimentali ed in sviluppo. Dobbiamo per quanto possibile essere cauti e fare backup frequenti, se abbiamo sul notebook dati importanti. Se per qualche motivo, di cui il più probabile è un errore nel software, si blocca il nuovo kernel potremmo perdere dati, quindi andiamo con molta cautela. Tenete comunque presente che aggiorno questa guida con notizie fresche appena disponibili, quindi se si presentano problemi grossi li evidenzierò appena si presentano.

Il lettore di SD card usa appunto driver sperimentali, ed il rischio di blocchi è abbastanza consistente. Intanto, per una manovra maldestra, nell'infilare una scheda ho fatto un insert/eject rapido, troppo: ne ho ricevuto un kernel panic, con blocco totale. Successivamente non sono più riuscito a ricreare il problema (la solita legge di Murphy...), ma comunque con questo tipo di manovra è facile fare danni. Quindi massima attenzione nell'inserire le schede nel lettore, diamo il tempo al software di fare il suo dovere.

Adesso la buona notizia. Mi è capitata per le mani una MMC card da 32 megabyte proveniente da una macchina fotografica. Guardandola bene, ho fatto caso che è praticamente uguale ad una SD card, con tre eccezioni: è più sottile di circa un terzo, non ha lo switch di protezione da scrittura ed ha due contatti in meno. Ricordando che il chip del lettore SD nel nostro notebook riporta la dicitura Ricoh Co Ltd R5C822 SD/SDIO/MMC/MS/MSPro Host Adapter, ho infilato la scheda MMC nel lettore. Sorpresa: rilevata e montata correttamente nella directory indicata in /etc/fstab in automatico. Dentro c'erano anche delle vecchie foto della mia nipotina, che ho copiato nella mia home senza problemi. Il problema è stato sfilarla dal lettore: per via del differente spessore, o per la mancanza della piccola tacca laterale, la scheda non agisce correttamente sulla molla e non viene espulsa premendola. Niente paura, basta avere le unghie un po' lunghe, e tramite la scanalatura sul lato posteriore della scheda si prende e si sfila senza troppi problemi.

Ma il bello viene ora. Dopo qualche minuto, preso dalla curiosità, ho riavviato per passare a Windows XP ed ho inserito la scheda MMC nel lettore. Nessun segno di vita. Come se non avessi infilato nulla. Ho tolto la scheda MMC ed infilato quella SD, il solito gong, "Periferica di memorizzazione di massa rilevata...", ecc. ecc.

Per fugare ogni dubbio, ho sfilato la scheda SD (con la "Rimozione sicura dell'hardware", certo), e reinserito quella MMC. Niente. Riavviando con Linux, al login la scheda era lì, montata sotto /media/sdcard, pronta per essere usata. Non credo ci sia bisogno di commenti.

6. Per finire

6.1. Contributi

Un sostanziale contributo di link a documentazione generale del notebook viene da parte di Ottorino (http://www.unifi.it/dssnp/docenti/pantani.htm) che ringrazio anche a nome vostro. Ottorino ha trovato questa guida che gli ha fatto prendere l'insana decisione di acquistare proprio un Thinkpad Z60t, con tutte le conseguenze del caso. Una delle quali è che ci siamo conosciuti, anche se solo per posta elettronica.

6.2. Ringraziamenti

Un sentito ringraziamento a mia moglie, che tollera le ore passate dal sottoscritto al computer, e che per fortuna non si occupa di informatica.

Senza l'ottimo lavoro fatto dal team di sviluppo di Fedora (http://fedoraproject.org/wiki/), la mia distribuzione Linux di riferimento, questo documento non avrebbe potuto vedere la luce. Ovviamente la stessa gratitudine va agli innumerevoli individui che contribuiscono alla realizzazione di tutto il software Open Source che costituisce il corpo del sistema operativo Linux e il suo contorno di applicazioni adatte a tutte le esigenze.

La nostra gratitudine va anche a Pierre Ossman, per il driver del lettore SD, a Jon Escombe, Robert Love e Shem Multinymous per tutto l'occorrente per l'Active Protection System su Linux e per l'applet in GNOME.

Un grazie, si fa per dire, alla programmazione televisiva, in virtù della quale ho recuperato tante ore che passo in modi più piacevoli e costruttivi, almeno per me.

6.3. Strumenti utilizzati

Per realizzare questo documento ho usato l'ambiente di creazione ed elaborazione testi di Fedora, aderente allo standard aperto DocBook XML, disponibile sul sito http://www.docbook.org/tdg/en/html/docbook.html. Il file XML sorgente di questo documento è stato realizzato con VIM, usando un file di personalizzazione dei comandi per velocizzare la digitazione dei tag più usati. Le immagini sono catturate ed elaborate con l'insostituibile Gimp.

6.4. Versioni aggiornate

Versioni aggiornate di questo documento le potete trovare sul mio sito web: http://ismprofessional.net/pascucci, insieme a molto altro.

6.5. Licenza e Copyright

Tutto il documento è rilasciato sotto licenza GNU FDL. Potete riprodurlo a piacere, senza modificarlo e citando l'autore originale.

Commenti (2) 

RSS dei commenti
:shock:
Guida perfetta.10 /10.
forse sarò O.T :Ho Sempre considerato i thinkpad i miglior notebook in assoluto insieme ai macbook(ma questo è un altro discorso) sta di fatto che mi sono accorto che acquistarne uno non è cosi semplice o meglio:andando sul sito italiano Lenovo mi sono accorto che non vi è la possibilita di scegliere e configurarlo come meglio si crede(cosa che peraltro avviene sul sito lenovo americano) e avviene in altri siti come Apple e Dell.Recandomi in un centro autorizzato segnalatomi dal centro clienti mi hanno detto:Lei scelga dal sito il modello che piu si avvicina alle sue esigenze e poi Noi apportiamo le modifiche che vuole...(in questo modo non ho convenienza ad acquistarlo da loro...l acquisto direttamente io e ci risparmio un po di soldini).Ma com è possibile una cosa del genere?lo stesso modello su internet si trova a prezzi che oscillano tra di loro con un gap anche di 200 euro!il cliente viene spiazzato a differenza della apple che si configura il pc e in qualunque parte acquista non ha il timore di prenderla in quel posto dato che i prezzi sono uguali dappertutto!!(al max trovera l offerta che fara ripsrmioare la 50 euro non di piu).
com è avvenuto il suo acquisto?  
0

manichino

dicembre 14, 2006

ciao, poi magari l'autore della guida ti rispondera' sulla questione acquisto.
effettivamente i prezzi dei ThinkPad sul mercato americano sono piu' convenienti e ci sono anche le opzioni BTO ma è un discorso abbastanza generalizzato. speriamo che la situazione cambi presto :wink:  
0

Dgenie

dicembre 14, 2006

Scrivi un commento
Si deve essere connessi al sito per poter inserire un commento. Registratevi se non avete ancora un account.

busy