# [Risolto] interfaccia wifi (ricompilare il kernel ex novo?)

## Hal-10000

Ciao a tutti,

da un pò di tempo e precisamente da quando ho installato il kernel 3.17.7, e poi anche con il successivo 3.17.8-gentoo-r1, Gentoo non riconosce più l'interfaccia wifi "wlp0s29f7u3". Me ne accorgo già al boot, poichè vedo scorrere nei POST, verso la fine, alcune voci in rosso con il nome dell'interfaccia  wlp0s29f7u3 e la dicitura "failed". Di più non sono riuscito a leggere poichè scorrono veloci; magari posto dmesg non appena riavvio con uno dei nuovi  kernel con cui si verifica il problema, visto che adesso sto con il vecchio kernel 3.16.5 perfettamente funzionante.

Come se ciò non bastasse, parallelamente a quanto detto sopra (ma non so dire se le questioni siano correlate), ho notato che dopo aver installato e ricompilato il kernel 3.17.7 (stessa cosa con il successivo 3.17.8-gentoo-r1) con la stringa che ho sempre usato

```
KCFLAGS="-march=prescott -O2 -pipe -fomit-frame-pointer" KCPPFLAGS="-march=prescott -O2 -pipe -fomit-frame-pointer" make -j3 && make modules_install && make install

```

poi non trovo bzImage in /usr/src/linux/arch/x86/boot da dove poi devo copiare, appunto bzImage in /boot/kernel.....ecc. ecc.

Per cui mi tocca ricompilare il kernel con il più semplice 

```
make modules_install && make install
```

.

Preciso che per ricompilare il kernel uso ricopiare il .config del kernel precedente 

 *Quote:*   

> cp ../linux-3.16.5-gentoo/.config .

 

Tuttavia, anche facendo in questo modo, cioè ricompilando con la stringa più semplice, ma meno ottimizzata di cui sopra, se per un verso trovo bzImage (e meno male), per altro verso, l'interfaccia di rete wifi non viene affatto riconosciuta, come dicevo sopra. Ciò nonostante nel kernel appena ricompilato sembra essere tutto a posto, visto che continuano ad essserci tutti i driver della scheda wifi usb da sempre utilizzati.

A questo punto mi chiedo se ricompilando il nuovo kernel da zero, cioè senza più utilizzare, ricopiandolo, il vecchio .config, possa essere d'aiuto. Solo che, anche ricompilando il kernel senza ricopiare il .config, mi accorgo che rimangono comunque tutte le impostazioni del vecchio config! Allora, come si fa ad avere un .config "originale" senza personalizzazioni? Sempre che questo possa risolvere il problema del mancato riconoscimento della scheda wifi.

Ringrazio in anticipo per la pazienza e la cortesia  :Very Happy: Last edited by Hal-10000 on Tue Feb 03, 2015 1:06 pm; edited 1 time in total

----------

## djinnZ

oldconfig e listnewconfig .... ed in generale make help.... codesti sconosciuti.

vedi che qualcosa è cambiato make bzImage non dovrebbe più essere implicito

per il resto  mi affido a genkernel e non capisco perchè lanciare make && make modules_install && make install.

----------

## pierino_89

 *Hal-10000 wrote:*   

