# Patch pacchetto LIRC in Portage

## UnoSD

Salve a tutti!

Sto cercando di compilare lirc tramite portage; mi da un errore così sono andato a controllare il build.log.

Ho scoperto navigando che è una funzione che va sostituita (__this_cpu_read(cpu.info.loops_per_jiffy) al posto di current_cpu_data.loops_per_jiffy) https://lkml.org/lkml/2010/12/8/128

Come faccio a sostituirla? Come posso applicare una patch ad un sorgente nei repository?

P.s. Ovviamente se qualcuno ha un'altra soluzione decente per far installare lirc è decisamente ben accetta!!

Grazie.

----------

## k01

smaschera e installa la versione testing se in quella l'hanno risolto, altrimenti dovresti creare un overlay locale

----------

## cloc3

io non ho problemi con lirc-0.9.0.

cerca di documentare meglio il tuo problema, indicando la versione dell'ebuild e postando il taglia-incolla di quelle parti dei log che ritieni significative.

per patchare un ebuild al volo, dovrebbe essere suffiicente creare un file nel percorso: 

```
/etc/portage/patches/<categoria>/<pacchetto>[-<versione>]/nomeACaso.patch
```

nel caso particolare di lirc, ho osservato che non funziona, perché l'ebuild è scritto in un modo strano.

per aggirare il problema, ho aggiunto uan chiamata ad epatch_user prima della chiamata ad autoreconf:

```

s939 lirc # pwd

/usr/local/portage/app-misc/lirc

s939 lirc # diff lirc-0.9.0.ebuild lirc-0.9.0-r1.ebuild -u

--- lirc-0.9.0.ebuild   2011-07-03 10:40:02.215461052 +0200

+++ lirc-0.9.0-r1.ebuild   2011-07-03 10:49:50.370461264 +0200

@@ -278,6 +278,7 @@

    done

    echo "#define LIRC_DRIVER_DEVICE \"${LIRC_DRIVER_DEVICE}\"" >> acconfig.h

 

+   epatch_user

    eautoreconf

 }

 

```

----------

## UnoSD

Grazie delle risposte!

Adesso provo il discorso della patch!

Vero che non c'è tutto sto rischio, ma preferisco installare solo i pacchetti stable.

----------

## cloc3

 *UnoSD wrote:*   

> 
> 
> Vero che non c'è tutto sto rischio, ma preferisco installare solo i pacchetti stable.

 

è una politica comprensibile, ma non sempre funzionale.

lirc è un pacchetto che in questo momento ha uno sviluppo piuttosto rapido, sotto le spinte commerciali di un mercato senza controllo, e, comprensibilmente, è un po' al margine delle attenzioni dei nostri sviluppatori di ebuild.

probabilmente, buttarsi sulla ~ è una violazione virtuosa delle buone regole.

prima di partire, tieni sempre un occhio sul bugzilla.

----------

## UnoSD

Alla fine sono crollato sotto la mia pigrizia... 

Non sapevo bene come si creava il file della patch e dopo mezzo tentativo ho optato per mettere lirc-0.9.0...

A proposito di bugzilla, ma come mai mi dice che il certificato non è sicuro? Chromium mi chiede ogni volta conferma e mi sbarra https con una linea rossa!!

----------

## cloc3

 *UnoSD wrote:*   

> 
> 
> Non sapevo bene come si creava il file della patch e dopo mezzo tentativo ho optato per mettere lirc-0.9.0...
> 
> 

 

era ovvio. stavi cercando di fare una cosa troppo sofisticata. comunque:

```

s939 ~ # mkdir -p /etc/portage/patches/app-misc/lirc-0.9.0 prova

s939 ~ # cd prova

s939 prova # tar xjf /var/gentoo-var/distfiles/lirc-0.9.0.tar.bz2 -C .

s939 prova # echo chePatch\!>lirc-0.9.0/remotes/README

s939 prova # diff -uNr lirc-0.9.0.orig/ lirc-0.9.0/ >/etc/portage/patches/app-misc/lirc-0.9.0/chePatch.patch

```

  :Smile: 

 *UnoSD wrote:*   

> 
> 
> A proposito di bugzilla, ma come mai mi dice che il certificato non è sicuro?

 

un certificato è sicuro quando è validato da un servizio esterno di terza parte.

