Progetto Kernelpkg Tool

[submax82]

grazie sto impazzendo con il supporto a initrd che forse aggiungo... è un sistema automatico che mi piacerebbe fare...

[submax82]

nessuno mi dà un'aiuto con il supporto a initrd ... sarebbe una creazione automatica dello stesso... ?!?!?

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


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...

[nuitari]

Che cosa ti serve sull'initrd?

[submax82]

Che cosa ti serve sull'initrd?

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....

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

BUON ANNO!

ora aiutatemi per l'initrd!!!

[nuitari]

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 ^^

[submax82]

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.

già kernelpkg lo fà ... la procedura sopra mi serve solo come prova! ... cioè è solo uno script di test...

Inoltre, non hai considerato LVM (opzione -L di mkinitrd).

una cosa alla volta! ... se poi qualcuno mi vuole dare una mano... visto che per ora non ho idea di come fare

I messaggi dovresti vederli con dmesg, difficilmente visualizza altri messaggi che non siano relativi al kernel, l'initrd.

ma dmesg non visualizza solo i messaggi del kernel ? anche quelli dell'initrd? devo ancora capire bene bene come funziona...

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 ^^

quella derivata da debian è sopra... la mia fà un pò pietà...

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


sono sempre script di prova embrionali....

[nuitari]

già kernelpkg lo fà ... la procedura sopra mi serve solo come prova! ... cioè è solo uno script di test...

Capito ^^

una cosa alla volta! ... se poi qualcuno mi vuole dare una mano... visto che per ora non ho idea di come fare

Non è una cosa difficile. con il comando lvs visualizzi le info sui volumi presenti (lvs per una spiega delle opzioni)
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.

ma dmesg non visualizza solo i messaggi del kernel ? anche quelli dell'initrd? devo ancora capire bene bene come funziona...

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.

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 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.
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.

quella derivata da debian è sopra... la mia fà un pò pietà...

Ora la guardo con calma.

[absinthe]

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:

Codice: Seleziona tutto

Using /lib/modules/2.6.21.5-smp/kernel/drivers/block/DAC960.ko


oppure sono errori, tipo quando a me cerca di caricare il driver per lo scsi che non esiste sul mio laptop!

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


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

[submax82]

grazie absinthe!!!! ... sarebbe interessante affinare per quanto possibile la procedura ... appena posso leggo la mail!!! grazie ancora ottimo test!!!

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!

sarebbe interessante fare procedure alternative e poi valutare tutti i vantaggi/svantaggi di ogniuna e decidere... quale inserire in kernelpkg 0.8.0

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]

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...

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!
non so però come si comporti con supporti scasi, controller raid etc!

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.

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.
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!

Per rdev scusami ma non sò bene a cosa serva...

man rdev

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???

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!

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.

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 con

Codice: Seleziona tutto

modprobe --set-version $KERNEL_VERSION --show-depends $MODULE_NAME


con il 2.4 non funziona?

M

[submax82]

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.

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.

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...

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


per 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...

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!

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.

[nuitari]

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.

Ehhh???? Guarda che ti sbagli. I moduli caricati nell'initrd non vengono più *scaricati*, dove l'hai letta questa cosa?

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]

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.

Ehhh???? Stai scherzando vero?
I moduli caricati nell'initrd non vengono più *scaricati*, dove l'hai letta questa cosa?

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....

io parlo per quello che capisco... non sono detentore della verità assoluta altrimenti non avrei aperto questa discussione

[nuitari]

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*).

[absinthe]

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.

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!!!

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.

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...

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!

per 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...

mmm. ingoro la cosa: se ce la faccio (sono già a lavoro ) do un occhio!

M