Il modo migliore per imparare nuove cose sul proprio sistema Debian è di risolvere i propri problemi ogni volta che è possibile. Molte persone trovano difficile capire da dove iniziare a cercare risposte. Ecco una descrizione delle prime cose che si dovrebbero guardare.

Leggere i messaggi di errore

La maggior parte dei programmi produce messaggi di errore significativi quando qualcosa va storto. Si dovrebbero leggere questi messagi e cercare con buona volontà di capire cosa vogliano dire. Iniziare sempre leggendo dall'inizio dell'output, perché spesso il primo messaggio di errore è la causa di quelli successivi. (Gli errori alla fine dell'output potrebbero non essere significativi o rilevanti, una volta risolto il primo errore.)

Ci sono alcune frasi chiave a cui si deve porre attenzione nei messaggi di errore Unix; sono le traduzioni in inglese, italiano (o in un'altra lingua impostata) dei vari valori errno(3) che sono restituiti dalle chiamate di sistema. Per esempio: 

unprogramma: pincopallino: No such file or directory

Questo significa che unprogramma ha cercato di aprire un file chiamato pincopallino, ma non c'è riuscito perché quel file non esiste. Oppure forse sta cercando di creare pincopallino ma non può perché la directory di cui ha bisogno per scrivervi non esiste ancora. Creare la directory potrebbe risolvere il problema. 

blah blah blah: No such device

Questo errore specifico significa che un programma ha cercato di comunicare con un device (un file nella directory /dev). Il file nella directory /dev esistse, ma il kernel non ha un driver per implementare tale device. Questo è un problema a livello di kernel, a meno che il programma non abbia semplicemente cercato di aprire il device sbagliato. Nella maggior parte dei casi, sarà necessario caricare il driver o installare un kernel diverso, ecc. 

un qualche file: Permission denied

Questo significa che un programma ha cercato di aprire un file ma non ha potuto a causa dei permessi (quelli che si possono vedere con ls -l) impostati per il file o la sua directory. Dare un'occhiata ai permessi e verificare che siano corretti. Eseguire il comando id(1) per verificare di appartenere al gruppo giusto e di avere fatto il login come l'utente corretto. 

blah blah blah: Operation not permitted

Questo errore sembra ad un primo sguardo simile all'errore precedente, ma è in realtà piuttosto diverso. Mentre nel caso precedente erano i permessi del file system a fermare l'utente, in questo caso si è cercato di eseguire una qualche chiamata di sistema che non si è autorizzati a fare. Per esempio, si è cercato di impostare l'ora di sistema quando non si era l'utente root. Questo è il più generico messaggio del tipo "non si è autorizzati a fare questa cosa" e ha moltissime cause possibili.

Cosa dice il registro?

Alcuni programmi, specialmente i demoni o altri processi sullo sfondo, non producono direttamente messaggi di errore a schermo. In questo caso ci sarà quasi sempre un qualche tipo di file di registro che viene scritto nel file system e che conterrà utili (o non-poi-così-utili) messaggi di errore. La posizione del file di registro cambia a seconda del programma e di molti altri fattori.

Se si tratta di un demone di sistema eseguito all'avvio, allora probabilmente userà il syslog(3): il registro di sistema. La posizione degli effettivi file di registro sarà pertanto specificata in syslog.conf(5). La maggior parte di essi è tuttavia nella directory /var/log e se non si sa di quale file esattamente si tratti, si può spesso usare questo trucchetto per vedere i file in ordine cronologico in base all'orario di modifica (mtime): 

$ ls -lart /var/log

I file modificati più di recente saranno alla fine dell'elenco.

XFree86 versione 4.x ha il proprio file di registro, /var/log/XFree86.0.log, che andrebbe consultato in caso di problemi con il server X (incluso il famigerato errore "No screens found" quando si tenta di avviare X).

Xorg mantiene i propri log in /var/log/Xorg.0.log, che andrebbero consultati se si hanno problemi con il server X.

Se si sta lavorando con il proprio gestore di finestre o un altro programma client X, allora il loro output probabilmente non sarà immediatamente visibile. La posizione del loro output dipenderà dal modo in cui si è avviato X. Se è stato usato startx(1) in una console, l'output probabilmente sarà apparso su quella console; provare Ctrl-Alt-F1 per tornare a tale console e poi Alt-F7 (di solito) per tornare a X. Se si è fatto il login con xdm(8), allora xdm crea un file chiamato .xsession-errors nella directory home dell'utente e si dovrebbe guardare quello. gdm(8) usa .gnome-errors. Gli altri programmi "*dm" dovrebbero avere file simili.

Da ultimo, il kernel Linux riporta informazioni attraverso un canale speciale (il ring buffer) che viene letto dal comando dmesg(1). Se si sta facendo qualcosa che ha a che fare con driver o device, si dovrebbe controllare dmesg per vedere se ci sono errori che possono essere correlati a ciò che si sta facendo. (Può anche registrare alcuni messaggi attraverso syslog che poi li invia a journald di systemd o ad un altro demone di gestione del registo di sistema.

Se si sta usando sarge o una versione successiva, si può anche abilitare il registro dei messaggi in spazio utente che sono generati durante l'avvio del sistema. Vedere bootlogd.

C'è qualcosa che manca?

Spesso gli errori possono essere causati dalla mancanza di pacchetti che sarebbero dovuti essere installati, ma che ancora non lo sono. Questo è molto frequente quando si sta compilando qualcosa e non si hanno i pacchetti *-dev necessari installati. Vedere la pagina sullo sviluppo per dettagli su questo caso.

In molti altri casi, un pacchetto può avere una riga che indica qualche altro pacchetto come "suggerito" o "raccomandato". Se si è installato il pacchetto con dselect(8), questi altri probabilmente sono stati inclusi, ma se si è usato apt-get(8), allora i loro nomi sono stati solamente indicati sullo schermo. Si può non averli considerati. Per esempio, il pacchetto gs (GhostScript) raccomanda il pacchetto gsfonts, ma non dipende strettamente da esso. Se un pacchetto sembra installato a metà, allora controllare con "apt-cache search" o aptitude(8) o dselect(8) i pacchetti aggiuntivi che hanno ciò di cui si ha bisogno.

Sono solo?

Se si ha un problema è probabile che qualcun altro lo ha avuto prima (a meno che non si usi "unstable"...). Di fatto ci potrebbe essere un metodo noto per aggirare il problema o persino una soluzione. Questo è il motivo per cui il sistema di tracciamento dei bug di Debian, il Debian Bug Tracking System (BTS), è così importante. Si può usare il pacchetto listbugs o il comando reportbug(1) per cercare tra i problemi conosciuti e le loro soluzioni, una volta che si è circoscritto il proprio problema ad uno specifico pacchetto Debian. Se non si trova lì una risposta, si può sottoporre una segnalazione di bug in modo che il problema venga risolto.

Si possono anche usare le scorciatoie seguenti per andare direttamente nel BTS con un browser: 

https://bugs.debian.org/nome-pacchetto
https://bugs.debian.org/numero-bug

Sostituire a nome-pacchetto il nome del pacchetto, oppure sostituire numero-bug con il numero assegnato ad un bug (adesso sono a 6 cifre). Inoltre notare che quando il topic del canale #debian contiene qualcosa del tipo "FIXED: pincopallo (#999999)", ciò significa che il bug di cui si parla era il #999999 nel BTS e che si dovrebbe andare all'indirizzo https://bugs.debian.org/999999 per vederlo.

Nel dubbio, fare una ricerca!

Anche se il primo messaggio di errore sembra incomprensibile, probabilmente significa qualcosa per qualcuno, specialmente il programmatore che lo ha scritto. Provare a copiare l'esatto messaggio di errore in DuckDuckGo o nel proprio motore di ricerca preferito.