Progetto Kernelpkg Tool
Moderatore: Staff
Regole del forum
1) Citare in modo preciso il nome del pacchetto.
2) Specificare se discussione/suggerimento o richiesta d'aiuto.
3) Leggere attentamente le risposte ricevute
4) Scrivere i messaggi con il colore di default, evitare altri colori.
5) Scrivere in Italiano o in Inglese, se possibile grammaticalmente corretto, evitate stili di scrittura poco chiari, quindi nessuna abbreviazione tipo telegramma o scrittura stile SMS o CHAT.
6) Appena registrati è consigliato presentarsi nel forum dedicato.
La non osservanza delle regole porta a provvedimenti di vari tipo da parte dello staff, in particolare la non osservanza della regola 5 porta alla cancellazione del post e alla segnalazione dell'utente. In caso di recidività l'utente rischia il ban temporaneo.
1) Citare in modo preciso il nome del pacchetto.
2) Specificare se discussione/suggerimento o richiesta d'aiuto.
3) Leggere attentamente le risposte ricevute
4) Scrivere i messaggi con il colore di default, evitare altri colori.
5) Scrivere in Italiano o in Inglese, se possibile grammaticalmente corretto, evitate stili di scrittura poco chiari, quindi nessuna abbreviazione tipo telegramma o scrittura stile SMS o CHAT.
6) Appena registrati è consigliato presentarsi nel forum dedicato.
La non osservanza delle regole porta a provvedimenti di vari tipo da parte dello staff, in particolare la non osservanza della regola 5 porta alla cancellazione del post e alla segnalazione dell'utente. In caso di recidività l'utente rischia il ban temporaneo.
- submax82
- Staff

- Messaggi: 3202
- Iscritto il: mer 31 ago 2005, 0:00
- Desktop: xfce
- Distribuzione: SalixOS
- Contatta:
nessuno mi dà un'aiuto con il supporto a initrd ... sarebbe una creazione automatica dello stesso... ?!?!?
ho preso questo dall'mkinitrd di debian
funzionicchia ... è modificato non è proprio come quello debian... ma al boot dà dei messaggi che non riesco a leggere/interpretare...
comunque avete capito la mia idea?!? sarebbe un wrapper all'mkinitrd di slack...
è solo uno script di test ... poi và integrato...
ho preso questo dall'mkinitrd di debian
Codice: Seleziona tutto
#!/bin/sh
# esempio per ricerca dipendenze di un modulo
# modprobe --set-version 2.6.17.13 --show-depends ext3
# uscita:
# insmod /lib/modules/2.6.17.13/kernel/fs/jbd/jbd.ko
# insmod /lib/modules/2.6.17.13/kernel/fs/ext3/ext3.ko
# part of code is than mkinitrd
# Copyright (C) 2001-2003 Herbert Xu <herbert@debian.org>
# under the terms of the GNU General Public License as published by
# the Free Software Foundation; either version 2 of the License, or
# (at your option) any later version.
get_modules_most() {
if [ -d "/lib/modules/$KERNELVERSION/kernel" ]; then
set "/lib/modules/$KERNELVERSION"/kernel/drivers/video/fb*.$EXT
[ -e "$1" ] && printf '%s\n' "$@"
set "/lib/modules/$KERNELVERSION/"kernel/drivers/video/cfb*.$EXT
[ -e "$1" ] && printf '%s\n' "$@"
set "/lib/modules/$KERNELVERSION/"kernel/drivers/video/console/f*.$EXT
[ -e "$1" ] && printf '%s\n' "$@"
for i in \
"/lib/modules/$KERNELVERSION/kernel/drivers/block" \
"/lib/modules/$KERNELVERSION/kernel/drivers/ide" \
"/lib/modules/$KERNELVERSION/kernel/drivers/md" \
"/lib/modules/$KERNELVERSION/kernel/drivers/scsi" \
"/lib/modules/$KERNELVERSION/kernel/fs" \
"/lib/modules/$KERNELVERSION/kernel/net/unix"
do
[ -d "$i/" ] || continue
find "$i/" -type f
done > /tmp/tmp1
< /tmp/tmp1 awk "
!/fs\/binfmt_[^\/]*\$/ &&
!/fs\/autofs.*\/[^\/]*\$/ &&
!/fs\/coda\/[^\/]*\$/ &&
!/fs\/intermezzo\/[^\/]*\$/ &&
!/fs\/lockd\/[^\/]*\$/ &&
!/fs\/ncpfs.*\/[^\/]*\$/ &&
!/fs\/nfs.*\/[^\/]*\$/ &&
!/fs\/nls\/[^\/]*\$/ &&
!/fs\/ramfs\/[^\/]*\$/ &&
!/fs\/smbfs\/[^\/]*\$/ &&
!/drivers\/block\/loop\.$EXT\$/ &&
!/drivers\/block\/nbd\.$EXT\$/ &&
!/drivers\/block\/paride\/[^\/]*\$/ &&
!/drivers\/ide\/ide-cs\.$EXT\$/ &&
!/drivers\/ide\/ide-tape\.$EXT\$/ &&
!/drivers\/scsi\/ide-scsi\.$EXT\$/ &&
!/drivers\/scsi\/osst\.$EXT\$/ &&
!/drivers\/scsi\/pcmcia\/[^\/]*\$/ &&
!/drivers\/scsi\/ppa\.$EXT\$/ &&
!/drivers\/scsi\/scsi_debug\.$EXT\$/ &&
!/drivers\/scsi\/s[gt]\.$EXT\$/ {
print
}
"
for i in \
"/lib/modules/$KERNELVERSION/kernel/drivers/message/fusion/mptbase".* \
"/lib/modules/$KERNELVERSION/kernel/drivers/message/fusion/mptscsih".*
do
[ -f "$i" ] || continue
echo "$i"
done
else
for i in \
"/usr/src/linux/block" \
"/usr/src/linux/fs" \
"/usr/src/linux/scsi"
do
[ -d "$i/" ] || continue
find "$i/" -type f
done
if [ -f "/usr/src/linux/misc/unix.$EXT" ]; then
echo "/lib/modules/$KERNELVERSION/misc/unix.$EXT"
fi
fi | while read SRCMOD; do
MODULE=$(basename $SRCMOD .$EXT)
echo -n "$MODULE:"
done | sed "s/:$/\n/"
}
build_initrd_auto()
{
EXT_K24="o"
EXT_K26="ko"
if [ $(echo $KERNELVERSION | cut -c -3) = "2.4" ]; then
EXT=$EXT_K24
elif [ $(echo $KERNELVERSION | cut -c -3) = "2.6" ]; then
EXT=$EXT_K26
fi
echo
echo "--- new debian mode ---"
get_modules_most
mkinitrd -c -k $KERNELVERSION -m $(get_modules_most) -f ext3 -r /dev/hda1 -o /boot/initrd-$KERNELVERSION-test.gz
}
KERNELVERSION=""
if [ ! -z "$1" ]; then
KERNELVERSION=$1
else
KERNELVERSION=$(uname -r)
fi
build_initrd_auto
comunque avete capito la mia idea?!? sarebbe un wrapper all'mkinitrd di slack...
è solo uno script di test ... poi và integrato...
- submax82
- Staff

