Le Cose Che Possono Capitare In Linux Ma Che Quasi Nessuno Sa

[MsZ]

E' un po' che non posto da queste parti, ma ho trovato un problema troppo interessante e una risoluzione che potrebbe essere utile a qualcuno. Poi ho pensato "Postiamolo, così chi ha lo stesso problema può trovare una soluzione rapida", ma non è detto che sia indolore.

Poi potrebbe darsi che il thread fiorisca e che riesca a trovare altre cose altrettanto interessanti.

Ma andiamo con ordine.

Avevo installato la Slackware 12.2 poco tempo fa, sarà un mese circa. C'era su lilo e volevo mettere su GRUB, molto più di classe, stabile e versatile (poi spiego una differenza sostanziale di struttura tra LILO e GRUB).

Morale: scaricati i sorgenti di GRUB 0.97, configurato, compilato ed installato.
Volevo installare GRUB sull'MBR, ma non andava. Continuava a dire strane cose, a non trovare il file "stage1" nella directory /boot/grub, dove potevo vederlo benissimo, con permessi e flag a posto. E non riuscivo a capire perchè. Stessa cosa, a quanto ne so, fa GRUB2.

Cerco un po' su Internet e trovo una discussione interessante che mi porta a capire una cosa importante.

Code: [Select]

dumpe2fs <volume> | grep inode_size
Se la riga inode_size riporta un numero diverso da 128 non c'è verso di far leggere a GRUB il file stage1. Le cose stanno così: GRUB sembra incapace di leggere filesystem con inode_size diverso da 128. E, purtroppo, l'unico modo per sistemare il problema è riformattare la partizione con il valore di inode_size giusto. Nel più semplice dei casi, se l'avete formattata con ext3 la riga può essere la seguente:

Code: [Select]

mke2fs -j -I 128 <volume>
dove <volume> rappresenta la partizione da formattare. Inutile che vi dica che prima di farlo, se avete a cuore quello che c'è sopra, fate un backup. Le cose possono diventare spinose se si tratta della partizione di sistema.

La partizione di sistema tiene dei file "delicati" che devono avere dei permessi e dei flag ben definiti, altrimenti si possono verificare problemi. Ad esempio, uno dei primi che mi è capitato era l'impossibilità di diventare superuser tramite su. Mi diceva sempre:

setgid: operation not permitted

o qualcosa del genere.
Allora controllate i flag di su con

Code: [Select]

ls -la /bin/su
I flag devono essere

-rwsr-xr-x

come specificato qui:
http://perl.plover.com/classes/unixsec/samples/slide008.html

Se non sono quelli sopra diventate root e fate:

Code: [Select]

chmod 4755 /bin/sue il problema scompare.

Ma i problemuzzi potrebbero essere altri.

LILO e GRUB sono fondamentalmente differenti. LILO è più semplice, ma fa anche molta fatica a riconoscere molte periferiche esterne, se non tutte. Ho notato che LILO e udev non stanno molto bene insieme: non appena delle periferiche vengono aggiunte al sistema udev si mette al lavoro e genera nuove periferiche secondo le specifiche in /etc/udev/rules.d, ma LILO non se ne accorge e confronta i volumi nel file /proc/partitions con le periferiche in /dev (che, guarda caso, è generato da udev).

Il problema si verifica quando esistono delle regole di udev che generano nomi di periferica "differenti" dalla normale nomenclatura dichiarata dal kernel (hda, hdb, sda, sdb...).
In altre parole, data una regola che chiama "/dev/sda1" (kernel) "/dev/USB_flash_key" (udev) e si tenti di installare LILO sull'MBR, LILO stesso evidenzia /proc/partitions (dichiarato dal kernel) differente dalla struttura di /dev/ (dichiarata da udev) ed esce dando un messaggio di errore.
GRUB invece no.

