Thema: (Gelöst) Vanilla-Kernel selbst kompilieren

Hi,

ich hab mich heute mal ans Kernel kompilieren getraut.
Nachdem ich ca. 1h lang mit dem configmenü verbracht habe, und der Kernel jetzt schon ne halbe stunde am "bauen" ist, hätt ich da mal ne Frage fürs nächste Mal:
Gibt es nicht irgeneine Möglichkeit, das Ganze zu beschleunigen?
Muss der mich wirklich jeden verdammten Treiber abfragen, der im Kernel-Paket vorhanden ist?
Ich hab irgendwo über Google gefunden, dass die .config da hilfreich sein könnte, aber nicht wie.

Du möchtest Dir das hier ansehen:

http://www.thomashertweck.de/kernel26.html

Code:

make oldconfig

make cloneconfig

wären da auch noch als Stichworte zu nennen.

Greetz,

RM

P.S.

Code:

uname -r 
2.6.18

*g*

Aaaaalso....
System ist gebootet mit dem neuen Kernel und 256³ Fehlermeldungen

Code:

FATAL: Module ip_tables not found.
iptables v1.3.3: can't initialize iptables table `filter': iptables who? (do you need to insmod?)
Perhaps iptables or your kernel needs to be upgraded.

iptables 1.3.3 sind aber natürlich installiert.
Kann ich die meldung ignorieren (ich denke mal nicht).
Ansonsten war das Kompilieren weit weniger schlimm, als ich dachte.

Code:

uname -r
2.6.17.13

Passt soweit!

Nein kann man nicht ignorieren.

Bei 2.6.17 hat sich AFAIR die Konfiguration von netfilter/iptables geändert.

Code:

cat .config|grep -i netfilter #==> Logischerweise im Verzeichnis der entpackten Quellen ausgeführt

cat .config|grep -i tables

Ausgaben posten.

Ich tippe mal, die neuen Einstellungen wurden nicht gesetzt, bei make cloneconfig werden nicht mehr vorhandene Einstellungen verworfen, bei make oldconfig werden zumindest die neuen Einstellungen abgefragt.

Greetz,

RM

cat .config|grep -i netfilter

Code:

CONFIG_NETFILTER=y
# CONFIG_NETFILTER_DEBUG is not set
CONFIG_BRIDGE_NETFILTER=y
# Core Netfilter Configuration
# CONFIG_NETFILTER_NETLINK is not set
# CONFIG_NETFILTER_XTABLES is not set
# IP: Netfilter Configuration
# IPv6: Netfilter Configuration (EXPERIMENTAL)
# DECnet: Netfilter Configuration
# Bridge: Netfilter Configuration

cat .config|grep -i tables

Code:

CONFIG_IP_MULTIPLE_TABLES=y
# CONFIG_NETFILTER_XTABLES is not set
CONFIG_BRIDGE_NF_EBTABLES=m

Büdde sag jetzt nicht "neu komplilieren"
Ich mag irgenwann heut doch noch mal ins Bett.

Zitat von Ministry

Code:

CONFIG_NETFILTER=y
# CONFIG_NETFILTER_DEBUG is not set
CONFIG_BRIDGE_NETFILTER=y
# Core Netfilter Configuration
# CONFIG_NETFILTER_NETLINK is not set
# CONFIG_NETFILTER_XTABLES is not set
# IP: Netfilter Configuration
# IPv6: Netfilter Configuration (EXPERIMENTAL)
# DECnet: Netfilter Configuration
# Bridge: Netfilter Configuration
Server:/usr/src/linux # cat .config|grep -i tables
CONFIG_IP_MULTIPLE_TABLES=y
# CONFIG_NETFILTER_XTABLES is not set
CONFIG_BRIDGE_NF_EBTABLES=m

Da haben wir den Übeltäter.

Code:

make menuconfig

Networking  --->

Networking options  --->
[*] Network packet filtering (replaces ipchains)  --->

#==>  Falls das leer ist, dann unbedingt so lange auf Leertaste drücken, 
bis ein "*" erscheint.

Core Netfilter Configuration  --->   

<*> Netfilter Xtables support (required for ip_tables)     (siehe OBEN "*")

So sieht das bei mir aus:

Code:

M> Netfilter netlink interface                                      │ │
  │ │<M>   Netfilter NFQUEUE over NFNETLINK interface                     │ │
  │ │<M>   Netfilter LOG over NFNETLINK interface                         │ │
  │ │<*> Netfilter Xtables support (required for ip_tables)               │ │
  │ │<M>   "CLASSIFY" target support                                      │ │
  │ │< >   "CONNMARK" target support                                      │ │
  │ │<M>   "MARK" target support                                          │ │
  │ │<M>   "NFQUEUE" target Support                                       │ │
  │ │< >   "NOTRACK" target support                                       │ │
  │ │< >   "SECMARK" target support

