# udev, coldplug e ipw3945: storia di un aggiornamento critico

## skypjack

Salve a tutti.

Credo che chi leggerà questo testo avrà riscontrato, come me, non pochi problemi nel passare al nuovo udev abbandonando coldplug e cercando di resuscitare la scheda wireless, per cui usiamo il nostro caro ipw3945 e compagnia bella!!

Ecco una breve guida per uscire indenni (o quasi) da questo aggiornamento!!

Andiamo per passi...

Notare che oltre a udev sono stati aggiornati i sorgenti del kernel. Il mio consiglio è un bel:

```

# emerge -u gentoo-sources

```

O meglio ancora, che non si sa mai:

```

# emerge -uND world

```

Adesso, possiamo cominciare.

Onde evitare di dover mettere mano a troppi file, ho seguito la procedura del "pulisci e reinstalla", ovvero:

```

# emerge -C ieee80211 ipw3945

# emerge --depclean

# emerge ipw3945

```

Questo, dati i nuovi sorgenti, potrebbe richiedere più passi, ma se avete già installato almeno una volta ipw3945 e ieee80211 sapete di cosa parlo e potrete risolverli da soli, senza ulteriori spiegazioni.

Vi troverete un nuovo file, ovvero: /etc/udev/rules.d/70-persistent-net.rules (lo spero per voi).

Se date un'occhiata a questo file, noterete che mappa la scheda wireless su eth2, pertanto consiglio di mettere mano al /etc/conf.d/net e fare le dovute modifiche, che non starò a spiegare (facile: eth1 --> eth2 !!).

Consiglio di compilare il kernel a modino, a questo punto, di renderlo funzionante e riavviare col nuovo kernel.

Supposto che lo abbiate fatto procediamo (altrimenti, fatelo!!).

A questo punto, dando un ifconfig, si può vedere che eth1 è mappata per la firewire. Questo è quantomeno strano (dal mio punto di vista) e per chi come me non ha bisogno di tale novità, consiglio di modificare /etc/conf.d/rc, ovvero:

```

RC_PLUG_SERVICES="!net.eth1"

```

Bene, ora tutto dovrebbe funzionare, se riavviate vengono caricati i moduli ma... Magia!!

Si, il demone ipw3945 non parte!!

Possiamo sempre lanciarlo a mano da root con:

```

# ipw3945d &

```

Dal mio punto di vista, aspettando che udev stabile migliori, ho optato per una modifica al file /etc/conf.d/net, aggiungendo:

```

preup() {

   [[ "${IFACE}" = "lo" ]] && /sbin/ipw3945d --quiet && sleep 2

   [[ "${IFACE}" = "lo" ]] && einfo "Starting ipw3945d [ Thanks to udev-stable!! ] ... :-)"

   return 0

   }

predown() {

   [[ "${IFACE}" = "lo" ]] && /sbin/ipw3945d --quiet --kill && sleep 2

   [[ "${IFACE}" = "lo" ]] && einfo "Stopping ipw3945d [ Thanks to udev-stable!! ] ... :-)"

   return 0

   }

```

Questa almeno mi ricorda ad ogni avvio da chi dipendono i miei problemi ed è una sorta di TODO per il futuro per ricordarmi di controllare e cercare soluzioni alternative e più eleganti.

Per il momento questo è tutto.

Riavviando, dovrebbe partire senza problemi, per ogni domanda fate pure, vi risponderò appena posso.

Spero di essere stato di aiuto per qualcuno.

Ciauz[/code]

----------

## riverdragon

Io ho avuto problemi fino a quando non ho dato un modprobe ipw3945 e da lì è ripartito tutto correttamente. Che versione di gentoo-sources usi? Con la 2.6.19-r1 ieee80211 non mi si compilava, sono ritornato al 2.6.18-r2, l'ho segnalato qui.

----------

## skypjack

L'ultimo stabile gentoo-sources, 2.6.18-r3 ad ieri, con ieee80211 1.1.13-r1, ipw3945 1.0.5, ipw3945d 1.7.18 e ipw3945-ucode 1.13.

il modprobe carica il modulo, ma non serve essendo comunque caricato correttamente dall'avvio, pertanto non risolveva il mio problema.

Il problema è che non partiva il demone ipw3945d all'avvio, come dovrebbe invece fare e faceva prima, pertanto la mia soluzione mira a correggere questo problema.

Un'alternativa, ho letto nel forum, è usare i moduli in-kernel di ieee80211 e ipw3945, scaricabili come patch da applicare, ma nn l'ho provato.

Inoltre, ho dato una panormica breve sul perchè e per come udev rimappa le periferiche aggiungendo firewire come eth1 e "spostando" la wireless su eth2. Cosa che come detto non mi piace, ma questo dipende dalle necessità e dai bisogni di ognuno, è un parere personale.

Vero, non ci si basa sull'ordine di creazione e si dovrebbero mappare a mano e periferiche di cui sopra, ma chi lo fa?

Scommetto meno dell'1% degli utenti...

Ad ogni modo, è solo una linea guida su come procedere che funziona, libero di presentarne una migliore perchè, come detto, è una soluzione on-the-fly ma che vorrei variare e raffinare per il futuro, magari aiutato dagli sviluppatori di udev e dal fatto che prima o poi il modulo che mi serve sarà integrato nel kernel, come i suoi predecessori (leggi ipw2200 e affini)!!

Ti sarò molto grato, anzi, se mi presenti una soluzione "ufficiale" al mio problema (che non sia però attingere da ~x86), così mi eviti di cercare ancora

Grazie e a presto.

----------

## crisandbea

 *skypjack wrote:*   

> L'ultimo stabile gentoo-sources, 2.6.18-r3 ad ieri, con ieee80211 1.1.13-r1, ipw3945 1.0.5, ipw3945d 1.7.18 e ipw3945-ucode 1.13.
> 
> il modprobe carica il modulo, ma non serve essendo comunque caricato correttamente dall'avvio, pertanto non risolveva il mio problema.
> 
> Il problema è che non partiva il demone ipw3945d all'avvio, come dovrebbe invece fare e faceva prima, pertanto la mia soluzione mira a correggere questo problema.
> ...

 

