<- Software libero per il trattamento di problemi scientifici - Indice Generale - Copertina - Il g77 e un esempio di applicazione in fisica classica come strumento di studio scolastico nelle scienze ->

Sistemi Liberi

Fedora Core 3: un'installazione difficile

di Rudi Giacomini Pilon

Dire, di Fedora Core 3, che si tratta di una distribuzione da "prendere con le pinze" non è un'esagerazione. Utilizzo GNU/Linux da anni ma l'installazione di questa distribuzione mi ha dato decisamente qualche grattacapo. Di seguito non troverete soluzioni originali: raccogliere questo materiale in giro per la rete e metterlo assieme è stato comunque oneroso. Con questo articolo vorrei decisamente risparmiare la fatica che ho fatto io ad altri malcapitati.

Scrivo queste note nel mese di dicembre 2004, non riporto le date precise perché non le ho annotate. Ecco la cronaca di quanto è successo.

Venerdì pomeriggio

Ho acquistato in edicola una rivista con i 4 CD della distribuzione allegati: non vedevo l'ora di installarla. Rientrato al lavoro, mi sono preparato ad aggiornare la mia postazione. Per prima cosa, come sempre, ho creato una copia dei CD (ne tengo un set al lavoro e uno a casa). Al termine della fase di copia ho eseguito un backup dei dati (che raccomando altamente), ho installato la distribuzione in modalità aggiornamento e, per impazienza, ho saltato il test dei CD (tanto non ho mai avuto problemi). Errore clamoroso!

Al terzo CD l'installazione si blocca lasciando un sistema aggiornato a metà. Tutto sommato non è andata male: il sistema si riavviava e la maggior parte delle applicazioni sembrava funzionare. Vista l'ora, ho deciso di lasciar perdere e di rimandare al lunedì la reinstallazione del sistema operativo.

Morale numero 1: eseguite il test dei CD prima di aggiornare un sistema funzionante.

Morale numero 2: fate il backup dei dati (poteva andare peggio).

Ora, qualcuno di voi potrebbe dire che mi sono cercato i miei guai e che, tutto sommato, non posso incolpare la distribuzione visto che, oltretutto, stavo installando dalle copie dei CD. Aspettate miscredenti, il meglio e il peggio devono ancora venire.

Sabato pomeriggio

Ho deciso di aggiornare la mia postazione a casa. Memore della brutta esperienza ho eseguito nell'ordine: backup, test dei CD, test della RAM (non si sa mai). Parto con l'installazione, che si blocca. La segnalazione dell'errore era la seguente:

[Assertion (heads > 0) at disk_dos.c:485 in function probe_partition_for_geom() failed.]

Rapida ricerca con Google ed ho ottenuto una pagina (red-hat-bugzilla: bug 138419) dove si trovano una serie di indicazioni per risolvere il problema, che sembra essere dovuto ad una errata scrittura delle partizioni da parte di fdisk della Microsoft. Concordo con questo tipo di osservazione in quanto ho spesso notato che nei sistemi dual-boot con entrambi i sistemi operativi nello stesso hard disk (come nel mio caso) il comando (MS)fdisk lascia spesso delle aree non marcate fra una partizione e l'altra riconosciute da Linux come "unused space" (spazio non utilizzato). Delle varie soluzioni, quella che ha funzionato è la seguente: ho scaricato dal link (http://people.redhat.com/~katzj/fc3-part-upd.img) indicato nell'articolo un'immagine che contiene delle modifiche al file disk_dos.c. Dal file ho ottenuto un floppy con il comando seguente:

$ dd if=updates.img of=/dev/fd0 bs=1440k

Ho riavviato l'installazione digitando al prompt iniziale (quando viene richiesto in quale modalità si desidera avviare l'installazione):

linux updates

Quando il programma di installazione lo ha richiesto, ho quindi inserito il floppy e superato il problema. La ricerca della soluzione di cui sopra e il download, a 33Kbit/sec, del file hanno consumato il poco tempo libero che mi rimaneva. Quindi ho dovuto rinviare l'installazione alla domenica.

Domenica pomeriggio

A questo punto ho aggiornato la mia Fedora Core 2 perfettamente funzionante ottenendo... un completo disastro. Il sistema era in qualche modo funzionante, ma non ero in grado di "vedere" i CD, i dispositivi nella directory /dev sembravano in gran parte scomparsi, l'audio totalmente assente, molte delle mie applicazioni preferite scomparse e all'avvio partiva una serie incredibile di servizi e demoni non richiesti. Ho cercato di collegarmi ad Internet per cercare aiuto, ma Konqueror si rifiutava di "navigare" andando in loop. In questo momento mi sono sentito un utente di un altro sistema operativo (ogni riferimento a fatti realmente accaduti è volutamente casuale). Sconfortato, ho spento il PC ed ho odiato profondamente questa distribuzione.

Morale numero 3: mai installare una nuova versione su una macchina di produzione funzionante senza avere effettuato un test su un PC di prova.

Lunedì mattina

