View previous topic :: View next topic |
Author |
Message |
dorian-gray84 Tux's lil' helper
Joined: 23 Apr 2005 Posts: 107 Location: Ravenna
|
Posted: Sat Jun 03, 2006 10:58 pm Post subject: Impedire a udev di caricare moduli al boot |
|
|
Ho notato che durante il boot del mio sistema e precisamente nella fase Quote: | * Letting udev process event | udev rileva alcune periferiche e ne carica il modulo corrispondente. Ad esempio rileva la scheda di rete e carica il suo modulo corrispondente. Se per certe cose questo può essere comodo per altre cose non lo è, ad esempio quando voglio che i moduli vengano caricati in un certo ordine o quando alcuni moduli li uso solo in rare occasioni...
Anche perchè durante la fase di boot udev parte prima della lettura di modules.autoload...
Googlando un po' ho trovato che per debian esiste un file dove si può specificare una sorta di blacklist dei moduli che udev non deve caricare ma per gentoo il file non c'è... http://lists.debian.org/debian-italian/2006/05/msg00287.html
Sul forum ho trovato altri che hanno il mio stesso problema: https://forums.gentoo.org/viewtopic-t-453445-highlight-udev+loading+kernel+modules.html
La keywords del mio sistema è "~x86".
La versione di udev installata è la 090.
Quella di hotplug-base è la 20040401
Spero che qualcuno di voi sappia come impedire a udev di caricare moduli in automatico al boot... |
|
Back to top |
|
|
codadilupo Advocate
Joined: 05 Aug 2003 Posts: 3135
|
Posted: Sat Jun 03, 2006 11:11 pm Post subject: |
|
|
non basta metterli nella blacklst di hotplug ?
Coda |
|
Back to top |
|
|
dorian-gray84 Tux's lil' helper
Joined: 23 Apr 2005 Posts: 107 Location: Ravenna
|
Posted: Sun Jun 04, 2006 10:57 am Post subject: |
|
|
Il problema è che io hotplug non ce l'ho installato e quindi non ho nemmeno la directory /etc/hotplug in cui mettere la blacklist...
Le uniche cose installate sono udev e hotplug-base |
|
Back to top |
|
|
.:chrome:. Advocate
Joined: 19 Feb 2005 Posts: 4588 Location: Brescia, Italy
|
Posted: Sun Jun 04, 2006 11:16 am Post subject: Re: Impedire a udev di caricare moduli al boot |
|
|
l'idea che sta alla base del nuovo udev è che appunto carica i moduli dell'hardware che trova in modo trasparente.
se non vuoi che un modulo non venga caricato, non hai altro da fare che non compilarlo
se vuoi che i moduloi vengano caricati in un certo ordine non c'è modo (anche perché non ha senso porsi questo problema)
l'unico punto per cui ha senso preoccuparsi dell'ordine di caricamento, sono le schede di rete, che vengono nominate in base all'ordine di caricamento dei moduli.
se vuoi fare in modo che un determinato modulo sia sempre eth0 e un altro sia sempre eth1, non hai altro da fare che impostare un alias in /etc/modules.d/, come spiegato nella guida del pacchetto module-init-tools |
|
Back to top |
|
|
dorian-gray84 Tux's lil' helper
Joined: 23 Apr 2005 Posts: 107 Location: Ravenna
|
Posted: Sun Jun 04, 2006 11:47 am Post subject: |
|
|
Non vorrei scatenare flame ma questa filosofia non è un po' anti-liberale??
Nel senso che mettiamo che io la scheda audio la usi una volta ogni morte di papa e quindi decida di tenerla come modulo in modo da poterla caricare solo quando questa effettivamente mi serve con questo nuovo udev non è possibile, o meglio o la metto come built-in oppure una volta avviato il sistema scarico il modulo.
Intendiamoci ai fini pratici non mi cambia nulla tenere la scheda audio come built-in o scaricare il modulo se non la uso... però vorrei che ci fosse la possibilità di poter scegliere la cosa che preferisco e questo è un dei punti su cui si basa linux e il mondo open source no?
E commentare questa linea in udev-rules??
Code: | SYSFS{modalias}=="?*", ACTION=="add", RUN+="/sbin/modprobe $env{MODALIAS}" |
in teoria dovrebbe essere colei che carica i moduli ma non vorrei che commentandola andassi a incasinare anche qualcos'altro... |
|
Back to top |
|
|
.:chrome:. Advocate
Joined: 19 Feb 2005 Posts: 4588 Location: Brescia, Italy
|
Posted: Sun Jun 04, 2006 12:00 pm Post subject: |
|
|
dorian-gray84 wrote: | Non vorrei scatenare flame ma questa filosofia non è un po' anti-liberale?? |
mah... non vedo cosa ci sia di anti-liberale
in fondo avere un modulo caricato in più o in meno non ti cambia niente. nel caso che hai segnalato sarebbe formalmente più corretto disattivare la scheda audio in user-space |
|
Back to top |
|
|
Cazzantonio Bodhisattva
Joined: 20 Mar 2004 Posts: 4514 Location: Somewere around the world
|
Posted: Sun Jun 04, 2006 5:14 pm Post subject: |
|
|
effettivamente il punto per me è chiaro... non me ne sono mai preoccupato perché ho sempre usato la blacklist di hotplug... strano che udev non consenta in modo semplice di non caricare un modulo...
se uno vuole i casi in cui farlo potrebbero essere tanti... mettiamo che uno abbia un modulo ancora in testing che spesso causa problemi e che pertanto vuole usare solo quando necessario (io faccio così per i driver proprietari ati... per fortuna vengono caricati da xorg e non da udev )
Sinceramente sono perplesso che i developer di udev non abbiano pensato ad un'eventualità tanto banale... si la trovo decisamente antiliberale... _________________ Any mans death diminishes me, because I am involved in Mankinde; and therefore never send to know for whom the bell tolls; It tolls for thee.
-John Donne |
|
Back to top |
|
|
.:chrome:. Advocate
Joined: 19 Feb 2005 Posts: 4588 Location: Brescia, Italy
|
Posted: Sun Jun 04, 2006 6:01 pm Post subject: |
|
|
ribadisco che non c'è nulla di antiliberale. tutti i sistemi Linux con kernel 2.6 funzionano in questo modo, ed è controproducente per una distribuzione andare contro corrente.
basterebbe crearsi un file di alias in /etc/modules.d/ sul modello di modprobe.conf
con quel file è possibile associare in modo univoco i nomi, e se si vuole disattivare un modulo basta fare l'alias con off:
niente di più semplice. non vedo cosa ci sia di tanto antiliberale
non credo sia questione di antiliberalità o meno. nel momento in cui si decide di usare un sistema si deve accettare il modo in cui esso funziona. se questo metodo di funzionamento non ci sta bene siamo liberissimi di proporne uno migliore; se non siamo in grado di progettare un metodo di funzionamento alternativo non mi sembra nemmeno il caso di sollevare tanta polvere per niente.
oltretutto questo problema si sarebbe risolto spontaneamente documentandosi un po' |
|
Back to top |
|
|
|