in questo modo sei garantito da un eventuale sito civetta che desideri intercettare la tua navigazione: il servizio di terza parte lo smascherebbe inevitabilmente, perché il sito civetta può simulare alla perfezione la pagina web, ma non duplicare il certificato ssl.

molti siti web si producono il proprio certificato a mano. In questo caso, la navigazione criptata ssl è garantita, ma la protezione dai siti civetta no.

----------

## UnoSD

Ehm, la cosa "complicata" che hai scritto è stata la prima cosa che ho fatto...

```
diff -u --recursive --new-file lirc-0.8.7/drivers/lirc_serial/lirc_serial.c lirc-0.8.7-patch/drivers/lirc_serial/lirc_serial.c

--- lirc-0.8.7/drivers/lirc_serial/lirc_serial.c   2010-08-16 22:20:47.000000000 +0200

+++ lirc-0.8.7-patch/drivers/lirc_serial/lirc_serial.c   2011-07-03 04:09:18.000000000 +0200

@@ -494,7 +494,7 @@

    duty_cycle = new_duty_cycle;

    freq = new_freq;

 

-   loops_per_sec = current_cpu_data.loops_per_jiffy;

+   loops_per_sec = __this_cpu_read(cpu.info.loops_per_jiffy);

    loops_per_sec *= HZ;

 

    /* How many clocks in a microsecond?, avoiding long long divide */

@@ -515,7 +515,7 @@

    dprintk("in init_timing_params, freq=%d, duty_cycle=%d, "

       "clk/jiffy=%ld, pulse=%ld, space=%ld, "

       "conv_us_to_clocks=%ld\n",

-      freq, duty_cycle, current_cpu_data.loops_per_jiffy,

+      freq, duty_cycle, __this_cpu_read(cpu.info.loops_per_jiffy),

       pulse_width, space_width, conv_us_to_clocks);

    return 0;

 }
```

Solo che ho provato ad applicarla e mi chiedeva il file cui applicarla, mi scocciavo di vedere il perché ed ho lasciato stare...

 *Quote:*   

> molti siti web si producono il proprio certificato a mano. In questo caso, la navigazione criptata ssl è garantita, ma la protezione dai siti civetta no.

 

Quindi Bugzilla produce il proprio certificato da solo, non è validato da un servizio esterno e quindi mi viene segnalato come potenzialmente dannoso perché non sono protetto dai siti civetta, ho capito bene?

----------

## ago

 *UnoSD wrote:*   

> Quindi Bugzilla produce il proprio certificato da solo, non è validato da un servizio esterno e quindi mi viene segnalato come potenzialmente dannoso perché non sono protetto dai siti civetta, ho capito bene?

 

Lascia stare le civette  :Very Happy: 

Il certificato non è stato controllato da nessuno, quindi vedi il warning. =)

----------

## UnoSD

Ok, grazie  :Smile: 

Cmq come faccio a far funzionare la patch? (ormai ho installato la 0.9.0 ma sono curioso e potrebbe servirmi in futuro... poi così posso pure mettere: RISOLTO!)

Altro "problema": Ho messo il modulo di lirc_serial nel kernel ma questo richiede prima che venga disattivata la uart della rs-232, come posso fare a farlo prima che parta lirc_serial? (senza compilarlo come modulo)

```
   [    2.482172] lirc_serial: port 03f8 already in use

   [    2.482172] lirc_serial: use 'setserial /dev/ttySX uart none'

   [    2.482173] lirc_serial: or compile the serial port driver as module and

   [    2.482174] lirc_serial: make sure this module is loaded first
```

E poi una piccola cosa o.t. per cui non credo valga la pena di aprire un'intera discussione: Come si fa ad avviare un binario da un'altra cartella?? Ho provato PWD=/nuovacartella gedit, bash -c 'export PWD=/nuovacartella; gedit' ma nulla sembra intaccare la directory in cui crede di essere gedit!! Pensa sempre di essere da dove l'ho lanciato!

----------

## ago

 *UnoSD wrote:*   

> Cmq come faccio a far funzionare la patch? (ormai ho installato la 0.9.0 ma sono curioso e potrebbe servirmi in futuro... poi così posso pure mettere: RISOLTO!)

 

Devi usare epatch in src_prepare, maggiori informazioni sul devmanual o sui $( eix --only-names | wc -l ) ebuild  :Wink: 

 *UnoSD wrote:*   

> E poi una piccola cosa o.t. per cui non credo valga la pena di aprire un'intera discussione

 