Da qui la mia "avversione" (che non è una vera e propria avversione, essendo LILO comunque un bootloader venerabile e rispettabile) verso LILO e la mia tendenza ad installare sempre GRUB.

[franz1789]

Un giorno ti parlerò della mia frustrazione nell'abbandonare la mia Arch e usare solo Ubuntu e sVista...

Comunque molto interessante, in genere nei programmi come fsdisk e tool generici di formattazione/creazione partizioni come lavorano? cioè, che inode mettono di default?

[MsZ]

La versione di mke2fs che uso io, la 1.41.3, genera filesystem con 256 byte per inode, di default. Nella 1.40 si era ancora a 128. Dalle versioni più recenti è necessario specificare un inode_size di 128 per far andare bene GRUB 0.97. Nelle ultime versioni di mkfs.xfs è 256 byte. In altre parole, se vuoi installare GRUB devi stare attento al filesystem che vuoi mettere sulla partizione di sistema.

I tool di partizionamento non creano nulla, spezzano il disco e basta. Tutti i dischi rigidi hanno settori di 512 byte.

[MsZ]

Con un uso intensivo di software p2p come aMule e Transmission sembra che il kernel 2.6.29 non regga tutte le connessioni. L'ho provato per almeno una settimana di fila e non c'è stato verso.

In media dopo 24 ore di utilizzo la rete salta e non c'è modo di ritirarla su. A volte ha funzionato togliere e rimettere nel kernel il modulo della scheda di rete, ma per quelli che lo hanno built-in, io mi chiedo?

Mah. Forse è una questione di hardware, mi risultava piuttosto difficile ripetere l'errore (kernel Oops+stack trace, dovuto generalmente alla rete) e dopo aver cambiato qualche configurazione generale (non dipendente dalla rete) la stabilità sembrava averne guadagnato un pochino, ma inevitabilmente dopo alcune (diverse) ore il problema si ripresentava. Quindi la causa non è nelle configurazioni generali.

Ho cambiato kernel, sto usando il 2.6.27.9 e sta andando liscio da almeno due giorni, senza alcun problema rilevato. aMule e Transmission, tutto a posto. E' un peccato, perchè nel 2.6.29 sono state introdotte cose interessanti. Terò d'occhio kernel.org per eventuali aggiornamenti.

Della serie, non fidatevi sempre delle ultime versioni, potrebbero non essere stabili o non avere un grado di stabilità a cui siete abituati. In generale, provare non costa nulla, a patto che rendiate disponibile un fallback ad una versione precedente del kernel, o che applichiate delle patch approvate.

[Philip J. Fry]

Al momento il mio uso non è intensivo, ma con kernel 2.6.29 *per ora* non ho avuto problemi. Continuo il test...

Uso eMule + Wine.

[MsZ]

Potrebbe anche essere una combinazione hardware/software. Della serie, al 2.6.29 non piace la SiS900, o viceversa.

[MsZ]

Dato il seguente xdm.log:

Code: [Select]

Mon Jul 20 14:43:59 2009 xdm info (pid 6963): starting
Mon Jul 20 14:43:59 2009 xdm info (pid 6963): starting X server on :0

X.Org X Server 1.6.0
Release Date: 2009-2-25
X Protocol Version 11, Revision 0
Build Operating System: Linux 2.6.24-23-server i686 Ubuntu
Current Operating System: Linux smallbox 2.6.28-13-generic #45-Ubuntu SMP Tue Jun 30 19:49:51 UTC 2009 i686
Build Date: 09 April 2009  02:10:02AM
xorg-server 2:1.6.0-0ubuntu14 (buildd@rothera.buildd)
Before reporting problems, check http://wiki.x.org
to make sure that you have the latest version.
Markers: (--) probed, (**) from config file, (==) default setting,
(++) from command line, (!!) notice, (II) informational,
(WW) warning, (EE) error, (NI) not implemented, (??) unknown.
(==) Log file: "/var/log/Xorg.0.log", Time: Mon Jul 20 14:43:59 2009
(==) Using config file: "/etc/X11/xorg.conf"
(EE) intel(0): No valid modes.
(EE) Screen(s) found, but none have a usable configuration.

