kernel 2.6.26 rilasciato

[sperelli]

Io ho il kernel 2.6.24.5-smp, se volessi patcharlo dovrei applicare prima la 2.6.25 e poi la 2.6.26?

ciao

ps: Se dopo aver patchato devo ricompilare, che senso ha patchare?

[targzeta]

Io ho il kernel 2.6.24.5-smp, se volessi patcharlo dovrei applicare prima la 2.6.25 e poi la 2.6.26?

ciao

ps: Se dopo aver patchato devo ricompilare, che senso ha patchare?

Leggi il file "Documentation/applying-patches.txt" (nei sorgenti del kernel) e sono sicuro che ti chiarirà le idee .

Spina

[masalapianta]

|------- Sicurezza --------------|

...
"aggiornare" non significa necessariamente utilizzare l'ultima release disponibile, ma anche patchare la medesima release con i vari aggiornamenti di sicurezza

Si, ma sei tu che escludi una delle due interpretazioni, non io.

lo escludo da cosa? sto dicendo che tenere un server con i pacchetti (soprattutto il kernel) aggiornato all'ultima release stabile e' deleterio sia per la sicurezza che per la stabilita', i motivi li ho gia spiegatie e faccio presente che non e' una mia fissazione o una mia idea personale, ma il modus comportandi standard in ambiente enterprise, quindi o tu hai visto la luce e il resto del mondo brancola nel buio oppure ti stai sbagliando

Da Programmazione.it

Fondata nel 1992 da Patrick Volkerding, Slackware è la più vecchia sopravvissuta distribuzione GNU/Linux. E' molto sicura, stabile ed è spesso raccomandata per le installazioni server...

Da linux.html.it

Slackware è stata una delle primissime distribuzioni a comparire sulla scena del mondo OpenSource (è presente fin dall'Aprile del 1993)....Risulta anche un'ottima scelta sui server, grazie alla fama di distribuzione sicura che ha saputo farsi col passare degli anni...

quindi, se l'ultima Slackware ha il kernel corrente dell'epoca, dovrebbe voler dire che Pat riteneva quel kernel current quantomeno sicuro......spero.

ripeto: a prescindere da quello che puoi trovare su questo o quel sito, slackware e' praticamente inesistente in ambiente enterprise (e questa non e' un opinione trovata su un sito, ma un dato di fatto riscontrabile girando per i ced)

Non voglio dire che è più sicuro passare all'ultimo kernel appena uscito, ma che non è del tutto vero che sia meno sicuro.

e' potenzialmente meno sicuro; ripeto: nuovo codice significa nuovi potenziali bug

|-------- Moduli vs. Statico ---------|
Da Appunti di Informatica Libera

...Tuttavia, a causa della frammentazione in molti file, l'uso dei moduli può essere fonte di errori....

questa frase da sola non ha alcun significato; errori di che tipo? ottenuti come? Per capire un discorso non basta fare copia e incolla da una pagina web

ancora

...Le distribuzioni GNU/Linux tendono a fornire agli utilizzatori un kernel modulare per usi generali....

Effettivamente ho usato il termine architettura in maniera errata quando ti parlavo di distribuzioni, quello che volevo dire è che le distribuzioni offrono i kernel modulari perchè non sanno su quale hardware andrà a finire, e non per i motivi pratici 1) e 2) che spieghi nell'altro post.

