Hi Leute!
Ich habe kernel-2.4-test12 heruntergeladen, konfiguriert und kompiliert. Dabei habe ich versucht, den kernel durch Modularisieren von beispielsweise Dateisystemen wie Sambafs möglichst klein zu halten. Vmlinuz ist jetzt exakt 766.67 KB groß. Lilo meint jedoch, der kernel sei "too big". Ich habe auch die Konfiguration noch mehrmals überprüft, aber weiteres Modularisieren wäre sinnlos. Mein System besteht aus drei Partitionen: boot(ca.20 MB), / (ca 5.8 GB) und swap (ca. 250 MB). Was soll ich nun tun? GRUB verwenden? Wenn ja, wie kann ich ihn konfigurieren?
Gruß PeterM
kernel 2.4 - too big
Re: kernel 2.4 - too big
hi,
wie hast du den Kernel kompiliert ?
verwende
<b>make bzlilo</b>
anstelle
make zlilo
Gruß
Thomas
PS: das b... ist wichtig, je nachdem welchen Befehl du zum Erstellen des Kernels verwendest
wie hast du den Kernel kompiliert ?
verwende
<b>make bzlilo</b>
anstelle
make zlilo
Gruß
Thomas
PS: das b... ist wichtig, je nachdem welchen Befehl du zum Erstellen des Kernels verwendest
-
oliver
Re: kernel 2.4 - too big
Hallo !
Ich nehme immer folgende Befehle zum Kernelcompilieren:
1 ) make dep clean bzImage (genau so eingeben)
2 ) make modules modules_install
Gruß
Olli
Ich nehme immer folgende Befehle zum Kernelcompilieren:
1 ) make dep clean bzImage (genau so eingeben)
2 ) make modules modules_install
Gruß
Olli
-
Keule
Re: kernel 2.4 - too big
Hallo!
Nach Deiner Beschreibung zufolge gibst du nach 'make bzImage' gleich 'make modules_install' ein.
Ich würde mal lieber nach bzImage noch als Zwischenschritte noch 'make modules', 'make install' eingeben und danach dann 'make modules_install'.
Dadurch hat es dann bei mir geklappt. (Geht zwar bestimmt noch einfacher mit nicht so viel Text, aber ich kompilier ja nicht jeden Tag einen Kernel!).
Tschö
Keule
Nach Deiner Beschreibung zufolge gibst du nach 'make bzImage' gleich 'make modules_install' ein.
Ich würde mal lieber nach bzImage noch als Zwischenschritte noch 'make modules', 'make install' eingeben und danach dann 'make modules_install'.
Dadurch hat es dann bei mir geklappt. (Geht zwar bestimmt noch einfacher mit nicht so viel Text, aber ich kompilier ja nicht jeden Tag einen Kernel!).
Tschö
Keule
-
oliver
Re: kernel 2.4 - too big
Hallo Keule!
Von dem Schritt zwischen make modules und make modules_install habe ich noch nichts gehört oder gelesen, aber danke für den Tip. Hat das install denn eine andere Funktion als modules_install ??
Gruß
Olli
Von dem Schritt zwischen make modules und make modules_install habe ich noch nichts gehört oder gelesen, aber danke für den Tip. Hat das install denn eine andere Funktion als modules_install ??
Gruß
Olli
-
Thomas Mitzkat
Re: kernel 2.4 - too big
Hi Leutz,
make dep wird nur einmal aufgerufen, wenn die kernelsource das erstemal neu installiert ist. make clean ist auch nicht notwendig, da dieser befehl alle zuvor erstellten objects wieder löscht, was bei einem zweiten versuch nur die zeit wesentlich verlängert, die der kernel braucht um fertig zu werden. jedoch muß der kernel bei lilo auch wieder eingetragen werden und wenn die kernelsourcen ganz neu installiert werden möglicherweise ein depmod-aufruf.
cd /usr/src/linux
make xconfig
1. | | nur wenn neue module er-
mal V V stellt werden.
make (dep) bzImage bzlilo (modules modules_install)
depmod -a (wenn neue module eingebunden werden unter /lib/modules.... )
guten rutsch
thomas
make dep wird nur einmal aufgerufen, wenn die kernelsource das erstemal neu installiert ist. make clean ist auch nicht notwendig, da dieser befehl alle zuvor erstellten objects wieder löscht, was bei einem zweiten versuch nur die zeit wesentlich verlängert, die der kernel braucht um fertig zu werden. jedoch muß der kernel bei lilo auch wieder eingetragen werden und wenn die kernelsourcen ganz neu installiert werden möglicherweise ein depmod-aufruf.
cd /usr/src/linux
make xconfig
1. | | nur wenn neue module er-
mal V V stellt werden.
make (dep) bzImage bzlilo (modules modules_install)
depmod -a (wenn neue module eingebunden werden unter /lib/modules.... )
guten rutsch
thomas
-
Jochen
Re: kernel 2.4 - too big
<li>Ein "make install" ruft zum Installieren ein Skript namens "installkernel" auf, welches jede Distro ausbauen kann wie sie will. "make bzlilo" dagegen verwendet ein fix im Makefile eingebautes Verfahren und ein paar dort definierte Variablen (wie INSTALLPATH z.B.). Ein "lilo" wird nach "make install" ebenfalls abgesetzt.
<li>Das "depmod -a" darf man sich meist schenken, es sei denn, man het sich ein LFS gebaut oder eine ältere Debian. Neuere Distros haben den depmod-Aufruf alle in einem sysinit-Skript stehen und führen es so beim Booten aus. Und: wenn man ein Kernel-Update macht und man will den depmod unbedingt von hand aufrufen, dann sollte man auch "depmod -a <i>neue.kernel.version</i>" aufrufen, sonst werden die Abhängigkeiten der Module des laufenden Kernels untersucht...
<li>"make dep" muss tatsächlich nicht immer aufgerufen werden, aber da das Vergessen des Aufrufs eine ziemlich fiese Fehlerquelle ist, würde ich's trotzdem machen. Da mir etwas der Überblick fehlt, ob bestimmte Module je nach Konfig des Kernels mal mehr oder weniger Features haben, setze ich auch das "make clean" mit ab. Der Kernelbau braucht dann etwas länger, aber ich kann sicher sein, dass eventuelle Fehler an der Konfiguration und nicht am Bau des Kernels liegen.
<li>Der Kernel ist mit 767KB zu gross, da der Prozessor noch im Real-Mode ist, wenn der Loader läuft. Daher Zugriffsbeschränkung auf 1 MB Speicher, davon etwas über 700KB frei verfügbar...
<li>Was verstehst Du unter "weiteres Modularisieren wäre sinnlos"? Auch wenn das Netzwerkkarten-Modul beim Starten immer geladen wird und nie aus dem Speicher geschmissen wird, ist es doch sinnvoll, diesen Treiber als Modul zu nehmen, wenn dadurch der Kernel kleiner wird, oder?
<li>Die Partitionen haben damit nix zu tun.
Viel Erfolg noch!
<li>Das "depmod -a" darf man sich meist schenken, es sei denn, man het sich ein LFS gebaut oder eine ältere Debian. Neuere Distros haben den depmod-Aufruf alle in einem sysinit-Skript stehen und führen es so beim Booten aus. Und: wenn man ein Kernel-Update macht und man will den depmod unbedingt von hand aufrufen, dann sollte man auch "depmod -a <i>neue.kernel.version</i>" aufrufen, sonst werden die Abhängigkeiten der Module des laufenden Kernels untersucht...
<li>"make dep" muss tatsächlich nicht immer aufgerufen werden, aber da das Vergessen des Aufrufs eine ziemlich fiese Fehlerquelle ist, würde ich's trotzdem machen. Da mir etwas der Überblick fehlt, ob bestimmte Module je nach Konfig des Kernels mal mehr oder weniger Features haben, setze ich auch das "make clean" mit ab. Der Kernelbau braucht dann etwas länger, aber ich kann sicher sein, dass eventuelle Fehler an der Konfiguration und nicht am Bau des Kernels liegen.
<li>Der Kernel ist mit 767KB zu gross, da der Prozessor noch im Real-Mode ist, wenn der Loader läuft. Daher Zugriffsbeschränkung auf 1 MB Speicher, davon etwas über 700KB frei verfügbar...
<li>Was verstehst Du unter "weiteres Modularisieren wäre sinnlos"? Auch wenn das Netzwerkkarten-Modul beim Starten immer geladen wird und nie aus dem Speicher geschmissen wird, ist es doch sinnvoll, diesen Treiber als Modul zu nehmen, wenn dadurch der Kernel kleiner wird, oder?
<li>Die Partitionen haben damit nix zu tun.
Viel Erfolg noch!
-
Jochen
Re: kernel 2.4 - too big
<li>Ein "make install" ruft zum Installieren ein Skript namens "installkernel" auf, welches jede Distro ausbauen kann wie sie will. "make bzlilo" dagegen verwendet ein fix im Makefile eingebautes Verfahren und ein paar dort definierte Variablen (wie INSTALLPATH z.B.). Ein "lilo" wird nach "make install" ebenfalls abgesetzt.
<li>Das "depmod -a" darf man sich meist schenken, es sei denn, man het sich ein LFS gebaut oder eine ältere Debian. Neuere Distros haben den depmod-Aufruf alle in einem sysinit-Skript stehen und führen es so beim Booten aus. Und: wenn man ein Kernel-Update macht und man will den depmod unbedingt von hand aufrufen, dann sollte man auch "depmod -a <i>neue.kernel.version</i>" aufrufen, sonst werden die Abhängigkeiten der Module des laufenden Kernels untersucht...
<li>"make dep" muss tatsächlich nicht immer aufgerufen werden, aber da das Vergessen des Aufrufs eine ziemlich fiese Fehlerquelle ist, würde ich's trotzdem machen. Da mir etwas der Überblick fehlt, ob bestimmte Module je nach Konfig des Kernels mal mehr oder weniger Features haben, setze ich auch das "make clean" mit ab. Der Kernelbau braucht dann etwas länger, aber ich kann sicher sein, dass eventuelle Fehler an der Konfiguration und nicht am Bau des Kernels liegen.
<li>Der Kernel ist mit 767KB zu gross, da der Prozessor noch im Real-Mode ist, wenn der Loader läuft. Daher Zugriffsbeschränkung auf 1 MB Speicher, davon etwas über 700KB frei verfügbar...
<li>Was verstehst Du unter "weiteres Modularisieren wäre sinnlos"? Auch wenn das Netzwerkkarten-Modul beim Starten immer geladen wird und nie aus dem Speicher geschmissen wird, ist es doch sinnvoll, diesen Treiber als Modul zu nehmen, wenn dadurch der Kernel kleiner wird, oder?
<li>Die Partitionen haben damit nix zu tun.
Viel Erfolg noch!
<li>Das "depmod -a" darf man sich meist schenken, es sei denn, man het sich ein LFS gebaut oder eine ältere Debian. Neuere Distros haben den depmod-Aufruf alle in einem sysinit-Skript stehen und führen es so beim Booten aus. Und: wenn man ein Kernel-Update macht und man will den depmod unbedingt von hand aufrufen, dann sollte man auch "depmod -a <i>neue.kernel.version</i>" aufrufen, sonst werden die Abhängigkeiten der Module des laufenden Kernels untersucht...
<li>"make dep" muss tatsächlich nicht immer aufgerufen werden, aber da das Vergessen des Aufrufs eine ziemlich fiese Fehlerquelle ist, würde ich's trotzdem machen. Da mir etwas der Überblick fehlt, ob bestimmte Module je nach Konfig des Kernels mal mehr oder weniger Features haben, setze ich auch das "make clean" mit ab. Der Kernelbau braucht dann etwas länger, aber ich kann sicher sein, dass eventuelle Fehler an der Konfiguration und nicht am Bau des Kernels liegen.
<li>Der Kernel ist mit 767KB zu gross, da der Prozessor noch im Real-Mode ist, wenn der Loader läuft. Daher Zugriffsbeschränkung auf 1 MB Speicher, davon etwas über 700KB frei verfügbar...
<li>Was verstehst Du unter "weiteres Modularisieren wäre sinnlos"? Auch wenn das Netzwerkkarten-Modul beim Starten immer geladen wird und nie aus dem Speicher geschmissen wird, ist es doch sinnvoll, diesen Treiber als Modul zu nehmen, wenn dadurch der Kernel kleiner wird, oder?
<li>Die Partitionen haben damit nix zu tun.
Viel Erfolg noch!
-
Jochen
Re: kernel 2.4 - too big
<li>Ein "make install" ruft zum Installieren ein Skript namens "installkernel" auf, welches jede Distro ausbauen kann wie sie will. "make bzlilo" dagegen verwendet ein fix im Makefile eingebautes Verfahren und ein paar dort definierte Variablen (wie INSTALLPATH z.B.). Ein "lilo" wird nach "make install" ebenfalls abgesetzt.
<li>Das "depmod -a" darf man sich meist schenken, es sei denn, man hat sich ein LFS gebaut oder eine ältere Debian. Neuere Distros haben den depmod-Aufruf alle in einem sysinit-Skript stehen und führen es so beim Booten aus. Und: wenn man ein Kernel-Update macht und man will den depmod unbedingt von Hand aufrufen, dann sollte man auch "depmod -a <i>neue.kernel.version</i>" aufrufen, sonst werden die Abhängigkeiten der Module des laufenden Kernels untersucht...
<li>"make dep" muss tatsächlich nicht immer aufgerufen werden, aber da das Vergessen des Aufrufs eine ziemlich fiese Fehlerquelle ist, würde ich's trotzdem machen. Da mir etwas der Überblick fehlt, ob bestimmte Module je nach Konfig des Kernels mal mehr oder weniger Features haben, setze ich auch das "make clean" mit ab. Der Kernelbau braucht dann etwas länger, aber ich kann sicher sein, dass eventuelle Fehler an der Konfiguration und nicht am Bau des Kernels liegen.
<li>Der Kernel ist mit 767KB zu gross, da der Prozessor noch im Real-Mode ist, wenn der Loader läuft. Daher Zugriffsbeschränkung auf 1 MB Speicher, davon etwas über 700KB frei verfügbar...
<li>Was verstehst Du unter "weiteres Modularisieren wäre sinnlos"? Auch wenn das Netzwerkkarten-Modul beim Starten immer geladen wird und nie aus dem Speicher geschmissen wird, ist es doch sinnvoll, diesen Treiber als Modul zu nehmen, wenn dadurch der Kernel kleiner wird, oder?
<li>Die Partitionen haben damit nix zu tun.
Viel Erfolg noch!
<li>Das "depmod -a" darf man sich meist schenken, es sei denn, man hat sich ein LFS gebaut oder eine ältere Debian. Neuere Distros haben den depmod-Aufruf alle in einem sysinit-Skript stehen und führen es so beim Booten aus. Und: wenn man ein Kernel-Update macht und man will den depmod unbedingt von Hand aufrufen, dann sollte man auch "depmod -a <i>neue.kernel.version</i>" aufrufen, sonst werden die Abhängigkeiten der Module des laufenden Kernels untersucht...
<li>"make dep" muss tatsächlich nicht immer aufgerufen werden, aber da das Vergessen des Aufrufs eine ziemlich fiese Fehlerquelle ist, würde ich's trotzdem machen. Da mir etwas der Überblick fehlt, ob bestimmte Module je nach Konfig des Kernels mal mehr oder weniger Features haben, setze ich auch das "make clean" mit ab. Der Kernelbau braucht dann etwas länger, aber ich kann sicher sein, dass eventuelle Fehler an der Konfiguration und nicht am Bau des Kernels liegen.
<li>Der Kernel ist mit 767KB zu gross, da der Prozessor noch im Real-Mode ist, wenn der Loader läuft. Daher Zugriffsbeschränkung auf 1 MB Speicher, davon etwas über 700KB frei verfügbar...
<li>Was verstehst Du unter "weiteres Modularisieren wäre sinnlos"? Auch wenn das Netzwerkkarten-Modul beim Starten immer geladen wird und nie aus dem Speicher geschmissen wird, ist es doch sinnvoll, diesen Treiber als Modul zu nehmen, wenn dadurch der Kernel kleiner wird, oder?
<li>Die Partitionen haben damit nix zu tun.
Viel Erfolg noch!
Re: kernel 2.4 - too big
Hi Leute!
Vielen Dank für Eure Tipps. Einen guten Rutsch für alle Forum-Besucher + Pro-Linux-Team wünscht
PeterM
Vielen Dank für Eure Tipps. Einen guten Rutsch für alle Forum-Besucher + Pro-Linux-Team wünscht
PeterM