Progetto Kernelpkg Tool

[submax82]

@nuitari

se è come dici .... allora come faccio a fare una procedura automatica per la creazione dell'initrd?!?!?!

@absinthe

no scusa mi sono spiegato male! se ad esempio io faccio un lspci del mio hw scopro che utilizzo un chipset della ali. aquel punto anzichè includere tutti i moduli come fa debian, fai un grep sui percorsi di /lib/modules/$KERNEL_VERSION e prendi _solo_ i moduli per chipset ali. è di per sè già automatizzata, non devi fare nessun case. semplicemente anzichè includere tutto ciò che si trova in quelle directory incluse da debian, tu greppi solo ciò che riguarda il tuo chipset!!!

ho capito ma metti che un chip si chiama "ali c8534" il modulo magari si chiama "c8534" con il tuo metodo non contenendo la parola "ali" non verrebbe incluso...

per calcolare le dipendenze anche con il 2.4 forse adesso ho capito come fare dal codice debian... per il 2.6 uso il metodo di pat che poi in fin dei conti è molto simile se non uguale e quello debian.

[nuitari]

@nuitari
se è come dici .... allora come faccio a fare una procedura automatica per la creazione dell'initrd?!?!?!

Perchè "se è come dico"? io dico solo che i moduli non vengono scaricati una volta caricati, tutto qui.

IMHO è un po' troppo pensare di fare una scansione dell'hardware per capire che moduli caricare... cioè, è una buona idea ma è titanica, bisognerebbe quantomeno fare un piccolo database da interrogare per capire quali moduli caricare e come (perchè esistono anche i parametri).

Più facile è fare la cosa in 2 passaggi.

Inizialmente crei l'immagine ed un initrd onnicomprensiva. Una volta installata e riavviato il sistema, fai una cernita dei moduli effettivamente caricati e scremi l'initrd.

In ogni caso, potresti comunque sperimentare blocchi e simili, perchè esistono cose come moduli deprecati, moduli compatibili, etc etc. E' per questo che in genere la selezione ed il caricamento dei moduli è un operazione che dovrebbero fare gli esseri umani.. guarda solo i problemi che la gente denuncia qui sul forum di slacky per la fase di post-installazione...

[submax82]

io dico solo che i moduli non vengono scaricati una volta caricati, tutto qui.

ok anche se rimango perplesso ...

IMHO è un po' troppo pensare di fare una scansione dell'hardware per capire che moduli caricare... cioè, è una buona idea ma è titanica, bisognerebbe quantomeno fare un piccolo database da interrogare per capire quali moduli caricare e come (perchè esistono anche i parametri).

concordo è quello che dico anche io...

Più facile è fare la cosa in 2 passaggi.
Inizialmente crei l'immagine ed un initrd onnicomprensiva. Una volta installata e riavviato il sistema, fai una cernita dei moduli effettivamente caricati e scremi l'initrd.

non ho idea di come fare e poi scusami ma non sono convinto della questione che rimangono caricati... non voglio essere irritante ma lasciami il tempo di convincermi

In ogni caso, potresti comunque sperimentare blocchi e simili, perchè esistono cose come moduli deprecati, moduli compatibili, etc etc.

infatti con la mia procedura si bloccava tutto mentre nel codice debian ho visto appunto che escludono dei moduli... infatti funziona... quindi da questo punto di vista ... dovrebbe essere tutto ok a meno di rivoluzioni nel kernel...

E' per questo che in genere la selezione ed il caricamento dei moduli è un operazione che dovrebbero fare gli esseri umani..

hai ragione potrei darla come possibilità ma volevo capire come funzionava debian che non richiede nulla... e dare questa possibilità al mio tool

[nuitari]

Eheh ma ti sembra sensato che i moduli di gestione del filesystem o del chipset o di lvm o dei controller vengano tolti dalla memoria per poi essere ricaricati? Nel momento in cui i moduli vengono rimossi, il kernel smette di gestire l'hardware relativo... si pianterebbe tutto.
E comunque, ricaricati da dove? Ipotizza che in un initrd metti il modulo per la gestione del filesystem del disco di root. Se il modulo viene rimosso, in che modo il kernel potrebbe leggere i moduli da caricare ex novo????? ripeto, non ha senso, non è scritta da nessuna parte.

Comunque, per quanto riguarda Debian: come dire, funziona, finchè... non funziona
Anche Pat nel suo kernel ha scelto le opzioni più comuni e più sicure.. eppure ogni tot compare qualcuno qui sul forum a cui quel kernel non va.. lo stesso è per Debian.
Se vuoi fare qualcosa che "nella migliore delle ipotesi funziona", ok, ma qualcosa di perfetto imho non lo potrai mai fare. Non tu in particolare, sia chiaro. Intendo nessuno. Almeno finchè il kernel e i moduli del kernel sono così.

