.config

[guennid]

Gehe ich recht in der Annahme, dass ich in diese Datei keine eigenen Kommentare schreiben kann?
Was passiert, wenn ich sie in den clon unter /boot schreibe und diesen clon wieder als als .config in /usr/src/linux benutze?

Grüße, Günther

[neuss]

Hallo,

die config-dein-kernel aus /boot ist ein guter Start als .config in /usr/src/linux.

Was passiert, wenn ich sie in den clon unter /boot schreibe und diesen clon wieder als als .config in /usr/src/linux benutze?

beschreibe dies bitte nochmal einfacher, was möchtest Du denn tun.

gruss neuss

[guennid]

Ich bin hier ziemlich heftig am rumprobieren mit einer einzigen Version (2.6.23.8 ), und um nicht vollends durcheinanderzugeraten, möchte ich mir Kommentare in die jeweilige config schreiben. Das habe ich irgendwann schon mal gemacht, und hatte das Gefühl, dass die beim Kompilieren beseitigt werden. Habe ich damals nicht genauer beachtet, weil nicht wichtig, aber jetzt brennt's. Wenn das nicht geht, muss ich mir was anderes einfallen lassen.

Grüße, Günther

[storm]

Code: Alles auswählen

$ head -n 2 .config
#
# Automatically generated make config: don't edit

Das hat doch einen Grund, warum das da drin steht. Wenn du dir etwas merken willst, schreib es in eine extra Datei. Falls du mit mehreren Kernel-images arbeitest und dabei zwischen zwei kerneln nur wenige Unterschiede erzeugst, kannst du auch gleich ein kernel mit einem entsprechenden Kürzel erstellen, Beispiel als ganze Befehlszeile:

Code: Alles auswählen

make-kpkg clean && make-kpkg --revision=c1 --append-to-version=-pxi2 --rootcmd fakeroot kernel_image

Der fertige Kernel heisst dann zB.: 2.6.23.8-pxi2

Die config, die du unter /boot findest, ist die .config im Quellverzeichnis des Kernels zum Zeitpunkt des Erstellens des Paketes. Je nach Befehl, den du zum Erzeugen eines neuen Kernels verwendest, wird sie neu erzeugt.

ciao, storm

[guennid]

Danke, storm.

Code: Alles auswählen

make-kpkg clean && make-kpkg --revision=c1 --append-to-version=-pxi2 --rootcmd fakeroot kernel_image

Da scheint mir noch einiger Ballast drin zu sein. Wo kann man sich über die Parameter von make-kpkg informieren? Eine man page habe ich nicht.

Grüße, Günther

[George Mason]

wie, Ballast? Meinste dein System läuft schneller, wenn du auf die Revision verzichtest?
Die Zeile ist schon richtig so... spätestens wenn du den gleichen Kernel noch einmal kompilierst, etwa weil Du einen Treiber vergessen hast, wirst Du merken, dass die Revisionsnummer eine gute Idee war...

Ansonsten gilt: google mal nach debian kernel kpkg 2.6

[GoKi]

Wo kann man sich über die Parameter von make-kpkg informieren? Eine man page habe ich nicht

kernel-package installieren, dann ist auch die manpage da.

[Spasswolf]

Man kann Buchstaben sparen, wenn man

Code: Alles auswählen

fakeroot make-kpkg ...

anstatt

Code: Alles auswählen

make-kpkg --rootcmd fakeroot ...

benutzt.

[guennid]

kernel-package installieren

Da magst du recht haben. Habe nicht dran gedacht, dass ich hier vor 'ner anderen Kiste sitze.

Also, so ganz der DAU bin ich auch nicht. Ich habe den Eindruck, ihr reitet hier eure persönlichen Steckenpferdchen.
Ich kann mir nicht vorstellen, dass ich fakeroot brauche. Ich sehe keinen Grund, warum ich einen kernel nicht als root bauen sollte. Und make-kpkg clean tut hier auch nichts zur Sache.

--rootcmd ist mir neu, aber ... siehe goki

Grüße, Günther