hai provato ad aggiungere il demone al runlevel di default???

credo che come tutti o quasi i demoni possa farsi..

ciauz

----------

## riverdragon

 *skypjack wrote:*   

> Inoltre, ho dato una panormica breve sul perchè e per come udev rimappa le periferiche aggiungendo firewire come eth1 e "spostando" la wireless su eth2. Cosa che come detto non mi piace, ma questo dipende dalle necessità e dai bisogni di ognuno, è un parere personale.
> 
> Vero, non ci si basa sull'ordine di creazione e si dovrebbero mappare a mano e periferiche di cui sopra, ma chi lo fa?
> 
> Scommetto meno dell'1% degli utenti...

 Per rimappare le periferiche devi editare il file /etc/udev/rules/10-eth-rules (credo che il nome del file sia abbastanza arbitrario, cerca invece di mantenere il "10-"), cerca qui sul forum, entro sera cerco di postarti qui il contenuto del mio.

EDIT: dove trovo la patch per inserire il supporto alla scheda ipw3945 direttamente nel kernel?Last edited by riverdragon on Mon Dec 04, 2006 2:49 pm; edited 1 time in total

----------

## skypjack

Quale demone?

Non ho alcun demone ipw3945 o simili, non ne ho mai avuti e un equery per ipw3945 (pacchetto) non parla di demoni di alcun tipo!!

Ma di quale demone parli, non ho capito?

----------

## riverdragon

Lui intende ipw3945d, è una dipendenza di ipw3945.

----------

## skypjack

Idem: un equery da ragione a me, mi spiace.

Niente script d'avvio!!

----------

## crisandbea

 *skypjack wrote:*   

> Idem: un equery da ragione a me, mi spiace.
> 
> Niente script d'avvio!!

 

in che modo ti dà ragione???

----------

## skypjack

Nel senso che un:

```

# equery files ipw3945d

```

Mi restituisce:

```

/etc

/etc/modules.d

/etc/modules.d/ipw3945d

/sbin

/sbin/ipw3945d

/usr

/usr/share

/usr/share/doc

/usr/share/doc/ipw3945d-1.7.18

/usr/share/doc/ipw3945d-1.7.18/README.ipw3945d.gz

```

Quale è lo script d'avvio?

Scusate, ma non sono l'ultimo arrivato!!

Uso Gentoo da poco, ma GNU/Linux da tanto.

Vi prego di non trattarmi come uno s***o, per favore.

Non c'è traccia di script e l'eseguibile ipw3945d è quello che uso nella mia soluzione.

Ergo, di quale script parlate?

Ps: scusate lo sfogo, cercherò di trattenermi in futuro.

----------

## crisandbea

 *skypjack wrote:*   

> Nel senso che un:
> 
> ```
> 
> # equery files ipw3945d
> ...

 

di cosa dovevi sfogarti??? chi ti ha trattato o ti stà trattando come dici tu???  chi ha parlato di script???

ti ho solo consigliato di fare questo:

```

inserire ipw3945d in /etc/modules.autoload.d/kernel-2.6

```

e verificare se andasse.  tutto qua.    :Wink: 

ciauz

nb:hai provato a riemergere ipw3945d ???

----------

## skypjack

Come scritto nel primo post, ho dato:

```

# emerge -C ipw3945 ieee80211 && emerge --depclean && emerge ipw3945

```

Quindi: si, ho provato!!  :Smile: 

La tua soluzione purtroppo non va, perchè il problema non è il modulo (che viene caricato correttamente all'avvio) ma il fatto che non parta il demone ipw3945d!!

Quindi, non risolve agire come indicato, mi spiace.

Grazie comunque.

Resto in attesa di altre idee e in caso trovassi una soluzione alternativa non esiterò a proporla!!

----------

## crisandbea

 *skypjack wrote:*   

> Come scritto nel primo post, ho dato:
> 
> ```
> 
> # emerge -C ipw3945 ieee80211 && emerge --depclean && emerge ipw3945
> ...

 

chiedo venia allora, avevo capito che non caricava il modulo all'avvio.   :Embarassed: 

però quando hai fatto ciò:

```

emerge -C ipw3945 ieee80211 && emerge --depclean && emerge ipw3945
```

prima di riemergere ipw3945 dovevi secondo me ti conveniva dare prima un :

```

dep -w && revdep-rebuild
```

ciauz

----------

## skypjack

Ok, malinteso chiarito.

Il dep non l'ho dato perchè essendo in ~x86 mi limito ad usarlo con un bel -sp per vedere che effetto avrebbero sul mio sistema le "pulizie di primavera"!!

Il revdep-rebuild come capirai non ha molta utilità in quella posizione.

Alla prossima.

Ciao.

----------

## crisandbea

 *skypjack wrote:*   

> Ok, malinteso chiarito.
> 
> Il dep non l'ho dato perchè essendo in ~x86 mi limito ad usarlo con un bel -sp per vedere che effetto avrebbero sul mio sistema le "pulizie di primavera"!!
> 
> Il revdep-rebuild come capirai non ha molta utilità in quella posizione.
> ...

 

beh nel tuo caso lavorando su un sistema in testing(è secondo me potevi dirlo prima   :Wink:  ), può capitare che hai quei problemi, li purtroppo devi cavartela da solo, o può aiutarti chi come te stà usando un sistema in testing.

ciauz

----------

## skypjack

Ehm... Veramente non ho un sistema in testing!!

Avrò si e no tre voci in package.keywords...

----------

## crisandbea

 *skypjack wrote:*   

> Ehm... Veramente non ho un sistema in testing!!
> 
> Avrò si e no tre voci in package.keywords...

 

allora intendevi che il dep era in ~x86???

quello si è in testing, ma funge bene.

----------

## skypjack

Non ne discuterò qua, ma la tua affermazione è forse azzardata.

C'è chi direbbe il contrario, io, nel dubbio, non mi fido e lo giudico per quel che è: instabile.

