Chiarimenti su compilazione Kernel!

[ChriD]

Come promesso, rieccomi pronto ad infastidirvi con le mie domande da niubbo....
Tempo permettendo vorrei dedicarmi un po' alla ricompilazione di un kernel a partire dai sorgenti scaricati da kernel.org
Credo di aver letto tuttavia in qualche discussione di questo forum che tale attivita' non e' molto indicata anche se non ho ben capito il motivo a favore di un kernel compilato dal Sig. Volkerding.
In ogni caso la mia attivita' e' legata alla voglia di imparare e smanettare, anche perche' ho una macchina secondaria che mi consente di continuare a lavorare in caso di necessita'.
L'ordine dovrebbe essere:

Codice: Seleziona tutto

[list]
[*]wget https://cdn.kernel.org/pub/linux/kernel/v4.x/linux-4.7.4.tar.xz
[*]su -
[*]mv linux-4.7.4.tar.xz /root
[*]tar -xJvf linux-4.7.4.tar.xz
[*]cd linux-4.7.4.tar.xz
[*]Bisogna sistemare i permessi? Un bel chmod +x make oppure chmod -R 755 ./
[*]make clean && make mrproper
[*]make localmodconfig oppure zcat /proc/config.gz > ./.config
[*]make menuconfig
[*]make -jX (numero di core/cpu)
[*]make modules_install
[/list]

Successivamente bisogna copiare i file generati vmlinuz-xxxx e System.map-xxxxx in /boot e ricreare i link simbolici ai file specifici con le versioni appropriate...
Tuttavia ho un po' di domande...

Bisogna creare l'initial ram disk con lo script mkinitrd anche se ad esempio il filesystem ext4 e' compilata come voce statica del kernel?
Inoltre, bisogna aggiornare GRUB2 considerando che ho usato questo boot loader al posto di ELILO? Magari bisogna inserire anche un riferimento all'initial ram disk solo se effettivamente e' necessario? Attualmente la Slackware 14.2 sembra non utilizzarlo...
Inoltre ancora anche il file config va salvato in /boot? Viene utilizzato?
Inoltre ancora, ho letto che dopo la compilazione del kernel il file module.dep contenente le varie dipendenze dei moduli e' vuoto, quindi va rigenerato con un bel depmod -a? La pratica e' necessaria oppure serve solo per velocizzare ad ogni avvio il caricamento dei moduli considerando che depmod dovrebbe risolvere automaticamente le dipendenze in assenza di entry all'interno di modules.dep?

Risolti questi dubbi... ne avrei di altri...

[targzeta]

Intanto ti dico subito che puoi compilare il kernel come utente normale. Solo l'install devi farla come root.

Fossi in te io partirei ricompilando lo stesso kernel che usi attualmente, questo ti permette di partire da un config già pronto. Quindi:

• scarica i sorgenti del kernel attualmente in uso;
• decomprimi i sorgenti da qualche parte, tipo /usr/tmp;
• entra nella directory;
• make clean; make mrproper;
• cp /boot/config .config;
• poi prova a fare: make localmodconfig - Update current config disabling modules not loaded e/o
• make localyesconfig - Update current config converting local mods to core;
• make
• poi lo installi come hai detto con l'utente root;

Usa l'opzione 'CONFIG_LOCALVERSION' per aggiungere un suffisso tuo locale, in modo da non sovrascrivere i moduli installati dal pacchetto della Slackware che usi.

L'intrd non ti serve se metti tutti i moduli nel core del kernel, va creato solo in casi particolari in cui ti serve che un modulo sia caricato prima dell'avvio del kernel.

Per il boot manager non ti posso aiutare, uso LILO ed ho due sezioni, una per il mio kernel ed una per il kernel di Pat, così se qualcosa va male....

Il config, così come il System.map non sono utilizzati. Io nel kernel setto l'opzione che crea il config.gz nella directory /proc (CONFIG_IKCONFI) così posso sempre recuperarlo.

Io il module.dep non l'ho mai generato, però ho visto che l'rc rc.modules esegue all'avvio il comando 'depmod'.

Buon divertimento,
Emanuele

[ChriD]