- Messaggi: 3202
- Iscritto il: mer 31 ago 2005, 0:00
- Desktop: xfce
- Distribuzione: SalixOS
- Contatta:
bè lo spiegato devo fare un wrapper automatico che includa tutti i moduli che possono essere necessari al boot cioè fs e driver ide/sata/scsi ... che è quello che fà la procedura sopra ma non in modo ippecabile visto che il boot lo fà ma ci sono alcuni messaggi strani che non riesco a leggere.... ma non penso siano importanti ... diciamo che mi servono test e impressioni, miglioramenti ecc....nuitari ha scritto:Che cosa ti serve sull'initrd?
all'inizio avevo fatto io una procedura diversa da quella sopra che per semplicità mi piaceva di più ma non funziona perchè il kernel non boota... se volete posto anche quella
tutto questo serve per creare un initrd con il wrapper senza specificare i moduli come nell'mkinitrd di slackware ... un pò come avviene in fedora e debian... e come in make-kpkg di debian aggiungere l'opzione --initrd al tool
sarebbe da testare su slackware 11.0 con kernel 2.4 e kernel 2.6 con l'fs della root come modulo e con il chip del controller della scheda madre come modulo.... per verificare che il wrapper funzioni
nel frattempo esce la NUOVA VERSIONE 0.7.0 .... per il changelog è sotto /usr/doc/kernelpkg-0.7.0/changelog-ita.txt ... di cui rimporto l'ultima parte
* 0.7.0
- correzioni inglese in progress, report e slack-desc vari grazie a danix85
- aggiunto supporto a elilo
- aggiunto file kernelpkg.conf in cui si possono settare i valori di default delle opzioni di kernelpkg
- aggiunto controllo della versione del kernel presente nell'header del config (deve coincidere con la versione del kernel che si stà per compilare)
- piccole aggiunte man
- modifiche nella creazione di kernel-source
- stampa del bootloader rilevato nello slack-desc del pacchetto kernel-image e eliminazione della riga quando è disabilitato (opzione -d)
- stampa errore quando non viene rilevato il bootloader in fase di installazione kernel-image
- prima della compilazione controllo che gli headers del kernel corrente siano presenti nel sistema
- piccoli ritocchi grafici
- aggiornamento licenza a GPL v3
- aggiunta creazione file .md5 + .txt con desc, per ogni pacchetto creato
- aggiunta sistemazione permessi, proprietario, gruppo
- modifica tracciamento rc.modules in fase di installazione kernel-image
ora aiutatemi per l'initrd!!!
- nuitari
- Linux 3.x