Torniamo al mio problema, ora?

----------

## riverdragon

 *riverdragon wrote:*   

> dove trovo la patch per inserire il supporto alla scheda ipw3945 direttamente nel kernel?

 Mi autoquoto per segnalare che ho trovato le patch in questione in questo thread create da rmh3093, questa è la patch che aggiunge i driver 1.1.2 per i kernel 2.6.18, mentre questa è la patch che aggiunge i driver 1.2.0 ai kernel 2.6.19. Quando ricompilerò il kernel vi farò sapere.

----------

## skypjack

Aspetto ansioso tue nuove, cavaliere...

----------

## riverdragon

La patch funziona correttamente.

MID-EDIT:per applicarla correttamente:

```
emerge -C ipw3945 ieee80211

emerge --depclean

emerge ipw3945d ipw3945-ucode
```

END_MID-EDIT

Ho provato a compilarla come built-in, ma si comporta stranamente: all'avvio, quando il sistema riconosce la periferica, si ferma per tre-quattro secondi per poi riprendere il boot.

Ho quindi letto nel thread che ho segnalato prima che è bene compilare lo stack ieee80211 come built-in e il supporto ipw3945 come modulo. Fatto così, il fastidio al boot è sparito.

Rimane il problema di ipw3945d, come tu stesso hai segnalato in apertura di thread, ma la periferica viene inizializzata correttamente.

Non ho fatto reali prove di connessione in quanto non dispongo ancora di un access point, ho giusto provato a connettermi ai due che vedo nelle vicinanze, e una volta ci sono pure riuscito.

Per far partire il servizio ipw3945d ho preferito mettere le mani in /etc/init.d/ipw3945d, alla riga 15 ho tolto "--pid-file=${PIDFILE}" perché non è un'opzione contemplata dal demone, e ora lo avvio come avvio normalmente i servizi.

Ora provo ad inserire le modifiche che hai segnalato prima.

EDIT: le modifiche non riesco a farle funzionare, quantomeno sostituendo il comando ipw3945d con il comando per l'avvio del servizio. Ho perciò trovato un'altra soluzione, che mi piace molto di più:

```
rm -fr /etc/init.d/net.wlan0

cp /etc/init.d/net.lo /etc/init.d/net.wlan0
```

e inserito, nella riga need, il servizio ipw3945d:

```
tomnote init.d # diff /etc/init.d/net.lo /etc/init.d/net.wlan0 

14c14

<       need localmount

---

>       need localmount ipw3945d
```

Ora ipw3945d parte subito prima di net.wlan0, ma non si ferma quando questo viene arrestato. Per il momento direi che va bene.

----------

## skypjack

Approfitto della tua disponibilità per farti alcune domande...

Allora, come te applico la patch con i seguenti comandi, a cui aggiungo l'emerge per ieee80211 (forse non è più necessario?). Ovviamente, seguendo le dovute istruzioni del caso se fosse richiesto di eliminare il supporto originario per ieee80211 dal kernel e cose del genere. Insomma, digito:

```
emerge ieee80211 ipw3945d ipw3945-ucode
```

Ora, tu dici:

 *riverdragon wrote:*   

> Ho quindi letto nel thread che ho segnalato prima che è bene compilare lo stack ieee80211 come built-in e il supporto ipw3945 come modulo. Fatto così, il fastidio al boot è sparito.

 

Vorresti dire, e lo chiedo senza sapere perchè in questo periodo non ho proprio il tempo di fare prove, che il pacchetto ieee80211 (come sopra) non è più necessario e per la nostra scheda wireless possiamo usare il supporto ieee80211 integrato nel kernel originario? Spiegati meglio...

 *riverdragon wrote:*   

> Rimane il problema di ipw3945d, come tu stesso hai segnalato in apertura di thread, ma la periferica viene inizializzata correttamente.

 

Vero, anche a me viene inizializzata e infatti basta avviare il demone e tutto funziona correttamente, provare per credere!

 *riverdragon wrote:*   

> Per far partire il servizio ipw3945d ho preferito mettere le mani in /etc/init.d/ipw3945d, alla riga 15 ho tolto "--pid-file=${PIDFILE}" perché non è un'opzione contemplata dal demone, e ora lo avvio come avvio normalmente i servizi.

 

Scusa se ti interrompo, ma di questo fantomatico /etc/init.d/ipw3945d ne ho già sentito parlare più volte, però il pacchetto ipw3945 e affini non lo contemplano (anche un equery mi da conferma). Mi spieghi da dove è saltato fuori? Forse, lo ricavi compilando la patch? Perchè se per caso lo hai tirato giù te a manina ti sarei molto grato se me lo presenti!!

 *riverdragon wrote:*   