Vale la pena  :Very Happy: 

----------

## UnoSD

Ti ringrazio, ci darò un'occhiata appena ho finito di fare un po' di sistemazioni più importanti sulla nuova installazione di Gentoo!

Ok, per l'altra cosa apro una discussione  :Smile:  Ma non ne starò aprendo troppe?

----------

## cloc3

 *UnoSD wrote:*   

> 
> 
> Cmq come faccio a far funzionare la patch? (ormai ho installato la 0.9.0 ma sono curioso e potrebbe servirmi in futuro... poi così posso pure mettere: RISOLTO!)
> 
> 

 

ho voluto a creare la tua stessa patch e a compilare lirc-0.8.7 con il metodo che ti ho illustrato ed ha funzionato.

(si fa per dire: la compilazione è fallita sul file lirc_serial.c, ma la patch è stata installata a dovere).

il vantaggio, rispetto all'uso di epatch è che non sei costretto a chiamare ebuild pacchetto manifest ogni volta che fai una modifica alla cartella <pacchetto>/files

inoltre, quell'ebuild di lirc è proprio strano, perché chiama autoreconf nella fase di src_unpack, che precede src_prepare.

mi sa che, se usi epatch nel modo corretto, succede un pasticcio.

@ago: è corretto scrivere gli ebuild in questo modo?

o sarebbe il caso di segnalare la cosa su bugzilla?

----------

## UnoSD

E cos'altro è fallito in lirc_serial.c oltre a quello?

----------

## cloc3

 *UnoSD wrote:*   

> E cos'altro è fallito in lirc_serial.c oltre a quello?

 http://pastebin.com/WH6BfjYN

----------

## ago

 *cloc3 wrote:*   

> @ago: è corretto scrivere gli ebuild in questo modo?
> 
> o sarebbe il caso di segnalare la cosa su bugzilla?

 

Dovrebbe essere possibile perché li viene usato EAPI 0, certo fare un porting ad EAPI 4, non sarebbe male  :Wink: 

----------

## UnoSD

Potresti mettere su pastebin il build.log? Da lì non si vede che errore specifico è...

 *Quote:*   

> Dovrebbe essere possibile perché li viene usato EAPI 0, certo fare un porting ad EAPI 4, non sarebbe male 

 

Eeeeh???

----------

## ago

 *UnoSD wrote:*   

> Potresti mettere su pastebin il build.log? Da lì non si vede che errore specifico è...

 

build.log su pastebin

 *Quote:*   

> Dovrebbe essere possibile perché li viene usato EAPI 0, certo fare un porting ad EAPI 4, non sarebbe male 

 

 *UnoSD wrote:*   

> Eeeeh???

 

si tratta di sintassi pe scrivere ebuild, nulla di più

----------

## UnoSD

 *ago wrote:*   

> build.log su pastebin

 

Questo non è l'output di emerge?

 *Quote:*   

> si tratta di sintassi pe scrivere ebuild, nulla di più

 

Grazie  :Smile: 

----------

## ago

 *UnoSD wrote:*   

> Questo non è l'output di emerge?

 

Tu cosa intendi per build.log?

----------

## UnoSD

 *ago wrote:*   

> Tu cosa intendi per build.log?

 

```
The complete build log is located at '/var/log/portage/app-misc:lirc-0.8.7:20110703-160558.log'.
```

A me lo chiamava /var/log/portage/app-misc/lirc-0.8.7/build.log ma comunque è quello... In emerge non ti dice niente riguardo agli errori nel codice...

----------

## cloc3

 *UnoSD wrote:*   

> ma comunque è quello... In emerge non ti dice niente riguardo agli errori nel codice...

 

probabilmente, togliendo la FEATURES -s dal make.conf, puoi ottenere un output verboso.

ma questo è compito tuo.

io ho fatto solo una prova per testare ciò che dicevo sulla patch on the fly.

se a te non funziona ancora, chiedi nuovi chiarimenti,  ma più in là non ti posso seguire.

----------

## UnoSD

 *cloc3 wrote:*   

> io ho fatto solo una prova per testare ciò che dicevo sulla patch on the fly.
> 
> se a te non funziona ancora, chiedi nuovi chiarimenti,  ma più in là non ti posso seguire.

 

Si ma se non so che errore ti da non so se la patch ha funzionato e se ha funzionato se ci sono altri problemi dopo... Il log dovrebbe essere ancora lì a meno di funzioni di "pulizia".