- Messaggi: 777
- Iscritto il: dom 14 ott 2007, 12:51
- Slackware: 12.0
- Località: San Colombano al Lambro
- Contatta:
Beh sicuramente quantomeno dovresti trovare un modo migliore per rilevare filesystem e volume di root, come ad esempio fare un semplice grep/sed/awk di fstab, o ancora meglio dell'output di mount.
Inoltre, non hai considerato LVM (opzione -L di mkinitrd).
I messaggi dovresti vederli con dmesg, difficilmente visualizza altri messaggi che non siano relativi al kernel, l'initrd.
Nella peggiore delle ipotesi, assicurati che lo scrollback sia nella system ram (opzione relativa del kernel) ed aumenta la dimensione del buffer, così li puoi vedere con PGUP/PGDOWN.
Od anche modifica temporaneamente lo script init dentro l'initrd e logga i mex da qualche parte (in genere si fa su un tmpfs ad hoc che devi solo avere l'accortezza di non smontare).
Posta pure la tua procedura, quantomeno gli diamo un occhiata ^^
Inoltre, non hai considerato LVM (opzione -L di mkinitrd).
I messaggi dovresti vederli con dmesg, difficilmente visualizza altri messaggi che non siano relativi al kernel, l'initrd.
Nella peggiore delle ipotesi, assicurati che lo scrollback sia nella system ram (opzione relativa del kernel) ed aumenta la dimensione del buffer, così li puoi vedere con PGUP/PGDOWN.
Od anche modifica temporaneamente lo script init dentro l'initrd e logga i mex da qualche parte (in genere si fa su un tmpfs ad hoc che devi solo avere l'accortezza di non smontare).
Posta pure la tua procedura, quantomeno gli diamo un occhiata ^^
- submax82
- Staff

- Messaggi: 3202
- Iscritto il: mer 31 ago 2005, 0:00
- Desktop: xfce
- Distribuzione: SalixOS
- Contatta:
già kernelpkg lo fà ... la procedura sopra mi serve solo come prova! ... cioè è solo uno script di test...Beh sicuramente quantomeno dovresti trovare un modo migliore per rilevare filesystem e volume di root, come ad esempio fare un semplice grep/sed/awk di fstab, o ancora meglio dell'output di mount.
una cosa alla volta! ... se poi qualcuno mi vuole dare una mano... visto che per ora non ho idea di come fareInoltre, non hai considerato LVM (opzione -L di mkinitrd).
ma dmesg non visualizza solo i messaggi del kernel ? anche quelli dell'initrd? devo ancora capire bene bene come funziona...I messaggi dovresti vederli con dmesg, difficilmente visualizza altri messaggi che non siano relativi al kernel, l'initrd.
?!Nella peggiore delle ipotesi, assicurati che lo scrollback sia nella system ram (opzione relativa del kernel) ed aumenta la dimensione del buffer, così li puoi vedere con PGUP/PGDOWN.
Od anche modifica temporaneamente lo script init dentro l'initrd e logga i mex da qualche parte (in genere si fa su un tmpfs ad hoc che devi solo avere l'accortezza di non smontare).
quella derivata da debian è sopra... la mia fà un pò pietà...Posta pure la tua procedura, quantomeno gli diamo un occhiata ^^
Codice: Seleziona tutto
#!/bin/sh
# esempio per ricerca dipendenze di un modulo
# modprobe --set-version 2.6.17.13 --show-depends ext3
# uscita:
# insmod /lib/modules/2.6.17.13/kernel/fs/jbd/jbd.ko
# insmod /lib/modules/2.6.17.13/kernel/fs/ext3/ext3.ko
build_initrd_auto()
{
EXT_K24="o"
EXT_K26="ko"
if [ $(echo $KERNELVERSION | cut -c -3) = "2.4" ]; then
EXT=$EXT_K24
elif [ $(echo $KERNELVERSION | cut -c -3) = "2.6" ]; then
EXT=$EXT_K26
fi
#ALL_MOD=$(find /lib/modules/$KERNELVERSION/kernel -name "*.$EXT" -type f -printf "%f:" | sed "s/:$//" | sed "s/\.$EXT//g")
#MODULES="$ALL_MOD"
ALL_MOD_FS=$(find /lib/modules/$KERNELVERSION/kernel/fs/ -name "*.$EXT" -type f -printf "%f:" | sed "s/:$//" | sed "s/\.$EXT//g")
ALL_MOD_SCSI=$(find /lib/modules/$KERNELVERSION/kernel/drivers/scsi/ -name "*.$EXT" -type f -printf "%f:" | sed "s/:$//" | sed "s/\.$EXT//g")
ALL_MOD_IDE=$(find /lib/modules/$KERNELVERSION/kernel/drivers/ide/ -name "*.$EXT" -type f -printf "%f:" | sed "s/:$//" | sed "s/\.$EXT//g")
MODULES="$ALL_MOD_IDE:$ALL_MOD_SCSI:$ALL_MOD_FS"
MODULES_BLACKLIST=""
MODULES="$(echo $MODULES | sed "s/$MODULES_BLACKLIST//g")"
# dep for linux 2.6
for MODULE in $(echo $MODULES | tr : \ ); do
/sbin/modprobe -q --set-version $KERNELVERSION --show-depends $MODULE
done | cut -f 2 -d ' ' | while read SRCMOD; do
DEPMOD=$(basename $SRCMOD .$EXT)
MODULES="$MODULES:$DEPMOD"
done
# dep for linux 2.4 ?
echo $MODULES
#cp /lib/modules/$KERNELVERSION/modules.* /boot/initrd-tree/lib/modules/$KERNELVERSION/
# -f ext3 -r /dev/hda1 saranno puoi passati dalla procedura di rilevamento
mkinitrd -c -k $KERNELVERSION -m $MODULES -f ext3 -r /dev/hda1 -o /boot/initrd-$KERNELVERSION-test.gz
}
KERNELVERSION=""
if [ ! -z "$1" ]; then
KERNELVERSION=$1
else
KERNELVERSION=$(uname -r)
fi
build_initrd_auto
- nuitari
- Linux 3.x