[edit]: Bin wieder zuhaus, ok, hab's geschnallt, make-kpkg ist hier also wegen "--append-to-version" doch vonnöten -- unglaublich!
Heißt für mich aber: Diesen Zirkus werde ich nicht veranstalten - ist mir zu fehlerträchtig.

Grüße, Günther

[novalix]

Hi Günther,

kurz zu fakeroot:
Da mit make-kpkg ein Debianpaket gebaut wird, haben sich die Autoren an die übliche Praxis für diese Tätigkeit gehalten. Verständlicherweise arbeiten Betreuer von Paketen an diesen nicht mit Rootrechten, sondern als normale user. Zur Erstellung der Pakete wird tar dazu angewiesen die enthatenen Dateien auf die UID 0 (also root) zu setzen, damit sichergestellt ist, dass auf jedem System, auf dem diese Software installiert werden soll, dies nur mit Rootrechten geschehen kann. "fakeroot" ist ein angepasstes Tool, dass genau diese Aufgabe beherrscht. Es ist aber natürlich auch möglich, diese Arbeit mit anderen Administrationswerkzeugen (sudo, su, ..) durchzuführen.
kurz zu make-kpkg clean:
Es ist ganz einfach unbedingt erforderlich, bevor das Image gebaut wird, die Sourcen aufzuräumen, sonst baust a Murks.
Zur initrd:
Ob Du Deine Kernel mit oder ohne baust, ist in den allermeisten Fällen Jacke wie Hose. Wenn Du aber einen Kernel ohne initrd baust, dann muss eben einiges, was im Debiankernel als Modul konfiguriert ist, fest einkompiliert werden. Im Zweifel eben lieber zu viel als zu wenig, aber allemal die Treiber für Deine Hardware und Dein Dateisystem.
Zur Revision:
Da Du ein Debianpaket eines Kernels erstellst, welches im Zweifelsfall auch in den original Repos vorhanden ist, besteht natürlich die Möglichkeit, dass Dein Kernelpaket bei einem dist-upgrade von einem möglicherweise aktualisierten Paket aus den Repos ausgetauscht wird. Deswegen erzeugt make-kpkg per Voreinstellung ein Paket mit der Revisionsnummer "10.00.custom". Damit bist Du erst mal aus dem Schneider. Es sei denn Du baust häufiger Kernelimages aus den selben Sourcen. In diesem Fall sei Dir angeraten das Revisionsmanagement händisch zu übernehmen.
Appendix:
Der Anhang an den Paketnamen ist in keiner Weise notwendig. Er macht die Sache aber hübsch übersichtlich, wenn man zB. Kernel für verschiedene Maschinen baut. Ein einfaches

Code: Alles auswählen

--append-to-version $NAME_DER_MASCHINE

ist dafür nicht zu viel verlangt.

ciao, niels

[Spasswolf]

[...]
Zur Erstellung der Pakete wird tar dazu angewiesen die enthaltenen Dateien auf die UID 0 (also root) zu setzen, damit sichergestellt ist, dass auf jedem System, auf dem diese Software installiert werden soll, dies nur mit Rootrechten geschehen kann.
[...]

Dass die Installation eines Debianpakets auf einem System Rootrechte erfordert, darf nicht von irgendwelchen Eigenschaften des Debianpakets abhängen.
Es geht nur darum das die Dateien den richtigen Eigentümer erhalten.

[novalix]

[...]
Zur Erstellung der Pakete wird tar dazu angewiesen die enthaltenen Dateien auf die UID 0 (also root) zu setzen, damit sichergestellt ist, dass auf jedem System, auf dem diese Software installiert werden soll, dies nur mit Rootrechten geschehen kann.
[...]

Dass die Installation eines Debianpakets auf einem System Rootrechte erfordert, darf nicht von irgendwelchen Eigenschaften des Debianpakets abhängen.
Es geht nur darum das die Dateien den richtigen Eigentümer erhalten.

Err .. richtig! Es geht um die Datenintegrietät. Man braucht Rootrechte, um den Bundestrojaner an ein Debianpaket anzuflanschen.

ciao, niels

[guennid]

"fakeroot" ist ein angepasstes Tool, dass genau diese Aufgabe beherrscht. Es ist aber natürlich auch möglich, diese Arbeit mit anderen Administrationswerkzeugen (sudo, su, ..) durchzuführen.

