Guida: Linux Fedora su IBM/Lenovo ThinkPad Z60t

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:

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%.

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:

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

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:

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

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.

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:

Puntiamo le righe Modes e le cambiamo in questo modo:

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

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ì:

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".

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:

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.

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:

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

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:

e quella cambiata invece è simile a questa:

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

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:

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

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.

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 è:

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:

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:

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

 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 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 inserire nel file /etc/modprobe.conf le due righe:

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:

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

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

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à:

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.

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. 

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:

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 è:

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:

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

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

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.

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:

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.

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:

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

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

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"

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"

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...

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:

Per installarlo:

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:

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.

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:

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:

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:

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):

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:

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

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

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.

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:

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:

ed aggiungiamo una riga in questo modo:

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):

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.

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):

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:

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:

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"

Figura 4. Configurazione con "make gconfig"

 

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.

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

non resta che attendere. 

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.

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

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

Subito dopo passiamo ad installare il kernel vero e proprio:

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. 

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.

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

seguito da:

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. 

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:

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:

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

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:

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... 

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:

che rimane in attesa. Se vediamo il messaggio:

non abbiamo caricato il modulo.

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

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

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:

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:

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:

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

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

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

Figura 7. 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...

...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:

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

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

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:

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:

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:

e dopo aver inserito la scheda:

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

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:

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:

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:

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.

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

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.

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.

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

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