Hey zusammen!

Hat wer von euch schonmal einen Kernel compilliert??

Ja. Was ist die Frage?

Was muss man da genau machen? Hab gehört es soll so ziemlich kompliziert sein. Trozdem möchte ich es gerne wissen.

Das hier sollte Dir weiterhelfen.

mutze

Die Frage ist warum Du einen Kernel compilieren willst?

Meine ersten Kernel waren noch zu 2.0.X Zeiten und da musste noch viel gemacht werden. Mittlerweile sind die Kernel von den Distributoren so modular, dass man kaum noch Hand anlegen muss. Hier ein Ausschnitt aus dem Gentoo-Handbuch um Dir einen kleinen Einblick zu verschaffen und mit welchen Befehlen Du den Kernel baust.

http://www.gentoo.de/doc/de/handbook/handbook-x86.xml?part=1&chap=7
und auch noch ein Debianspezifisches http://www.desktop-linux.net/debkernel.htm

Es sieht schlimmer aus als es ist, natürlich immer schön vorsichtig, denn man kann sich natürlich das System zerschiessen. Aber wie alles im Leben, wenn man es nicht mal ausprobiert kann man auch nicht mitreden und das schöne an Linux ist, das man den Kernel auf seine eigene Hardware massschneidern kann.

Das sieht aber leicht veraltet aus - lilo, und „make bzimage“ - gibt es letzteres überhaupt noch bei 2.6? Und dann manuelle Installation, kein .deb?

Da gibt es für Ubuntu ein einfacheres Verfahren:

apt-get install linux-source-2.6.8.1 ncurses-dev build-essentials kernel-package
cd /usr/src
tar -xjf linux-source-2.6.8.1.tar.bz2
ln -s linux-source-2.6.8.1 linux (manchmal nützlich)
cd linux
cp /boot/config-2.6.8.1-3-386 .config
make menuconfig
(Konfiguration anpassen)
make kpkg --initrd binary
dpkg -i ../kernel-*

Und wenn man dann vielleicht eine Option vergessen hat oder noch ein Modul nachbauen will (ich deaktiviere meist erstmal versehentlich irgendwas wichtiges…)

make
make-kpkg --initrd binary
dpkg -i ../kernel-*

Wenn‘s nur um ein Modul ging, danach noch depmod -a ausführen, damit es gleich zur Verfügung steht.

{{{make modules_install install}}}und passt dann noch den Bootloader von Hand an. In diesem Fall ohne initrd!

Die Debianmethode sollte man sich nicht unbedingt angewöhnen. Falls man mal an einer anderen Distribution sitzt hat man hoffnungslos verloren.

Hey,

Danke für die zahlreichen Posts. Werde alles in ruhe durchlesen. Aber so weit ich gekommen bin ist der Kernel eine Art Treiberdatenbank. Oder liege ich da falsch?

Ich wollt einen Kernel kompillieren weil mein Akku von meinem Laptop nich richtig erkannt wurde. Was glaub ich am ACPI-Piloten liegt.

Aber wie gesagt, mal schauen

Hallo,
nen netten Text über die daseinsberechtigung des kernels findest du hier:
http://de.wikipedia.org/wiki/Linux-Kernel

Gruss,
lapalomino / Mirko

Marduk hat geschrieben:

Die Debianmethode sollte man sich nicht unbedingt angewöhnen. Falls man mal an einer anderen Distribution sitzt hat man hoffnungslos verloren.

Wieso das denn? Anleitungen für andere Distris oder das „Standardverfahren“ kann man doch bei Bedarf problemlos finden. Meist ist das Problem doch eher nicht die genaue Methode der Installation, sondern eher die richtige Konfiguration, oder? Nicht, daß das normale Verfahren wesentlich komplizierter wäre, aber es ist doch schön, wenn
- der ganze installierte Kram in der Paketverwaltung auftaucht - macht es übersichtlich und leicht zu deinstallieren
- man sich um die Anpassung der menu.lst nicht kümmern muß (vielleicht geht es nur mir so, aber ich vergesse das regelmäßig und muß dann auf die Grub-Konsole)

Aber es schadet natürlich nicht, wenn man das allgemeine Verfahren kennt, da kann ich Dir nur zustimmen.

(BTW: ich habe seit 2.6 (test9 ff) nie mehr make dep benutzt, und auch make clean schien nicht mehr nötig zu sein - hatte jedenfalls keine Probleme ohne. Zum Kompilieren der Kernels einschließlich der Module genügte immer ein einfaches „make“, was ja dann auch wieder nicht so schwer zu merken ist. Oder hab ich was falsch gemacht?)

droebbel hat geschrieben:

Wieso das denn? Anleitungen für andere Distris oder das „Standardverfahren“ kann man doch bei Bedarf problemlos finden.

Die Begründung ist ziemlich einfach, professionelle Faulheit
Anleitungen sollten generell Distributionsübergreifend sein, denn die Möglichkeit mal an einer anderen Distribution zu sitzen ist ziemlich hoch. Da lerne ich lieber eine Methode die immer und überall funktioniert statt eine Distributionstypische Methode zu erlernen.

So wie die Frage gestellt wurde ist davon auszugehen, das er/sie noch nie einen Kernel kompiliert hat, also gleich effizient lernen eine Methode die immer und überall funktioniert.