> 
> 
> Come se ciò non bastasse, parallelamente a quanto detto sopra (ma non so dire se le questioni siano correlate), ho notato che dopo aver installato e ricompilato il kernel 3.17.7 (stessa cosa con il successivo 3.17.8-gentoo-r1) con la stringa che ho sempre usato
> 
> ```
> ...

 

Non è correlato con il problema, però se non salta fuori bzImage significa che da qualche parte si è verificato un errore. Controlla l'output, mi pare sia anche possibile fare "make bzImage" così magari riduci il testo da controllare.

 *Quote:*   

> 
> 
> Tuttavia, anche facendo in questo modo, cioè ricompilando con la stringa più semplice, ma meno ottimizzata di cui sopra, se per un verso trovo bzImage (e meno male), per altro verso, l'interfaccia di rete wifi non viene affatto riconosciuta, come dicevo sopra. Ciò nonostante nel kernel appena ricompilato sembra essere tutto a posto, visto che continuano ad essserci tutti i driver della scheda wifi usb da sempre utilizzati.

 

Se sfornava errori all'avvio, ci servono gli errori per capire. Magari banalmente non trova il firmware o non gli piace la versione installata.

 *Quote:*   

> 
> 
> A questo punto mi chiedo se ricompilando il nuovo kernel da zero, cioè senza più utilizzare, ricopiandolo, il vecchio .config, possa essere d'aiuto.

 

Di base no, però potresti scoprire qualche opzione nascosta da altre che hai abilitato tu.

 *Quote:*   

> Solo che, anche ricompilando il kernel senza ricopiare il .config, mi accorgo che rimangono comunque tutte le impostazioni del vecchio config! Allora, come si fa ad avere un .config "originale" senza personalizzazioni?

 

Evidentemente è rimasto quello che avevi copiato prima. Comunque mi pare che si possa falciare con "make mrproper", ma se ti documenti è meglio.

----------

## Hal-10000

Ciao e grazie per le risposte 

 *djinnZ wrote:*   

> oldconfig e listnewconfig .... ed in generale make help.... codesti sconosciuti.

 

Non è che oldconfig mi sia proprio "sconosciuto" poichè nel manuale si consiglia di optare per make menuconfig: "Un metodo di aggiornamento molto più sicuro è quello di copiare la propria configurazione come mostrato in precedenza, ed eseguire semplicemente make menuconfig. In questo modo si evitano i problemi di make oldconfig menzionati in precedenza, in quanto make menuconfig caricherà la configurazione precedente il più possibile nel menu." https://www.gentoo.org/doc/it/kernel-upgrade.xml (a fine pagina). Fin dalla prima installazione di gentoo ho sempre seguito questa guida e mi ci sono trovato bene. 

Adesso però le cose sembrano cambiate. Infatti,  *djinnZ wrote:*   

> vedi che qualcosa è cambiato make bzImage non dovrebbe più essere implicito 

  Pure tu usi il condizionale, quindi...figurati io.

 *djinnZ wrote:*   

>  per il resto  mi affido a genkernel e non capisco perchè lanciare make && make modules_install && make install.

 

Perchè lo si dice nel wiki http://wiki.gentoo.org/wiki/Kernel/Upgrade/it

Qui dopo aver parlato di "make silentoldconfig", c'è un link ad un'altra pagina del wiki dove si dice che poi va usato "make"  http://wiki.gentoo.org/wiki/Kernel/Configuration#Build

Ovviamente sempre se ho capito bene..(e non è detto)

In ogni caso ho seguito tutti i passaggi del wiki a proposito dell'aggiornamento del kernel come sopra indicati (http://wiki.gentoo.org/wiki/Kernel/Upgrade/it   e  http://wiki.gentoo.org/wiki/Kernel/Configuration#Build  ) ma non ho risolto nulla, in quanto l'interfaccia di rete non viene comunque caricata.

Vedo di trovare e postare gli errori  visualizzati nel POST, in modo da essere più preciso.

----------

## Hal-10000

Ciao e grazie per le risposte

 *pierino_89 wrote:*   

>  Controlla l'output, mi pare sia anche possibile fare "make bzImage" così magari riduci il testo da controllare.

 

infatti se dò solo make, bzImage viene generato, mentre con la stringa più lunga no. Non si capisce il perchè di questa novità, nè dove sia stata riportata (in quale news). Non ho mai provato a dare make bzImage.

 *pierino_89 wrote:*   

> Se sfornava errori all'avvio, ci servono gli errori per capire. Magari banalmente non trova il firmware o non gli piace la versione installata.

 

Adesso vedo di postare dmesg; attendi un pò, perchè senza connessione non va neppure l'ssh.

per il resto riguardo la compilazione del kernel, mi riporto a quanto detto sopra.

EDIT

dmesg  sembra riportare un problema di firmware

```

