last update: 11/ march / 2005

Fedora Core 3: un'installazione difficile

Fedora Core 3

[Il documento che state per leggere spiega come risolvere alcuni problemi che possono insorgere durante e dopo l' installazione di una distribuzione Fedora Core 3.]

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 dato decisamente qualche difficoltà. Non troverete, di seguito, soluzioni originali ma raccogliere questo materiale in giro per la rete e metterlo assieme è stato oneroso e vorrei decisamente risparmiare la fatica 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 e 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) e poi ho installato la distribuzione in modalità aggiornamento e... per impazienza, 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 sembravano 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 un 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
$ dd if=updates.img of=/dev/fd0 bs=1440k
Ho riavviato l' installazione digitando linux updates al prompt iniziale (quando viene richiesto in quale modalità si desidera avviare l' installazione). 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 33Kb/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 upgradato 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 partivano 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 drivers vengono caricati (potete trovare degli appunti in merito sul mio sito). 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 solo 302 file. Questo già 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 (ma 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 /media/cdrom. Se volete mantenere le vostre abitudini un link risolve molti mal di testa quindi
ln -s /media/cdrom /mnt/cdrom
dovrebbe bastare. In prima istanza io 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 và 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 devices 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 (Advanced Linux Sound Architecture) quindi tutto il sistema audio è modificato. Ho abbandonato quindi momentaneamente il problema accontentandomi di completare la personalizzazione del sistema.

- Martedi 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 è che 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 man page:
$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 (linea in) ho dovuto abilitare due canali logici [fig. 1, e 3].

fig. 1 - alsamixer controlli
fig. 1

fig. 2 - alsamixer controlli
fig. 2

fig. 3 - alsamixer controlli
fig. 3

A quel punto sono riuscito a registrare solo per scoprire che...

- Mercoledì sera -
Riavviando il PC per una registrazione ho scoperto che i volumi erano di nuovo a zero. Rileggendo la man-page 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 restoreper 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 riproduzione si ottiene il meglio con diverse regolazioni dei canali audio. Per esempio se registro da cassetta audio 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 di valutare bene questa distribuzione prima di aggiornare una 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. E 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 puntuali 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:

di Rudi Giacomini Pilon


articoli