Non pago dell'esperienza precedente e desideroso di conferme, ho reinstallato completamente la distribuzione nella mia postazione in ufficio, ottenendo gli stessi risultati ma con una maggior banda a disposizione per navigare su Internet.
Ho abbandonato Konqueror, aperto Mozilla su Google ed una console di root, da cui eseguire le varie verifiche, ed è iniziata la guerra.
Dopo tre minuti passati sul sito della Fedora, ecco le prime verità: da questa versione non viene più utilizzata la directory /dev popolata staticamente con i device, ma viene invece popolata dinamicamente dal programma udev man mano che i device driver vengono caricati (potete trovare degli appunti in merito sull'articolo Il progetto Utopia, presente in questo stesso numero del PLUTO Journal). La scelta è motivata dal fatto che la directory /dev conteneva ormai più di 18.000 nodi e questo portava ad una serie di problemi di gestione.
Ho verificato che con il nuovo sistema la directory risulta effettivamente popolata da soli 302 file. Questo giustificava la sparizione di gran parte dei dispositivi dalla directory in questione. Una bella nota segnalava inoltre la necessità di passare immediatamente alla versione udev-039-10.FC3.1 in quanto il pacchetto incluso nella distribuzione contiene del codice di debugging che provoca dei malfunzionamenti. Ho scaricato quindi l'ultimo aggiornamento disponibile che, per la cronaca, era udev-039-11.FC3.5.i386.rpm, che trovate al link http://download.fedora.redhat.com/pub/fedora/linux/core/updates/3/i386/ ed ho aggiornato il sistema con:

rpm -U udev-039-11.FC3.5.i386.rpm

Incredibile ma vero, a questo punto viene consigliato dalle istruzioni il riavvio del sistema (siamo sicuri che non stiamo parlando di un altro sistema operativo?).

Al riavvio, i problemi di accesso ai CD erano risolti. Bisogna però fare attenzione che il mount-point di default non è più sotto /mnt/cdrom, ma si trova sotto /media/cdrom. Se volete mantenere le vostre abitudini un link risolve molti mal di testa, quindi dovrebbe bastare il comando seguente:

ln -s /media/cdrom /mnt/cdrom

In prima istanza, ho preferito modificare direttamente /etc/fstab inserendo i mount point per i vari device. Non fatelo, è tempo sprecato, in quanto il demone relativo all'Hardware Abstraction Layer (hald) introdotto in Fedora Core 3 va a modificare automaticamente tale file, sovrascrivendo le vostre modifiche. Sempre in /media trovate anche /floppy e, se avete un masterizzatore, anche /cdrecorder.

Siccome la postazione era ormai operativa, a questo punto ho scaricato dai vari repository i consueti aggiornamenti ed il software mancante ed ho iniziato a lavorare. Chiaramente nel frattempo ho eliminato alcuni dei servizi che non utilizzo come ad esempio il supporto PCMCIA (non mi serve sul PC fisso), il supporto bluetooth (non ho device di questo tipo), NFS e Samba (non devo condividere nulla) e così via.

Morale numero 4: prima di installare una nuova release leggere almeno le release notes.

Morale numero 5: l'aiuto per i sistemi GNU non è teorico. Il supporto della comunità funziona.

Lunedì sera

Ho aggiornato il PC di casa, ma l'audio non ne voleva sapere di funzionare. Al lavoro utilizzo raramente l'audio quindi non ho effettuato verifiche in proposito, ma a casa sto utilizzando il PC per riversare la mia collezione di musicassette in digitale per preservarle dalla smagnetizzazione (alcune sono degli anni '70), quindi l'audio deve risultare funzionante. Dopo le opportune verifiche, ho scoperto che è stato abbandonato il sistema OSS per ALSA, quindi tutto il sistema audio è stato modificato. Ho quindi abbandonato momentaneamente il problema, accontentandomi di completare la personalizzazione del sistema.

Martedì sera

Dopo avere letto di un sacco di problemi analoghi, relativi all'audio, ho avviato il mixer da riga di comando con alsamixer e scoperto che tutti i volumi erano a zero; banale... se non fosse che avevo regolato i volumi con Kmix senza sortire nessun effetto. Un po' di regolazioni e mi sono accorto che anche con i volumi al massimo non si sentiva nulla. Leggendo di un caso analogo in un forum e provando un po' a caso (e un po' con il calcolo delle combinazioni) ho scoperto che rendendo muti due canali (tasto M premuto dopo aver selezionato i canali stessi) [fig. 1 e 2] si riesce ad ascoltare l'audio. La cosa che non ho ben capito è come mai i canali da rendere muti sembrano essere diversi a seconda della segnalazione che si va a leggere nei vari forum, anche a parità di scheda: lascio volentieri ad altri il compito di approfondire (o forse lo potrò fare in altra occasione con un po' più di tempo a disposizione).
Piccolo problema: funzionava solo l'output e risultava ancora impossibile registrare.
Non trovando nulla su Internet, con un lampo di idiozia (per dire lampo di genio avrei dovuto pensarci prima) ho fatto ricorso alla pagina man (man alsamixer) e mi sono trovato di fronte la seguente frase: "SPACE toggles recording: the current channel will be added or removed from the sources used for recording". Sembra tutto ovvio: premendo la barra spaziatrice su un canale questo viene abilitato all'input... la cosa non ovvia è che per registrare da un solo canale fisico (line in) ho dovuto abilitare due canali logici [fig. 1 e 3].