[    6.953745] usb 1-3: r8712u: CustomerID = 0x0000

[    6.955855] usb 1-3: r8712u: MAC Address from efuse = 94:44:52:b4:86:54

[    6.957912] usb 1-3: r8712u: Loading firmware from "rtlwifi/rtl8712u.bin"

[    6.960021] usb 1-3: Direct firmware load for rtlwifi/rtl8712u.bin failed with error -2

[    6.962186] usb 1-3: r8712u: Firmware request failed
```

Non capisco perche'

----------

## djinnZ

la guida del wiki ... meglio che mi autocensuro.

Ribadisco che è più produttivo utilizzare genkernel (con initrd assemblato nel kernel ed accorgimenti vari).

Se proprio vuoi passare per una configurazione manuale lancia in un terminale listnewconfig di modo da capire cosa è cambiato e poi oldconfig, dopo rifinisci con menuconfig/xconfig (pur usando genkernel alle volte faccio così, e genkernel lo uso solo per non ripetere la solita sequenza idiota di comandi)

Devi installare linux-firmware od il pacchetto apposito (non ho tempo di andare a cercare) ed includere il firmware nel kernel se il driver è builtin, o nell'initrd se è modulare (nel dubbio imposto sempre entrambi, male non fa)

vedi che lanciare make modules_ install && make install è diverso dal lanciare make -j3 modules_install install

----------

## Hal-10000

Ho risolto credo casualmente:

```
Device Drivers -->  Staging Drivers

   --- Staging drivers                                                              │ │  

  │ │          < >   Agere ET-1310 Gigabit Ethernet support                                     │ │  

  │ │          < >   Alacritech Gigabit IS-NIC support                                          │ │  

  │ │          < >   Prism2.5/3 USB driver                                                      │ │  

  │ │          < >   Data acquisition support (comedi)                                          │ │  

  │ │          <M>   RealTek RTL8192U Wireless LAN NIC driver                                   │ │  

  │ │          < >   Support for rtllib wireless devices                                        │ │  

  │ │          <M>   RealTek RTL8712U (RTL8192SU) Wireless LAN NIC driver                      │ │  

  │ │          < >   Realtek RTL8188EU Wireless LAN NIC driver                                  │ │  

  │ │          < >   Realtek RTL8192EE Wireless Network Adapter                                 │ │  

  │ │          < >   Realtek RTL8723AU Wireless LAN NIC driver                                  │ │  

  │ │          < >   RealTek RTL8821AE Wireless LAN NIC driver                                  │ │  

  │ │          < >   Realtek PCI-E Card Reader RTS5208/5288 support                             │ │  

  │ │          < >   Line6 USB support  ----                                                    │ │  

  │ │          < >   VIA Technologies VT6655 support                                            │ │  

  │ │          < >   VIA Technologies VT6656 support                                            │ │  

  │ │          < >   XGI display support                                                        │ │  

  │ │          < >   Beceem BCS200/BCS220-3 and BCSM250 wimax support                           │ │  