Und ich behaupte, das ist ein "Steckenpferdchen". Da mag für Kernelentwickler sinnvoll oder meinetwegen gar notwendig sein, das kann und will ich nicht beurteilen. Ich baue als user seit ca. vier Jahren kernel ohne sudo, fakeroot, etc. schlicht als root mit make-kpkg, ohne dass mir da Fehler aufgefallen wären.

Es ist ganz einfach unbedingt erforderlich, bevor das Image gebaut wird, die Sourcen aufzuräumen, sonst baust a Murks.

Das ist selbstverständlich und darum geht's gar nicht. Allerdings scheintst du da nicht ganz auf der Höhe der Zeit zu sein, denn wenn ich die manpage richtig verstanden habe, funktioniert ein

Ein einfaches

Code: Alles auswählen

--append-to-version $NAME_DER_MASCHINE

nicht, wenn ich nicht nach make menuconfig (nochmals) ein make-kpkg clean ausführe, auch wenn ich die Aufräumarbeiten bereits vorher erledigt gehabt zu haben galube. Das war mir auch neu, damit hatte ich nicht gerechnet.

Im Übrigen wird das hier eine sehr theoretische Diskussion, über "rechtgläubiges" kernelbauen, die mich wenig weiterbringt. Ich werde mir meine Notizen unabhängig vom Kernelbauen machen, denn bei dem hier von storm vorgeschlagenen Verfahren sehe ich mich schon zu viele Fehler machen. Punkt.

Wenn Du aber einen Kernel ohne initrd baust, dann muss eben einiges, was im Debiankernel als Modul konfiguriert ist, fest einkompiliert werden.

Das Problem ist hier das "einiges". Genau das weiß ich halt nicht sicher.

Ich poste euch mal die config meines "privaten" 2.6.23.8er (ohne initrd) nach nopaste. Der kernel bootet fehlerfrei. Wenn ich nicht eine DVD hätte anschauen wollen, wären mir im Leben keine Defizite aufgefallen: DMA lässt sich nicht aktivieren. Ich wäre euch - die ihr sicherlich vom kernel eine ganze Menge mehr versteht als ich - sehr dankbar, wenn ihr mir konkret sagen könntet, was ich fest in den kernel einbauen muss, um die initrd zu umgehen. Einen DMA-fähigen 2.6.23.8er "Monster"kernel (ca. 50 MB) auf der Basis der config eines 2.6.18-4-686-etch standard-kernels habe ich bereits.

Grüße, Günther

[storm]

Günther, kannst du bitte als Ergänzung noch die Ausgabe von lspci in's nopaste stellen?

ciao, storm

[guennid]

@storm
Kriegst du hier
Was mir hier vorgeschlagen wurde, scheint nicht auszureichen.

Grüße, Günther

[novalix]

Und ich behaupte, das ist ein "Steckenpferdchen".

Das ist es, was ich schrub.
Wenn Du eh root bist, brauchst Du diesen Schalter nicht.
Du musst Dich auch nicht um die Revision oder den Appendix kümmern, wenn es Dich nicht interessiert.
Was allerdings obligatorisch ist, ist das Aufräumen der Quellen vor dem Bau also nach der Konfiguration. Das kannst Du nur als gottgegeben akzeptieren. Da hilft auch keine Exegese diverser Bibeln.

ciao, niels

[storm]

Und ich behaupte, das ist ein "Steckenpferdchen". Da mag für Kernelentwickler sinnvoll oder meinetwegen gar notwendig sein, das kann und will ich nicht beurteilen. Ich baue als user seit ca. vier Jahren kernel ohne sudo, fakeroot, etc. schlicht als root mit make-kpkg, ohne dass mir da Fehler aufgefallen wären.

Natürlich kannst du das halten wie du möchtest, wenn du damit besser zurecht kommst bzw. damit der Befehl kürzer (und somit besser merkbar) ist, dann bleib einfach dabei. Ich hatte den nur so aus nem xterm rauskopiert, wo ich ihn seit einer halben Ewigkeit so nutze. Aber das ist nicht einfach nur ein Steckenpferd, sondern auch eine Frage der Disziplin (nur root, wenn alles andere nicht ausreicht!)