Mit "/" kann man übrigens nach einer Einstellung suchen lassen.

Zitat von make menuconfig

────────────────────── Linux Kernel Configuration ───────────────
│ Arrow keys navigate the menu. <Enter> selects submenus --->. │
│ Highlighted letters are hotkeys. Pressing <Y> includes, <N> excludes, │
│ <M> modularizes features. Press <Esc><Esc> to exit, <?> for Help, </> │
│ for Search. Legend:[*] built-in [ ] excluded <M> module < > │

Code:

Linux Kernel v2.6.18 Configuration
 ──────────────────────────────────────────────────────────────────────────────





  ┌──────────────────── Search Configuration Parameter ─────────────────────┐
  │        Enter CONFIG_ (sub)string to search for (omit CONFIG_)           │
  │ ┌─────────────────────────────────────────────────────────────────────┐ │
  │ │                                                                     │ │
  │ └─────────────────────────────────────────────────────────────────────┘ │
  │                                                                         │
  │                                                                         │
  ├─────────────────────────────────────────────────────────────────────────┤
  │                         <  Ok  >      < Help >                          │
  └─────────────────────────────────────────────────────────────────────────┘

"XTABLES" eingetippt:

Code:

Linux Kernel v2.6.18 Configuration
 ──────────────────────────────────────────────────────────────────────────────
  ┌──────────────────────────── Search Results ─────────────────────────────┐
  │ Symbol: NETFILTER_XTABLES [=y]                                          │
  │ Prompt: Netfilter Xtables support (required for ip_tables)              │
  │   Defined at net/netfilter/Kconfig:117                                  │
  │   Depends on: NET && NETFILTER                                          │
  │   Location:                                                             │
  │     -> Networking                                                       │
  │       -> Networking support (NET [=y])                                  │
  │         -> Networking options                                           │
  │           -> Network packet filtering (replaces ipchains) (NETFILTER [= │
  │             -> Core Netfilter Configuration                             │
  │                                                                         │
  │                                                                         │
  │                                                                         │
  │                                                                         │
  │                                                                         │
  │                                                                         │
  ├─────────────────────────────────────────────────────────────────(100%)──┤
  │                                < Exit >                                 │
  └─────────────────────────────────────────────────────────────────────────┘

"Und der Weg ward ihm gewiesen" (Amen *g*).

Zitat von Ministry

Büdde sag jetzt nicht "neu komplilieren"

Was denn sonst? Alles was "Y" gesetzt ist, wird fest in den Kernel reinkompiliert, deshalb muß der Kernel selbst auch neu kompiliert werden.
Das "make" selbst dauert sicher nicht lange (vielleicht 10-15 Minuten).

Allerdings dürfte das

Code:

make modules

was erfahrungsgemäß deutlich länger dauert, nur noch ein paar Minuten dauern, wenn überhaupt, da (IIRC) nur die Änderungen neu kompiliert werden.

Zitat von Ministry

Ich mag irgenwann heut doch noch mal ins Bett.

Niemand zwingt Dich dazu, aber mit dem Kernel ist es wie mit der Million, die erste ist immer die schwerste.

Der 2.6.18er, der hier läuft, war keine 15 Minuten "Arbeit".

Code:

make oldconfig

Etwa 50-60 Änderungen, die meisten einfach mit <ENTER> auf den vorgeschlagenen Werten gelassen (5 Minuten), dann

Code:

make && make modules

10 Sekunden eintippen ==> Kaffee Trinken gegangen.

Code:

su

make modules_install

wieder 10 Sekunden eintippen ==> Kleine Zigarettenpause.

Kernel kopieren, INITRD schreiben, GRUB anpassen (vielleicht 5 Minuten).

Neustart und schön die Meldungen angeschaut (3 Minuten).

Code:

uname -a
Linux Adamantan 2.6.18 #1 SMP PREEMPT Wed Sep 20 12:23:27 CEST 2006 i686 GNU/Linux

==> Läuft.

Greetz,

RM

soderle...
Ich bin jetzt zum dritten Mal heute dabei, das make durchlaufen zu lassen.
Ich hoffe, dass sich das Problem danach erledigt hat.
Nun noch ne ganz andere Frage :
Inwieweit bringt es Performance-Gewinn, wenn ich sachen, die ich nicht brauche (ISDN, USB, usw) komplett aus dem Kernel entferne?
Auf meinem kleinem Testserver brauch ich wirklich keine Sound-Unterstützung, ne ISDN-Karte hat er nicht, und die USB-Ports werden nie genutzt.
Aber lohnt sich das? (Aufwand vs. Nutzen)

In den meisten Fällen bringt das wenig bis nichts, da Hardware, welche nicht unbedingt zum Start des Systems benötigt wird, über Kernelmodule angesprochen wird, welche dann eh nur zur Laufzeit geladen werden, also dann, wenn benötigt.

Wenn man da was rausholen will, muß man meist sehr gut über die eigene Hardware und die Kernelkonfiguration bescheid wissen.

Wenn Deine Hardware vom mitgelieferten Distributionskernel unterstützt wird, dann lohnt es sich meist eh nicht.

Performancegewinn lässt sich sehr viel besser durch das gezielte Abschalten nicht benötigter Systemdienste erzielen, Stichwort Runlevel-Editor.

Außerdem sind SuSE-Kernel meist recht stark gepatcht und ich habe mir gestern den Spaß gemacht, mal einen mit "make oldconfig" aus den aktuellen Quellen des 2.6.18er einen Kernel für meine 10.1 zu basteln.

AppArmor wird z.B. nicht unterstützt (bzw. einige Module wie "securityfs"), der Automounter scheint bei mir auch Probleme zu machen und schneller läuft der neue Kernel auch nicht.

Einen eigenen Kernel zu bauen ist zumindest in den meisten Fällen nur ein Testgelände zum Üben und "Linux lernen".

Auf meinem (K)Ubuntu hingegen kommt der Vanilla-Kernel besser klar, wahrscheinlich sind dort weniger oder zumindest andere Patches eingepflegt worden, so daß es zu keinen Ausfällen kommt (AppArmor gibt es da z.B. gar nicht, eigentlich logisch, ist ja auch eine Novell/SuSE-Entwicklung).

Warum allerdings der Automounter besser funktioniert als mit einem Vanilla-Kernel unter SuSE 10.1 kann ich jetzt auch nicht sagen, da müsste ich mal genauer nachforschen.

Ein weiterer Grund auf einem SERVER einen eigenen Kernel zu bauen, ist das Einbauen von Sicherheitsoptionen wie z.B. "Selinux" o.ä., dazu braucht man aber wirklich gute Kenntnisse.

Greetz,

RM

Naja...im Prinzip ist mein "Test-Server" ja nix anderes als ein Übungsgelände.
Ich hab deshalb das Kernelupdate "geübt", weil ich mal ein bischen mit debian rumspielen wollte und deshalb einen VServer anlegen wollte....
Alles spielereien, die aber hoffentlich helfen Linux an sich besser zu kapieren, weil doch viel Konsolenarbeit nötig ist.

Code:

  CC [M]  drivers/net/irda/ali-ircc.o
drivers/net/irda/ali-ircc.c: In function 'ali_ircc_cleanup':
drivers/net/irda/ali-ircc.c:232: warning: 'pm_unregister_all' is deprecated (declared at include/linux/pm_legacy.h:21)
drivers/net/irda/ali-ircc.c: In function 'ali_ircc_open':
drivers/net/irda/ali-ircc.c:361: warning: 'pm_register' is deprecated (declared at include/linux/pm_legacy.h:16)
  CC [M]  drivers/net/irda/vlsi_ir.o

Das sind aktuell meine Fehlermeldungen beim Kompilieren...wobei ich sowieso nix mit Infrarot am Hut hab. Zumindest sowas könnte man dann doch "rausschmeissen".
Und zu welchem Zweck ich Tokenring-Adapter unterstützen soll, ist mir auch rätselhaft.

Der letzte Kernel hat übrigens auch wieder Fehlermeldungen gebracht:

Code:

FATAL: Module ip6table_mangle not fund

und

Code:

iptables: No chain/target/match by that name

Mal gucken was nach diesem Durchlauf ist.
Sollte jetzt hoffentlich funktionieren.

Nur zur Klärung:

Code:

CC [M]  drivers/net/irda/ali-ircc.o
drivers/net/irda/ali-ircc.c: In function 'ali_ircc_cleanup':
drivers/net/irda/ali-ircc.c:232: warning: 'pm_unregister_all' is deprecated (declared at include/linux/pm_legacy.h:21)
drivers/net/irda/ali-ircc.c: In function 'ali_ircc_open':
drivers/net/irda/ali-ircc.c:361: warning: 'pm_register' is deprecated (declared at include/linux/pm_legacy.h:16)
  CC [M]  drivers/net/irda/vlsi_ir.o

Zitat von Ministry

Das sind aktuell meine Fehlermeldungen beim Kompilieren...

Falsch, das sind nur "Warnings", wahrscheinlich weil eine c-Funktion in der Datei "ali-ircc.c" veraltet ist und nicht mehr verwendet wird, aber immer noch im Quellcode der Datei vorhanden ist. Das ist ganz normal, ein Kompiliervorgang OHNE Warnings würde mich eher stutzig machen.

Greetz,

RM