Meist ist das Problem doch eher nicht die genaue Methode der Installation, sondern eher die richtige Konfiguration, oder?

Kernel ist Kernel und wird überall gleich konfiguriert. Egal ob Ubuntu/Debian oder XY-Distribution.

Marduk hat geschrieben:

Anleitungen sollten generell Distributionsübergreifend sein, denn die Möglichkeit mal an einer anderen Distribution zu sitzen ist ziemlich hoch. Da lerne ich lieber eine Methode die immer und überall funktioniert statt eine Distributionstypische Methode zu erlernen.

ok, weg mit apt, und bitte auch kein ceckinstall mehr. Und dann vielleicht konsequenterweise gleich auch zu LFS wechseln, wenn man die Distributionswerkzeuge eh nicht nehmen will

Im Ernst: Wer das hier fragt, hat möglicherweise gar nicht den Ehrgeiz, massenhaft Kernel für beliebige Distributionen zu backen (sonst wäre die Frage hier nicht ganz gut platziert). Ich habe es jedenfalls so aufgefasst, daß es unter Ubuntu einen guten Grund gab, einen eigenen Kernel zu bauen. Dann schadet es nicht, über die für Ubuntu insgesamt am besten geeignete Methode Bescheid zu wissen. Auch aus Faulheit, aber für den nicht-professionellen Kernelbäcker.
In den Kernelquellen ist übrigens eine README-Datei, in der das allgemeine Vorgehen beschrieben wird. Insofern wird man wohl nirgendwo ganz ohne Hoffnung dastehen, solange man lesen kann.

Noch was: Beim Kernel mag sich das nicht auswirken, aber generell ist es doch eher suboptimal, Programme am Paketsystem vorbei zu installieren. Wollte ich jetzt eine Software auf einem rpm-basierten System installieren, würd ich eben kurz die manpage studieren, statt das einfach über make install zu machen. (ok, es gibt noch /usr/local)
Nachteil: man müsste drei Methoden beherrschen. Vorteil: ein leichter wartbares Ergebnis. Das wär‘s mir aber wert.

Kernel ist Kernel und wird überall gleich konfiguriert. Egal ob Ubuntu/Debian oder XY-Distribution.

Das wollte ich eigentlich sagen - wenn man das Hauptproblem gemeistert hat, wird man die Installation wohl auch noch hinbekommen. Bis auf das „modules_install“ ist es ja einigermaßen naheliegend.

Der Vollständigkeit halber passe ich aber meinen ersten Post mal an, so daß beide Methoden drin sind.

P.S.
Ich habe übrigens früher eine Menge Programme per Dreisprung installiert, und irgendwann dann doch entweder die Übersicht verloren, oder in irgendeiner Form ein Problem damit bekommen, daß die Paketverwaltung nichts davon wußte. Bezeichnest Du es wirklich als professionell, aus anfänglicher Faulheit die Möglichkeit späterer Komplikationen in Kauf zu nehmen?
Vielleicht war ich aber auch nur zu blöd - bin kein Profi Bin jedenfalls jetzt froh über Werkzeuge wie checkinstall und kernel-package.

nero.ch hat geschrieben:

Ich wollt einen Kernel kompillieren weil mein Akku von meinem Laptop nich richtig erkannt wurde. Was glaub ich am ACPI-Piloten liegt.

Das battery-Modul ist schon beim Standard-Kernel vorhanden, dafür musst Du nichts Neues bauen.
Wenn „modprobe acpi“ oder danach „modprobe battery“ nicht funktioniert, liegt das nicht am Kernel, sondern wahrscheinlich an einer fehlerhaften ACPI-Implementierung bei Deinem Notebook. Wenn acpi nicht lädt, oder nur das acpi-Modul lädt, das battery-modul aber nicht, versuch mal ohne acpi zu starten und apm zu verwenden. (irgendeine Kerneloption, die ich nicht im Kopf hab, die Du aber sicher irgendwo hier im Forum findest - noacpi oder so.)

(Hab hier vor mir ein Thinkpad X20, auf dem mit uraltem BIOS acpi nicht ging und der Batteriestand nur mit apm angezeigt wird. Mit dem neuesten BIOS funktioniert acpi aber perfekt.)

@droebbel Zustimmung! Auf einem debianbasierten System, sollte man sich debianisierte Methoden aneignen, oder man ist hoffnungslos verloren. Ein Debian hat viele Mechanismen, die nicht eins zu eins auf jedes „Kraut-und-Rüben-Linux“ zutreffen. Vieles ist so gut durchdacht (z.B. diversions, dpkg-reconfigure), dass es dem Admin eine Menge Arbeit abnimmt und die Wartbarkeit enorm erhöht.

CIh wusste nicht, dass es debianbasierende Methoden gibt , einen Kernel zu backen.
CIh hab mit Sonntag einen Kernel gebacken (normal Methode: make menuconfig, make bzImage modules modules_install) und irgendwie konnte ich dann den neukompilierten Kernle nicht booten. Irgendein Fehler beim einbinden des root-Dircetory (da stand noch was über VFS).

Dann muss ich wohl anfangen, den Kernel auf debianische Art zu backen

Grüße,
gismo