```

la riga    "RealTek RTL8712U (RTL8192SU) Wireless LAN NIC driver"

l'ho fatta caricare come Modulo <M> e non piu' build in <*> come era prima;

poi make -j3 (la solita sfilza di comandi)

ed ha funzionato. L'interfaccia wifi e' di nuovo riconosciuta perfettamente.

Adesso vorrei passare dal kernel 3.17.7-gentoo al 3.17.8-gentoo-r1.

Se la guida di gentoo per aggiornare il kernel non va bene

(http://wiki.gentoo.org/wiki/Kernel/Upgrade/it e http://wiki.gentoo.org/wiki/Kernel/Configuration#Build)

dove dovrei andare a guardare?

Intanto, ringrazio tutti per la pazienza e la cortesia.

----------

## pierino_89

 *Hal-10000 wrote:*   

> 
> 
> infatti se dò solo make, bzImage viene generato, mentre con la stringa più lunga no. Non si capisce il perchè di questa novità, nè dove sia stata riportata (in quale news). Non ho mai provato a dare make bzImage.
> 
> 

 

Questo era ovvio, intendevo dire: lancia make bzImage con le varie flags così limiti l'output e trovi più facilmente dove si è piantato   :Wink:  .

Se hai messo il wifi builtin nel kernel devi avere il firmware caricato come blob perché quando carichi il kernel il filesystem non è ancora montato, e quindi è normale che non lo riesca a trovare. Magari sei stato fortunato fino ad oggi e il filesystem è sempre stato montato prima che il kernel cercasse di caricare il firmware, ma non è un metodo consistente. L'initrd non è strettamente necessario, puoi farlo o non farlo, funziona ugualmente, non mi dilungo perché diventa una questione religiosa  :Razz: 

Per aggiornare il kernel solitamente i passaggi sono: copia la configurazione, "make oldconfig", eventuale revisione con "make menuconfig/gconfig/xconfig", "make", "make modules/bzImage" se necessario, "make install", "make modules_install". In teoria "make modules" e "make bzImage" dovrebbero essere inclusi in "make" o perlomeno essere lanciati durante "make install" e "make modules_install", ma se li lanci prima ti togli il pensiero. Tanto non lo fa due volte a meno che non usi "make clean". Ovviamente se usi genkernel dovrebbe fare tutto lui, ma anche qui andiamo sul religioso.

----------

## Hal-10000

 *pierino_89 wrote:*   

>  lancia make bzImage con le varie flags così limiti l'output e trovi più facilmente dove si è piantato   .

 

OK capito. Evidentemente bzImage me l'ha fatta il solo make.

 *pierino_89 wrote:*   

>  Se hai messo il wifi builtin nel kernel devi avere il firmware caricato come blob perché quando carichi il kernel il filesystem non è ancora montato, e quindi è normale che non lo riesca a trovare. Magari sei stato fortunato fino ad oggi e il filesystem è sempre stato montato prima che il kernel cercasse di caricare il firmware, ma non è un metodo consistente. L'initrd non è strettamente necessario, puoi farlo o non farlo, funziona ugualmente, non mi dilungo perché diventa una questione religiosa 

 

OK, prima lo avevo built in, ma adesso l'ho messo come modulo; per il resto devo approfondire. 

 *pierino_89 wrote:*   

>  Per aggiornare il kernel solitamente i passaggi sono: copia la configurazione, "make oldconfig", eventuale revisione con "make menuconfig/gconfig/xconfig", "make", "make modules/bzImage" se necessario, "make install", "make modules_install". In teoria "make modules" e "make bzImage" dovrebbero essere inclusi in "make" o perlomeno essere lanciati durante "make install" e "make modules_install", ma se li lanci prima ti togli il pensiero. Tanto non lo fa due volte a meno che non usi "make clean". Ovviamente se usi genkernel dovrebbe fare tutto lui, ma anche qui andiamo sul religioso.

 

mi chiedo se occorre alla fine copiare bzImage in /boot. Evidentemente no. Serviva solo alla primissima installazione di gentoo. Vero?

1000 grazie  :Very Happy: 

----------

## pierino_89

 *Hal-10000 wrote:*   

> 
> 
> mi chiedo se occorre alla fine copiare bzImage in /boot. Evidentemente no. Serviva solo alla primissima installazione di gentoo. Vero?
> 
> 1000 grazie 

 

bzImage è l'immagine del kernel, te la copia e rinomina "make install". Se preferisci rinominartela te puoi saltare make install e copiarla a mano. Sicuramente in un modo o nell'altro va fatto ogni volta   :Razz: 

----------

## Hal-10000

 *pierino_89 wrote:*   

>  *Hal-10000 wrote:*   
> 
> mi chiedo se occorre alla fine copiare bzImage in /boot. Evidentemente no. Serviva solo alla primissima installazione di gentoo. Vero?
> 
> 1000 grazie  
> ...

 

Ok capito, molto chiaro. 

ti ringrazio di nuovo   :Very Happy: 

----------

## djinnZ

 *pierino_89 wrote:*   

> religioso

   :Evil or Very Mad:  attento a quel che dici... certa gentaglia potrebbe offendersi e mandarti qualcuno ad attenderti sotto casa... e non puoi dire di non essetela andata a cercare... è gravemente offensivo attribuire ritardi nello sviluppo (il credere negli amici immaginari ed alle favole/babbo natale etc...) alla gente... soprattutto a chi già usava i computer quando tu ancora dovevi imparare a camminare (o forse, dipende dal mese, quando eri ancora in cantiere)...

Dopo le cretinate le cose serie, se il modulo è caricato automaticamente dal kernel dall'initrd il firmware devi averlo nell'initrd. Se viene caricato successivamente deve essere sul filesystem. Blob e moduli non vanno troppo d'accordo.

Dato che non è che hai molto controllo sui moduli inclusi nell'initrd (ed in questo genkernel è una emerita cagata visto che non è per niente d'aiuto) e l'autoload non è una scienza esatta... melius abbundare quam deficere.

Non è proprio un caso...

E con uefi l'immagine integrata dovrà diventare un'abitudine.

Quanto al passaggio di versione, premesso che è bene oltre al canonico emerge sys-kernel/vattelappesca è bene anche un emerge -n =sys-kernel/vattelappesca-versione una volta che si è adottato un kernel in via stabile, tanto per non trovarselo piallato alla prima occasione, se è un banale 3.17.1 a 3.17.2 mi arrischio ad un genkernel --menuconfig --kernel-config=/etc/kernel/vattelappesca-3.17.1 all ma se passo da un 3.12.x ad un 3.17.x ... prima lancio sempre un 

```
cp /etc/kernel/vattelappesca /usr/src/linux/.confg

