Ricompilare debian: metodo classico o standard.

[gianlucab70]

Salve a tutti.
Come da titolo.
Vorrei qualche delucidazione.
Mi è parso di capire che ricompilando con il metodo standard (alla debian) si ottiene un kernel-image.deb da installare dandolo in pasto a dpkg.

Qual' è il vantaggio ,Visto che ci vorrà anche + tempo per la compilazione?

[Franco2]

Con il metodo classico devi spostare l'immagine del kernel nella directory /boot, creare un file initrd, cambiare le impostazioni a grub o a lilo.
Con il metodo debian è più facile: fa tutto l'installer.
Non mi pare ci voglia più tempo per la compilazione. Ci vorrà al max un minuto in più per creare il pacchetto .deb, ma questo dopo la compilazione del kernel.

Quando compili con il make-kpkg ricorda di metterci sempre l'opzione "--initrd", altrimenti non crea il file initrd e ti va in kernel panic quando fai il reboot. Io ho fatto un paio di ricompilazioni a vuoto pensando di aver sbagliato qualcosa nel settare i parametri.

[s-y]

io non scarterei il metodo classico per l'operazione, in modo da assimilare un sistema che andra' bene per qualsiasi distro.

initrd non e' necessario, basta compilare staticamente i moduli giusti, e il kernel panic si evita. si velocizza anche leggermente il boot e si risparmia quel po' di filesystem.

[jeremy.83]

Originariamente inviato da s-y

io non scarterei il metodo classico per l'operazione, in modo da assimilare un sistema che andra' bene per qualsiasi distro.

initrd non e' necessario, basta compilare staticamente i moduli giusti, e il kernel panic si evita. si velocizza anche leggermente il boot e si risparmia quel po' di filesystem.

Quoto, prima di compilare il kernel, ti consiglio di salvarti o stamparti l'output di "lsmod". Ti ritrovi tutti i moduli che hai caricato in quel momento, così da compilarli staticamente quando dai il make menuconfig. Sempre dentro in quella schermata per riconoscere i vari moduli digita "'?" se non ricordo male

[s-y]

in realta' per evitare il kernel panic senza inirtd non e' strettamente necessario compilare staticamente tutti i moduli, ma solamente quelli relativi al sottosistema disco fisso, o meglio disco di boot. ora a memoria non ricordo esattamente ma dovrebbe essere: controller del disco, disco, e filesystem. per non saper leggere ne' scrivere ho sempre abbondato in tali categorie.