ripeto: nelle distribuzioni destinate ad ambienti dove sicurezza e stabilita' sono importanti si usano kernel modulari per entrambe le ragioni non ho citato quella per cui si adattano a un parco macchine eterogeneo perche' mi sembrava oltremodo ovvia; ma la 1) e la 2) restano valide (e sono i motivi per i quali in quell'ambiente non si usano e non si dovrebbero usare kernel monolitici)

...e torno a dire che a meno che tu non abbia 500 macchine identiche (impossibile se non parliamo di cluster per calcolo parallelo o render farm), e'verosimile che con kernel monolitici, in caso di aggiornamento tu debba ricompilare se non 500 kernel, un numero che gli si avvicina molto...

Intanto non è così impossibile, visto che quando un azienda compra dei PC, li compra in massa e tutti dalla stessa casa prodruttrice (con la quale generalmente ha un contratto), e tutti identici.

io temo di non riuscire a spiegarmi (anche se mi sembra di averlo fatto piu' volte), sto parlando di ambiente enterprise, non di piccì; vai in qualsiasi ced (che ripeto, non ospiti cluster per calcolo parallelo o render farm) e dimmi se trovi un parco macchine non eterogeneo

Poi, se hai architetture diverse, devi compilare tante volte il kernel per quante architetture hai, semplicemente perchè se hai compilato il kernel per x86, non puoi portarlo sulla macchina sparc, ma questo discorso vale sia per i kernel modulari sia per quelli non modulari.

a questo punto ti reinvito a rilegger i miei precedenti post (dove tra le altre cose affermavo anche questo); cito:

infatti le distro offrono n versioni del medesimo kernel modulare, uno per ogni architettura

Cioè, supponiamo che io ho tre macchine con architetture diverse, se voglio pathcare il kernel per correggere un bug, allora lo devo fare su tutte e tre le macchine e devo ricompilare il kernel su tutte e tre le macchine. Se invece le macchine sono tutte e tre uguali, mi basta farlo su una e ricompilare il kernel una volta....ma a prescindere dal fatto che il kernel sia modulare o no.

questo e' un esempio fazioso, sai bene (spero) che in un ced non hai 3 macchine ma centinaia, mentre le architetture sono molto poche; quindi per aggiornare centinaia di macchine dovrai ricompilare pochissimi kernel (verosimilmente meno di 10) se usi un modulare, mentre se usi un monolitico dovrai ricompilare centinaia di kernel

Poi è ovvio che se sei l'ammistratore di server che al mattino hanno bisogno di un 'modprobe' e la sera di un 'modprobe -r', allora ti devi fare un kernel modulare, anche perchè effettivamente è poco pratico fare un modprobe su un kernel che non supporta i moduli

temo di non aver capito; voleva essere una simpatica battuta o che altro?

masalapianta, per non generare equivoci, io non dico che è meglio avere i kernel statici, dico solo che esageri quando dici che ha poco senso averli.

confermo che in ambiente enterprise non ha alcun senso avere kernel statici (e infatti nessuno li ha); le motivazioni di
questo te le ho gia spiegate

mi piace discutere, tutto qui.

discutere e' utile solo se leggi quel che gli altri ti scrivono e quando rispondi porti argomentazioni; se qualcuno afferma qualcosa e argomenta le sue affermazioni (anche se avrebbe potuto limitarsi a dire che quello e' il modus comportandi standard in quell'ambiente), diventa poco utile rispondere senza confutare quelle argomentazioni, limitandosi ad alzare polvere portando frasi copiaincollate dal web e decontestualizzate; anche a me piace discutere, ma quando la discussione e' costruttiva e vengono poste sul piatto argomentazioni solide e non fumo; per completezza riporto di seguito le argomentazioni che ho portato e a cui tu non hai risposto:

sicurezza e stabilita':
nuovo codice porta potenzialmente nuovi bug, per questo, in ambienti dove sicurezza e stabilita' sono importanti, non si usa quasi mai (e questo, lo ripeto, non e' una mia idea personale, ma il modus comportandi standard che segue tutto il mondo) l'ultima release stabile di ogni software, ma versioni sufficientemente testate (e quando esce un bug, per il medesimo motivo non si fa l'upgrade della release ma il back porting del fix)

modulare vs statico:
usa kernel statici in ambito server _non_ha_alcun_senso_ perche' una volta che sul modulare hai disabilitato CAP_SYS_RAWIO e CAP_SYS_MODULE, a livello di sicurezza i due approcci si equivalgono, mentre a livello di praticita' vince nettamente il modulare; questo perche':
1) seppure, dovendo abilitare il supporto a qualcosa, in entrambi i casi e' necessario un reboot (una volta tolta di mezzo una capabilities l'unico modo per ripristinarla e' il reboot (a meno di sistemi che permettano di sostituire il kernel senza reboot fisico (kexec))), nel caso del modulare poi basta un modprobe (e ridisabilitazione delle due capabilities di cui sopra, subito dopo), mentre con il kernel senza il supporto ai moduli devi ricompilare tutto e in ambiente enterprise (do per scontato che non si parli del serverino nello sgabuzzino, altrimenti vale quel che ho detto per i sistemi casalinghi nel mio post precedente) le cose spesso devono essere fatte per ieri (tempo==molti soldi) e su N macchine.
2) con il modulare posso utilizzare il medesimo kernel su 500 macchine e fixare i bug patchando e ricompilando una singola volta (se tutte le macchine hanno la stessa architettura, altrimenti N volte dove N e' il numero di architetture che ho, ma si parla di un numero quasi sempre piccolissimo), viceversa usando kernel senza supporto ai moduli devo ricompilare 500 kernel.

Questo e' il motivo per cui in certi ambienti, salvo _rarissime_ occasioni, i kernel non si ricompilano, ma si usano i precompilati forniti con le distro in uso; che spesso sono versioni stabili (non certo l'ultima release) e quando esce un bug il supporto della distro fa uscire un precompilato della stessa versione patchato facendo il backporting del fix, quindi da un ipotetico x.y.z-1 si passa a un x.y.z-2; oppure se si hanno particolari esigenze non si usano i precompilati delle distro in uso, ma si compilano e pacchettizzano i kernel in casa, sempre utilizzano pochi kernel modulari (uno per ogni architettura in uso), una versione stabile e facendo i backporting dei fix invece di aggiornare le release.