- Messaggi: 777
- Iscritto il: dom 14 ott 2007, 12:51
- Slackware: 12.0
- Località: San Colombano al Lambro
- Contatta:
Capito ^^submax82 ha scritto:già kernelpkg lo fà ... la procedura sopra mi serve solo come prova! ... cioè è solo uno script di test...
Non è una cosa difficile. con il comando lvs visualizzi le info sui volumi presenti (lvs per una spiega delle opzioni)submax82 ha scritto:una cosa alla volta! ... se poi qualcuno mi vuole dare una mano... visto che per ora non ho idea di come fare
Se trovi qualcosa, allora aggiungi l'opzione "-L", se no no ^^ non serve altro. Ovviamente se uno ha compilato lvm come modulo, devi includere pure quelli nell'initrd.
L'initrd viene processata dal kernel, per cui quei messaggi che vedi possono essere messaggi del kernel. Potrebbero anche essere messaggi diretti dallo script initrd presente nell'initrd-tree.submax82 ha scritto:ma dmesg non visualizza solo i messaggi del kernel ? anche quelli dell'initrd? devo ancora capire bene bene come funziona...
Se premi SHIFT+PGUP/PGDOWN scrolli l'output su terminale in alto. Il prob è che di solito il buffer a disposizione è ridotto, per cui ti perdi le scritte di avvio etc.Nella peggiore delle ipotesi, assicurati che lo scrollback sia nella system ram (opzione relativa del kernel) ed aumenta la dimensione del buffer, così li puoi vedere con PGUP/PGDOWN.
Od anche modifica temporaneamente lo script init dentro l'initrd e logga i mex da qualche parte (in genere si fa su un tmpfs ad hoc che devi solo avere l'accortezza di non smontare).
Se vai nel kernel, sezione driver -> graphic -> console, trovi un opzione che ti permette 1) di posizionare il buffer nella system ram 2) di aumentarne la dimensione. La dimensione ti consiglio d'aumentarla con un parametro a lilo, così quando non ti serve rimane normale.
Ora la guardo con calma.submax82 ha scritto:quella derivata da debian è sopra... la mia fà un pò pietà...![]()
- absinthe
- Iper Master

