allg. Fragen [war: Buchstabenwirrwarr]

[novalix]

bei lilo bin ich mir nicht 100% sicher aber normalerweise solltest du keine haendischen aenderungen mehr vornehmen muessen. das erledigen die post-instalation-scripts, die kernel-package in das image einfuegt. zumindest bei grub laeuft das problemfrei, so das du sowohl images mit - als auch ohne - initrd paralell betreiben kannst.

niels

[jhr-online]

Ja, ich gebe zu, ich konnte nciht abwarten und habe es sowieso ausprobiert. Der Kernel bootet *proud* . Nun zum nächsten Punkt: Ich habe Minimalkonfiguration erstellt. Wie muss ich vorgehen, damit ich den gleichen Kernel neu mit menuconfig bearbeiten kann, um WLAN und so zu implementieren und den neu zu installieren, ohne dass die Installation abbricht. Es ist ja schließlich schon ein Kernel dieser Art da...

jhr

[novalix]

einfach in deinen fallback-kernel (2.6.8\) booten und die sourcen neu bearbeiten:

Code: Alles auswählen

cd /dahin/wo/die/sourcen/sind/linux-sources-2.6.15
make menuconfig (und immer schoen die hilfe lesen auch wenn man nur bahnhof versteht)
"sudo" make-kpkg clean
"sudo" make-kpkg --revision <was-anderes-als-das-letzte-mal> --append-to-version \
<ausdruck-von-besitzerstolz> kernel_image

revision ist 'n nettes feature, was dir erlaubt, verschiedene images der gleichen branch zu verwalten. falls du aber trotzdem probleme bei der installation hast (dpkg meckert ueber schon vorhandene modules usw.), einfach das alte image deinstallieren (du arbeitest ja unter 2.6.8\) und das neue image installieren.
happy hackin', niels

[jhr-online]

Kompiliert hatte ich beim letzten Mal so:

Code: Alles auswählen

make-kpkg kernel_image kernel_headers --revision.0.1
... *wart* *wart*
dpkg -i linux-headers-2.6.15_jhrbook.0.1_i386.deb
dpkg -i linux-image-2.6.15_jhrbook.0.1_i386.deb

Also gehe ich jetzt nach /usr/src/kernel-source-2.6.15 und mache dann

Code: Alles auswählen

make menuconfig
...
make-kpkg clean
make-kpkg kernel_image kernel_headers --revision.0.2
...
dpkg -i linux-headers-2.6.15_jhrbook.0.2_i386.deb
dpkg -i linux-image-2.6.15_jhrbook.0.2_i386.deb

Richtig? Und was soll

--append-to-version \
<ausdruck-von-besitzerstolz>

bedeuten bzw. bewirken?

jhr

[novalix]

Und was soll

--append-to-version \
<ausdruck-von-besitzerstolz>

bedeuten bzw. bewirken?

anscheinend hast du den anhang an die kernelversion (mein-laptop) in der kernel-conf eingetragen. das brauchst du nicht, wenn du make-kpkg verwendest. das flag --append-to-version kann das auch. ist egal, wie du das machst, aber benutz nicht beides.
zu deiner befehlszeile:
ueblich ist es nach dem befehl (make-kpkg) zuerst die argumente (--revision, --append-to-version, --applied-patches, etc..) aufzurufen und dann das target (kernel_image) zu nennen.
die kernel-header brauchst du nicht. die machen nichts. die liegen nur rum.
die dokumentation von kernel-package unter /usr/share/doc ist etwas unsortiert und teilweise kryptisch. die lektuere sollte dir dennoch einige konzepte naeher bringen. ansonsten - bitte nicht krumm nehmen - read the fine manual:

Code: Alles auswählen

man make-kpkg

und auch die ersten beiden referenzen kernel-pkg.conf und kernel-img.conf.
wenn du erst mal deinen (debian-) weg gefunden hast wirst du diese tools nicht mehr missen wollen, hand drauf.

niels

[jhr-online]

Sorry, war ein Fehler in meinem letzten Post. Es sollte beim Kernel-bauen natürlich

Code: Alles auswählen

--revision=jhrbook.0.1

heißen. So wie's da steht macht's keinen Sinn. Und gerade deswegen versteh ich das append-to-version nicht. Macht das dann nicht das gleiche? Bzw. welche Rolle spielt das für den Kernel?
man-page hab ich gelesen, wurde ich aber nicht wirklich schlauer durch

Thx bytheway! Kernel läuft (auch der zweite Anlauf), hab's so gemacht, wie ich oben geschrieben hab, nur das Netzwerk tut irgendwie noch nicht... Ich sollte mir meine Hardware nochmal genauer angucken...

jhr

[novalix]

hi,