Figura 1.

Figura 2.

Figura 3.

A quel punto, sono riuscito a registrare, per poi scoprire che...

Mercoledì sera

Riavviando il PC per una registrazione ho scoperto che i volumi erano di nuovo a zero. Rileggendo la pagina man apprendo che la configurazione del mixer andava salvata e che il comando relativo è:

alsactl store #0

e che bisognava modificare il file /etc/rc.local aggiungendo

alsactl restore

per ripristinare la configurazione ad ogni riavvio del PC.
Eseguite le modifiche, da buon scettico, ho riavviato il PC per constatare che non funzionava.
Per il momento ho risolto salvando la configurazione con

alsactl store -f soundcard.cfg

e recuperandola di volta in volta manualmente con

alsactl restore -f soundcard.cfg

Sto ancora verificando come automatizzare il processo, anche se in realtà ho trovato il modo di sfruttare questo inconveniente. Mi sono infatti reso conto che, a seconda della sorgente di registrazione o di riproduzione, si ottiene il meglio con diverse regolazioni dei canali audio. Per esempio, se registro da audiocassetta mi conviene usare la linea "in" della scheda audio, che ha un guadagno minore, in quanto l'output della piastra dello stereo è relativamente alto. Se registro da dischi in vinile mi conviene usare la linea "mic" che ha un maggior guadagno (e anche così devo portare i volumi di ingresso al massimo). Quindi ho salvato in file diversi le diverse regolazioni ed ho creato uno script che in base ad un parametro passato carica la configurazione scelta.
Ulteriori migliorie: in una delle due installazioni (quella fatta ex-novo in ufficio) non viene mostrato il menù iniziale di GRUB. Al suo posto compare un count-down che avvisa dell'imminente avvio della partizione scelta come predefinita. Premendo un tasto compare il menù usuale.
Personalmente preferisco il solito menù, quindi in /etc/grub.conf ho commentato la linea che nasconde il menù iniziale:

hiddenmenu

A casa utilizzo Internet in maniera molto limitata, con il firewall abilitato, e sono l'unico utente del PC. Ho quindi ritenuto superfluo l'utilizzo di SE-LINUX, che però da questa release è un'opzione compilata di default nel kernel. Quindi sempre in /etc/grub.conf ho modificato la riga:

kernel /vmlinuz-2.6.9-1.667 ro root=LABEL=/ rhgb

in

kernel /vmlinuz-2.6.9-1.667 ro root=LABEL=/ rhgb selinux=0

in modo da disattivare l'opzione.

Fedora Core 3 utilizza e abilita di default il protocollo tcp/ip v.6, che nel mio caso è totalmente inutile. Per disabilitare tale opzione ho quindi editato il file /etc/modules.conf, aggiungendo all'inizio del file le seguenti istruzioni:

alias net-pf-10 off
alias ipv6 off

Conclusioni

Oltre a ribadire la necessità di valutare bene questa distribuzione prima di aggiornare un'installazione funzionante, vorrei esprimere alcune opinioni personali.
Trovo che molte delle innovazioni di questa distribuzione, e di fatto tutte quelle che mi hanno procurato dei problemi, sono rivolte ad aumentare l'usabilità di GNU/Linux in ambiente desktop. Di fatto è possibile rimuovere tutte queste feature e ritrovare la configurazione tradizionale rinunciando ad alcuni automatismi.
A chi giovano queste innovazioni? Sicuramente ai nuovi utenti meno smaliziati. Per un utente esperto possono addirittura essere noiose oltre che inutili. Sicuramente lo sono in un server. Inoltre, per quanto siano sviluppati correttamente, probabilmente questi servizi aggiunti contribuiscono a rallentare le prestazioni del PC (non ho avuto il tempo di effettuare delle misure di consumo di cicli macchina e occupazione di memoria).
Sicuramente posso dire che la versione 3.3 di KDE inclusa nella distribuzione risulta un po' più brillante della precedente e, visto che ormai ho adottato questo window manager (anche se ogni tanto rimpiango il vecchio WindowMaker), penso di avere avuto dei benefici dall'upgrade.
Ritengo valido, comunque, un consiglio ricevuto una volta da un altro utente Linux: non aggiornate la distribuzione ma solo i pacchetti di cui volete l'upgrade... ne guadagnerete in tempo e salute.

Riferimenti:

red-hat-bugzilla: bug 138419 - Fedora udev notes

<- Software libero per il trattamento di problemi scientifici - Indice Generale - Copertina - Il g77 e un esempio di applicazione in fisica classica come strumento di studio scolastico nelle scienze ->