Driver per scheda wireless Atheros AR242x su Ubuntu 9.04

Per installare il driver sui sistemi Ubuntu 8.04 oppure 8.10 consultate questa guida: http://elubuntu.blogspot.com/2009/02/installare-driver-per-scheda-wireless.html

Sul sistema Ubuntu Jaunty Jackalope appena installato, la mia scheda wireless Atheros AR242x era già funzionante, quindi non ho avuto bisogno di installare nulla di nuovo.

Se qualcuno avesse comunque la necessità di installare il driver per questa scheda su Ubuntu 9.04, la procedura dovrebbe essere del tutto analoga a quella per il sistema Ubuntu 8.10 (non ho avuto la necessità di eseguirla e non l'ho testata personalmente, ma leggendo in giro dovrebbe funzionare). Riporto per completezza tutte le operazioni da eseguire.

Per prima cosa vi serve sapere quale scheda wireless avete sul vostro pc. Per fare ciò, nel terminale digitate

lspci

Se avete una scheda wireless come la mia, a un certo punto dovreste trovare una stringa tipo questa:

03:00.0 Ethernet controller: Atheros Communications Inc. AR242x 802.11abg Wireless PCI Express Adapter (rev 01)

Se vi spaventa mettervi a cercare quella stringa in tutto l'output di lspci fate la ricerca in questo modo:

lspci | grep Atheros

Se avete quindi trovato la mia stessa scheda potete seguire queste guide. La guida è valida anche per schede AR5007eg. Se avete già installato altri driver che però non funzionano vi conviene rimuoverli prima di procedere (Sistema → Amministrazione → Driver hardware).

La procedura di installazione del driver è molto semplice, dove però prima attivare, se non l'avete già fatto, i repository Backports: Sistema → Amministrazione → Sorgenti software e nella scheda Aggiornamenti mettete la spunta a Aggiornamenti non supportati (jaunty-backports)

(l'immagine fa riferimento a Ubuntu 8.10)

Quindi installate il pacchetto linux-backports-modules-jaunty con Synaptic, oppure via terminale con questo comando:

sudo apt-get install linux-backports-modules-jaunty

o cliccando qui. Riavviate il computer e il gioco è fatto!
Se dopo il riavvio il driver continua a non funzionare controllate che il driver non sia incluso nella blacklist dei moduli (cioè la lista nera dei moduli del kernel che non devono essere caricati). Per effettuare la ricerca, potete utilizzare Tracker, oppure il terminale con il comando

grep -r "blacklist ath5k" /etc/modprobe.d/

Segnatevi i file che ottenete come risultato, apriteli da terminale con il comando

gksudo gedit nomefile

e commentate (cioè aggiungete il simbolo cancelletto # a inizio riga) le righe che contengono

blacklist ath5k

Se ancora, dopo il riavvio, la scheda wireless non sembra dare segni di vita, provate a blacklistare altri driver per questa scheda wireless (cioè aggiungete i moduli relativi a questi driver nella lista nera e in questo modo non verranno caricati), per evitare che entrino in conflitto con quello appena installato: alla fine del file /etc/modprobe.d/blacklist aggiungete il seguente testo

# driver madwifi atheros
blacklist ath_pci
blacklist ath_hal

Poiché non potete modificare direttamente il file, dovete aprirlo tramite terminale attraverso il comando gksudo (sostitute a gedit il nome del vostro editor preferito se non avete gedit installato; potete anche usare l'editor da terminale nano):

gksudo gedit /etc/modprobe.d/blacklist

Il post è stato modificato l'ultima volta il 21 luglio 2009

Avanzamento di versione su installazione minimale

Pochi giorni fa volevo eseguire l'avanzamento di versione da Intrepid a Jaunty su un computer su cui ho installato una versione minimale che utilizza come ambiente desktop LXDE. Tutte le guide che avevo trovato suggerivano di aprire update-manager (il gestore degli aggiornamenti presente su GNOME) ed eseguire l'aggiornamento. Io però non avevo intenzione di installare update-manager perché si porta dietro alcuni altri pacchetti, non molti a dir la verità, ma su un sistema minimale vorrei avere lo stretto indispensabile!

Sul forum di Ubuntu ho quindi scoperto che basta installare solo il pacchetto update-manager-core, cioè lo stesso che serve per eseguire l'aggiornamento sui server (e che, per la cronaca, è anche una dipendenza di update-manager). La procedura di installazione avviene tramite interfaccia a linea di comando, non grafica. Se il terminale vi spaventa o ve ne fate una ragione oppure installate update-manager, comunque non c'è niente di difficile nel fare l'aggiornamento con questo metodo.

Il pacchetto update-manager-core può essere ottenuto tramite Synaptic (se è installato), oppure nel terminale con il comando

sudo apt-get install update-manager-core

Per effettuare l'aggiornamento del sistema è sufficiente dare il comando

sudo do-release-upgrade

e seguire le istruzioni a video. Se dovete avanzare a una versione di sviluppo di Ubuntu (quindi una versione Alpha, Beta o Release Candidate) allora è necessario aggiungere l'opzione --devel-release (che può essere abbreviata con -d):

sudo do-release-upgrade -d

come spiegato, per esempio, qui.

[Risolto] Problema con at: «Cannot open lockfile /var/spool/cron/atjobs/.SEQ: No such file or directory»

Stasera volevo provare il comando at che serve per eseguire comandi a un orario specificato. Per esempio volevo eseguire immediatamente uno script bash che si trova nella Scrivania (ovviamente per fare questo non è necessario at, era giusto per vedere come funziona). Per fare ciò si può dare il comando

echo "~/Scrivania/script.sh" | at now

però il terminale mi ha risposto in questo modo:

warning: commands will be executed using /bin/sh
Cannot open lockfile /var/spool/cron/atjobs/.SEQ: No such file or directory
bash: echo: errore di scrittura: Pipe interrotta

Il primo messaggio non è preoccupato, non mi è piaciuto invece il secondo. Ci dice che il file /var/spool/cron/atjobs/.SEQ non può essere aperto semplicemente perché non esiste. Ho quindi creato un file vuoto con quel nome con il comando

sudo touch /var/spool/cron/atjobs/.SEQ

Dando nuovamente il comando at, però, ho ricevuto questo output:

warning: commands will be executed using /bin/sh
Cannot open lockfile /var/spool/cron/atjobs/.SEQ: Permission denied
bash: echo: errore di scrittura: Pipe interrotta

A questo punto mi è arrivato in soccorso google: ho scoperto che si trattava di un problema di permessi. Quando ho creato il file con il comando sudo touch il proprietario del file è stato impostato a root (come anche il gruppo, queste informazioni posso essere viste con il comando sudo ls -l /var/spool/cron/atjobs/.SEQ). Invece il proprietario e il gruppo del file dovrebbero essere daemon. Per modificare il proprietario e il gruppo del file ho dato il comando

sudo chown daemon:daemon /var/spool/cron/atjobs/.SEQ

e finalmente ho potuto provare il comando

echo "~/Scrivania/script.sh" | at now

dopo cui è comparso

warning: commands will be executed using /bin/sh
job 1 at Sat Apr 18 00:18:00 2009

Il sito che ho consultato per risolvere questo problema è http://www.mail-archive.com/debian-bugs-dist@lists.debian.org/msg78730.html. Faccio notare che l'autore di quel messaggio ha dovuto eseguire un'ulteriore operazione oltre a quelle che ho indicato. Se le istruzioni che ho esposto non sono state sufficienti date un'occhiata lì.

[Risolto] Problema con cupsd: «Child exited with status 1!»

A ogni avvio del sistema mi compariva il messaggio

cupsd: Child exited with status 1!

(per maggiori informazioni su CUPS potete vedere qui). Ho controllato i log relativi a CUPS con il comando nel terminale

cat /var/log/cups/error_log

(se non amate leggere file sul terminale potete anche aprire il file /var/log/cups/error_log con un editor di testo qualsiasi). Ho potuto ammirare una lunga sfilza di messaggi di errore di questo tipo:

E [17/Apr/2009:14:14:18 +0200] "/etc/cups/ssl/server.crt" is a bad symlink - No such file or directory

Perciò ho controllato cosa avesse il file /etc/cups/ssl/server.crt che non andava. Il comando

sudo file /etc/cups/ssl/server.crt

mi ha restituito questo output:

/etc/cups/ssl/server.crt: broken symbolic link to `/etc/ssl/certs/ssl-cert-snakeoil.pem'

Nella stessa cartella del file server.crt era presente anche un altro file chiamato server.key:

sudo file /etc/cups/ssl/server.key

Risultato:

/etc/cups/ssl/server.key: broken symbolic link to `/etc/ssl/private/ssl-cert-snakeoil.key'

Ho quindi cancellato i due file che erano solo dei link simbolici non funzionanti. Prima, però, ho per sicurezza creato una copia di quei file, non si sa mai:

sudo cp -pr /etc/cups/ssl/ $HOME

e poi ho rimossi i file nella cartella /etc/cups/ssl/ (non la loro copia di backup salvata nella home) con il comando:

sudo rm /etc/cups/ssl/server.crt /etc/cups/ssl/server.key

A questo punto ho riavviato cups con il comando

sudo /etc/init.d/cups restart

e il messaggio

* Restarting Common Unix Printing System: cupsd [ OK ]

mi ha fatto capire che tutto era andato bene e ho potuto cancellare la copia di sicurezza della cartella /etc/cups/ssl/ con il comando

sudo rm -rf $HOME/ssl/

Esiste anche una soluzione (alternativa a quella precedente, non c'è bisogno di seguirle tutte e due) meno violenta per i file server.crt e server.key: semplicemente creare i file mancanti. Si può fare almeno in due modi differenti (sempre attraverso comandi nel terminale):

cd /etc/ssl/certs/
sudo make-ssl-cert generate-default-snakeoil

oppure reinstallando il pacchetto ssl-cert:

sudo apt-get install --reinstall ssl-cert

Anche dopo queste operazioni va dato il comando per riavviare cups per controllare che il problema sia stato effettivamente risolto.

(Fonte: http://crunchbanglinux.org/forums/topic/53/printing-broken/)

Mancato avvio di APT Key Manager

Se avete installato su Ubuntu Intrepid (ma forse il problema è presente in Jaunty) il pacchetto gui-apt-key per poter autenticare comodamente attraverso un'interfaccia grafica i repository di terze parti (maggiori informazioni qui) avrete notato che avviando il programma da Applicazioni → Strumenti di sistema → APT Key Manager viene mostrato il seguente messaggio di errore:

Impossibile lanciare la voce di menù
Esecuzione del processo figlio "/usr/bin/su-to-root" fallita (Nessun file o directory)

Il problema è dovuto al comando di esecuzione inserito nel file /usr/share/applications/gui-apt-key.desktop (che è il collegamento presente nel menu). Il comando in questione è, ovviamente, su-to-root. Si tratta di uno script bash che si può ottenere installando il pacchetto menu (fonte). L'installazione può essere fatta tramite Synaptic oppure nel terminale con il comando

sudo apt-get install menu

Se volete evitare di installare il pacchetto menu (che comunque pesa solo circa 400 kB) potete risolvere il problema o modificando direttamente il file del collegamento, in particolare la chiave Exec così come spiegato più avanti, oppure per via grafica. Per seguire quest'ultima strada dovete fare clic con il tasto destro sul menu principale (dove c'è scritto Applicazioni | Risorse | Sistema) e poi selezionare Modifica menu. Si può avviare lo stesso programma da terminale con il comando

alacarte

Quindi sulla sinistra selezionate Strumenti di sistema, e sulla destra selezionate APT Key Manager, quindi fate clic sul pulsante Proprietà sulla destra. Nella finestra che vi si aprirà dovete modificare il comando

/usr/bin/su-to-root -X -c /usr/sbin/gak

in

gksu -u root /usr/sbin/gak

cioè così com'era nella versione 0.3 presente in Ubuntu 8.04.

Questo piccolo bug è stato segnalato su Launchpad (https://bugs.launchpad.net/ubuntu/+source/gui-apt-key/+bug/282185)

Correzione errori nel file system

Oggi accendendo il computer mi è comparsa questa (molto poco) rassicurante scritta:

*An automatic file system check (fsck) of the root filesystem failed.
A manual fsck must be performed, then the system restarted.
The fsck should be performed in maintenance mode with the
root filesystem mounted in read-only mode.
*The root filesystem is currently mounted in read-only mode.
A maintenance shell will now be started.
After performing system mainteance, press CONTROL-D
to terminate the maintenance shell and restart the system.
Give root password for maintenance
(or type Control-D to continue):

Il problema è che non sapevo che password inserire per continuare: la password del mio utente, infatti, non è la password di root (e comunque provando a inserire quella password mi segnalava login non valido). Anche avviando il computer in recovery mode la situazione era la stessa. Ho quindi avviato il computer con il Live CD (conservatelo sempre, può tornare molto utile in questi casi) per eseguire il controllo del file system manualmente. Ho dovuto però prima individuare quale fosse il file system su cui è installato Ubuntu. per fare ciò ho dato nel terminale il comando

sudo fdisk -l

che mi ha restituito questo output:

Disco /dev/sda: 40.0 GB, 40027029504 byte
255 testine, 63 settori/tracce, 4866 cilindri
Unità = cilindri di 16065 * 512 = 8225280 byte
Identificativo disco: 0x16281627

Dispositivo Boot Start End Blocks Id System
/dev/sda1 * 1 2433 19543041 7 HPFS/NTFS
/dev/sda2 2434 4866 19543072+ 5 Esteso
/dev/sda5 2434 4759 18683563+ 83 Linux
/dev/sda6 4760 4866 859446 82 Linux swap / Solaris

Disco /dev/sdb: 20.4 GB, 20416757760 byte
255 testine, 63 settori/tracce, 2482 cilindri
Unità = cilindri di 16065 * 512 = 8225280 byte
Identificativo disco: 0x29ab86bc

Dispositivo Boot Start End Blocks Id System
/dev/sdb1 1 2482 19936633+ c W95 FAT32 (LBA)

Ubuntu è installato nel dispositivo il cui sistema si chiama Linux. Nel mio caso il dispositivo è /dev/sda5. Quindi ho eseguito il controllo del file system con il comando

sudo fsck /dev/sda5

Dopo alcune correzioni di errori presenti il controllo è terminato e riavviando il pc sono tornato nuovamente in possesso del computer.