Cmq ovviamente non voglio farti perdere tempo, se non vuoi metterlo non fa niente!

----------

## UnoSD

Il driver lirc_serial, se integrato nel kernel (non come modulo) mi da quest'errore:

```
   [    2.482172] lirc_serial: port 03f8 already in use

   [    2.482172] lirc_serial: use 'setserial /dev/ttySX uart none'

   [    2.482173] lirc_serial: or compile the serial port driver as module and

   [    2.482174] lirc_serial: make sure this module is loaded first
```

E se do il comando per disattivare la uart dopo comunque non funziona, devo per forza compilarlo come modulo???

Perché dare la possibilità di integrarlo nel kernel se poi non si può disattivare la uart prima? C'è un modo per farlo?

----------

## cloc3

 *UnoSD wrote:*   

> 
> 
> Perché dare la possibilità di integrarlo nel kernel 

 

tutti i moduli, indistintamente, possono essere integrati nel kernel o predisposti per il caricamento al volo.

se per caso un modulo implica, per il proprio funzionamento, l'attivazione di qualche software in userspace, capita che compilarlo built-in non funzioni.

tieni conto che il kernel linux comincia ad avere un'espansione smisurata e che il rischio di interazioni improprie tra moduli secondari diventa ogni giorno più concreta. un po' come accade a windows dai primordi.

----------

## UnoSD

Quindi non c'è un modo di avviare setserial prima?

----------

## UnoSD

Ok, sto cominciando a pensare di tornare a Fedora solo per la frustrazione che mi da cercare di mettere lirc!

Non c'è verso, la vecchia versione non riesco a patcharla (0.8.7), la nuova si installa e sembra andare bene (però a differenza della vecchia non sembra provare a compilarsi da sola lirc_serial quindi lo faccio a parte direttamente dal kernel)

Quando carico il modulo lirc_serial mi dice:

```
insmod /lib/modules/2.6.38-gentoo-r6-unosd/misc/lirc_dev.ko 

WARNING: Error inserting lirc_dev (/lib/modules/2.6.38-gentoo-r6-unosd/misc/lirc_dev.ko): Invalid module format

FATAL: Error inserting lirc_serial (/lib/modules/2.6.38-gentoo-r6-unosd/misc/lirc_serial.ko): Invalid module format
```

Aiutatemi!!

P.s.

dmesg mi dice:

```
lirc_dev: exports duplicate symbol lirc_dev_fop_write (owned by kernel)
```

----------

## cloc3

 *UnoSD wrote:*   

> 
> 
> dmesg mi dice:
> 
> ```
> ...

 

ma tu credi che qui siamo una squadra di capoccioni che ribaldano il codice del kernel ogni cinque minuti?

quello che stai facendo è affascinante, e piuttosto incompatibile con lo spirito di fedora, che è una distribuzione di binari, meno versata di mamma gentoo ad assisterti nell'applicazione delle patch.

ma allo stesso tempo la tua non è una strada facile, perché pretendi di mettere mano a qualche cosa che trascende i compiti stessi di una metadistribuzione. naturalmente, se nessuno lo ha già fatto, faresti benissimo ad aprire un baco su bugzilla, far notare che la 0.8.7, nominalmente, è stabile, ma non funziona un ciucca e che sarebbe il caso di stabilizzare la 0.9.0, scrivendola magari con uno stile pià adatto (EAPI 4, diceva ago).

fai bene attenzione di non farti cogliere in fallo in questioni di FAQ.

 :Rolling Eyes: 

----------

## ago

 *cloc3 wrote:*   

> e che sarebbe il caso di stabilizzare la 0.9.0, scrivendola magari con uno stile pià adatto (EAPI 4, diceva ago).

 

Ci sono anche dei bug per la 0.9.0 ad ogni modo a me la stabile compila =)

----------

## UnoSD

 *cloc3 wrote:*   

> ma tu credi che qui siamo una squadra di capoccioni che ribaldano il codice del kernel ogni cinque minuti?

 

Non ho ben compreso cosa intendi... (Comunque credevo che in questo forum ci fossero anche sviluppatori!)

```
quello che stai facendo è affascinante, e piuttosto incompatibile con lo spirito di fedora, che è una distribuzione di binari, meno versata di mamma gentoo ad assisterti nell'applicazione delle patch.