make listnewconfig | less
```

 per andare a vedere non solo quali sono le nuove opzioni ma anche quali sono le dipendenze.

da notare che mentre con oldonfig la tendenza è ad aggiungere e conservare (ovvero se una opzione richiede una dipendenza vengono attivate entrambe) con menuconfig è l'opposto (se una opzione è necessaria viene disattivata anche quella che la richiede).

----------

## pierino_89

 *djinnZ wrote:*   

>  attento a quel che dici... certa gentaglia potrebbe offendersi e mandarti qualcuno ad attenderti sotto casa... e non puoi dire di non essetela andata a cercare... è gravemente offensivo attribuire ritardi nello sviluppo (il credere negli amici immaginari ed alle favole/babbo natale etc...) alla gente... soprattutto a chi già usava i computer quando tu ancora dovevi imparare a camminare (o forse, dipende dal mese, quando eri ancora in cantiere)...

 

Lungi da me l'attribuirlo, sarebbe stato un'offesa per ambo le parti  :Laughing: 

----------

## djinnZ

Troppo tardi...  :Twisted Evil:  Ho già fornitpo il tuo recapito ad un conoscente che verrà a trovarti ... e scoprirai a tue spese quanto vigorosamente la "forza" scorre in quell'uomo... [risata satanica in stile dr. Zero, per chi rimembra fantaman]

@Hal-10000: vista la situazione ti converrebbe impostare il driver builtin con il blob e, se includi rfkill nel kernel, disabilitare l'hardlock.  :Wink:  me ne ero dimenticato.

----------

## Hal-10000

ciao djinnZ, potresti dirmi per favore, sia pure molto succintamente, a cosa servono  questi comandi che hai menzionato a proposito del cambio di versione del kernel?

 *djinnZ wrote:*   

> ... Quanto al passaggio di versione, premesso che è bene oltre al canonico emerge sys-kernel/vattelappesca è bene anche un emerge -n =sys-kernel/vattelappesca-versione ...

  mi interessa sapere solo il secondo emerge, cioe' "emerge -n ..." a cosa serve?

poi:

 *djinnZ wrote:*   

>  ... se è un banale 3.17.1 a 3.17.2 mi arrischio ad un genkernel --menuconfig --kernel-config=/etc/kernel/vattelappesca-3.17.1 all ...

 

questo e' un unico comando? 

Non so se possa funzionare da me, visto che in /etc/kernel non ho quasi nulla:

```
 /etc/kernel $ ls -al