Offtopic: masalapianta, sono contento di sapere che non mi hai plonkato, come invece dicesti di aver fatto

veramente ti avevo plonkato, ma ogni tanto rivedo l'ignore list e se non ricordo il perche' ci ho messo un nick, lo tolgo; evidentemente faccio male e anche se non ne ricordo il perche' dovrei fidarmi delle mie precedenti decisioni;

[masalapianta]

DNFTT

spesso si da da mangiare ai troll non tanto perche' non ci si rende conto che trollano, quanto per evitare che qualche novizio, leggendoli li prenda sul serio e si crei delle convinzioni che non stanno ne in cielo ne in terra

[sperelli]

Confermate che 2.6.26 ha problemi con i driver proprietari nVidia?

[targzeta]

Vabbuò masalapianta, tanto non si arriva da nessuna parte, se pensi che il tuo interlocutore sia un idiota, di certo non lo ascolti, potresti diventare idiota anche tu, giusto? E non voglio di certo farti correre questo rischio
Ti invito anche io a rileggerti i miei post, ma con l'umiltà che si addice ai sapienti, e non con l'arroganza che ho percepito dalle tue risposte. Se le miei frasi copiaincolla, come le chiami tu, pensi che non stanno né in cielo né in terra, leggiti i link e vedrai che le frasi decontestualizzate saranno per magia contestualizzate, ma non da me, dagli autori dei pezzi. A quel punto se hai problemi con quei pezzi, scrivi gli autori.
Io penso di aver argomentato in maniera esaustiva il discorso dal quale si è partiti io e tu, ovvero dal fatto che secondo me esageri quando dici che ha poco senso installare un server statico su macchine server. Poi, ho cercato anche di argomentare l'altra discussione sulla sicurezza, per quanto io non consideri una cattiva idea rimanere con un kernel stabile, ma semplicemente facendo notare che non sempre nuovo codice uguale nuovi bug, ma vuol dire anche bug fix, e quindi, o la media dei bug è la stessa, oppure siamo lì. Anche perchè scusami, le patch che sono? non sono forse nuovo codice che potrebbe quindi modificare la struttura del software aggiungendo nuovi bug ? (per essere chiaro, dato che mi sembra che hai detto che non capisci, questa era una battuta, ci ho messo anche la faccina visto )
Tu sei quello categorico, quello che è sicuro di avere ragione, io cercavo di capire, ma non è che mi hai fatto capire granché. Si dice che anche dio sbagliò a riposarsi il settimo giorno, visto le guerre che si sono succedute sulla terra. Per dire, se voli basso puoi solo salire (ora mi sono beccato un altro plonk giusto?)

Stammi bene masalapianta,
Spina

[sperelli]

Ho ricompilato il kernel: finalmente posso usare il 100% della barra del volume dell'audio in kmix (prima già al 50% non si sentiva nulla) e funziona il led del wi-fi.

L'unico problema che ho è con lo scaling della cpu, che non funziona.
Ho compilato il kernel con Default CPUFreq impostato a userspace.

Codice: Seleziona tutto

davide@slack:/sys/devices/system/cpu/cpu0$ cpufreq-info
cpufrequtils 002: cpufreq-info (C) Dominik Brodowski 2004-2006
Per favore, comunicare errori e malfunzionamenti a linux@brodo.de.
analisi della CPU 0:
  nessun modulo o modulo cpufreq sconosciuto per questa CPU
analisi della CPU 1:
  nessun modulo o modulo cpufreq sconosciuto per questa CPU