ma allo stesso tempo la tua non è una strada facile, perché pretendi di mettere mano a qualche cosa che trascende i compiti stessi di una metadistribuzione. naturalmente, se nessuno lo ha già fatto, faresti benissimo ad aprire un baco su bugzilla, far notare che la 0.8.7, nominalmente, è stabile, ma non funziona un ciucca e che sarebbe il caso di stabilizzare la 0.9.0, scrivendola magari con uno stile pià adatto (EAPI 4, diceva ago).
```

Mi spiace dirlo di nuovo ma non ho capito nemmeno bene cosa intendi ora... Io cosa sto facendo di tanto "trascendentale"? Pensavo di star operando come un'utente medio di Gentoo a differenza di un utente per distribuzioni più semplici. (per esempio di Ubuntu, Fedora, ecc...)

 *Quote:*   

> fai bene attenzione di non farti cogliere in fallo in questioni di FAQ

 

Ho visto, non c'è scritto molto.

Sinceramente sono uno cui piace fare le cose pulite e per bene, avrei voluto una distribuzione "perfetta" e perfettamente in linea con le mie esigenze (cosa che Gentoo favorisce a differenza di altre); ma arrivato a questo punto di esasperazione mi accontenterei anche di un pacchetto binario funzionante per lirc compilato per 32bit per non scocciare più voi e non intossicare me a furia di cercare di farlo a modo mio secondo ogni più piccolo dettaglio che voglio decidere; ma ora come ora si tratta più di una questione pratica, non di un capriccio per avere la perfezione: mi serve lirc funzionante!!

Visto che sono nuovo al mondo Gentoo e Portage, non so bene come affrontare queste questioni!

Su Fedora se un pacchetto non funzionava, scaricavo i sorgenti. Se i sorgenti davano problemi di compilazione, cercavo problemi simili su internet. Se non trovavo niente mettevo direttamente mano al codice e modificavo in maniera "rozza" il problema che leggevo nei log di make... Ora però, dato che Portage agisce direttamente sui sorgenti, non mi sembra il caso di scaricare il pacchetto di lirc a parte e farlo andare, ma non so come agire su Portage! Per questo vi sto massacrando di post! Spero così di imparare qualcosa e dopo essere io stesso ad aiutare gli altri che hanno problemi!

P.s.

Ovviamente, prima di postare sul forum cerco sempre su Google per evitare di martellarvi. Ma quando non è facile trovare risposte allora chiedo ad esseri umani in carne ed ossa!

----------

## ago

IN qualche modo ti stiamo solo dicendo di distinguere i problemi da forum con quelli da bugzilla =)

----------

## UnoSD

 *ago wrote:*   

> IN qualche modo ti stiamo solo dicendo di distinguere i problemi da forum con quelli da bugzilla =)

 

Infatti non so distiguerli!! Non ho mai usato Bugzilla se non passivamente (per leggere le segnalazioni degli altri)!

Modifica:

Non c'è una qualche "guida" che suggerisce il limite del problema da forum?

Poi non mi ha risposto nessuno lì ma volevo chiedere: Tra le regole del forum, c'è un limite di topic quotidiano? Io sto continuando a fare nuove richieste perché ho mille domande ma non vorrei fosse "esagerato" aprire tutte queste discussioni...

----------

## cloc3

 *UnoSD wrote:*   

> 
> 
> Infatti non so distiguerli!! 

 

niente paura. scusa se sono stato brusco.

più che altro, ho l'impressione che tu sia un po' incerto con l'inglese (è un complimento: l'uso smodato delle lingue proprietarie non è necessariamente una virtù  :Smile:  ). la faq che ti ho postato spiega che la 0.8.7 non funziona con kernel recenti.

quindi il problema sta nel codice sorgente (in inglese: upstream), non nell'ebuild gentoo. se vai su bugzilla a postare il tuo problema in questo modo, ti rispondono di usare un kernel precedente o di passare alla 0.9.0. se invece tu facessi presente che un ebuild scritto bene dovrebbe riconoscere un kernel sbagliato e dovrebbe usare un EAPI attuale, allora porteresti un contributo utile che sarebbe sicuramente ascoltato da tutti.

----------

## UnoSD

 *cloc3 wrote:*   

> niente paura. scusa se sono stato brusco.

 

Figurati! Sono abituato a forum in cui la gente non è brusca ma maleducata... Ed io preferisco di gran lunga la schiettezza alla maleducazione!

 *Quote:*   

> più che altro, ho l'impressione che tu sia un po' incerto con l'inglese. la faq che ti ho postato spiega che la 0.8.7 non funziona con kernel recenti.

 

Sono madrelingua... (Nel senso che ho il CEF C2)

Però in compenso devo dire che sono pigro e ho letto quasi solo i titoli... (Scusa! XD Ora lo leggo meglio...)

 *Quote:*   

> se vai su bugzilla a postare il tuo problema in questo modo, ti rispondono di usare un kernel precedente o di passare alla 0.9.0. se invece tu facessi presente che un ebuild scritto bene dovrebbe riconoscere un kernel sbagliato e dovrebbe usare un EAPI attuale, allora porteresti un contributo utile che sarebbe sicuramente ascoltato da tutti.

 

Allora lo farò ma io sto provando la versione 0.9.0 e comunque non funziona!!

Cioè, più che altro il problema qui non è di lirc ma del modulo del kernel lirc_serial (che a quanto pare non è parte di lirc ma proprio del kernel) che non viene compilato bene visto che mi dice "Invalid module format"...

Cmq devo dire che mi piace questo forum! (Tranne per il fatto che nessuno mi dice se posso aprire altri topic o c'è qualche regola che vieta di farne troppi al giorno!)

Modifica:

Ecco, io avevo letto questo: lirc-0.8.7 has been tested with kernel versions up to 2.6.35. Older versions should also work. 2.4.x kernels are not supported anymore. E pensavo riguardasse solo come fare per i kernel 2.4 quindi ho smesso di leggerlo...

----------

## ago

 *UnoSD wrote:*   

> Infatti non so distiguerli!! Non ho mai usato Bugzilla se non passivamente (per leggere le segnalazioni degli altri)!

 

Come già detto da cloc, niente paura. Il forum serve per aiuti personali, quando non arrivi a fare un qualcosa. IL bugzilla è più per segnalare problemi che stanno a monte, tipo errori negli ebuild, errori in fase di compilazione che non dipendono da fail(s) locali ecc ecc.

----------

## UnoSD

Chiedo una piccola cosa OT:

Visto che ho mille piccole domande, posso aprire un topic con tante piccole domande oppure devo per forza farli separati?

(Mi rispondono se magari le faccio su irc?)

----------

## cloc3

 *UnoSD wrote:*   

> 
> 
> Sono madrelingua...

 

 :Shocked:  hack, era una spia....

 *UnoSD wrote:*   

>  ma del modulo del kernel lirc_serial
> 
> 

 

la tua analisi è chiara. non centrea l'ebuild, ma il sorgente del kernel.

forse c'è stato qualche problema nella compilazione. salva il tuo .config, lancia un make mrproper, cancella la /lib/modules/<versione> e ricompila.

sostitituisci il nuovo bzImage. così vedi quello che succede.

ricompila anche lirc, giusto per completezza.

io sto usando lirc con moduli diversi e a me funziona. cerca anche in rete altre campane.

 *UnoSD wrote:*   

> Tranne per il fatto che nessuno mi dice se posso aprire altri topic 
> 
> 

 

sotto il profilo della correttezza, questo forum è un mortuorio.

i nostri moderatori sono schizzati dalla noia da tempo immemore e ripassano giusto a pasqua e natale per fare una pisciatina di fretta.

da qualche parte esistono le linee guida. la regola madre sarebbe di aprire un nuovo topic per singolo argomento.

il fatto che, per te, fino ad ora, le cose si sono succedute in un modo abbastanza spontaneo e nessuno si è preso l'onere di fare il farmacista.

----------

## UnoSD

 *cloc3 wrote:*   

>  hack, era una spia....

 

XD

 *Quote:*   

> la tua analisi è chiara. non centrea l'ebuild, ma il sorgente del kernel.
> 
> forse c'è stato qualche problema nella compilazione. salva il tuo .config, lancia un make mrproper, cancella la /lib/modules/<versione> e ricompila.
> 
> sostitituisci il nuovo bzImage. così vedi quello che succede.

 

Cosa fare make mrproper? Vabbè, do' un'occhiata all'help, lo faccio però più tardi; a spezzare la mia nerdaggine è venuta la mia ragazza (che per inciso non mi ha ancora lasciato nonostante Gentoo XD)

 *Quote:*   

> cerca anche in rete altre campane.

 

Campane?

 *Quote:*   

> sotto il profilo della correttezza, questo forum è un mortuorio.
> 
> i nostri moderatori sono schizzati dalla noia da tempo immemore e ripassano giusto a pasqua e natale per fare una pisciatina di fretta.
> 
> da qualche parte esistono le linee guida. la regola madre sarebbe di aprire un nuovo topic per singolo argomento.
> ...

 

Hehe, allora ne approfitto XD

----------

## cloc3

 *UnoSD wrote:*   

>  per inciso non mi ha ancora lasciato

 

uh. di certo te ne sei cercata una brutta.

----------

## UnoSD

 *cloc3 wrote:*   

>  *UnoSD wrote:*    per inciso non mi ha ancora lasciato 
> 
> uh. di certo te ne sei cercata una brutta.

 

Stranamente no! Dev'essere una di quelle cui piacciono i nerd! XD

Vabbè dai, in realtà sono solo un nerd part-time!

----------

## UnoSD

Sentite, io mi rifiuto di crederci...

Ho cancellato i moduli nella cartella di quelli compilati.

Ho rifatto make modules_install.

E va!!!!!!!!!!!!!!!

Non posso credere ad una cosa così assurda e stupida... Ma è mai possibile che make modules_install non cancella quelli vecchi?? Devo dare sempre prima un make modules_clean o qualcosa di simile?

Funziona e sono contento (anche se non capisco perché non andasse prima) ma comunque sono molto frustrato...

----------

## cloc3

 *UnoSD wrote:*   

> 
> 
> E va!!!!!!!!!!!!!!!
> 
> 

 

 :Very Happy: 

qualche volta, per problemi di simboli, basta un semplice depmod.

ma è difficile prevderlo. anche perché ci possono essere interferenze di moduli esterni che sporcano la situzione.

per questo ho preferito consigliarti una pulizia generale.

qui una discussione recente sul tema.

----------

## UnoSD

Ma è normale che non sovrascriva i moduli vecchi??

Devo fare make clean forse?

----------

## ago

 *UnoSD wrote:*   

> Devo fare make clean forse?

 

 *Quote:*   

> Cleaning targets:
> 
>   clean           - Remove most generated files but keep the config and
> 
>                     enough build support to build external modules

 

----------

## UnoSD

Ma make clean non li rimuove solo dalla cartella dei sorgenti??

A me servirebbe forse più qualcosa tipo: make uninstall... Che i moduli da "ripulire" sono già stati installati nelle cartelle...

----------

## ago

 *UnoSD wrote:*   

> Ma make clean non li rimuove solo dalla cartella dei sorgenti??
> 
> A me servirebbe forse più qualcosa tipo: make uninstall... Che i moduli da "ripulire" sono già stati installati nelle cartelle...

 

Appunto, ti ho citato il manuale, hai detto che sei madrelingua inglese  :Razz: 

a te serve un rm -fr =)

----------

## UnoSD

Remove most generated files but keep the config and 

enough build support to build external modules -> Rimuove la maggior parte dei file generati ma mantiene la configurazione e un supporto per compilare i moduli esterni.

Quindi deduco che non vada bene! Quindi deduco che l'unico modo è cancellarli a mano?

----------

## ago

se devi cancellare a mano i moduli devi rimuoverli manualmente in /lib/modules/$uname -r/

----------

## UnoSD

Posso dare un bel "rm -rf /lib/modules/cartelladelmiokernel/*"? O elimino anche altre cose che non andrebbero eliminate?

----------

## ago

si ma poi devi ricompilare altrimenti non ti funziano i moduli  :Razz: 

----------

## UnoSD

Ovviamente...

Anche se praticamente di modulare non ho nulla! (Tranne lirc_serial)

----------

## cloc3

 *UnoSD wrote:*   

> O elimino anche altre cose che non andrebbero eliminate?

 

elimi anche i moduli esterni, tipo i driver nvidia.

ma non è un dramma, perché emerge offre il comando emerge @module-rebuild (almeno con portage-2.2.* , alla peggio , esiste il pacchetto module-rebuild).

----------

## UnoSD

Non ho moduli nemmeno esterni! Davverso solo lirc_serial. (Ora ho scoperto, dopo aver buttato il sangue, anche l'inutilità dei moduli per il monitoraggio hardware come k10temp, it87, i2c-dev, i2c_piix4, hwmon_vid)

----------