totale 12

drwxr-xr-x   3 root root 4096 13 dic  2012 .

drwxr-xr-x 100 root root 4096  5 feb 08.19 ..

drwxr-xr-x   2 root root 4096 28 set 13.16 postinst.d

```

lo stesso dubbio (in /etc/kernel non ho nulla) per l'altro comando nel caso di "salto di versione":

 *djinnZ wrote:*   

>  ... ma se passo da un 3.12.x ad un 3.17.x ... prima lancio sempre un 
> 
> ```
> cp /etc/kernel/vattelappesca /usr/src/linux/.confg
> 
> ...

 

grazie

----------

## Hal-10000

 *djinnZ wrote:*   

> @Hal-10000: vista la situazione ti converrebbe impostare il driver builtin con il blob e, se includi rfkill nel kernel, disabilitare l'hardlock.  me ne ero dimenticato.

 

perdonami, ma non so cosa significa impostare " il blob" quando rendo il driver built in;

come pure non ho capito " se includi rfkill nel kernel, disabilitare l'hardlock."

Abbi pazienza  :Laughing: 

Grazie

----------

## djinnZ

Non sai cosa è un firmware blob ma ti impegoli nella compilazione manuale certo che questo sia saper compilare il kernel... poi dite che sono tedioso con questa storia di genkernel.

Non è solo perché è da idioti ripetere sempre la stessa sfilza di comandi quando ne basta uno ma perché il niubbo viene illuso di saper fare e si concentra su cavolate (ma sembra tanto eroico fare una sfilza di make... poi non fanno bene quelli di debian a prenderci per i fondelli... come per la faccenda dei log di default di emerge...) senza approfondire i veri problemi della configurazione penando alla compilazione.

Comunque... tanto per farla breve genkernel genera in automatico copia della configurazione andata a buon fine in /etc/kernels.

Quando arriva un nuovo kernel con --kernnel-config vado a riprendere un file di configurazione specifico invece di usare quello predefinito di genkernel.

Oppure copio alla vecchia maniera su /usr/src/linux/.config, configuro manualmente (se ho da lanciare listnewconfig) e compilo con genkernel --noclean all. (o puoi disabilitarlo direttamente, qui è questione di preferenze personali)

Il primo emerge aggiunge sys-kernel/vattelappesca a world ed è quanto indicato nella guida per l'installazione (bada bene per l'installazione non per la configurazione e manutenzione). Questo fa si che l'ultima versione stabile o l'ultima disponibile siano automaticamente installate ma l'autoclean dovrebbe piallare le vecchie quindi rischi di ritrovarti senza i sorgenti del kernel che usi e che, nel frattempo, potrebbe essere stato rimosso da portage.

Per evitare le bestemmie, quando decidi che un kernel ti sta bene e lo usi stabilmente, lanci emerge -n =sys-kernel/vattelappesca-versione di modo che la versione specifica viene aggiunta a portage ed anche un maldestro depclean non lo rimuove e, q7uando viene rimosso, avrai un warn da emerge che ti informarà del fatto che è stato rimosso dall'albero di portage. Quando arriva il momento di fare le pulizie di primavera lanci un emerge -C per la versione che non ti interessa più e pialli lib/modules, l'immagine e quant'altro.

A parte il configurare a manina o no, ti consiglio (leggere: ti intimo) di usare genkernel per compilare (e va configurato) badando ad impostare una compressione adeguata (ripulendo poi la configurazione del kernel dai metodi di compressione inutili), l'initrd integrato, disabilitare i supporti lvm & C se non ti servono od abilitando ad esempio mdadm (con copia del file conf che non fa mai male) etc.