> 
> 
> ```
> rm -fr /etc/init.d/net.wlan0
> 
> ...

 

Scusa, sarò breve e chiaro: COSA??

Nel senso, mi puoi spiegare quest'ultimo passo perchè non l'ho mica capito, ne da cosa nasce, ne perchè e ne a cosa mira. Ad ogni modo, se non ho capito male, è solo una soluzione alternativa alla mia, meglio o peggio secondo i gusti, ma il problema del demone ipw3945d resta e lo confermi, non è vero?

Grazie per l'aiuto...

----------

## fbcyborg

Ciao a tutti, 

anche io sono fra gli sfigati incappati in questo tribolo assurdo... 

non appena posso provo a fixare tutto con quello che è scritto nel primo post, 

ringrazio infinitamente l'autore in anticipo.

Due curiosità:

leggendo tutto il thread mi sembra di aver capito (forse male) che bisogna patchare il kernel per avere il supporto alla nostra scheda wireless, ok, ma è un'alternativa all'emerge di ipw3945???

Nel senso: o patcho il kernel così uso quei driver oppure emergo ipw3945... 

Seconda cosa: invece di usare depclean... è meglio dep -w ???? Va bene come alternativa?

Caso strano, 2 volte su 100 sono riuscito a connettermi ad un AP anche nelle condizioni di malfunzionamento in cui mi trovo; reboot e tutto torna a non funzionare.

Anche io uso la versione testing di ipw3945d ed ho lo script in /etc/init.d/.

----------

## riverdragon

Il supporto per lo stack wireless 80211 va compilato nel kernel come built-in (è proprio per questo che si usa la patch per ipw3945, altrimenti funzionerebbe già l'ebuild esterno, no?  :Smile:  ) quindi non serve emergere ieee80211,

La patch sostituisce solo l'ebuild ipw3945, quindi gli altri due pacchetti collegati (ipw3945d e ipw3945-ucode) vanno emersi separatamente. Spero di aver capito male quello che hai scritto, ma il comando che emerge questi due pacchetti NON applica la patch al kernel, per quello ci vuole un comando a parte.

Il servizio ipw3945d non fa parte dell'ebuild ipw3945 ma io ce l'ho, non l'ho scaricato a mano e che io sappia è sempre stato lì. Boh. Comunque puoi metterlo anche a mano, se vuoi ti copio qui il mio.

Per l'ultimo passo, i servizi possono basarsi su altri che devono essere già avviati; perciò tu lanci un servizio e questo controlla se tutte le sue dipendenze sono avviate, in caso contrario le avvia. Così, modificando /etc/init.d/net.wlan0 scrivendo che necessita anche del servizio ipw3945d, questo viene avviato se viene trovato non attivo. Niente di complicato. L'unica cosa a cui stare attenti è che i file per le periferiche di rete, seguendo l'handbook, sono tutti link simbolici a net.lo, ma solo l'avvio del modulo wireless ha bisogno di ipw3945d, quindi ho rimosso il symlink e copiato il file che sono andato poi a modificare.

@fbcyborg: patchare il kernel è un'alternativa ad emergere l'ebuild, entrambe le cose non si possono fare, altrettanto per ieee80211.

Non ho capito in che caso dep -w sarebbe un'alternativa a depclean.

----------

## skypjack

Grazie dragon, sei stato molto utile ma vuoi per mancanza di tempo e vuoi perchè al momento mi trovo bene così preferisco aspettare un pò prima di mettere mano all'ambaradan piazzato per far funzionare la wireles... Prima o poi anche ipw3945 entrerà nel kernel, che cavolo!! I suoi fratelli minori ci sono già, nn vedo perchè dovrebbe fare eccezione... Problema: prima o poi? Mah...

Per quanto riguarda dep, è unstable, il che deve essere un campanello d'allarme ogni volta che l'usi anche se funziona bene: il giorno che non lo farà ti pentirai!! Uomo avvisato...

----------

## fbcyborg

 *riverdragon wrote:*   

> Il supporto per lo stack wireless 80211 va compilato nel kernel come built-in (è proprio per questo che si usa la patch per ipw3945, altrimenti funzionerebbe già l'ebuild esterno, no?  ) quindi non serve emergere ieee80211,
> 
> 

 Ok, quindi al contrario di quello che dice quì tu preferisci usare il supporto ieee80211 del kernel (ok, quindi è solo una scelta personale.. pensavo che fosse "obbligatorio" nel senso che sennò altrimenti non avrebbe funzionato quello che fa fare in quell'howto. *Quote:*   

> 
> 
> La patch sostituisce solo l'ebuild ipw3945, quindi gli altri due pacchetti collegati (ipw3945d e ipw3945-ucode) vanno emersi separatamente. Spero di aver capito male quello che hai scritto, ma il comando che emerge questi due pacchetti NON applica la patch al kernel, per quello ci vuole un comando a parte.

 si si, hai capito male.. lo so che con l'emerge non applico la patch al kernel. Io avevo capito che la patch era per il kernel e servisse per "inserire" il sorgente del modulo del driver che ci serve a noi per la nostra scheda wireless. In caso, basta che vado nel kernel tree ed applico la patch al solito modo? Va applicata in ogni caso? Scusa tutte queste domande ma forse non ho tutto ben chiaro, in merito al da farsi, ma leggendo l'intero thread poi mi sono confuso le idee. Se mi limito a seguire solo quello che dici nel primo post spero che vada bene lo stesso. *Quote:*   

> 
> 
> Il servizio ipw3945d non fa parte dell'ebuild ipw3945 ma io ce l'ho, non l'ho scaricato a mano e che io sappia è sempre stato lì. Boh. Comunque puoi metterlo anche a mano, se vuoi ti copio qui il mio.

 Io quello script ce l'ho solo grazie al fatto che ho emerso ipw3945d (che è ancora in testing) *Quote:*   

> 
> 
> Per l'ultimo passo, i servizi possono basarsi su altri che devono essere già avviati; perciò tu lanci un servizio e questo controlla se tutte le sue dipendenze sono avviate, in caso contrario le avvia. Così, modificando /etc/init.d/net.wlan0 scrivendo che necessita anche del servizio ipw3945d, questo viene avviato se viene trovato non attivo. Niente di complicato. L'unica cosa a cui stare attenti è che i file per le periferiche di rete, seguendo l'handbook, sono tutti link simbolici a net.lo, ma solo l'avvio del modulo wireless ha bisogno di ipw3945d, quindi ho rimosso il symlink e copiato il file che sono andato poi a modificare.

 Ok, allora forse quì sarebbe necessario un bell'update dell'handbook ufficiale forse. Lì consigliano di fare solo link simbolici. *Quote:*   

> 
> 
> @fbcyborg: patchare il kernel è un'alternativa ad emergere l'ebuild, entrambe le cose non si possono fare, altrettanto per ieee80211.
> 
> Non ho capito in che caso dep -w sarebbe un'alternativa a depclean.

 

[/quote]Ok, quindi mi avevi già chiarito il dubbio ad inizio post. Grazie. Quindi in caso comunque tu consigli patch al kernel + supporto ieee80211 interno al kernel? Per quanto riguarda dep, mi sembrava ci fosse una discussione nel forum che ne consigliava l'uso al posto di depclean.. ma forse non ho capito bene.. comunque, per stare tranquillo vorrei elencare la lista di tutti i pacchetti ridondandi, vorrei sapere se rischio qualcosa ad eseguire il dep -w[quote]

```
!!!REDUNDANT ENTRY!!! kde-base/nsplugins depended on by:

  kde-base/kdebase-meta-3.5.5          ~kde-base/nsplugins-3.5.5

    WORLD FILE                           kde-base/kdebase-meta