Fatal server error:
no screens found

Si notino le ultime due righe con (EE).

Subito dopo l'upgrade del PC (mobo P5QL-EM con scheda video uscita DVI e audio integrato) ho avuto dei problemi con il riconoscimento del monitor con difficoltà ad entrare in X. O meglio, in X entravo, ma si presentava una finestrella con su scritte le ultime due righe di errore di xdm.log. Le suddette righe si trovano anche in Xorg.0.log appena notate che c'è qualcosa che non va.

Comunque: dopo essermi rotto la testa per capire che cavolo potesse essere successo, dietro anche un consiglio di un simpatico commesso che conosco di un negozietto di PC, ovvero reset "brutale", come lo chiama lui, della scheda madre, ho notato che la presa del cavo DVI connessa al monitor era parzialmente allentata... l'ho connessa bene e X, come per magia, è partito correttamente.

Sulla mobo ho un chipset Intel G43 ICH10. Il dubbio che non fosse un problema software mi era venuto perchè con qualsiasi LiveCD usassi il problema si ripresentava, sistematicamente. Allora ho pensato che fosse un qualche tipo di problema hardware, ma comunque mi sembrava molto strano che ci fosse un problema hardware in una scheda madre appena comprata.

Può sembrare una stupidaggine, ma se sorgono problemi come questo, per prima cosa controllate che tutte le connessioni siano solide e funzionanti. Poi controllate che non ci siano configurazioni strane nel BIOS, e solo come ultima possibilità fate un reset del CMOS e in seguito un reset "brutale" della scheda madre.

Si fa in questo modo:

-Aprite il PC e scollegate qualsiasi cosa tranne l'alimentazione della scheda madre dalla scheda madre stessa. Avete capito bene.
Ogni cosa: processore, RAM, ogni scheda connessa, unità di memorizzazione, lettori/masterizzatori DVD, eccetera.
-Ora il vostro PC sarà composto solo da alimentatore e scheda madre.
-Collegate l'alimentazione e accendete il "PC". Ovviamente sarà incompleto e non succederà nulla, o si metterà a fare bip strani. Lasciatelo acceso per qualche secondo, poi spegnetelo, se necessario disattivando l'alimentatore.
-Collegate il processore, ovviamente con dissipatore. Ripetete l'accensione e lo spegnimento al passaggio precedente.
-Ora potete collegare la RAM, ripetendo l'accensione. Andate nel BIOS e caricate le impostazioni di default: dopo la pulizia del CMOS il PC dovrà essere riconfigurato.
-Ora potete ricollegare tutte le unità di memorizzazione (IDE e SATA). In generale, riportate il PC allo stato originario. Prima di fare strane cose nel BIOS provate a caricare il sistema operativo. Comunque date ancora una controllata alle connessioni, sia esterne che interne.

Con me ha funzionato così. Siate prudenti mentre fate questo, e ricordate di scollegare materialmente l'alimentazione prima di scollegare o ricollegare qualcosa.

[MsZ]

Questa mi giunge del tutto nuova, però è estremamente interessante sapere che X è ancora un territorio per me quasi inesplorato.


Ho installato la Gentoo e ci ho messo appena un giorno e mezzo per riuscire a scrivervi da Firefox (standing ovation). E sono stato ritardato da un fatto insolito.

Al primo avvio di X mi è preso il panico: non riuscivo a comunicare con il server grafico, nè con tastiera nè tramite mouse.
Niente da fare. Non ho potuto fare altro che premere il tasto di reset per riavviare il sistema. (Con buona pace dei filesystem, che mi stanno ancora bestemmiando addosso.)

Ho fatto delle prove, e mandando in esecuzione la seguente riga

Code: [Select]