Perfetto, sono contentissimo di aver ricevuto una tua risposta in modo da potermi confrontare....
Ti volevo chiedere alcune cose in merito ai tuoi suggerimenti.... Vorrei approfondire per capire meglio...
Mi hai consigliato di copiare il config in /boot da utilizzare come base per la mia configurazione, rispetto al mio metodo che copio decomprimendo il file config.gz da /proc
Non dovrebbe essere maggiormente corretto la copia da /proc considerando che dovrebbe contenere l'esatta configurazione generata in fase di avvio dal kernel?
Inoltre mi suggerisci di dare un make localmodconfig e/o make localyesconfig.... In realtà non essendo la stessa cosa una scelta dovrebbe escludere obbligatoriamente l'altra o mi sbaglio?
CONFIG_LOCALVERSION deve essere modificata nel .config oppure la posso passare come parametro ai vari make XXXXconfig?

[targzeta]

Se usi il kernel della Slackware, allora il config che trovi nel /boot è uguale al .gz nel proc, però usa pure quale ti pare.

Codice: Seleziona tutto

  localmodconfig  - Update current config disabling modules not loaded
  localyesconfig  - Update current config converting local mods to core

il primo ti modifica il .config mettendo a 'NO' tutti i moduli non utilizzati, il secondo mettere a 'YES' tutti quelli utilizzati. Non vedo perché un'opzione dovrebbe escludere l'altra.

Una volta lanciati quei comandi devi anche configurare il kernel con uno dei suoi menù. Io personalmente uso 'make menuconfig'. È da li che puoi trovare e settare la variabile 'CONFIG_LOCALVERSION'.

Emanuele

[ChriD]

Se usi il kernel della Slackware, allora il config che trovi nel /boot è uguale al .gz nel proc, però usa pure quale ti pare.

Codice: Seleziona tutto

  localmodconfig  - Update current config disabling modules not loaded
  localyesconfig  - Update current config converting local mods to core

il primo ti modifica il .config mettendo a 'NO' tutti i moduli non utilizzati, il secondo mettere a 'YES' tutti quelli utilizzati. Non vedo perché un'opzione dovrebbe escludere l'altra.

Una volta lanciati quei comandi devi anche configurare il kernel con uno dei suoi menù. Io personalmente uso 'make menuconfig'. È da li che puoi trovare e settare la variabile 'CONFIG_LOCALVERSION'.

Emanuele

Ho dato un bel diff tra i due file config e risultano perfettamente uguali... quindi rimane solo un discorso di modus operandi, credo....
Aggiungo che sto provando a lavorare sui sorgenti del kernel installati tramite il setup di Slackware ma hanno tutti i file i permessi 644... sarebbe quindi corretto modificarli o compilarli da root?

Codice: Seleziona tutto

  localmodconfig  - Update current config disabling modules not loaded
  localyesconfig  - Update current config converting local mods to core

localmodconfig dovrebbe lasciare tutte le voci statiche selezionate e abilitare come moduli solo quelli effettivamente caricati dal sistema in uso escludendo quelle non caricate,
localyesconfig invece lascia sempre tutte le voci statiche a statiche ma in piu' trasforma anche i moduli effettivamente utilizzati a voci statiche escludendo sempre i moduli non caricati....

Forse ho capito male io? Ma se si usa uno poi non dovrebbe avere senso usare l'altro...

From the kernel README:

"make localmodconfig" Create a config based on current config and loaded modules (lsmod). Disables any module option that is not needed for the loadedmodules.

To create a localmodconfig for another machine, store the lsmod of that machine into a file and pass it in as a LSMOD parameter.

target$ lsmod > /tmp/mylsmod
target$ scp /tmp/mylsmod host:/tmp

host$ make LSMOD=/tmp/mylsmod localmodconfig
The above also works when cross compiling.

"make localyesconfig" Similar to localmodconfig, except it will convert
all module options to built in (=y) options.

Da qui mi sembra di capire che bisogna scegliere quale utilizzare.... Banalizzando se in totale in config ho 80 voci statiche e 20 voci modulari effettivamente caricati nel sistema entrambi i comandi mi daranno una configurazione con 100 voci totali... il primo localmodconfig rimane 80 statiche e 20 modulari, il secondo localyesconfig 100 voci statiche e basta....

[targzeta]

Io mi soffermavo principalmente sui moduli non necessari, non su quelli necessari. Però se anche localyesconfig, come localmodconfig, disabilita i moduli non necessari allora sì, scegli pure uno dei due.

Emanuele

[ChriD]

Giusto per aggiornarvi sul punto della situazione...
Sto lavorando sul kernel 4.7.4 l'ultimo
ho dovuto fare una piccola digressione su makepkg al fine di creare un pacchetto per avere una coerenza con i pacchetti installati......

Voi come gestite la cosa?

[targzeta]

Io ho creato uno build personalizzato e lo uso lanciando make install, infatti:

Codice: Seleziona tutto

  install      - Install kernel using
                  (your) ~/bin/installkernel or
                  (distribution) /sbin/installkernel or
                  install to $(INSTALL_PATH) and run lilo

Emanuele

[ChriD]

Scusa questo script che hai realizzato, che scopo ha? Piazzare i relativi file al termine della compilazione in /boot, aggiornare lilo oppure crea anche i pacchetti? Tipo uno slackbuild?

[ChriD]

Ho visto che in nessun modo, anche realizzando pacchetti ad-hoc si riesce a mantenere la coerenza con quelli gestiti da slackpkg e quelli installati nel sistema...
Il mio problema era che ad esempio installando il kernel 4.7.4 volevo fare in modo che slackpkg se ne accorgesse del nuovo kernel e non ne installasse un altro (magari anche precedente) dando uno slakpkg upgrade-all...
Alla fine non ci riesco in quanto credo di aver capito che slackpkg in qualche modo vede solo quelli ufficiali, mentre quelli non ufficiali li vede ma non li considera come metro di comparazione per quelli disponibili da installare... Alla fine ho inserito nella blacklist i pacchetti del kernel cosi' ho piena libertà' su di esso....

[ponce]

scusa, che problema ti crea se slackpkg ne installa un altro? tanto sei te nella configurazione del bootloader che decidi quale fargli caricare e quale no...

io i kernel non li pacchettizzo proprio o se mi capita di volerlo fare realizzo un pacchetto unico con sorgenti, /lib/modules/x.x.x, /lib/firmware e file dentro /boot dandogli un nome personalizzato (tipo kernel-host-x.x.x-x86_64-1ponce), in modo che il pacchetto non vada in conflitto con altri del sistema in fase di aggiornamento: che te lo aggiorni o meno dipende dal nome che hai dato al tuo pacchetto.

[ChriD]

scusa, che problema ti crea se slackpkg ne installa un altro? tanto sei te nella configurazione del bootloader che decidi quale fargli caricare e quale no...

io i kernel non li pacchettizzo proprio o se mi capita di volerlo fare realizzo un pacchetto unico con sorgenti, /lib/modules/x.x.x, /lib/firmware e file dentro /boot dandogli un nome personalizzato (tipo kernel-host-x.x.x-x86_64-1ponce), in modo che il pacchetto non vada in conflitto con altri del sistema in fase di aggiornamento: che te lo aggiorni o meno dipende dal nome che hai dato al tuo pacchetto.

Io stavo inutilmente provando a creare pacchetti diversi con lo stesso nome di quelli di Pat ma con versioning superiore in modo da far capire a slackpkg che i miei fossero gia' i piu' aggiornati... ma nulla.... slackpkg mi propone sempre di aggiornarli anche se la versione proposta e' antecedente a quella specificata dal nome del mio pacchetto....
Comunque credo che potrei utilizzare il tuo modus opernadi... ossia crearmi un pacchetto con moduli, firmware e file di boot con un nome alternativo e lasciare aggiornare quelli presenti nel sistema o al piu' mettere quelli del kernel in blacklist...

[ponce]

la numerazione non conta niente, te lo aggiorna anche solo se e' diversa.

se non vuoi che te lo aggiorni col solito nome puoi dare un TAG personalizzato al pacchetto e poi dire a slackpkg di non toccare i pacchetti con quel TAG: per esempio, se metti in /etc/slackpkg/blacklist

Codice: Seleziona tutto

[0-9]+pippo

dicendogli cosi' di ignorare i pacchetti con TAG="pippo" e hai installato un pacchetto kernel-generic-4.7.4-x86_64-1pippo allora quello non verra' aggiornato.

[ChriD]

la numerazione non conta niente, te lo aggiorna anche solo se e' diversa.

se non vuoi che te lo aggiorni col solito nome puoi dare un TAG personalizzato al pacchetto e poi dire a slackpkg di non toccare i pacchetti con quel TAG: per esempio, se metti in /etc/slackpkg/blacklist

Codice: Seleziona tutto

[0-9]+pippo

dicendogli cosi' di ignorare i pacchetti con TAG="pippo" e hai installato un pacchetto kernel-generic-4.7.4-x86_64-1pippo allora quello non verra' aggiornato.

[targzeta]

Scusa questo script che hai realizzato, che scopo ha? Piazzare i relativi file al termine della compilazione in /boot, aggiornare lilo oppure crea anche i pacchetti? Tipo uno slackbuild?

Fa uno (anzi tre) pacchetti per la Slackware.

Emanuele