Ich werde mir meine Notizen unabhängig vom Kernelbauen machen, denn bei dem hier von storm vorgeschlagenen Verfahren sehe ich mich schon zu viele Fehler machen. Punkt.

Das ist doch eine einfache und gut zu merkende Befehlskette, oder nicht? Du kannst IMO bei dem oben angegebenen Befehl auch noch das --revision und --rootcmd weglassen, somit reduziert sich das Erstellen eines neuen Paketes auf:

Code: Alles auswählen

make menuconfig
.... (Ändern einiger Optionen, dann exit und save)
make-kpkg clean && make-kpkg --append-to-version=-foobar kernel_image

Und mit der bash kannst du dir per history den Befehl auch wiederholen und musst ihn nicht komplett neu eintippen. Oder missversteh ich dich hier? Selbst das --append-to-version kannst du weglassen, wenn du die Option CONFIG_LOCALVERSION nutzt. Letztlich ist das auch eine Frage des Geschmacks und der Gewöhnung. *g

+++

Jetzt zu den Sachen, die mir in deiner .config aufgefallen sind:

Code: Alles auswählen

CONFIG_BLK_DEV_CMD640
CONFIG_BLK_DEV_RZ1000
CONFIG_BLK_DEV_PIIX

kannst du wegwerfen, also entfernen. Dein Chipsatz (CONFIG_BLK_DEV_AMD74XX=m) ist schon richtig, allerdings solltest du den auf y setzen, also fix im kernel. Und die Option CONFIG_BLK_DEV_IDEPCI (PCI IDE chipset support) kreuzt du besser auch an, sonst kann das mit dem DMA auch nix werden.

Theoretisch könntest du die ganze Abteilung ATA/ATAPI/MFM/RLL support wegwerfen und alles mit libata machen, das ist die neuere Variante. Allerdings ändern sich dann auch die Bezeichnungen für die Laufwerke (hda->sda). Das kannst du dir ja für später vornehmen, wenn du mal Langeweile hast. *g

Weiterhin hast du als Prozessor den K7 in deiner .config, der lspci-Ausgabe zufolge aber einen K8, also Athlon64. Das ist zwar nicht weiter störend, aber da fehlen dann ein paar Erweiterungen im Kernel (die die CPU aber hat).

Wenn mir noch mehr auffällt, poste ich noch mal.

ciao, storm

[storm]

Und die Option CONFIG_BLK_DEV_IDEPCI (PCI IDE chipset support) kreuzt du besser auch an, sonst kann das mit dem DMA auch nix werden.

Argh, hab ich flasch gekuckt, die ist an.

[guennid]

Na Leute, ihr beschämt mich ja regelrecht. Dankeschön!!!
@storm:
CONFIG_BLK_DEV_IDEPCI hatte ich schon - wie im zweiten link angegeben - fest im kernel, aber ohne initrd hat der keine DMA-Unterstützung.
KBDCALLS hat vor ca. zweieinhalb Jahren mal hier was geschrieben, dass man die initrd auslesen könne:

Code: Alles auswählen

mount -o loop -t cramfs /boot/initrd-2.6.10-1-k7 /mnt

das hat aber bei mir nicht funktioniert.

cramfs veraltet?

In der /etc/modules habe ich u.a. diese Einträge gefunden:

Code: Alles auswählen

ide-cd
ide-disk
ide-generic
amd74xx

stören die, wenn da was von fest im kernel ist?

Grüße, Günther

[storm]

Noch was (in dem anderen Thread gesehen): da wurde vorgeschlagen:

CONFIG_BLK_DEV_AMD74XX=y

CONFIG_BLK_DEV_IDECD=y

also fix im kernel und deine Entgegneung war, dass das auch nix bringt, weil im anderen kernel (2.6.18) sind die auch als Module drin und da geht DMA. Richtig, aber der std-etch-kernel hat ja eine initrd, die du ja hier gerade loswerden willst. Also der springende Punkt ist der Unterschied:

kernel + module -> braucht initrd
...
kernel ohne initrd -> wichtige Treiber nicht als Module, sondern fest im kernel