resta il fatto che compilare staticamente tutti i moduli (scelta indolore a patto che l'hw del computer non cambi spesso, o si debba consentire il collegamento di periferiche esterne non sempre uguali) consente di ottenere un kernel piu' compatto e quindi meno pesante in memoria, forse anche leggermente piu' prestante, pur senza differenze abissali. la cosa puo' avere piu' senso, a parte esigenze particolari, per sistemi non recenti. si risparmia poi ulteriore spazio disco dato che la dir /lib/modules del kernel in uso sara' vuota.

[gianlucab70]

Andiamo con ordine.
Ho sentito parlare di compilazioni statiche. E' la stessa cosa di kernel monolitico?

Metodo classico.
La bzImage che viene creata in /usr/src/linux/arch/i386/boot deve essere ricopiata in /boot e rinominata in vmlinuz-versione.kernel. ?

Il grub lo aggiorno con update-grub ?

[s-y]

Originariamente inviato da gianlucab70

Andiamo con ordine.
Ho sentito parlare di compilazioni statiche. E' la stessa cosa di kernel monolitico?

Metodo classico.
La bzImage che viene creata in /usr/src/linux/arch/i386/boot deve essere ricopiata in /boot e rinominata in vmlinuz-versione.kernel. ?

Il grub lo aggiorno con update-grub ?

1. ni. o meglio, il kernel monolitico sarebbe gia' quello di linux in contrapposizione con quelli modulari (famoso il flame su usenet torvalds/tannenbaum). cmq parlando di rebuild si puo' dire che un kernel sia compilato monoliticamente (o staticamente), quando tutti i moduli sono compilati al suo interno, quindi staticamente, e quindi non essendo piu' 'moduli' per definizione.

2. si. si puo' cmq rinominare a piacere, basta che il bootloader punti a quel file.

3. non conosco tale strumento, io ho sempre fatto editando a mano /boot/grub/menu.lst, che e' cosa di un attimo e permette credo maggior controllo.

[jeremy.83]

Comunque per chi usa debian, imho è meglio la debian-way che ti leva dallle scatole alcune cosette.

Ad esempio quando dai il make-kpkg puoi definire col comando append-to-version il nome da dare al kernel.

[Devil!]

io consiglio di creare anche il pacchetto per i kernel headers oltre a quello per il kernel

invece di

$ make-kpkg kernel_image

mettere

$ make-kpkg kernel_image kernel_headers

[gianlucab70]

Originariamente inviato da s-y

1. ni. o meglio, il kernel monolitico sarebbe gia' quello di linux in contrapposizione con quelli modulari (famoso il flame su usenet torvalds/tannenbaum). cmq parlando di rebuild si puo' dire che un kernel sia compilato monoliticamente (o staticamente), quando tutti i moduli sono compilati al suo interno, quindi staticamente, e quindi non essendo piu' 'moduli' per definizione.

Il kernel monolitico a cui fai riferimento dovrebbe essere il cosiddetto "vanilla" distributo dalla kernel.org ?

2. si. si puo' cmq rinominare a piacere, basta che il bootloader punti a quel file.

ok, ma come la mettiamo con il file sistem.map (presente in /boot) ?

Originariamente inviato da jeremy.83

Comunque per chi usa debian, imho è meglio la debian-way che ti leva dallle scatole alcune cosette.

Ad esempio quando dai il make-kpkg puoi definire col comando append-to-version il nome da dare al kernel.

Sicuramente è da provare anche la ricompilazione standard.

Per adesso voglio fare un quadro generale di tutto. Grazie.

[gianlucab70]

Originariamente inviato da Devil!

io consiglio di creare anche il pacchetto per i kernel headers oltre a quello per il kernel

Non sono troppo sicuro.
Gli headers hanno solo l'utilità di occupare meno spazio rispetto al kernel-source .
Ma se uno utilizza sempre e solo il suddetto file (impacchettato e salvato in un'altra partizione), può fare a meno degli headers.

[s-y]

Originariamente inviato da gianlucab70

Il kernel monolitico a cui fai riferimento dovrebbe essere il cosiddetto "vanilla" distributo dalla kernel.org ?

no, 'vanilla' in generale definiscono le major release 2.6.xx, quelle non patchate successivamente, che hanno invece numero 2.6.xx.y. la terminologia poi si applica a tutto il mondo gnu/linux, tipo kde o gnome 'vanilla', le versioni nude e crude senza personalizzazioni.

il kernel linux e' monolitico per definizione, proprio come architettura.
forse meglio riferirsi a 'statico' per definire un kernel senza moduli.

ok, ma come la mettiamo con il file sistem.map (presente in /boot) ?

premesso che non e' un file essenziale (tipicamente serve per fare debugging) quando lanci la compilazione viene generata una versione adattata al kernel nuovo. non ricordo esattamente dove viene creata (cmq all'interno della subdir dei sorgenti) ma ripeto che non e' strettamente necessario usarlo.

[s-y]

doppio uno...

[s-y]

e doppio due...

[s-y]

e doppio tre...

[gianlucab70]

Originariamente inviato da s-y

no, 'vanilla' in generale definiscono le major release 2.6.xx, quelle non patchate successivamente, che hanno invece numero 2.6.xx.y. la terminologia poi si applica a tutto il mondo gnu/linux, tipo kde o gnome 'vanilla', le versioni nude e crude senza personalizzazioni.

[Piccolo ot. Mi sa tanto che il server da i numeri!!!! ]
Veniamo a noi.
Sul sito della kernel.org si mettono a disposizione diverse versioni.
La full source è sicuramente quella patchata (attualmente è 2.6.27.9) e che quindi non è la versione vanilla.
Sul server dei package-source di ubuntu http://packages.ubuntu.com/source/hardy/linux è presente la versione con denominazione in stile vanilla (2.6.xx) e con la dicitura (con aggiunta patch di ubuntu).

1) Questa denonminazione sembrerebbe non linea con lo standard. ?
2) Le patch aggiunte dalla distro sono indicate con la dicitura 2.6.xx-xx.xx ?
3) Le patch della distro rappresentano un' ulteriore aggiunta a quelle della kernel.org?

[s-y]

Originariamente inviato da gianlucab70

[Piccolo ot. Mi sa tanto che il server da i numeri!!!! ]

credo sia successo perche' ho postato quando il db del forum non era ancora uscito dalla fase di manutenzione, che se non mi sbaglio avviene ogni notte inoltrata.

Veniamo a noi.
Sul sito della kernel.org si mettono a disposizione diverse versioni.
La full source è sicuramente quella patchata (attualmente è 2.6.27.9) e che quindi non è la versione vanilla.
Sul server dei package-source di ubuntu http://packages.ubuntu.com/source/hardy/linux è presente la versione con denominazione in stile vanilla (2.6.xx) e con la dicitura (con aggiunta patch di ubuntu).

1) Questa denonminazione sembrerebbe non linea con lo standard. ?
2) Le patch aggiunte dalla distro sono indicate con la dicitura 2.6.xx-xx.xx ?
3) Le patch della distro rappresentano un' ulteriore aggiunta a quelle della kernel.org?

1. premesso che la nomenclatura ufficiale del kernel non la conosco, credo che ubuntu sia considerabile come riferimento rispetto agli standard quanto 'il fantino' rispetto alla sincerita'...

2. si, credo di si, ma vedi sopra. in piu' credo non esista una regola universale.

3. in teoria si. sono una patch rispetto alla versione indicata, per l'appunto.

ad ogni modo per fare pratica di rebuild credo sia preferibile scaricare i sorgenti da kernel.org, in modo da non inserire ulteriori 'variabili'. anzi credo che sia preferibile farlo sempre e basta.

[gianlucab70]

ok .
Adesso inizia ad essere un po + chiaro.
Vedo quello che riesco a fare........eventualmente chiedo aiuto.
Grazie di tutto.

[gianlucab70]

Ho ricompilato con metodo classico un kernel modulare.
Unico inconveniente , non mi ha creato il file initrd.img_nuova_versione_di_kernel_compilato.
Tento l'avvio richiamando (purtroppo) quello della versione precedente.
Non carica i moduli e quindi non si avvia!!! .........