- Messaggi: 2354
- Iscritto il: dom 15 mag 2005, 0:00
- Nome Cognome: Matteo Nunziati
- Slackware: 12.1 - defunct
- Kernel: 2.6.32-5-amd64
- Desktop: gnome
- Distribuzione: debian squeeze
- Località: Prato
- Contatta:
allora ho fatto una prova con la slack 12.0 ed il kernel generic a disposizione. la tua procedura (quella dello script di test preso da debian!) funziona senza problemi. i messaggi li ho rediretti in un file di testo facendo un piccolo hack ai file creati in automatico da Pat! tutto l'output te lo allego per e.mail perchè è grossino!
in pratica accade questo: lo script di prova inserice il MONDO nell'initrd, ci vanno tutti i filesystem e tutti i chipset e supporti hw.
le scritte che passano sono l'output di insmod che, a seconda del caso, o sono semplici notifiche del tipo:
oppure sono errori, tipo quando a me cerca di caricare il driver per lo scsi che non esiste sul mio laptop!
in pratica sono messaggi ignorabili! a mio avviso la procedura è perfetta!
se poi la metti sullo stile, diciamo che mettere in initrd tutti i possibili fs e tutti i possibili chipset/supporti hw non ha molto senso, visto che con lspci e con fstab e rdev tiri fuori quasi tutte le info strettamente necessarie per un initrd su misura!
ma come primo step di implementazione nel mio caso è perfetto! insmod ci pensa da solo a scaciare i driver inutili oppure carica drivers inutili in ram ma questi non sembrano dare fastidio.
credo che la cosa funizoni finchè due o più moduli non mandano in conflitto il kernel (è un'ipotesi non so se può accadere!!)
per quanto riguarda la redirezione.. io non so come fare a visualizzare i dati dell'initrd senza modificare il buffer. di default dentro dmesg non ci sono! allora ho modificato gli script di pat... in particolare ho fatto così:
-ho usato lo script di submax
-sono entrato nella dir /boot/initrd-tree creata da mkinitrd
-ho rediretto stderr e sdtout di alcuni dati processati dalla script init (te lo allego in mail)
-ho rilanciato mkinitrd senza argomenti e lui mi ha ricreato l'immagine!
M
in pratica accade questo: lo script di prova inserice il MONDO nell'initrd, ci vanno tutti i filesystem e tutti i chipset e supporti hw.
le scritte che passano sono l'output di insmod che, a seconda del caso, o sono semplici notifiche del tipo:
Codice: Seleziona tutto
Using /lib/modules/2.6.21.5-smp/kernel/drivers/block/DAC960.ko
Codice: Seleziona tutto
insmod: cannot insert '/lib/modules/2.6.21.5-smp/kernel/drivers/scsi/psi240i.ko': No such device (-1): No such device
se poi la metti sullo stile, diciamo che mettere in initrd tutti i possibili fs e tutti i possibili chipset/supporti hw non ha molto senso, visto che con lspci e con fstab e rdev tiri fuori quasi tutte le info strettamente necessarie per un initrd su misura!
ma come primo step di implementazione nel mio caso è perfetto! insmod ci pensa da solo a scaciare i driver inutili oppure carica drivers inutili in ram ma questi non sembrano dare fastidio.
credo che la cosa funizoni finchè due o più moduli non mandano in conflitto il kernel (è un'ipotesi non so se può accadere!!)
per quanto riguarda la redirezione.. io non so come fare a visualizzare i dati dell'initrd senza modificare il buffer. di default dentro dmesg non ci sono! allora ho modificato gli script di pat... in particolare ho fatto così:
-ho usato lo script di submax
-sono entrato nella dir /boot/initrd-tree creata da mkinitrd
-ho rediretto stderr e sdtout di alcuni dati processati dalla script init (te lo allego in mail)
-ho rilanciato mkinitrd senza argomenti e lui mi ha ricreato l'immagine!
M
- submax82
- Staff

- Messaggi: 3202
- Iscritto il: mer 31 ago 2005, 0:00
- Desktop: xfce
- Distribuzione: SalixOS
- Contatta:
grazie absinthe!!!! ... sarebbe interessante affinare per quanto possibile la procedura ... appena posso leggo la mail!!! grazie ancora ottimo test!!!
PERO' c'è da dire che il problema è che lspci non ti dà il modulo che serve per ogni tipo di device... quindi come fai a creare la corrispondenza tra l'uscita di lspci e il modulo/i da passare a mkinitrd... anche se uno lo fà la cosa diventa difficilmente gestibile all'uscita di hardware o moduli nuovi... per questo ho preferito una cosa generica che carica tutto... non a caso debian funziona così di default... almeno credo... e il fatto che lo faccia una distro del genere fà capire che forse è l'unica soluzione per uno sviluppo gestibile di kernelpkg... fstab ti può dire il tipo di filesystem ma anche qui è lo stesso discorso... devi creare una corrispondenza con i moduli da caricare... e se esce un nuovo fs ... se kernelpkg non viene aggiornato l'initrd che crea il suo wrapper non funzionerebbe perchè gli mancano i moduli da passare a mkinitrd per quell'fs in particolare... per questo è meglio includere tutti i moduli per filesystem esistenti per quel kernel. Per rdev scusami ma non sò bene a cosa serva...
DOMANDA1: ma il fatto di far caricare tutti quei moduli a initrd.... tali moduli non vengono caricati quando il kernel viene avviato perchè sono solo temporanei, giusto? cioè poi carica SOLO quelli specificati in /etc/rc.d/rc.modules-2.6.23.12 ... per esempio ... esatto??? avevo fatto dei test in passato e sembravano confermarlo... tu confermi questo funzionamento???
DOMANDA2: qualcuno capisce come adattare la procedura debian per calcolare anche le dipendenze di ogni modulo sia per 2.6 che per 2.4... i sorgenti dell'mkinitrd di debian da cui estrapolare le porzioni è qui http://ftp.de.debian.org/debian/pool/ma ... 4.2.tar.gz ... non capisco bene come funziona... questo perchè nell'mkinitrd di slack11 che voglio supportare non c'è il calcolo automatico delle dipendenze... quindi il wrapper di kernelpkg deve essere in grado di farlo.
aspetto fiducioso test/suggerimenti/novità da chiunque voglia contribuire allo sviluppo di kernelpkg...
grazie ragazzi/e (solo per Paoletta
) 
sarebbe interessante fare procedure alternative e poi valutare tutti i vantaggi/svantaggi di ogniuna e decidere... quale inserire in kernelpkg 0.8.0mettere in initrd tutti i possibili fs e tutti i possibili chipset/supporti hw non ha molto senso, visto che con lspci e con fstab e rdev tiri fuori quasi tutte le info strettamente necessarie per un initrd su misura!
PERO' c'è da dire che il problema è che lspci non ti dà il modulo che serve per ogni tipo di device... quindi come fai a creare la corrispondenza tra l'uscita di lspci e il modulo/i da passare a mkinitrd... anche se uno lo fà la cosa diventa difficilmente gestibile all'uscita di hardware o moduli nuovi... per questo ho preferito una cosa generica che carica tutto... non a caso debian funziona così di default... almeno credo... e il fatto che lo faccia una distro del genere fà capire che forse è l'unica soluzione per uno sviluppo gestibile di kernelpkg... fstab ti può dire il tipo di filesystem ma anche qui è lo stesso discorso... devi creare una corrispondenza con i moduli da caricare... e se esce un nuovo fs ... se kernelpkg non viene aggiornato l'initrd che crea il suo wrapper non funzionerebbe perchè gli mancano i moduli da passare a mkinitrd per quell'fs in particolare... per questo è meglio includere tutti i moduli per filesystem esistenti per quel kernel. Per rdev scusami ma non sò bene a cosa serva...
DOMANDA1: ma il fatto di far caricare tutti quei moduli a initrd.... tali moduli non vengono caricati quando il kernel viene avviato perchè sono solo temporanei, giusto? cioè poi carica SOLO quelli specificati in /etc/rc.d/rc.modules-2.6.23.12 ... per esempio ... esatto??? avevo fatto dei test in passato e sembravano confermarlo... tu confermi questo funzionamento???
DOMANDA2: qualcuno capisce come adattare la procedura debian per calcolare anche le dipendenze di ogni modulo sia per 2.6 che per 2.4... i sorgenti dell'mkinitrd di debian da cui estrapolare le porzioni è qui http://ftp.de.debian.org/debian/pool/ma ... 4.2.tar.gz ... non capisco bene come funziona... questo perchè nell'mkinitrd di slack11 che voglio supportare non c'è il calcolo automatico delle dipendenze... quindi il wrapper di kernelpkg deve essere in grado di farlo.
aspetto fiducioso test/suggerimenti/novità da chiunque voglia contribuire allo sviluppo di kernelpkg...
grazie ragazzi/e (solo per Paoletta
- absinthe
- Iper Master

- Messaggi: 2354
- Iscritto il: dom 15 mag 2005, 0:00
- Nome Cognome: Matteo Nunziati
- Slackware: 12.1 - defunct
- Kernel: 2.6.32-5-amd64
- Desktop: gnome
- Distribuzione: debian squeeze
- Località: Prato
- Contatta:
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!submax82 ha scritto: PERO' c'è da dire che il problema è che lspci non ti dà il modulo che serve per ogni tipo di device... quindi come fai a creare la corrispondenza tra l'uscita di lspci e il modulo/i da passare a mkinitrd... anche se uno lo fà la cosa diventa difficilmente gestibile all'uscita di hardware o moduli nuovi... per questo ho preferito una cosa generica che carica tutto...
non so però come si comporti con supporti scasi, controller raid etc!
no mkinitrd della 12.0 indovina da solo il filesystem della root corrente e risolve le dipendenze dei moduli (con modprobe) puoi emulare quel comportamento facendo una specie di backporting. basta che il tipo che si vuol fare l'initrd o non passi alcun dato al wrapper e quindi lasci che il wrapper prenda il filesystem e la root corrente, oppure il tipo passi il filesystem e la root del pc su cui vorrà installare il kernel e il wrapper risolve le dipendenze su misura.non a caso debian funziona così di default... almeno credo... e il fatto che lo faccia una distro del genere fà capire che forse è l'unica soluzione per uno sviluppo gestibile di kernelpkg... fstab ti può dire il tipo di filesystem ma anche qui è lo stesso discorso... devi creare una corrispondenza con i moduli da caricare... e se esce un nuovo fs ... se kernelpkg non viene aggiornato l'initrd che crea il suo wrapper non funzionerebbe perchè gli mancano i moduli da passare a mkinitrd per quell'fs in particolare... per questo è meglio includere tutti i moduli per filesystem esistenti per quel kernel.
al più si sarà costretti ad inserire un pò di moduli per il supporto hw, tipo una flag --guess che fa sì che lspci limiti il numero di moduli da installare per l'hw su cui è compilato il kernel.
per il software non vedo particolari problemi a fare un initrd ad hoc anche per macchine diverse da quelle di compilazione. forse l'hw è più complesso hai ragione!
il fatto che debian facia così vuol dire solo una cosa: se il lavoro è già stato fatto riusalo come base e poi portalo avanti. non è detto che se debian non lo fa tu non possa trovare il modo di farlo! altrimenti su questa base non avresti sviluppato neppure kernelpkg perchè la slack non lo aveva già implementato!
man rdevPer rdev scusami ma non sò bene a cosa serva...![]()
non lo so... devo controllare. potrebbe non saprei ... ti faccio sapere! il fatto di fare su misura l'initrd è dovuto più che altro al fatto che se uno si deve caricare l'impossibile nell'initrd, allora tanto vale che si tenga un kernel con built in tutti sti aggeggi!DOMANDA1: ma il fatto di far caricare tutti quei moduli a initrd.... tali moduli non vengono caricati quando il kernel viene avviato perchè sono solo temporanei, giusto? cioè poi carica SOLO quelli specificati in /etc/rc.d/rc.modules-2.6.23.12 ... per esempio ... esatto??? avevo fatto dei test in passato e sembravano confermarlo... tu confermi questo funzionamento???
cosa intendi? le dipendenze vengono calcolate da modprobe ha un opzione apposta per quello. tu passi dei moduli al mkinitrd (prendi spunto anche da quello della slack 12.0) e poi conDOMANDA2: qualcuno capisce come adattare la procedura debian per calcolare anche le dipendenze di ogni modulo sia per 2.6 che per 2.4... i sorgenti dell'mkinitrd di debian da cui estrapolare le porzioni è qui http://ftp.de.debian.org/debian/pool/ma ... 4.2.tar.gz ... non capisco bene come funziona... questo perchè nell'mkinitrd di slack11 che voglio supportare non c'è il calcolo automatico delle dipendenze... quindi il wrapper di kernelpkg deve essere in grado di farlo.
Codice: Seleziona tutto
modprobe --set-version $KERNEL_VERSION --show-depends $MODULE_NAME
M
- submax82
- Staff

- Messaggi: 3202
- Iscritto il: mer 31 ago 2005, 0:00
- Desktop: xfce
- Distribuzione: SalixOS
- Contatta:
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.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!
no io prendo come riferimento l'mkinitrd di slackware 11.0 perchè è l'ultima release che supporta il kernel 2.4 quindi voglio che kernelpkg funzioni a partire dalla 11.0 in poi...no mkinitrd della 12.0 indovina da solo il filesystem della root corrente e risolve le dipendenze dei moduli (con modprobe) puoi emulare quel comportamento facendo una specie di backporting. basta che il tipo che si vuol fare l'initrd o non passi alcun dato al wrapper e quindi lasci che il wrapper prenda il filesystem e la root corrente, oppure il tipo passi il filesystem e la root del pc su cui vorrà installare il kernel e il wrapper risolve le dipendenze su misura.
il wrapper viene lanciato sul pc dove verrà installato il pacchetto... quindi sarà compito suo rilevare root e tipo di fs... questo perchè è nel doinst.sh di kernel-image... quindi sarà tutto automatizzato.
Per le dipendenze devo includere la procedura perchè l'mkinitrd di slackware 11 non le risolve... per il 2.6 ho capito come funziona... e cioè come hai detto tu
Codice: Seleziona tutto
modprobe --set-version $KERNEL_VERSION --show-depends $MODULE_NAME
qui non sono d'accordo. A mio parere funziona sicuramnete così perchè altrimenti se uno fà l'initrd il file /etc/rc.d/rc.modules-2.6.23.12 non servirebbe a nulla... e proprio perchè dovrebbe funzionare come ho detto fare un initrd bello "pieno" è completamente diverso che fare un kernel built-in ... questo perchè i moduli caricati dall'initrd sono solo temporanei e servono solo per far bootare il pc ... ma poi vengono scaricati e caricati i moduli "veri" dall'rc.modules... quindi l'effetto sarebbe mooolto diverso.non lo so... devo controllare. potrebbe non saprei ... ti faccio sapere! il fatto di fare su misura l'initrd è dovuto più che altro al fatto che se uno si deve caricare l'impossibile nell'initrd, allora tanto vale che si tenga un kernel con built in tutti sti aggeggi!
- nuitari
- Linux 3.x

- Messaggi: 777
- Iscritto il: dom 14 ott 2007, 12:51
- Slackware: 12.0
- Località: San Colombano al Lambro
- Contatta:
Ehhh???? Guarda che ti sbagli. I moduli caricati nell'initrd non vengono più *scaricati*, dove l'hai letta questa cosa?submax82 ha scritto:questo perchè i moduli caricati dall'initrd sono solo temporanei e servono solo per far bootare il pc ... ma poi vengono scaricati e caricati i moduli "veri" dall'rc.modules... quindi l'effetto sarebbe mooolto diverso.
Lo scopo dell'initrd è fornire al kernel accesso a funzionalità nel cosiddetto "early boot process", e solo questo.
E' utile quando sono necessarie inizializzazioni pre-init, come nel caso di raid, LVM etc.
Tutto il resto è fuffa. Si si può usare per caricare moduli del filesystem od altro, ma il motivo per cui viene generalmente fatto è che la gente crea kernel iper-modulari per i kernel standard delle distro, tutto qui.
Per il resto, non ti basta verificare eventualmente nei moduli caricati dall'utente? O fare una procedura post-install che fa il probe dei moduli e si segna quelli che ha caricato e quelli che non ha caricato, sistemando l'initrd di conseguenza?
- submax82
- Staff

- Messaggi: 3202
- Iscritto il: mer 31 ago 2005, 0:00
- Desktop: xfce
- Distribuzione: SalixOS
- Contatta:
prova a fare un initrd che contiene mooolti moduli... poi fai lsmod quando il sistema è caricato... io nelle mie prove non gli vedo più... ma vedo solo quelli specificati in rc.modules....nuitari ha scritto:Ehhh???? Stai scherzando vero?submax82 ha scritto:questo perchè i moduli caricati dall'initrd sono solo temporanei e servono solo per far bootare il pc ... ma poi vengono scaricati e caricati i moduli "veri" dall'rc.modules... quindi l'effetto sarebbe mooolto diverso.
I moduli caricati nell'initrd non vengono più *scaricati*, dove l'hai letta questa cosa?
io parlo per quello che capisco... non sono detentore della verità assoluta
- nuitari
- Linux 3.x

- Messaggi: 777
- Iscritto il: dom 14 ott 2007, 12:51
- Slackware: 12.0
- Località: San Colombano al Lambro
- Contatta:
eheh si no, non volevo mica dire che devi sapere tutto ^^ è che ero stupito tutto li.
Il motivo per cui non vedi tutti i driver che metti nell'initrd è che lui carica solo quelli che gli servono, che può *bindare* all'hardware, il che può includere tutti quelli che hai dentro modprobe.conf così come quelli che vengono caricati dal kernel in automatico se l'opzione relativa è attivata.
Fidati, quei moduli non vengono unloadati dopo l'avvio dell'initrd. A parte che per alcuni non è possibile e sarebbe controproducente (tipo quelli sul chipset), in ogni caso puoi verificarlo guardando gli script, in cui non c'è una parte relativa all'unloading dei moduli (e lui fa quel che c'è negli script, non è che fa altre operazioni *nascoste*).
Il motivo per cui non vedi tutti i driver che metti nell'initrd è che lui carica solo quelli che gli servono, che può *bindare* all'hardware, il che può includere tutti quelli che hai dentro modprobe.conf così come quelli che vengono caricati dal kernel in automatico se l'opzione relativa è attivata.
Fidati, quei moduli non vengono unloadati dopo l'avvio dell'initrd. A parte che per alcuni non è possibile e sarebbe controproducente (tipo quelli sul chipset), in ogni caso puoi verificarlo guardando gli script, in cui non c'è una parte relativa all'unloading dei moduli (e lui fa quel che c'è negli script, non è che fa altre operazioni *nascoste*).
- absinthe
- Iper Master

- Messaggi: 2354
- Iscritto il: dom 15 mag 2005, 0:00
- Nome Cognome: Matteo Nunziati
- Slackware: 12.1 - defunct
- Kernel: 2.6.32-5-amd64
- Desktop: gnome
- Distribuzione: debian squeeze
- Località: Prato
- Contatta:
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!!!submax82 ha scritto: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.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!
io intendevo dire che puoi vedere come fa lo script di Pat e inserire quelle righe nel tuo wrapper: per la 12.0 saranno ridondanti ma aggiungi tale funzionalità che manca nell'initrd della 11.0!no io prendo come riferimento l'mkinitrd di slackware 11.0 perchè è l'ultima release che supporta il kernel 2.4 quindi voglio che kernelpkg funzioni a partire dalla 11.0 in poi...no mkinitrd della 12.0 indovina da solo il filesystem della root corrente e risolve le dipendenze dei moduli (con modprobe) puoi emulare quel comportamento facendo una specie di backporting. basta che il tipo che si vuol fare l'initrd o non passi alcun dato al wrapper e quindi lasci che il wrapper prenda il filesystem e la root corrente, oppure il tipo passi il filesystem e la root del pc su cui vorrà installare il kernel e il wrapper risolve le dipendenze su misura.
mmm. ingoro la cosa: se ce la faccio (sono già a lavoroper il 2.4 funziona in modo diverso... infatti se vedi l'mkinitrd di debian c'è la procedura separata per il 2.4 ma non riesco a capirla.... per modificarla...
M