hm, ich hab es ja fast geahnt!
Code:
debian2:/usr/src/linux-source-2.6.21# make menuconfig
HOSTCC scripts/kconfig/lxdialog/checklist.o
In file included from scripts/kconfig/lxdialog/checklist.c:24:
scripts/kconfig/lxdialog/dialog.h:32:20: error: curses.h: Datei oder Verzeichnis nicht gefunden
Dir fehlt die Library mit den Headern der exports fuer das Konfigurationsmenu, wohl libncurses5-dev...um es kurz mal zusammenzufassen.
Kernel(Binary-)bau:
Du brauchst den Quellcode, auch Sourcen genannt, des Binaries - hier linux-source-<kernel-version-number> .
Du brauchst die binutils/autoconf/automake, also eine Toolchain (Werkzeugkette
) welche sich in GNU entwickelt hat um Einstellungen an den Sourcen vorzunehmen, und um den Build-Vorgan zu steuern, was je nach Hardware-/Betriebssystem-Grundlage verschieden sein kann.
Dann brauchst du ggf. Helpers, ein Werkzeug, das ein Entwickler aufgrund seiner Neigung bevorzugt um einen speziellen Task zu bewerkstelligen der nicht unbedingt "normal" ist bei einem Binary-Bau; hier z.B. die ncurses-Library welche (denke ich glauben zu duerfen) fuer die User - Ein-/Aus-gabe beim Konfigurationsdialog benutzt wird. Das waere z.B. nicht noetig wenn du make xconfig, oder make config genommen haettest. Aber make config ist ECHT nicht empfehlenswert; xconfig, wenn man mal die ncurses-Variante kennt zwar grundsaetzlich sehr Aehnlich, aber auf einem Server oftmals unpraktikabel ist, weil es als X-Client, der dann auf dem Server die xlib und anderes (mit eben mehr overhead gegenueber ncurses) erfordern wuerde, nun nicht die Wahl der Wahl darstellt.
Und du brauchst einen Compiler, hier wohl gcc; mit eigenen helpers, wie z.B. gpp (preprozessor, also ein Programm das den Quellcode in ein Format Aufloest ( heisst header-Dateien einbindet, #define's ersetzt usw.) das der Compiler schluckt, und einen Assembler (as ?) der den Assembler-Code den gcc erstellt ( ja, der erstellt assembler-Code soweit ich weiss ) in Object-/Maschinen-code "uebersetzt" , und einen Linker (ld glaub ich) der die Objectdateien in ein fuer das Betriebssystem akzeptables Binary zusammenfuehrt - bei einem Kernel ist das letzte dann wieder aus einem etwas anderen Aspekt zu beleuchten, da er ja nicht von einem Betriebssystem in den Speicher geladen wird (darum LiLo oder Grub
); trotzdem MUESSTE es aber so sein das es an die dem Systemrichtlienien unterliegenden Kriterien fuer ein lauffaehiges Binary unterliegt, was zwar nicht zwingendermassen der Fall sein duerfte, aber unpraktikabel waere wenn es nicht so ist....LOL.
Ok, was du zum bauen von Binaries brauchst:
0. Hardware, Leidenschaft
1. Sourcen / Quellcode
2. Toolchain - binutils, make, automake, autoconf...
3. Helpers - ncurses, dialog, usw...
4. Compiler o. Interpreter - gcc, python, sh, usw...
.
.
.
EDIT (autom. Beitragszusammenführung) :
.
?? make-kpkg fasst die menu.lst überhaupt nicht an ...
Das kann Dir max. beim installieren des (oder jedes anderen) erzeugten Image-Paketes passieren. Und wenn Dir das nicht passt, dann pass halt die /etc/kernel-img.conf an ...
...ich hab keine initrd, und folgenden Eintrag in der menu.lst{code]title custom
root (hd<x>,<y>)
kernel /boot/custom root=/dev/hd<x><y>[/code]
In /boot ist custom ein Link auf eine Datei vmlinuz-<kernel-Version><local-Version>, wobei local-Version im Menupunkt "General-Setup--->Local_Version" von mir persoenlich gesetzt wird. Ein
Code:
make install; make modules_install; reboot
Kopiert den (neuen) Kernel nach /boot, auch die System.map und config, und kopiert vorher (falls vorhanden) den alten Kernel mit gleichem namen nach <name>.old . Ein Link mit old nach <name>.old in /boot und ein Eintrag wie
Code:
title custom
root (hd<x>,<y>)
kernel /boot/old root=/dev/hd<x><y>
wird den Fall so lange erledigen so lange man keine neue Version anstrebt, und dann muesste man eben die Links aktualisieren.
reboot ? - Eigentlich recht simpel.