!!!REDUNDANT ENTRY!!! media-gfx/splashutils depended on by:

  media-gfx/splash-themes-livecd-2006.1  >=media-gfx/splashutils-1.1.9.10-r1

    WORLD FILE                           media-gfx/splash-themes-livecd

!!!REDUNDANT ENTRY!!! media-sound/alsa-utils depended on by:

  net-wireless/bluetooth-alsa-utils-0.41  media-sound/alsa-utils

    WORLD FILE                           net-wireless/bluetooth-alsa-utils

!!!REDUNDANT ENTRY!!! net-im/skype depended on by:

  net-wireless/bluetooth-alsa-utils-0.41  skype? net-im/skype

    WORLD FILE                           net-wireless/bluetooth-alsa-utils

!!!REDUNDANT ENTRY!!! net-print/cups depended on by:

  app-text/ghostscript-gpl-8.54        cups? >=net-print/cups-1.1.20

    virtual/ghostscript-0                || app-text/ghostscript-gpl

      app-text/evince-0.6.1                virtual/ghostscript

        WORLD FILE                           app-text/evince

!!!REDUNDANT ENTRY!!! net-wireless/bluez-libs depended on by:

  net-wireless/bluetooth-alsa-utils-0.41  >=net-wireless/bluez-libs-2.19

    WORLD FILE                           net-wireless/bluetooth-alsa-utils

!!!REDUNDANT ENTRY!!! net-wireless/bluez-utils depended on by:

  net-wireless/bluetooth-alsa-utils-0.41  >=net-wireless/bluez-utils-2.19

    WORLD FILE                           net-wireless/bluetooth-alsa-utils

!!!REDUNDANT ENTRY!!! net-wireless/ieee80211 depended on by:

  net-wireless/ipw2200-1.1.3           >=net-wireless/ieee80211-1.1.13

    WORLD FILE                           net-wireless/ipw2200

!!!REDUNDANT ENTRY!!! net-wireless/ipw3945-ucode depended on by:

  net-wireless/ipw3945-1.1.3           >=net-wireless/ipw3945-ucode-1.13

    WORLD FILE                           net-wireless/ipw3945

!!!REDUNDANT ENTRY!!! net-wireless/ipw3945d depended on by:

  net-wireless/ipw3945-1.1.3           >=net-wireless/ipw3945d-1.7.22

    WORLD FILE                           net-wireless/ipw3945

!!!REDUNDANT ENTRY!!! net-wireless/wireless-tools depended on by:

  kde-base/kwifimanager-3.5.5          net-wireless/wireless-tools

    kde-base/kdenetwork-meta-3.5.5       wifi? ~kde-base/kwifimanager-3.5.5

      WORLD FILE                           kde-base/kdenetwork-meta

!!!REDUNDANT ENTRY!!! sys-apps/pcmciautils depended on by:

  virtual/pcmcia-2.6.13                || sys-apps/pcmciautils

    WORLD FILE                           virtual/pcmcia

!!!REDUNDANT ENTRY!!! sys-fs/udev depended on by:

  net-wireless/bluez-utils-2.25-r1     udev? sys-fs/udev

    net-wireless/bluetooth-alsa-utils-0.41  >=net-wireless/bluez-utils-2.19

      WORLD FILE                           net-wireless/bluetooth-alsa-utils

!!!REDUNDANT ENTRY!!! sys-kernel/gentoo-sources depended on by:

  WORLD FILE                           sys-kernel/gentoo-sources

  media-libs/alsa-lib-1.0.13           virtual/alsa

    app-cdr/k3b-0.12.17                  alsa? media-libs/alsa-lib

      WORLD FILE                           app-cdr/k3b

!!!REDUNDANT ENTRY!!! sys-power/acpid depended on by:

  app-laptop/laptop-mode-tools-1.31    acpi? sys-power/acpid

    WORLD FILE                           app-laptop/laptop-mode-tools

!!!REDUNDANT ENTRY!!! x11-drivers/nvidia-drivers depended on by:

  media-video/nvidia-settings-1.0.20051122-r3  || >=x11-drivers/nvidia-drivers-1.0.8178

    WORLD FILE                           media-video/nvidia-settings

!!!REDUNDANT ENTRY!!! x11-drivers/synaptics depended on by:

  x11-base/xorg-server-1.1.1-r1        xorg? input_devices_synaptics? x11-drivers/synaptics

    gnome-base/libbonoboui-2.16.0        X? || x11-base/xorg-server

      gnome-base/libgnomeui-2.16.1         >=gnome-base/libbonoboui-2.13.1

        app-text/evince-0.6.1                >=gnome-base/libgnomeui-2.14

          WORLD FILE                           app-text/evince

!!!REDUNDANT ENTRY!!! x11-libs/cairo depended on by:

  app-text/poppler-bindings-0.5.4      cairo? >=x11-libs/cairo-0.5

    app-text/evince-0.6.1                >=app-text/poppler-bindings-0.5.4

      WORLD FILE                           app-text/evince               

85 packages in world:  67 valid,  18 redundant;

61 packages in system;

687 packages installed: 8% in system, 12% in world, 81% deps.