Also beim Konfigurieren [y] statt [m].

(hoffentlich reden wir nicht aneinander vorbei *g)

ciao, storm

[guennid]

hoffentlich reden wir nicht aneinander vorbei

Sagen wir mal, es scheint noch Missverständnisse zu geben.

Was der Kollege da vorgeschlagen hat, habe ich umgesetzt: die genannten Module fest in den kernel (y) und kompiliert ohne initrd.

Code: Alles auswählen

# make-kpkg --revison=xyz linux-image

So mach ich das immer
Der so gebaute kernel bootete, aber DMA war nicht zu aktivieren.

Grüße, Günther

[storm]

Kannst du eventuell noch einen Ausschnitt aus dem syslog in's nopaste stellen und zwar von dem Kernel, der kein DMA anschalten will?

[guennid]

Also ich sag's ja es ist langsam verwirrend.
Deine Anforderung ist nicht eindeutig
Ich interpretiere sie mal so: Ich beabsichtige den syslog von dem kernel zu posten, bei dem ich die config des etch-standard zugrunde gelegt habe, den ich nur gemäß Tintoms Empfehlungen abgeändert und ohne initrd gebaut habe. Es ist also in meinem Verständnis ein leicht variierter etch-standard. Du kriegst ihn, wenn ich neu installiert und gebootet habe.

Bitte um etwas Geduld

Grüße, Günther

[guennid]

Bitteschön, hierist er.
Ich habe den kompletten letzten bootvorgang genommen.

Grüße, Günther

[storm]

Also stutzig machen die folgenden Zeilen (die letzten zwei):

Code: Alles auswählen

Nov 22 22:25:35 tux1 kernel: NFORCE-MCP61: IDE controller at PCI slot 0000:00:06.0
Nov 22 22:25:35 tux1 kernel: NFORCE-MCP61: chipset revision 162
Nov 22 22:25:35 tux1 kernel: NFORCE-MCP61: not 100%% native mode: will probe irqs later
Nov 22 22:25:35 tux1 kernel: NFORCE-MCP61: 0000:00:06.0 (rev a2) UDMA133 controller
Nov 22 22:25:35 tux1 kernel: NFORCE-MCP61: port 0x01f0 already claimed by ide0
Nov 22 22:25:35 tux1 kernel: NFORCE-MCP61: neither IDE port enabled (BIOS)

Die Suche mittels der direkten Eingabe der Zeile mit 'already claimed' brachte auch sofort einen Treffer im mandriva-bugtracker. Erstaunlicherweise hat der Bug-Reporter sogar das gleiche DVD-Laufwerk wie du. Als Fix wird da vorgeschlagen:
ersetze:

Code: Alles auswählen

     install ide-controller /sbin/modprobe ide_generic; /sbin/modprobe amd74xx; /bin/true

mit

Code: Alles auswählen

    install ide-controller /sbin/modprobe amd74xx; /bin/true

Diese Einträge befinden sich bei mandriva in /etc/modprobe.conf; bei debian (wenn vorhanden) in /etc/modprobe.c/*: das heisst, du müsstest mal in diesem Verzeichnis die Dateien untersuchen, ob in irgendeiner diese Zeilen vorkommen, und wenn ja die Ersetzung vornehmen. Oder du erstellst noch mal einen Kernel ohne IDE_GENERIC, dann musst du nicht extra in den Dateien rumeditieren und hast einen sauberen kernel. Vielleicht reicht es auch zum Testen ide_generic zu blacklisten:

Code: Alles auswählen

grep ide_generic /lib/modules/`uname -r`/modules.alias | sed 's/ide_generic/off/' > /etc/modprobe.d/ide_generic

Die Befehlszeile ist hier eigentlich overkill, da sie für boot-only Treiber keinen weiteren Nutzen bringt. Aber das Modul ist trotzdem erstmal für das automatische Laden durch udev gesperrt.

Böderweise kann es aber auch passieren, dass der Fix bei dir nicht funktioniert, der Reporter hat nur das DVD-Laufwerk am IDE und sonst nur eine Platte am SATA. Aber probier das erstmal. Vielleicht haut das dann hin. :)


ciao, storm