Per quanto riguarda la storia dei due passaggi, basta fare un lsmod una volta riavviato il sistema e tirare giù il nome dei moduli

[submax82]

ok mi hai convinto ... anche da questa frase dell'init dell'initrd-tree

# With a generic kernel, you need to load the modules needed to mount the
# root partition. This might mean a SCSI, RAID, or other drive controller
# module, as well as the module to support the root filesystem. Once the
# root partition is mounted all the other modules will be available so you
# don't need to load them here.

la cosa che ancora non ho ancora capito è come mai nell'lsmod non compaiono dopo che il nuovo kernel ha completato il boot

[nuitari]

Ma ne sei certo? Quali moduli non vedi nell'lsmod che dovrebbero esserci?

[submax82]

Ma ne sei certo? Quali moduli non vedi nell'lsmod che dovrebbero esserci?

poi riprovo e ti posto tutto

[submax82]

HAI RAGIONE AL 100% ... rimangono caricati

mannaggggia

[nuitari]

meglio così dai =) almeno sappiamo come funziona, se no non sapevo a che santi appellarmi .

[submax82]

meglio così dai =) almeno sappiamo come funziona, se no non sapevo a che santi appellarmi .

grazie di quello che mi hai insegnato...

ora però sono confuso se inserire o no la procedura in kernelpkg

[nuitari]

Ma si mettila, basta che trovi un modo di fare una screma dei moduli utili, tutto li.
Se fai un tool che fa il package del kernel, è sensato che faccia anche l'initrd come opzione.

Se poi ci aggiungi la patch per la console decoration... sai che figata? . . (si lo so, sono monotono)

[zetsu]

diciamo che lspci ti da informazioni almeno sulla famiglia di chipset. ad esempio con un lspci -vv un grep e un paio di cut io so esattamante quale famiglia di controlloer ho a bordo. non ho ancora capito se riesco ad ottenere il modello preciso, ma limito l'initrd a un paio di drivers!

anche se ottieni la famiglia devi poi creare un "case" o un file dove c'è la corrispondenza famiglia - moduli da caricare. Inoltre se ci sono 10000 famiglie è ingestibile... ho intenzione di includere in kernelpkg procedure semplici e facilmente mantenibili... e soprattutto il più possibile "adattanti" in modo che non devo aggiornarlo a ogni uscita di una famiglia di chip o a ogni uscita di una nuova versione del kernel.

Non si potrebbe fare un database più o meno completo (che prenda la maggior parte dei dispositivi) facendosi aiutare dalla comunita slacky.eu?

Mi spiego meglio... un database in cui tutti noi inseriamo la corrispondenza device-moduli, compilabile (non so se è la parola giusta; perdonatemi, sono un novellino) via web.

Tipo: una pagina in cui inseriamo il device (dato da lspci) e il modulo che sta usando, che andranno direttamente ad alimentrare il database.
Però bisogna anche fare una guida "passo passo" che permetta, anche a chi non sa bene cosa fare, di trovare effettivamente i moduli relativi a ogni singolo device.
Non so se mi sono spiegato... Comunque è solo un'idea

[submax82]

@zetsu: no non è una cosa gestibile ... non voglio inserire in kernelpkg una procedura che si basa su un db... è troppo oneroso da mantenere.

@nuitari

Se poi ci aggiungi la patch per la console decoration... sai che figata? . . (si lo so, sono monotono)

cosa intendi? l'output di kernelpkg colorato?

@tutti
penso ormai di aver scelto:

nuova opzione --initrd con due modalità:

--initrd mod1:mod2:mod3 ---------> crea un initrd con i moduli specificati
--initrd ----------> senza argomenti builda un initrd con tutti i moduli compilati per quel kernel che potrebbero essere necessari per il boot .... cioè get_most_modules derivato da debian.

ho scritto il wrapper, migliorato la procedura debian, e fatto la parte che calcola le dipendeze dei moduli sia per kernel 2.4 che per 2.6... ora se riesco devo scrivere la procedura per lvm e siamo a posto.

che ne dite? vanno bene le opzioni?

[nuitari]

cosa intendi? l'output di kernelpkg colorato?

Eheh no lascia stare, era un delirio sulla decorazione framebuffer della console, una battuta niente più.

[submax82]

cosa intendi? l'output di kernelpkg colorato?

Eheh no lascia stare, era un delirio sulla decorazione framebuffer della console, una battuta niente più.

però sarebbe interessante mettere l'output colorato... anche se in effetti è un orpello inutile

ho cambiato una cosa nella proposta --initrd

MOST --------->>> fà l'initrd ciccione
mod1:mod2:ecc... --------->>> fà l'initrd con i moduli specificati calcolando le dipendenze anche su slack 11.0

vi piace? va bene?