```

Ho paura di incasinare qualcosa e di cancellare cose buone.

Grazie.

----------

## riverdragon

Una cosa per volta.

La guida consiglia di usare l'ebuild per ieee80211 e di non compilare il supporto interno al kernel perché l'ebuild ipw3945 richiede espressamente ieee80211 esterno: quando sono stati rilasciati i driver dalla intel (aprile scorso mi sembra) la versione dello stack 80211 era troppo vecchia per far funzionare il nuovissimo driver; ma all'epoca il kernel era il 2.6.15, ora siamo al 2.6.19, mentre l'ebuild ieee80211 è sempre rimasto lo stesso.

Per la patch, si applica nel modo normale, cosa intendi per "va applicata in ogni caso?" ?

ipw3945d è stabile nella versione 1.7.18 e ~x86 nella versione 1.7.22, ma se controlli noterai che nessuno dei pacchetti in questione ti fornisce il file che viene messo dentro a /etc/init.d, come ti può confermare il comando equery b /etc/init.d/ipw3945d. L'unica spiegazione che so darmi è che sia stato messo da una precedente versione dell'ebuild.

Più che aggiornare l'handbook ufficiale bisognerebbe far funzionare come si deve udev in maniera che, riconosciuta la dipendenza ipw3945d per la scheda wireless, la faccia partire sempre prima del servizio di rete. Questo mio sistema si può classificare tra gli "hack", i trucchetti, non fa parte del metodo standard.

Per dep, non confondere il comando dep che viene dall'ebuild udept con emerge --depclean, il primo ti rimuove le voci ridondanti dal file world, il secondo rimuove i pacchetti non necessari dal sistema, sono ben diversi!

@skypjack: una cosa che ho notato positivamente nell'utilizzare la patch è che si è risolto il problema che mi bloccava la scheda ethernet quando tentavo di avviare la wireless con il modulo ipw3945 compilato esternamente, ora invece funziona benissimo, magari c'entra il fatto che ipw stabile è 1.0.5 mentre la patch applica il 1.2.0.

----------

## fbcyborg

 *riverdragon wrote:*   

> Una cosa per volta.
> 
> La guida consiglia di usare l'ebuild per ieee80211 e di non compilare il supporto interno al kernel perché l'ebuild ipw3945 richiede espressamente ieee80211 esterno: quando sono stati rilasciati i driver dalla intel (aprile scorso mi sembra) la versione dello stack 80211 era troppo vecchia per far funzionare il nuovissimo driver; ma all'epoca il kernel era il 2.6.15, ora siamo al 2.6.19, mentre l'ebuild ieee80211 è sempre rimasto lo stesso.

 Ok! allora opto per ieee80211 del kernel, anche se ora dovrei riemergere i sorgenti visto che ho dato il comando remove-old consigliato/obbligato dall'emerge stesso di quel pacchetto. *Quote:*   

> 
> 
> Per la patch, si applica nel modo normale, cosa intendi per "va applicata in ogni caso?" ?
> 
> 

 Mi sembra di aver capito che quella patch serve per avere nel kernel anche i driver/moduli per questa scheda wireless.. Bene, se non applico la patch sono costretto a usare il driver disponibile in portage.. e basta.. In pratica, con la patch applicata non devo più fare 

```
emerge ipw3945
```

?? *Quote:*   

> 
> 
> ipw3945d è stabile nella versione 1.7.18 e ~x86 nella versione 1.7.22, ma se controlli noterai che nessuno dei pacchetti in questione ti fornisce il file che viene messo dentro a /etc/init.d, come ti può confermare il comando equery b /etc/init.d/ipw3945d. L'unica spiegazione che so darmi è che sia stato messo da una precedente versione dell'ebuild.
> 
> 

 Io quel file in init.d ce l'ho da quando ho smascherato ed emerso la versione di testing di ipw3945d, infatti come dice quì *HowTo wrote:*   

> In order to use the ipw3945 device, you need to have the ipw3945d daemon running. In versions of ipw3945d >=1.7.22, this is controlled by an init script, /etc/init.d/ipw3945d. 

  inoltre:

```
# equery b /etc/init.d/ipw3945d

[ Searching for file(s) /etc/init.d/ipw3945d in *... ]

net-wireless/ipw3945d-1.7.22-r4 (/etc/init.d/ipw3945d)
```

 Non so perché a te venga fuori qualcosa di diverso... Io so solo che da quando ho una versione di ipw3945d maggiore o uguale a 1.7.22 ho quel file. *Quote:*   

> 
> 
> Per dep, non confondere il comando dep che viene dall'ebuild udept con emerge --depclean, il primo ti rimuove le voci ridondanti dal file world, il secondo rimuove i pacchetti non necessari dal sistema, sono ben diversi!

 Ah, ok grazie, allora posso stare tranquillo con la rimozione?

----------

## skypjack

River, scusa se ti "sfrutto" ma come detto non ho modo di provare / cercare in questi giorni, causa esame in preparazione.

Ti volevo chiedere: all'orizzonte niente in merito ad una imminente inclusione nel kernel, che tu sappia?

Così, se per caso ti è capitato di leggerlo da qualche parte...

Comunque, anche a me risulta che lo script non fa parte di alcun pacchetto, se potete postarlo mi fate un piacere.

Per quanto riguarda il tutto, continuerò ad usare il mio metodo non per sfiducia ma perchè funziona e non voglio cambiarlo fino a che non ne esce uno "ufficiale" al quale aggrapparsi / convertirsi.

Ad ogni modo, appena ho tempo provo anche ad applicare la patch al kernel, per curiosità, ma questo avverrà non prima di fine Gennaio. Mi potete indicare dove trovarla? Grazie. (Se non lo ricordate fa niente, la cerco da me).

Ciao.

----------

## fbcyborg

```
# cat /etc/init.d/ipw3945d

#!/sbin/runscript

# Copyright 1999-2006 Gentoo Foundation

# Distributed under the terms of the GNU General Public License v2

# $Header: /var/cvsroot/gentoo-x86/net-wireless/ipw3945d/files/ipw3945d-init.d,v 1.4 2006/12/22 10:11:26 phreak Exp $

PIDFILE=/var/run/ipw3945d/ipw3945d.pid

depend() {

        before net

}

check() {

        # Let's check if the pidfile is still present.

        if [ -f "${PIDFILE}" ] ; then

                eerror "The pidfile ($PIDFILE) is still present."

                eerror "Please check that the daemon isn't running!"

                return 1

        fi

}