gdm; sleep 10; killall gdm
dopo 10 secondi usciva correttamente nel terminale (la prima volta; la seconda non so perchè si incuneava in una specie di limbo tra X e il terminale, anche in questo caso impallamento totale), il che mi portava correttamente a supporre che non fosse un crash di sistema, nè un problema del kernel perchè in terminale la tastiera funzionava come al solito.
Poi mi ero accorto, leggendo nel log di Xorg in /var/log/Xorg.0.log.old che non esisteva file di configurazione, ovvero /etc/X11/xorg.conf. Bravo stupido.

Allora ho preso il template (xorg.conf.example) e l'ho cucito sulle mie esigenze (anche con xorgconfig). Riavvio X e... nulla da fare. Come prima, come morto.
Bah. Adesso mi sono stufato, mi sono detto.

Spengo il PC, piglio la bici e vado a fare un giro, 25 chilometri, giusto per rilassarmi.

Al ritorno ci riprovo. Ritento la fortuna e scrivo la riga di comando gdm che ho descritto sopra.

Ciccia.

Al che riprendo il bravo Xorg.0.log.old e vedo una riga alquanto sospetta.

(WW) AllowEmptyInput is on, devices using drivers 'kbd', 'mouse' or 'vmmouse' will be disabled.

E sotto altre due che mi svelano l'ineluttabile fatalità.
(WW) Disabling Mouse1
(WW) Disabling Keyboard0

Un rapido sguardo a man xorg.conf ed è tutto chiaro. Aggiungo una riga a xorg.conf:

Code: [Select]

Option          "AllowEmptyInput"          "off"
Riavvio X e il server è perfettamente pronto e ascolta tutto quello che ho da dire.

Bello, ho imparato qualcosa.


Girovagando per la rete ho scoperto che il comportamento sopra esposto ha a che fare con l'assenza/presenza di HAL (Hardware Abstraction Layer) nel sistema. Sembra che sia a causa della sua assenza, come descritto qui:
http://kmandla.wordpress.com/2008/11/30/hal-xserver-153-and-allowemptyinput/

E guardando >>>qui<<< AllowEmptyInput dice che le periferiche configurate staticamente sono disabilitate.
Just to be clear... AllowEmptyInput does claim that statically configured devices will be disabled.

Comunque, che abbiate o non abbiate HAL, adesso sapete come girare attorno al problema, se mai dovesse capitare anche a voi.

[MsZ]

Poco sopra ho scritto che sono riuscito ad installare la Gentoo. Beh, un giorno e mezzo (anzi, meno: ho cominciato ieri sera) per installarla è un notevole miglioramento rispetto a due anni fa, quando impiegavo due-tre giorni solo per installare le toolchain.

Comunque, Portage (il sistema di installazione di pacchetti di Gentoo) si basa anche su un simpatico file che si chiama /etc/make.conf.
All'interno di make.conf c'è una simpatica variabile che si chiama USE. Chi ha lavorato un pochettino con Gentoo sa che cos'è. L'ho scritto >>>qui<<<, ma un ripasso non fa mai male.

La variabile USE contiene una serie di elementi (i programmatori amano chiamarli "token", gli sviluppatori della Gentoo li chiamano "flags") che giocano un ruolo importante nella compilazione dei pacchetti.

Per farla breve, è molto probabile che la variabile USE possa essere molto, molto, mmoolllttoooooo lunga. E ne va della comprensibilità della variabile stessa, e a uno capita di chiedersi "Che cacchio ho messo qui dentro?", come succede ogni tanto a me.

Allora ho fatto delle prove e ho scoperto una cosa molto interessante: la variabile USE è una variabile Bash.

...si, vabbeh, magari è anche scritto, però vuoi mettere la soddisfazione di scoprire queste cose da solo?

Per qualcuno non smaliziato non vuol dire un accidente. Però per qualcuno che conosce un po' Bash e che ha a cuore la comprensibilità, la leggibilità e l'impacchettamento delle cose, può tornare molto utile.