nur noch eine kleine ergaenzung. der schalter revision ist dafuer gedacht die versionsnummer des kernel-branchs zu ergaenzen. damit macht man dpkg gluecklich. die debian kernel-maintainer nutzen das, um automatisch aktualisierbare ausgaben des gleichen kernel-branchs ins repository zu stellen (zb nach nem bugfix wird aus kernel x.y.z-1 x.y.z-2 ). bei einem nicht revisionierten custom-kernel wuerde apt diesen sofort durch einen neuen ersetzen, sobald die minorversion sich erhoeht. welchen string du benutzt ist letztlich egal (meistens sieht man in tutorials sowas wie custom.1.0 - manche machen auch lustige spielchen mit date), solange du die kernel nur fuer dich baust und den ueberblick behaelst.
der schalter append-to-version ist dagegen explizit dafuer vorgesehen dem kernel einen namen zu geben, der ihn fuer anwender identifizierbar macht. ist schon ein wenig wie:
eine fliege mit zwei klappen schlagen - aber aus unterschiedlichen richtungen.

ciao, niels

[jhr-online]

Ich finde, das ist auch eine allgemeine Frage, daher hänge ich die mal an diesen Thread an:
Sehe ich das richtig, dass wenn ich alle mit lsmod aufgeführten Module in den Kerneleinstellungen raussuche, diese dann fest einkompiliert werden, oder verwechsel ich da jetzt was? Falls ja, wird doch nicht weiter geladen; d.h. ich könnte das Laden von Modulen direkt im Kernel ausschalten, korrekt?

jhr

[novalix]

hi,

wenn ich dich jetzt richtig verstanden habe, dann zielt deine frage dahin, ob es moeglich ist einen kernel ganz ohne module zu bauen. im prinzip geht das und ist auch sinnvoll bei rechnern die ganz klar begrenzte aufgabenbereiche haben (zb. firewall-router). in diesem falle brauchst du natuerlich keine module-autoloader funktion.
letztlich gewaehrt dir die benutzung von loadable kernel modules - vor allen dingen auf desktopsystemen - allerdings ein groesseres mass an flexibilitaet, indem du treiber oder funktionen als module kompilierst, die du vielleicht spaeter einmal gebrauchen kannst (neues usb-device: 1. einfach modul laden <-> 2. neuen kernel kompilieren).
waehrend es meistens eine frage des geschmacks, oder der intendierten funktion ist, gibt es allerdings auch mitunter technische bedingungen:
1. ein kosequent modular erzeugter kernel erzwingt die verwendung einer initial ramdisk
2. manche treiber funktionieren nicht oder zicken rum, wenn sie fest einkompiliert sind
3. manche treiber (x) koennen zwar als modul geladen werden, setzen aber einen anderen treiber (y) voraus, und manchmal ist es schwierig die reihenfolge so festzulegen, dass y vor x startet. y fest einkompilieren ist in so nem fall ne gute alternative.

cu, niels

[jhr-online]

Meine Frage zielte letzten Endes darauf ab, ob es nicht sinnvoll wäre, die Module, die der Kernel sowieso bei jedem Start lädt, fest reinzukompilieren; dann muss er sich darüber "keine Gedanken mehr machen". Dann schaut man noch, was man evtl. braucht und nimmt es als Modul rein und den Rest schmeißt man raus. Das hätte dann doch den Vorteil eines sehr kleinen und folglich schnell bootenden Kernels, oder sehe ich das falsch?
Was mich aber auch interessiert, ist, wo er die Information hernimmt, welche Module zu laden sind. /etc/modules hat bei mir drei Module drin stehen, er scheint aber beim Booten erheblich mehr zu laden und zeigt auch einige Module an mit

Code: Alles auswählen

* Skipping <modul_name> ...

Woher nimmt er das?

jhr

[novalix]

Woher nimmt er das?
jhr

ehrlich gesagt: frag ich mich auch manchmal.
wenn ich so in der trueben suppe meines halbwissens rumkrame, foerdere ich folgende stichworte zu tage:
1. der autoloader schmeisst alles rein, was die hardware-detection bei der installation und ggf. danach root in die modules.conf eingetragen haben.
2. hotplug (aka udev) mischen da noch mit.
automagically
dementsprechend werden module, die zwar potentiell vorhanden sind aber momentan nicht gebraucht werden, erst dann geladen, wenn der bedarf besteht (hotplug- aka udev event). ansonsten stoeren sie, was die performance angeht, allerdings auch nicht weiter; liegen einfach nur rum. einen signifikanten geschwindigkeitsvorteil beim bootvorgang kannst du afaik nicht erwarten, wenn du alles, was deine hardware definitiv braucht, fest einkompilierst. ne andere sache ist es, wenn du gesteigerte sicherheitsbelange hast. da ist jeder unnoetige code-schnipsel auf dem system zu vermeiden. kernel-module sind ein beliebter ansatzpunkt fuer exploits.
letzlich ist zwischen weitgehend modular und vollkommen statisch jede variante vernuenftig, die fuer die jeweiligen aufgaben und deinen persoenlichen geschmack praktikabel erscheint.

ciao, niels