Il mio processore è un core duo

model name : Intel(R) Core(TM)2 Duo CPU T7500 @ 2.20GHz (info di proc/cpu)

[masalapianta]

Vabbuò masalapianta, tanto non si arriva da nessuna parte, se pensi che il tuo interlocutore sia un idiota, di certo non lo ascolti, potresti diventare idiota anche tu, giusto? E non voglio di certo farti correre questo rischio

se pensassi che sei idiota non ti avrei risposto, quel che ti ho fatto notare e' che anziche' rispondere entrando nel merito delle mie affermazioni ti sei limitato a "buttarla in caciara", facendo copia e incolla dal web di singole frasi decontestualizzate ed evitando accuratamente di rispondere alle argomentazioni che ti avevo portato

Ti invito anche io a rileggerti i miei post, ma con l'umiltà che si addice ai sapienti, e non con l'arroganza che ho percepito dalle tue risposte.

ho riletto i tuoi post e senza alcuna arroganza confermo che non hai portato lo straccio di un'argomentazione

Se le miei frasi copiaincolla, come le chiami tu,

abbi pazienza ma non "le chiamo io", sono prese dal web e hai citato anche la fonte

pensi che non stanno né in cielo né in terra, leggiti i link e vedrai che le frasi decontestualizzate saranno per magia contestualizzate, ma non da me, dagli autori dei pezzi.

appunto, e' esattamente per questo che ho parlato di fumo, leggendo il contesto di quelle frasi si capisce che con le argomentazioni che ti avevo portato c'entrano come i cavoli a merenda; sono state utilizzate decontestualizzandole per far sembrare che confutassero quanto detto io (mentre lette nel giusto contesto appare evidente che non c'entrano una mazza con quello di cui si parlava)

Io penso di aver argomentato in maniera esaustiva il discorso dal quale si è partiti io e tu, ovvero dal fatto che secondo me esageri quando dici che ha poco senso installare un server statico su macchine server.

stai scherzando? non hai portato lo straccio di un'argomentazione che fosse una; non hai risposto a mezza argomentazione che ti ho portato io, se questo per te e' argomentare allora si, hai argomentato

Poi, ho cercato anche di argomentare l'altra discussione sulla sicurezza, per quanto io non consideri una cattiva idea rimanere con un kernel stabile, ma semplicemente facendo notare che non sempre nuovo codice uguale nuovi bug,

il punto non e' la certezza che ci siano nuovi bug ma la concreta possibilita'; per questo motivo in produzione si tende a non usare l'ultima release stabile di un software; e lo ripeto, non sono mie elucubrazioni personali, ma il modus comportandi standard universalmente adottato in ambito sicurezza, quindi o tutto il mondo sbaglia e tu hai ragione oppure c'e' qualcosa che non va in quel che dici

ma vuol dire anche bug fix, e quindi, o la media dei bug è la stessa, oppure siamo lì.

quale parte di "fare backporting dei fix" non ti e' chiara?

Anche perchè scusami, le patch che sono? non sono forse nuovo codice che potrebbe quindi modificare la struttura del software aggiungendo nuovi bug

il codice del fix normalmente son poche righe, e quindi l'audit e' relativamente semplice; nuove release di un software puo' significare molto nuovo codice e il rischio di bug aumenta di conseguenza

Tu sei quello categorico, quello che è sicuro di avere ragione, io cercavo di capire, ma non è che mi hai fatto capire granché

da come ti sei posto e dal fatto che invece che rispondere argomentando, hai portato solo fumo, mi sembra di capire che piu' che capire il tuo interesse e' far polemica; io in questo caso sono sicuro di aver ragione perche' ho solide argomentazioni a riguardo (cui, ricordo per l'ennesima volta, ti sei guardato bene dal rispondere) e perche' quel che affermo e' il modus comportandi adottato a livello mondiale in ambiente enterprise (quindi non una mia teoria personale); se poi tu sei convinto che il resto del mondo abbia torto e tu ragione (e senza portare argomentazioni ma per puro principio) buon per te

Stammi bene

irrilevante


per l'ennesima volta, con la pia illusione che stavolta risponderai argomentando, ti riporto le mie argomentazioni:

sicurezza e stabilita':
nuovo codice porta potenzialmente nuovi bug, per questo, in ambienti dove sicurezza e stabilita' sono importanti, non si usa quasi mai (e questo, lo ripeto, non e' una mia idea personale, ma il modus comportandi standard che segue tutto il mondo) l'ultima release stabile di ogni software, ma versioni sufficientemente testate (e quando esce un bug, per il medesimo motivo non si fa l'upgrade della release ma il back porting del fix)

modulare vs statico:
usa kernel statici in ambito server _non_ha_alcun_senso_ perche' una volta che sul modulare hai disabilitato CAP_SYS_RAWIO e CAP_SYS_MODULE, a livello di sicurezza i due approcci si equivalgono, mentre a livello di praticita' vince nettamente il modulare; questo perche':
1) seppure, dovendo abilitare il supporto a qualcosa, in entrambi i casi e' necessario un reboot (una volta tolta di mezzo una capabilities l'unico modo per ripristinarla e' il reboot (a meno di sistemi che permettano di sostituire il kernel senza reboot fisico (kexec))), nel caso del modulare poi basta un modprobe (e ridisabilitazione delle due capabilities di cui sopra, subito dopo), mentre con il kernel senza il supporto ai moduli devi ricompilare tutto e in ambiente enterprise (do per scontato che non si parli del serverino nello sgabuzzino, altrimenti vale quel che ho detto per i sistemi casalinghi nel mio post precedente) le cose spesso devono essere fatte per ieri (tempo==molti soldi) e su N macchine.
2) con il modulare posso utilizzare il medesimo kernel su 500 macchine e fixare i bug patchando e ricompilando una singola volta (se tutte le macchine hanno la stessa architettura, altrimenti N volte dove N e' il numero di architetture che ho, ma si parla di un numero quasi sempre piccolissimo), viceversa usando kernel senza supporto ai moduli devo ricompilare 500 kernel.

Questo e' il motivo per cui in certi ambienti, salvo _rarissime_ occasioni, i kernel non si ricompilano, ma si usano i precompilati forniti con le distro in uso; che spesso sono versioni stabili (non certo l'ultima release) e quando esce un bug il supporto della distro fa uscire un precompilato della stessa versione patchato facendo il backporting del fix, quindi da un ipotetico x.y.z-1 si passa a un x.y.z-2; oppure se si hanno particolari esigenze non si usano i precompilati delle distro in uso, ma si compilano e pacchettizzano i kernel in casa, sempre utilizzano pochi kernel modulari (uno per ogni architettura in uso), una versione stabile e facendo i backporting dei fix invece di aggiornare le release.

[Vito]

Confermate che 2.6.26 ha problemi con i driver proprietari nVidia?

Confermo. Per risolvere i problemi usa questi : http://www.nvidia.com/object/linux_disp ... 14.09.html

[sperelli]

Confermate che 2.6.26 ha problemi con i driver proprietari nVidia?

Confermo. Per risolvere i problemi usa questi : http://www.nvidia.com/object/linux_disp ... 14.09.html

Grazie! Resta da risolvere il problema con lo scaling che ho descritto un paio di post fa.

ciao

[Mario Vanoni]

(e questo, lo ripeto, non e' una mia idea personale, ma il modus comportandi standard che segue tutto il mondo) l'ultima release stabile di ogni software, ma versioni sufficientemente testate (e quando esce un bug, per il medesimo motivo non si fa l'upgrade della release ma il back porting del fix)

Questo e' il motivo per cui in certi ambienti, salvo _rarissime_ occasioni, i kernel non si ricompilano, ma si usano i precompilati forniti con le distro in uso; che spesso sono versioni stabili (non certo l'ultima release) e quando esce un bug il supporto della distro fa uscire un precompilato della stessa versione patchato facendo il backporting del fix, quindi da un ipotetico x.y.z-1 si passa a un x.y.z-2; oppure se si hanno particolari esigenze non si usano i precompilati delle distro in uso, ma si compilano e pacchettizzano i kernel in casa, sempre utilizzano pochi kernel modulari (uno per ogni architettura in uso), una versione stabile e facendo i backporting dei fix invece di aggiornare le release.

a) tutto il mondo - 1

b) e senza reboot?

[robbybby]

Anni fa abbiamo fatto diversi test con traceroute, a giorni diversi:

andare/copiare dall'Europa all'Europa si passava via Giappone/USA ecc.
Permetti quindi di dubitare sul minor consumo.

In questo momento ftp.eu.kernel.org porta in Svezia senza giri strani,
mentre ftp.kernel.org porta in California.
In altri momenti non so: non avevo mai fatto prove.