Questo si traduce in due immediati vantaggi:
1-Si può spaccare una variabile di molti token in più variabili che contengono pochi token;
2-I contenuti di una variabile si possono spaccare su più righe.

Per fare un esempio, questa è la mia variabile USE.

Code: [Select]

# X flags
FLAGX="X gd gtk qt4 xcomposite xscreensaver xcb wxwidgets tk gnome"

# Processor flags
FLAGPROC="smp sse sse2 ssse3 mmx"

# Memory management flags
FLAGMM="memlimit mmap"

# Codecs flags
FLAGC="a52 aac aalib ffmpeg flac lame matroska xvid x264
win32codecs vorbis theora speex ogg musepack mp3 mpeg encode"

# Various applications
FLAGAPP="cdparanoia bash-completion cups dbus emacs firefox gimp
lm_sensors rdesktop pdf mplayer"

# Compression flags
FLAGCOMP="bzip2 zlib szip lzo gzip"

# Net tools
FLAGNET="curl cvs ftp geoip libwww nsplugin php xulrunner subversion samba ssl"

# Security
FLAGSEC="cra*klib crypt gnutls pam hardened"

# Libraries
FLAGLIB="cairo expat fontconfig imlib ncurses nptl pcre readline slang
truetype svga lcms"

# Image handling
FLAGIMG="gif xpm tiff svg png jpeg jpeg2k"

# Audio flags
FLAGAUDIO="alsa ao esd"

# Video flags
FLAGVIDEO="xv dga dri glut opengl"

# Build flags
FLAGBUILD="cxx posix threads perl python tcl unicode"

# Hardware flags
FLAGHARD="acpi apm cdr dbus dvd dvdr hal usb"

# Other flags (X env, unusual flags)
FLAGOTHER="java java6 javascript offensive"

# Specific aMule flags
FLAGAMULE="daemon remote upnp stats"

# Global USE variable
USE=" $FLAGAPP $FLAGOTHER $FLAGHARD $FLAGVIDEO $FLAGAUDIO $FLAGIMG
$FLAGLIB $FLAGSEC $FLAGNET $FLAGCOMP $FLAGC $FLAGMM $FLAGPROC
$FLAGX $FLAGBUILD $FLAGAMULE"
Magari può anche sembrare un mezzo casino, però se devo cambiare un flag e dico "Oh, devo disabilitare python" non devo fare altro che andare a cercare FLAGBUILD e modificarla a seconda delle esigenze. E poi volendo posso rimuovere in toto un gruppo di token semplicemente rimuovendone la variabile dal totale in USE.

Secondo me è un sacco utile questa cosa, aiuta a tenere le cose un po' più organizzate. La Gentoo non è di semplice manutenzione, ricordatevelo.

--- Nota personale ---
La variabile di Bash di sistema IFS contiene tre caratteri speciali: <spazio><tab><newline>. Finchè si mettono le cose tra doppi apici non ha importanza che si separino i token con spazi, tabulazioni o newline.

[MsZ]

Oh, ma quante cose che scopro oggi

Se quando tentate di cambiare credenziali da utente e diventare root, e vi compare un messaggio di
su: Permission denied

allora potreste non essere membri del gruppo 'wheel'.

>>Administering your Linux system<<

Wheel

The wheel group is a legacy from UNIX. When a server had to be maintained at a higher level than the day-to-day system administrator, root rights were often required. The 'wheel' group was used to create a pool of user accounts that were allowed to get that level of access to the server. If you weren't in the 'wheel' group, you were denied access to root.[...]

In poche parole, se avete creato un utente a mano e non riuscite ad accedere come root tramite su (probabile) non dovete fare altro che aggiungere l'utente al gruppo 'wheel':

Code: [Select]

usermod -a -G wheel <utente>
e il gioco è fatto.