start() {

        check

        ebegin "Starting ipw3945d"

        chown ipw3945d /sys/bus/pci/drivers/ipw3945/00*/cmd

        chmod a-w,u+rw /sys/bus/pci/drivers/ipw3945/00*/cmd

        start-stop-daemon --start --exec /sbin/ipw3945d --pidfile ${PIDFILE} -- \

                --pid-file=${PIDFILE} ${ARGS}

        eend ${?}

}

stop() {

        ebegin "Stopping ipw3945d"

        start-stop-daemon --stop --exec /sbin/ipw3945d --pidfile ${PIDFILE}

        eend ${?}

}

```

----------

## riverdragon

@skypjack: Non so se e quando il supporto verra` incluso nel kernel, ma visto che al momento la patch funziona bene non me ne preoccupo troppo. Lo script /etc/init.d/ipw3945d, come detto da fbcyborg, e` incluso nell'ebuild con versione >=1.7.22. Effettivamente tempo fa avevo tutti gli ebuild in testing (da quando sono comparsi su portage) per cui ho lo script grazie a cio`. La patch e` linkata in un mio post nella prima pagina.

@fbcyborg: con la patch applicata non devi fare piu` "emerge ipw3945". Come ho gia` detto, i pacchetti ipw3945d e ipw3945-ucode, che erano installati come dipendenze di ipw3945, devi ora installarli a mano. A me non viene fuori nulla da equery perche` ho ipw3945d stabile (1.7.18 ) e non ~x86.

Lancia emerge --depclean -p e controlla cosa ti viene rimosso, se non ci sono problemi strani rimuovi il "-p", quindi lancia revdep-rebuild && emerge -uDavN world per risistemare eventuali pacchetti necessari rimossi dal depclean.

----------

## fbcyborg

 *skypjack wrote:*   

> Grazie dragon, sei stato molto utile ma vuoi per mancanza di tempo e vuoi perchè al momento mi trovo bene così preferisco aspettare un pò prima di mettere mano all'ambaradan piazzato per far funzionare la wireles... Prima o poi anche ipw3945 entrerà nel kernel, che cavolo!! I suoi fratelli minori ci sono già, nn vedo perchè dovrebbe fare eccezione... Problema: prima o poi? Mah...
> 
> Per quanto riguarda dep, è unstable, il che deve essere un campanello d'allarme ogni volta che l'usi anche se funziona bene: il giorno che non lo farà ti pentirai!! Uomo avvisato...

 

Quindi dici che prima o poi tutto si risolverà con un emerge -uDN world???

----------

## skypjack

No, dico solo che il supporto per le precedenti schede wireless della categoria è stato introdotto nel kernel, che se non sbaglio è l'intel stessa a guidare o quantomeno fornire le basi per lo sviluppo del driver e quindi non vedo perchè dovrei dubitare che l'ipw3945 non segua la stessa via.

Questo non sarà forse fra un giorno o fra un mese, ma prima o poi...

Ad ogni modo, credo che il pacchetto ipw3945 nel frattempo raggiunga la maturità e quindi, trucchi a parte per mettere una pezza ai problemi via via, come quello che ho suggerito io, non lo voglio snobbare ma bensì utilizzarlo.

In fondo, applicare la patch è a tuo rischio e pericolo mentre attingere da portage ramo stabile solitamente da la certezza che quel determinato pacchetto sia passato da una serie di test e abbia raggiunto una stabilità sufficiente. Ripeto, solitamente...

Insomma, sono vie diverse, ne giuste ne sbagliate, dipende dal tempo e la voglia che hai di seguirle e dalle motivazioni che ti spingono a farlo.

Le mie le ho esternate, se hai dubbi chiedi pure e non esiterò a rispondere, poi sta a te scegliere cosa fare.

Buon lavoro, qualunque sia la tua scelta...

----------

## fbcyborg

Ti ringrazio tantissimo per la tua risposta.. quindi in pratica confermi quello che dico io ... Prima o poi, quando farò un aggiornamento globale le cose si sistemeranno da sole.. e forse sarà buona cosa utilizzare sia i moduli ipw3945 nel kernel che quelli in portage che( forse, e dico forse) saranno più aggiornati.

Se è così posso anche aspettare.

EDIT: ma guarda guarda... caso strano facendo un emerge -uDNpv world ecco cosa ho trovato:

```
[ebuild     UD] net-wireless/ieee80211-1.1.13-r1 [1.2.15] USE="-debug" 0 kB

[ebuild     UD] net-wireless/ipw3945-1.1.0-r1 [1.1.3] USE="-debug" 191 kB

```

curioso non trovate???

guardate quì: mascheramento a tappeto!!!!   :Rolling Eyes:   :Rolling Eyes:  non è curioso??? vediamo un po' che succede se eseguo l'emerge...

----------

## skypjack

In realtà o usi la patch o il modulo preso da portage. Entrambi non andranno molto d'accordo!

Per quanto riguarda l'essere più aggiornato, la patch scaricata a mano dalla rete è sicuramente più aggiornata del modulo preso da portage.

Per quanto riguarda l'inclusione nel kernel, si vedrà.

Non credo che un: emerge -uND world, risolverà mai i problemi. Gentoo è una gran distro, ma lascia all'utente tutto in mano (e questo è il bello o il brutto, dipende dai punti di vista) e sta all'utente risolvere eventuali problemi. Mi spiace deluderti... La potenza e il controllo si pagano in complessità della soluzione e Gentoo è l'esempio di quanto detto, spero concorderai.

Ciao, a presto.

Ps: sono curioso, fammi sapere... Magari posso togliere la pezza che ho messo un mese fa alla rete!!  :Very Happy: 

Pps: Ma sei sicuro? A me non risulta, non è che le hai smascherate?

----------

## fbcyborg

Ha funzionatoooooooooooooooo!!!!!  :Very Happy: 

Woow! era colpa dei drivers!!!!!

finalmente il prima o poi è arrivato più prima che poi!!! LOL

EDIT: basta avere anche un po' di fiducia in gentoo, e molte cose si sistemano da sole per fortuna!