[targzeta]

....L'unico problema che ho è con lo scaling della cpu, che non funziona.
Ho compilato il kernel con Default CPUFreq impostato a userspace.

Codice: Seleziona tutto

davide@slack:/sys/devices/system/cpu/cpu0$ cpufreq-info
cpufrequtils 002: cpufreq-info (C) Dominik Brodowski 2004-2006
Per favore, comunicare errori e malfunzionamenti a linux@brodo.de.
analisi della CPU 0:
  nessun modulo o modulo cpufreq sconosciuto per questa CPU
analisi della CPU 1:
  nessun modulo o modulo cpufreq sconosciuto per questa CPU

Il mio processore è un core duo

model name : Intel(R) Core(TM)2 Duo CPU T7500 @ 2.20GHz (info di proc/cpu)

Io ho il tuo stesso processore, nella sezione dei driver per il frequency scaling, ho impostato solo

ACPI Processor P-States driver

dei governor invece ho messo di default il conservative, se usi l'userspace, dovresti avere un programma in spazio utente che gestisce la frequenza.
Il tuo problema dovrebbe essere legato al driver comunque, se non hai compilato quello di cui sopra, prova a compilarlo in builtin nel kernel, oppure, se lo hai compilato come modulo, prova a dare un

Codice: Seleziona tutto

modprobe acpi-cpufreq

.

Spina

[masalapianta]

(e questo, lo ripeto, non e' una mia idea personale, ma il modus comportandi standard che segue tutto il mondo) l'ultima release stabile di ogni software, ma versioni sufficientemente testate (e quando esce un bug, per il medesimo motivo non si fa l'upgrade della release ma il back porting del fix)

Questo e' il motivo per cui in certi ambienti, salvo _rarissime_ occasioni, i kernel non si ricompilano, ma si usano i precompilati forniti con le distro in uso; che spesso sono versioni stabili (non certo l'ultima release) e quando esce un bug il supporto della distro fa uscire un precompilato della stessa versione patchato facendo il backporting del fix, quindi da un ipotetico x.y.z-1 si passa a un x.y.z-2; oppure se si hanno particolari esigenze non si usano i precompilati delle distro in uso, ma si compilano e pacchettizzano i kernel in casa, sempre utilizzano pochi kernel modulari (uno per ogni architettura in uso), una versione stabile e facendo i backporting dei fix invece di aggiornare le release.

a) tutto il mondo - 1

lavori in ambiente enterprise (di quell'ambiente parlavo)? a quanto ho capito (correggimi se sbaglio) amministri una manciata di piccoli server che utilizzi nella tua azienda; ripeto: do per scontato che non si parli dei "serverini nello sgabuzzino" (non ti offendere, e' un modo di dire per intendere piccole macchine utilizzate da una pmi o un privato, dietro un'adsl o connessione simile, e sistemate alla buona e non in un vero ced), altrimenti vale quel che ho detto per i sistemi casalinghi in un mio precedente post:
"Poi ovviamente su macchine casalinghe (dove sicurezza e stabilita' non sono requisiti cosi' necessari) uno puo' tranquillamente tenere l'ultimissima release di ogni software, ma che non si creda per questo di perseguire la sicurezza, perche' e' l'esatto contrario."

b) e senza reboot?

potresti essere meno ermetico? che significa "e senza reboot?"? come ho gia detto in entrambi i casi (modulare e monolitico) per aggiungere una funzionalita' e' richiesto (se si toglie, per ragioni di sicurezza la CAP_SYS_MODULE usando un modulare) il reboot fisico della macchina (a meno di kexec); con la differenza che nel caso del modulare poi basta un modprobe (e ridisabilitazione delle due capabilities di cui sopra, subito dopo), mentre con il kernel senza il supporto ai moduli devi ricompilare tutto. Se invece parliamo di aggiornamenti di sicurezza anche qui il reboot e' ovviamente necessario in entrambi i casi (sempre a meno di kexec), con la differenza che, avendo un buon parco macchine (diverse centinaia), se usi dei kernel compilati staticamente devi ricompilare centinaia di kernel, mentre se usi dei modulari ti basta ricompilare tanti kernel quante sono le architetture di cui disponi (nel 99% dei casi meno di una decina)

[sperelli]

Grazie Spina ora funziona, io, sbagliando, caricavo cpufreq_powersave.

ciao