Tutte cose già ripetute sino alla noia. Cerca i miei vecchi interventi. E leggi la documentazione di genkernel e quello che c'è nel file di configurazione.

Fatto questo inizia a concentrarti sulla vera configurazione del kernel. Come impostare l'rcu, come impostare la linea di comando etc.

Nel riportare elementi di configurazione del kernel uso direttamente la variabile, basta digitare "/" in menuconfig per avere l'help ed andarla a trovare. Invece che riportare come imbecilli tutto il percorso (che può cambiare).

In ogni caso il mio suggerimento è impostare nella conf del kernel

CONFIG_CMDLINE_BOOL=y

CONFIG_CMDLINE="rfkill.master_switch_mode=2" (se hai rfkill, altrimenti te ne puoi fregare)

e

CONFIG_EXTRA_FIRMWARE="rtlwifi/rtl8712u.bin" (verifica, non sono sicuro del percorso)

CONFIG_EXTRA_FIRMWARE_DIR="/lib64/firmware" (tanto per accorciare il pathname se includi più blob, ad esempio i firmware per ATI/Nvidia open)

E concentrati sulla configurazione effettiva. Non sulle cretinate.

Attenzione che CONFIG_INITRAMFS_SOURCE deve essere vuoto quando esci dal menuconfig. Poi è genkernel che lo inserisce in automatico in .config (solo se non è già valorizzato)

----------

## Hal-10000

@djinnZ: grazie per la spiegazione. Genkernel non l'ho mai usato, ma visto il tuo consiglio (intimazione), proverò a farlo, anche se ciò richiederà qualche ulteriore approfondimento dato che le opzioni e le flag che si possono impostare nell'unico comando di genkernel sono numerose e bisogna sceglierle con cura.

Tornando al meno importante discorso del "firmware blob", credo (correggetemi se sbaglio) che si tratti di un driver binario proprietario, e dunque closed e non open source, http://en.wikipedia.org/wiki/Binary_blob.

Nel mio caso è proprio questo: rtl8712u.bin che, se ho capito bene, risulta impostato (come modulo, mentre prima lo avevo built in) perchè ho questa riga nella configurazione del kernel: 

```
<M>   RealTek RTL8712U (RTL8192SU) Wireless LAN NIC driver 
```

 E' così?

Però non ho ben capito:

pierino_89 quando dici:  

"Se hai messo il wifi builtin nel kernel devi avere il firmware caricato come blob perché quando carichi il kernel il filesystem non è ancora montato, e quindi è normale che non lo riesca a trovare."

@djinnZ quando dici:

"se il modulo è caricato automaticamente dal kernel dall'initrd il firmware devi averlo nell'initrd. Se viene caricato successivamente deve essere sul filesystem. Blob e moduli non vanno troppo d'accordo."

Vi sarei grato se mi vorrete dare qualche piccolo chiarimento in proposito (lo so, mi mancano le basi, ma magari qualcosina la posso imparare)

P.S.: 

@djinnZ: Ignorare cosa sia un "firmware blob", per chi, profano della materia, si è avvicinato a Gentoo non per professione, ma solo per divertimento, non mi sembra così grave, nè mi devo sentire in imbarazzo nel chiedere qualche spiegazione sul forum. Inoltre, non presumo affatto di sapere compilare il kernel manualmente, nè tantomeno sono "certo" di saperlo fare. Magari lo fossi - :Smile:  Comunque ti ringrazio ancora per le spiegazioni.

----------

## pierino_89

Stai facendo un casino   :Razz: . Il firmware (blob) è un file che sta in /lib/firmware/ ed è una parte aggiuntiva necessaria per il funzionamento del modulo.

Il modulo invece è un file *.ko che sta in /lib/modules.

Il file del firmware è dunque necessario per il funzionamento della tua realtek, sia che sia stata messa builtin che sia compilata come modulo.

SE BUILTIN:

è fondamentale che il firmware sia incluso all'interno del kernel (nella bzImage), in quel caso non te ne frega più niente di averlo in /lib/firmware o di quando venga montata, perché ormai ce l'ha già dentro. È fondamentale perché, come ti dicevo prima, non sai se verrà prima montato / o cercato il firmware. Può andarti bene oppure no.

SE MODULO:

A seconda di quando il modulo viene caricato, il firmware devi averlo come file nell'initramfs (se il modulo viene caricato prima che venga montato /) o in /lib/firmware. Nel tuo caso bastava metterlo come modulo (mi pare funzionasse) perché il wifi non mi pare sia previsto al boot, ma piuttosto caricato poi da udev o proprio da /etc/conf.d/modules.

Infine, "rfkill" è banalmente il sistema per attivare e disattivare wifi/bluetooth/robe varie con i vari switch che trovi sui portatili. Se non stai usando un portatile, probabilmente non ti serve a niente.

----------

## djinnZ

@pierino_89: rfkill non ricordo per quale ragione tende a creare rogne con i driver realtek e nel momento in cui disabiliti l'interfaccia (ifconfig xxx down) capita che si attivi l'hardlock, anche per un banale /etc/init.d/net.vattelappesca restart.

Quindi o trovi un modo per lanciare rfkill con privilegi di root prima di ifconfig (devi stravolgere openrc) nello script o disabiliti l'hardlock automatico.

A seconda delle versioni del kernel questo problema appare e scompare (e non per tutte le schede).

@Hal-10000: Grazie a questa idiozia del compilare manualmente uno come te (relativamente alle prime armi, quindi) perde tempo a capire come lanciare una sequenza di comandi di dubbia utilità, a cercare opzioni per ottimizzare la compilazione e riceve nel riuscirci una falsa convinzione di aver fatto progressi invece di concentrarsi sulle opzioni da inserire in menuconfig che fanno, invece, realmente la differenza.

Prova a limitare le allocazioni per rcu, impostare i cgroups builtin, ripulire le opzioni inutili per debugging e tracing etc. e vedrai maggiori benefici del compilare con -march=native il kernel.

Dico solo che il pubblicizzare l'uso della compilazione manuale è "diseducativo" perché ti conduce a limitarti. Visto che usi linux per divertimento meglio non darti illusioni e non farti perder tempo (limitato, a meno che non sei un vecchiardo nullafacente e senza pensieri come l'ex presidente od il suo dominus ancora in parlamento) dietro a cose inutili. E perdi tempo a ripetere sempre sempre le stesse sequenze. Questa è la mia modesta opinione.

Non ce l'ho con te ma con la guida che è fuorviante in materia.

Il firmware di cui stiamo parlando può essere di tutto, il driver semi-propietario  come nel caso delle schede grafiche ATI/Nvidia/intel, le "voci" per il midi nelle schede audio soundblaster, il codice (eseguito dal processore della scheda non dalla cpu) per il raid (su alcuni controller), le impostazioni video invece di scaricarle dal device etc.

Alcuni moduli lo richiedono. Quindi quando viene inizializzato l'hardware va caricato anche il firmware in memoria (o meglio è parte dell'inizializzazione).

Il problema è che alcuni moduli inizializzano l'hardware all'atto del caricamento (del kernel o del modulo) altri no. Per i primi se sono builtin è meglio che il modulo sia già disponibile, anche prima dell'accesso all'initrd e per questo, nel dubbio, è sempre bene inserirli nel kernel come blob, così eviti di lambiccarti.

Di contro alcune volte capita che caricando un modulo il loader del firmware ignori il blob e cerchi solo nel filesystem da cui carica il modulo. Quindi, quando sono moduli... meglio che il firmware sia anche lui nell'initrd o nel filesystem.

Se lo piazzi ovunque... non ti poni altro problema che perdere qualche millisecondo per caricare un kernel ed un initrd leggermente più grandi ma non ti devi sforzare a capire dove metterli se ricompili per cambiare un driver da modulare a builtin e viceversa.

----------