----------

## skypjack

 *fbcyborg wrote:*   

> 
> 
> ```
> [ebuild     UD] net-wireless/ieee80211-1.1.13-r1 [1.2.15] USE="-debug" 0 kB
> 
> ...

 

Scusa, ma io posso solo dire che:

```
$ ACCEPT_KEYWORDS="~x86" emerge -pv ipw3945 ieee80211

These are the packages that would be merged, in order:

Calculating dependencies... done!

[ebuild     U ] net-wireless/ipw3945d-1.7.22-r4 [1.7.18] 58 kB 

[ebuild     U ] net-wireless/ipw3945-1.1.0-r1 [1.0.5] USE="-debug" 191 kB 

[ebuild     U ] net-wireless/ieee80211-1.2.15 [1.1.13-r1] USE="-debug" 67 kB 

Total size of downloads: 317 kB

```

Come me lo spieghi?

Ripeto, non è che li hai smascherati?

----------

## fbcyborg

Si, nel mio /etc/portage/package.keywords ci sono le seguenti righe:

```
net-wireless/ipw3945 ~x86

net-wireless/ipw3945-ucode ~x86

net-wireless/ipw3945d ~x86

net-wireless/ieee80211 ~x86

```

ma comunque in ogni caso, alcuni di quelli che prima erano considerati testing, ora sono hard masked. Adesso essendo ~M quelli non funzionanti sono rimasti smascherati solo quelli testing funzionanti.

In ogni caso assicurati di aver dato un bell'emerge --sync prima. Deve darti gli stessi risultati, sono anche io su x86.

----------

## riverdragon

La patch che ho linkato nella pagina scorsa per il kernel 2.6.19 si applica senza problemi anche sul kernel 2.6.20.

----------

## skypjack

Col kernel 2.6.19 la versione stabile di ipw3945 fa i capricci.

Mi spiego: tutto funziona, la scheda è correttamente rilevata e il modulo caricato, ma il passaggio dell'essid, una volta trovata una rete utilizzabile nota, avviene troncando l'ultima lettera; quindi, per collegarsi a PIPPO, si deve passare a mano tramite iwconfig qualcosa tipo PIPPOO o qualsiasi altra lettera aggiuntiva al posto della O.

Lo so, può sembrare assurdo, ma così funziona.

Giusto per dire, casomai qualcuno stesse impazzendo per questo motivo, una soluzione grezza ma efficace...

----------

## fbcyborg

Io ho applicato la patch e sto usando il driver che ora è presente nel kernel come modulo, ma ho sempre questo problema:

Durante la fase di boot, e l'avvio di tutti i servizi mi dice: 

```
* Starting eth1

*    Bringing up eth1

*        192.168.1.110

*        network interface eth1 does not exist

*        please verify hardware or kernel module (driver) 
```

Non capisco perché al momento del bringing up di eth1 non la vede.. poi entro in kde, apro una shell e se faccio

```
/etc/init.d/net.eth1 start
```

 tutto torna a posto.

Vorrei evitare di dover inserire qualcosa in ~/.kde/Autostart

----------

## riverdragon

Quel messaggio mi compare quando avvio la scheda wireless senza che il demone ipw3945d sia attivo. Uso la penultima versione di ipw3945d perché con l'ultima non funziona nulla.

----------

## fbcyborg

Io uso la 1.7.22-r4 ma ho solo quel problema. Per il resto funziona tutto bene.

----------

## fbcyborg

 *fbcyborg wrote:*   

> Io ho applicato la patch e sto usando il driver che ora è presente nel kernel come modulo, ma ho sempre questo problema:
> 
> Durante la fase di boot, e l'avvio di tutti i servizi mi dice: 
> 
> ```
> ...

 

Ho aggiornato il kernel alla versione 2.6.20-r6 e non ho più avuto questo problema.

L'unico messaggio strano riguarda udev che vuole caricare il driver ipw3945 ma non gli è permesso fino a che non sono stati avviati prima altri servizi.

----------

## Elbryan

 *fbcyborg wrote:*   

>  *fbcyborg wrote:*   Io ho applicato la patch e sto usando il driver che ora è presente nel kernel come modulo, ma ho sempre questo problema:
> 
> Durante la fase di boot, e l'avvio di tutti i servizi mi dice: 
> 
> ```
> ...

 

stessa cosa per me..

quell'errore comunque è fastidioso..

----------

## fbcyborg

Sto cercando di risolverlo con l'aiuto di questo thread. 

Loro dicono "SOLVED", ma a me non funziona. Forse ho dimenticato di fare qualcosa.

----------

## xveilsidex

 *fbcyborg wrote:*   

> Sto cercando di risolverlo con l'aiuto di questo thread. 
> 
> Loro dicono "SOLVED", ma a me non funziona. Forse ho dimenticato di fare qualcosa.

 

Guarda ti stavo postando lo stesso thread perchè ho avuto il tuo stesso problema dopo un aggiornamento al pc pero' seguendo quel thread si è risolto il problema O MEGLIO.. riavviai il pc ma il problema persisteva, riavviai la seconda volta e inizio' a funzionare! bho o_O

----------

## fbcyborg

Alla fine poi sono stato costretto a fare un 

```
update-modules --force
```

 perchÃ¨ non mi funzionavano piÃ¹ un sacco di altre cose. 

CosÃ¬ facendo ho risolto anche il problema di udev.

----------

## Elbryan

confermo..

commentare quelle 2 righe nel /etc/modules.d/ipw3945d risolve il problema.

Ricordate di dare un "update-modules --force" 

^^

----------

## fbcyborg

Prima che io aggiorni di nuovo il mio kernel: qualcuno sa se il driver per la scheda wireless di cui stiamo parlando è stato finalmente incluso nei sorgenti, senza dover includere una patch? Ora ho il 2.6.20-r6.

----------

## riverdragon

Non è ancora incluso.

La patch per il 2.6.20 si applica correttamente anche sul 2.6.21, ho provato personalmente.

----------

