Mein erster Versuch beim Kernelbacken bringt folgende Meldung: fs/fs.o: In function `user_get': fs/fs.o(.text+0x8c48c): undefined reference to `reiserfs_permission_locked' fs/fs.o: In function `user_set': fs/fs.o(.text+0x8c537): undefined reference to `reiserfs_permission_locked' fs/fs.o: In function `user_del': fs/fs.o(.text+0x8c5cc): undefined reference to `reiserfs_permission_locked' make: *** [vmlinux] Fehler 1 Laufendes System SuSE8.1. Der neue Kernel ist src.rpm vom SuSE-FTP. Mit xconfig habe ich unter Filesystem alles mit "n" markiert, was nicht Reiser, ext2, ext3 und vfat war. Also Solaris, Minix und soweiter rausgeschmissen. Bei Anlegen von root habe ich leider nicht darauf geachtet auch ext3 anzugeben. Tscha. Jetzt weiß ich nicht weiter. Da das mein erster Versuch ist, weiß ich auch nicht, welche Infos ich jetzt noch hätte geben sollen. Ach ja: make dep und make dep clean hab ich zur Sicherheit schon ein paarmal davor und danach laufen lassen. Peter
Peter Lipp schrieb:
Mein erster Versuch beim Kernelbacken bringt folgende Meldung: fs/fs.o: In function `user_get': fs/fs.o(.text+0x8c48c): undefined reference to `reiserfs_permission_locked' fs/fs.o: In function `user_set': fs/fs.o(.text+0x8c537): undefined reference to `reiserfs_permission_locked' fs/fs.o: In function `user_del': fs/fs.o(.text+0x8c5cc): undefined reference to `reiserfs_permission_locked' make: *** [vmlinux] Fehler 1
Laufendes System SuSE8.1. Der neue Kernel ist src.rpm vom SuSE-FTP. Mit xconfig habe ich unter Filesystem alles mit "n" markiert, was nicht Reiser, ext2, ext3 und vfat war. Also Solaris, Minix und soweiter rausgeschmissen. Bei Anlegen von root habe ich leider nicht darauf geachtet auch ext3 anzugeben. Tscha. Jetzt weiß ich nicht weiter.
Du hast wohl ein bissl zu viel rausgeschmissen - jedenfalls hast Du nun einen Fehler in Deiner Konfiguration des Kernels, der dazu fuehrt, dass eine Referenz nicht aufgeloest werden kann. Ueberpruefe Deine Kernel-Konfiguration (insbesondere im Bereich Filesysteme, es waere moeglich, dass Du da etwas zu ReiserFS Attributes oder ACL abgewaehlt hast, was besser nicht abgewaehlt sein sollte)... Fuehre anschliessend ein "make dep clean", "make bzImage modules" und ein "make modules_install" aus. Aber lese zuvor(!) unbedingt das Multikernel-Howto[1]. Gruesse, Thomson [1] http://www.dhaller.de/linux/multikernel.html -- Thomas Hertweck, Dipl.-Geophys., GPI Universitaet Karlsruhe === First they ignore you, then they laugh at you, then === === they fight you, then you win. (M. Ghandi) ===
Am Donnerstag, 15. Mai 2003 23:27 schrieb Thomas Hertweck:
Ueberpruefe Deine Kernel-Konfiguration (insbesondere im Bereich Filesysteme, es waere moeglich, dass Du da etwas zu ReiserFS Attributes oder ACL abgewaehlt hast, was besser nicht abgewaehlt sein sollte)
xconfig läßt mich alles zu ReiserFS anwählen. ReiserFS Posix Access Controls List ist aber geghosted und auf "n". POSIX ACLs ist nicht geghosted aber weder "y" noch "n" sind gewählt oder wählbar.
Fuehre anschliessend ein "make dep clean", "make bzImage modules" und ein "make modules_install" aus.
Hab ich oft und oft gemacht, davor und danach.
Aber lese zuvor(!) unbedingt das Multikernel-Howto[1].
Dem hab ich entnommen, daß es auch Probleme mit xconfig geben kann. Vielleicht sind die obigen Auswahlprobleme ein Zeichen dafür? Oder fehlt die monierte Referenz, weil ein bla-devel.rpm nicht installiert ist? Weitergekommen bin ich also bisher nicht. Und weiß jetzt auch nicht so recht, wo ich ansetzen soll. Wäre es eine gute Idee, erstmal zum Test ein Mammut-Kernel zu backen, in dem ich als auf "y" setze? Vielen Dank für die wie immer prompte Antwort. Peter
Peter Lipp
xconfig läßt mich alles zu ReiserFS anwählen. ReiserFS Posix Access Controls List ist aber geghosted und auf "n". POSIX ACLs ist nicht geghosted aber weder "y" noch "n" sind gewählt oder wählbar.
Versuche es doch bitte mal mit menuconfig. Philipp
Am Freitag, 16. Mai 2003 01:47 schrieb Philipp Thomas:
Versuche es doch bitte mal mit menuconfig.
Dazu muß ich wohl erst ncurses-devel installieren und der angebotene Aufruf von yast2 wollte grade nicht. ncurses scheint ja nicht gerade ein gutes Omen zu sein und yast fürchte ich eh. Peter
Peter Lipp wrote:
[...] Dem hab ich entnommen, daß es auch Probleme mit xconfig geben kann. Vielleicht sind die obigen Auswahlprobleme ein Zeichen dafür?
"make xconfig" wird es im neuen 2.6 Kernel nicht mehr geben. Die Konfiguration des Kernels ist in den neuen Versionen veraendert und es wird wohl in Zukunft mehr externe Programme mit GUI etc. fuer die Kernel-Konfiguration geben, nicht mehr interne (d.h. bei den Kernel-Sourcen mitgelie- ferte). Dementsprechend kann es schon sein, dass ein "make xconfig" nicht mehr ganz so gut ge- pflegt wird in letzter Zeit. Gruesse, Thomson -- Thomas Hertweck, Geophysicist Geophysical Institute, Karlsruhe University (TH)
Am Donnerstag, 15. Mai 2003 15:49 schrieb Peter Lipp: Mit Euren Tips und menuconfig hat es bisher also geklappt. Bei make modules_install kam jetzt eine Litanei von unresolved symbols, die aber auf den ersten Blick nur Module betreffen, die ich eh nur bei Filesystems angewählt habe, damit nur nicht etwas fehlt, was ReiserFS braucht. Kann ich es mit dem neues Kernel versuchen? Ich würde ihn als vmlinuz-2.4.20 nach boot verschieben und in grub.menulist einen Titel nach linux aufnehmen "linux2_4" und auf den entsprechenden Kernel in boot verweisen. Reicht das? Peter
Peter Lipp wrote:
Mit Euren Tips und menuconfig hat es bisher also geklappt.
Gut.
Bei make modules_install kam jetzt eine Litanei von unresolved symbols, die aber auf den ersten Blick nur Module betreffen, die ich eh nur bei Filesystems angewählt habe, damit nur nicht etwas fehlt, was ReiserFS braucht.
Naja, nicht ideal, aber solange Du die Module nicht verwendest, sollten die "unresolved symbols" die restliche Funktion des Kernels und der anderen Module nicht beeinflussen.
Kann ich es mit dem neues Kernel versuchen?
Versuchen kann man es immer ;-)
Ich würde ihn als vmlinuz-2.4.20 nach boot verschieben und in grub.menulist einen Titel nach linux aufnehmen "linux2_4" und auf den entsprechenden Kernel in boot verweisen. Reicht das?
Kommt drauf an, ob Du eine Initial Ramdisk brauchst oder nicht, sprich: ist alles, was zum Booten be- noetigt wird, fest im Kernel oder evtl modular com- piliert... Falls letzteres der Fall ist, dann muss diese initrd auch erstellt werden. Die System.map solltest Du entsprechend auch mit Version versehen nach /boot kopieren. Achte darauf, dass alle Kernel und alle System.map Dateien mit Versionen versehen sind - gibt es eine System.map ohne Versionsangabe, so wird _immer_ diese verwendet, egal welchen Kernel Du bootest, und das ist nicht das, was Du willst. Ist der Bootloader angepasst, so kannst Du dann Re- booten und hoffen, dass alles klappt ;-) Bei lilo muesste man natuerlich noch /sbin/lilo aufrufen vor dem Reboot. Gruesse, Thomson -- Thomas Hertweck, Geophysicist Geophysical Institute, Karlsruhe University (TH)
Am Freitag, 16. Mai 2003 09:02 schrieb Thomas Hertweck:
Ich würde ihn als vmlinuz-2.4.20 nach boot verschieben und in grub.menulist einen Titel nach linux aufnehmen "linux2_4" und auf den entsprechenden Kernel in boot verweisen. Reicht das?
Kommt drauf an, ob Du eine Initial Ramdisk brauchst oder nicht, sprich: ist alles, was zum Booten be- noetigt wird, fest im Kernel oder evtl modular com- piliert... Falls letzteres der Fall ist, dann muss diese initrd auch erstellt werden. Die System.map solltest Du entsprechend auch mit Version versehen nach /boot kopieren. Achte darauf, dass alle Kernel und alle System.map Dateien mit Versionen versehen sind - gibt es eine System.map ohne Versionsangabe, so wird _immer_ diese verwendet, egal welchen Kernel Du bootest, und das ist nicht das, was Du willst. Ist der Bootloader angepasst, so kannst Du dann Re- booten und hoffen, dass alles klappt ;-) Bei lilo muesste man natuerlich noch /sbin/lilo aufrufen vor dem Reboot.
Kann das sein, daß Du die Fragen meiner letzten mail gerade beantwortet hast, bevor ich sie überhaupt gestellt habe? Gespenstisch! Danke Peter
Peter Lipp wrote:
[...] Kann das sein, daß Du die Fragen meiner letzten mail gerade beantwortet hast, bevor ich sie überhaupt gestellt habe? Gespenstisch!
Nene, manchmal klappt das schon (je nach verwen- deter Glaskugel)... Es war einfach nur die lo- gische Fortsetzung von dem, was Du da so gemacht hast *g*. So, und nun beame ich mich mal rueber zum Groenemeyer Konzert ins Wildparkstadion ;-)) Sssssuuuuuuuuuuuummmmmm *...und weg isser*
Einen hab ich noch: Die beiden vmlinuz_2.4.19 bzw .._2.4.20 stehen in boot. grub-menu anscheinend alles iO. Jetzt sind in boot aber auch ein paar Headerdateien, die davon nicht berührt wurden - zB eine, in der die Versionsnummer definiert wird. Hätte nicht make modules_install dort neue Dateien anlegen müssen. Alle Beschreibungen, die ich gelesen habe, wollen immer noch einen lilo-Aufruf. In /usr/src.../i386/boot ist auch ein install.sh, in dem lilo auftaucht. Da ich grub verwende, hab ich das weggelassen. Was fehlt noch? Immerhin: Wähle ich bei grub den neuen Kernel, bleibt der Bildschirm zwar schwarz, aber die Kiste rappelt noch eine Weile. Peter
Peter Lipp wrote:
Die beiden vmlinuz_2.4.19 bzw .._2.4.20 stehen in boot. grub-menu anscheinend alles iO. Jetzt sind in boot aber auch ein paar Headerdateien, die davon nicht berührt wurden - zB eine, in der die Versionsnummer definiert wird. Hätte nicht make modules_install dort neue Dateien anlegen müssen.
Nein. Die Dateien dort wurden vom SuSE-Kernel RPM installiert und definieren einfach die fuer den SuSE-Kernel verwendeten Konfigurationen.
Alle Beschreibungen, die ich gelesen habe, wollen immer noch einen lilo-Aufruf. In /usr/src.../i386/boot ist auch ein install.sh, in dem lilo auftaucht.
Du verwendest grub; grub braucht man nicht jedes Mal neu in den MBR installieren, das ist schon OK so.
Da ich grub verwende, hab ich das weggelassen. Was fehlt noch?
Initial Ramdisk? Framebuffer Support? Versuche es im Zweifelsfalle mit dem Bootparameter "vga=normal". CU, Th. -- Thomas Hertweck, Geophysicist Geophysical Institute, Karlsruhe University (TH)
Hallo, On Fri, 16 May 2003, Peter Lipp wrote:
Die beiden vmlinuz_2.4.19 bzw .._2.4.20 stehen in boot. grub-menu anscheinend alles iO. Jetzt sind in boot aber auch ein paar Headerdateien, die davon nicht berührt wurden - zB eine, in der die Versionsnummer definiert wird.
Das ist nur ein Extraservice, den SuSE vor einer Weile begonnen hat, und was du ebenfalls machen solltest. Die .config findest du direkt in /usr/src/linux, die version.h in /usr/src/linux/include/linux/. Diese kannst du ebenfalls (mit Versionen versehen) nach /boot kopieren. Allerdings wuerde ich das wohl erst machen, wenn der zugehoerige neue Kernel auch laeuft ;)
Hätte nicht make modules_install dort neue Dateien anlegen müssen.
Nein. modules_install kopiert nur die fertigen Module nach /lib/modules/$(KERNELRELEASE). Fuer weiteres ist 'make bzlilo' zustaendig -- aber das versioniert nicht, deswegen muss man das von Hand machen. Und ich mach das eh lieber per Hand, obwohl ich mal ein script angefangen habe, dass nach meinen Vorstellungen den Kernel kopiert...
Alle Beschreibungen, die ich gelesen habe, wollen immer noch einen lilo-Aufruf.
Der faellt bei grub natuerlich weg.
In /usr/src.../i386/boot ist auch ein install.sh, in dem lilo auftaucht.
Das ist das script das von 'make install' aufgerufen wird. Das ist aber genauso simpel wie make zlilo/make bzlilo und versioniert auch nicht (und ueberschreibt beim zweiten Aufruf den alten Kernel!).
Da ich grub verwende, hab ich das weggelassen. Was fehlt noch?
Siehe Thomas' Mail. System.map schon kopiert?
Immerhin: Wähle ich bei grub den neuen Kernel, bleibt der Bildschirm zwar schwarz, aber die Kiste rappelt noch eine Weile.
Hm. Framebuffertreiber eingebaut? Bzw. welche vga= Einstellung? Boote mal mit 'vga=normal' als Kernelparameter... -dnh -- "Remember, no matter how cynical you think you are, reality is going to find a way to make you look naive." -- Shmuel Metz in the SDM
Einen hab ich noch: System.map finde ich nicht. Nach dem was zu lesen war, müßte es sich in /usr/src/linux/arch/boot/bzImage befinden. Das Verzeichnis bzImage wurde offenbar dort nicht angelegt. Das in .../i386/ befindlich script install.sh sucht System.map auch dort. Jetzt sind wir glaub ich ganz dicht dran. Make bzImage lief nämlich ohne Fehler durch. Ist die System.map etwas, was von make clean gelöscht wird? make modules_install, das ich als letztes ausgeführt habe, brachte zwar einen Haufen unresolved symbols, die aber alle sound und "abi" betrafen. Das wär mir jetzt egal gewesen. Soll ich vor weiteren Fragen vielleicht erstmal, den alten 2.4.19 als Zweitkernel (das hat man jetzt) versuchen? Gibt es ein Programm, das mir zum laufenden Kernel das so anzeigt als würde ich ihn gerade mit make menuconfig bauen? Dann wüßte ich schon mal, was ich alles brauche oder nicht brauche. Kann es an den gewählten Sourcen liegen (586,686...)? Die Kiste ist 5 Monate alt mit einem Pentium 4. Peter
Peter Lipp schrieb:
Einen hab ich noch:
Kapelle, einen Tusch bitte... :-)
System.map finde ich nicht. Nach dem was zu lesen war, müßte es sich in /usr/src/linux/arch/boot/bzImage befinden. Das Verzeichnis bzImage wurde offenbar dort nicht angelegt.
Moment! Es wird nie ein derartiges Verzeichnis geben. Erstens fehlt in dieser Verzeichnisangabe die wirkli- che Architektur, d.h. in Deinem Falle ein ../i386/.., zweitens ist /usr/src/linux/arch/i386/boot/bzImage das neu erstellte (komprimierte) Kernel-Image und kein Ver- zeichnis. Die System.map liegt nach dem Compilieren des Kernels direkt in /usr/src/linux/ und kann von dort nach /boot kopiert werden (Versionsangabe nicht vergessen).
Das in .../i386/ befindlich script install.sh sucht System.map auch dort.
Nein.
Jetzt sind wir glaub ich ganz dicht dran. Make bzImage lief nämlich ohne Fehler durch. Ist die System.map etwas, was von make clean gelöscht wird?
Ja. Ein "make clean" loescht u.a. den Kernel und auch die System.map $> /usr/src/linux # make clean [...] make[1]: Entering directory `/usr/src/linux-2.4.20.SuSE/arch/i386/boot' rm -f tools/build rm -f setup bootsect zImage compressed/vmlinux.out [...] make[1]: Leaving directory `/usr/src/linux-2.4.20.SuSE/arch/i386/kernel' [...] rm -f kernel/ksyms.lst include/linux/compile.h vmlinux System.map [...]
make modules_install, das ich als letztes ausgeführt habe, brachte zwar einen Haufen unresolved symbols, die aber alle sound und "abi" betrafen. Das wär mir jetzt egal gewesen.
Unschoen...
Soll ich vor weiteren Fragen vielleicht erstmal, den alten 2.4.19 als Zweitkernel (das hat man jetzt) versuchen? Gibt es ein Programm, das mir zum laufenden Kernel das so anzeigt als würde ich ihn gerade mit make menuconfig bauen?
Die Frage verstehe ich nicht. Was soll angezeigt werden? Bei SuSE-Kerneln kannst Du die Konfiguration des laufen- den Kernels per "make cloneconfig" im Source-Tree kopie- ren. Aber SuSE muss natuerlich quasi alles aktivieren im Kernel, da dieser ja saemtliche Dinge unterstuetzen soll. Fuer einen speziellen Kernel, der auf Dein System ange- passt ist, ist das viel zu viel... Du kannst diese Kon- figuration natuerlich aus Ausgangsbasis nehmen. Nochmal kurz die Vorgehensweise: konfiguriere den Kernel, fuehre ein "make dep clean", "make bzImage modules" und ein "make modules_install" aus (vor dieser ganzen Ge- schichte evtl. im Makefile des Kernels eine Extra-Version setzen, damit Module spaeter nicht ueberschrieben werden unter /lib/modules/`uname -r`/), kopiere dann den neuen Kernel aus ./arch/i386/boot nach /boot (mit Versions- nummer), kopiere die System.map nach /boot (mit Versions- nummer), erstelle die Initial Ramdisk neu (falls nicht alle Dinge zum Booten fest in den Kernel compiliert sind, was beim SuSE-Kernel eben der Fall ist - er muss ja auf voellig unterschiedlicher Hardware laufen koennen), passe den Bootloader an, und das sollte es dann gewesen sein.
Dann wüßte ich schon mal, was ich alles brauche oder nicht brauche. Kann es an den gewählten Sourcen liegen (586,686...)? Die Kiste ist 5 Monate alt mit einem Pentium 4.
Sourcen sind Sourcen - erst mit der Einstellung zum Pro- zessor bei der Kernel-Konfiguration optimierst Du fuer ein bestimmtes System bzw. eine bestimmte CPU... Gruesse, Thomson -- Thomas Hertweck, Dipl.-Geophys., GPI Universitaet Karlsruhe === First they ignore you, then they laugh at you, then === === they fight you, then you win. (M. Ghandi) ===
Am Samstag, 17. Mai 2003 12:35 schrieb Thomas Hertweck:
Kapelle, einen Tusch bitte... :-)
Hoffentlich gehen sie mir irgendwann aus.
System.map finde ich nicht. Nach dem was zu lesen war, müßte es sich in /usr/src/linux/arch/boot/bzImage befinden. Das Verzeichnis bzImage wurde offenbar dort nicht angelegt.
Moment! Es wird nie ein derartiges Verzeichnis geben. Erstens fehlt in dieser Verzeichnisangabe die wirkli- che Architektur, d.h. in Deinem Falle ein ../i386/.., zweitens ist /usr/src/linux/arch/i386/boot/bzImage das neu erstellte (komprimierte) Kernel-Image und kein Ver- zeichnis.
Hat mich auch gewundert. das i386 hab ich nur vergessen. Der Rest ist scheints ein erratum in LINUX-Systemverwaltung p. 285 unten.
Die System.map liegt nach dem Compilieren des Kernels direkt in /usr/src/linux/ und kann von dort nach /boot kopiert werden (Versionsangabe nicht vergessen). Wozu braucht er die eigentlich? Beim jetzigen Hochfahren, hat er sie zum ersten Mal nicht mehr gefunden (der alte) - funktionieren tut er trotzdem.
Bei SuSE-Kerneln kannst Du die Konfiguration des laufen- den Kernels per "make cloneconfig" im Source-Tree kopie- ren. Das sieht doch nach Supertip aus. Ich nehm ihn so und schmeiß dann alles sukkzessive raus.
[ .. das ganz wichtige, das mir ein bisserl zuviel voraussetzt...] Bisher hab ich in /boot die vorhandenen files mit _2.4.19 ergänzt. Zumindest den Kernel hat er natürlich gefunden, da ich diesen ja explizit in grub.menu.lst angeben kann. Das laufende Programm konnte das ja nicht wissen. Hab ich mit dem Unterstrich zufällig die richtige Konvention erwischt? Mit System_2.4.19 ja anscheinend nicht. Wie ich das im Makefile ändern kann, ging mir in Deiner Antwort zu schnell. Notfalls initrd machen. Können vor lachen. Wie bitte bitte. In den zwei 1000 Seiten dicken Büchern stand zu Makefile und initrd schon mal gar nix. Bitte bitte Peter Wie war Gröni? Die neue Arena, auf die die Chemnitzer hier so stolz sind, war ihm ja zu klein (13000 Plätze).
Hallo, On Sat, 17 May 2003, Peter Lipp wrote:
[ .. das ganz wichtige, das mir ein bisserl zuviel voraussetzt...] Bisher hab ich in /boot die vorhandenen files mit _2.4.19 ergänzt. Zumindest den Kernel hat er natürlich gefunden, da ich diesen ja explizit in grub.menu.lst angeben kann. Das laufende Programm konnte das ja nicht wissen. Hab ich mit dem Unterstrich zufällig die richtige Konvention erwischt? Mit System_2.4.19 ja anscheinend nicht.
*autsch* Les das Howto nochmal etwas genauer ;) Du musst -$(KERNELRELEASE) (also -`uname -r` des neuen Kernels) verwenden. Das sieht dann z.B. fuer meinen laufenden Kernel so aus: $ ls -a /boot/ | grep `uname -r` .config-2.4.16-3 System.map-2.4.16-3 bzImage-2.4.16-3 Wobei das '-3' die EXTRAVERSION ist und die .config eben die /usr/src/linux/.config zum Kernel.
Wie ich das im Makefile ändern kann, ging mir in Deiner Antwort zu schnell.
Was willst du im Makefile aendern?
Notfalls initrd machen. Können vor lachen. Wie bitte bitte.
man mk_initrd, man mkinitrd Aber ich wuerde dir empfehlen, die zum booten noetigen Module fest in den Kernel zu bauen, dann kannst du dir die initrd sparen. -dnh -- Man beachte das "A" in ADSL (="A"ufwärts langsam). -- Holger Marzen
Peter Lipp schrieb:
Am Samstag, 17. Mai 2003 12:35 schrieb Thomas Hertweck: [...] Hat mich auch gewundert. das i386 hab ich nur vergessen. Der Rest ist scheints ein erratum in LINUX-Systemverwaltung p. 285 unten.
OK, das kenne ich nicht, mag aber natuerlich sein.
[... System.map...]
Wozu braucht er die eigentlich? Beim jetzigen Hochfahren, hat er sie zum ersten Mal nicht mehr gefunden (der alte) - funktionieren tut er trotzdem.
Ja, funktionieren tut es vielleicht :-) Aber: Die System.map beinhaltet Informationen ueber sog. entry points fuer Funktionen, die Du in den Kernel compiliert hast, und ebenso gewisse Debug-Informa- tionen. Der Kernel selbst kennt natuerlich die be- noetigten Adressen und entry points, aber andere Programme eben nicht, z.B. klogd, ksymoops, depmod (falls es nicht fuer den aktuell laufenden Kernel aufgerufen wird) und manche Programme, die auf /proc zurueckgreifen (AFAIK z.B. auch ps und Konsorten). So gesehen wird Dein System auch ohne System.map funktionieren (was Du so auch erlebt hast), aber es koennte in Zukunft eben bei Dir irgendwann mal das Problem auftauchen, dass etwas nicht so wie erwar- tet arbeitet - und das kann dann (wie oben erwaehnt) evtl. an der fehlenden System.map liegen.
[ .. das ganz wichtige, das mir ein bisserl zuviel voraussetzt...] Bisher hab ich in /boot die vorhandenen files mit _2.4.19 ergänzt. Zumindest den Kernel hat er natürlich gefunden, da ich diesen ja explizit in grub.menu.lst angeben kann. Das laufende Programm konnte das ja nicht wissen. Hab ich mit dem Unterstrich zufällig die richtige Konvention erwischt? Mit System_2.4.19 ja anscheinend nicht.
Die Datei heisst ja auch System.map, das .map kannst Du ja nicht einfach abschneiden!
Wie ich das im Makefile ändern kann, ging mir in Deiner Antwort zu schnell. Notfalls initrd machen. Können vor lachen. Wie bitte bitte.
Eigentlich wird das alles wie schon erwaehnt in Davids Multikernel-Howto sehr ausfuehrlich dargelegt, siehe http://www.dhaller.de/linux/multikernel.html. Insbe- sondere wird dort auch erwaehnt, wie man das Makefile anpassen muss. Kurz: es geht um das Makefile unter /usr/src/linux/ (wenn dort die neuen Kernel-Quellen liegen). Dort findest Du oben die Definition einiger Variablen: VERSION = 2 PATCHLEVEL = 4 SUBLEVEL = 20 EXTRAVERSION = Fuer einen eigenen Kernel kannst Du z.B. die Variable EXTRAVERSION benutzen und dort entsprechend etwas ein- tragen. Was das Erstellen der initrd angeht: siehe dazu "/sbin/mkinitrd -h". Fuer einen eigenen Kernel musst Du die Optionen -k und -i verwenden. Die Module, die in die initrd aufgenommen werden sollten, werden aus /etc/sysconfig/kernel gelesen - willst Du das nicht, so kannst Du sie direkt per Option -m angeben. Fuer Dich sollte also der Aufruf in etwa wie (als root) mkinitrd -k vmlinuz_2.4.20.myversion \ -i initrd_2.4.20.myversion lauten... Den Namen der Initial ramdisk musst Du dann entsprechend beim Bootloader fuer den zugehoerigen Kernel verwenden und dort eintragen.
Wie war Gröni? Die neue Arena, auf die die Chemnitzer hier so stolz sind, war ihm ja zu klein (13000 Plätze).
Das Konzert war ziemlich genial. 43.000 Menschen, eine grosse Party, La Ola im Stadion, 3h Konzert, 4 Zugaben. Stand 10m vor der Buehne... :-) Den Preis war es allemal wert!! Gruesse, Thomson -- Thomas Hertweck, Dipl.-Geophys., GPI Universitaet Karlsruhe === First they ignore you, then they laugh at you, then === === they fight you, then you win. (M. Ghandi) ===
Peter Lipp
Die System.map liegt nach dem Compilieren des Kernels direkt in /usr/src/linux/ und kann von dort nach /boot kopiert werden (Versionsangabe nicht vergessen). Wozu braucht er die eigentlich?
Die System.map enthält die Namen aller Symbole (Variablen und Funktionen) inklusive ihrer Adresse. Anhand dieser Tabelle können Programme wie klogd Adressen in Kernel-Ausgaben in verständliche Namen umsetzen.
Bisher hab ich in /boot die vorhandenen files mit _2.4.19 ergänzt. Zumindest den Kernel hat er natürlich gefunden, da ich diesen ja explizit in grub.menu.lst angeben kann. Das laufende Programm konnte das ja nicht wissen. Hab ich mit dem Unterstrich zufällig die richtige Konvention erwischt?
Fast :) Eigentlich ist eine beliebige Endung möglich, nur muss diese bei vmlinuz und System.map identisch sein, also bei dir z.B. vmlinuz_2.4.19 und System.map_2.4.19. Um das alles zu vereinfachen, im Anhang ein Patch für die Kernel-Makefiles für i386. Damit braucht man nur ggfs. die Extraversion zu setzen und bekommt vmlinuz und System.map mit passender Endung direkt nach /boot (oder wohin INSTALLPATH zeigt) kopiert. Einfach nur 'make bzgrub' aufrufen :) Zum Anbringen des Patches einfach: cd /usr/src/linux patch -p0 -i /pfad/zum/patch ^^^^^^^^^^^^^^^ Da musst du anpassen Philipp
David Haller
Schick ;)
Nicht wahr? Aber schliesslich sind Makefiles dazu da, einem die Arbeit zu erleichtern :))) Stammt noch aus den Zeiten, als ich ausgiebig mit den Entwicklungskerneln experimentiert habe, wozu ich heute keine Zeit mehr habe. Aber für Sachen wie das Erstellen eines Kernels mit matroxfb statt vesafb ist es auch heute noch gut. Philipp
Danke Euch allen. Wenn ich es mit den ganzen Infos jetzt nicht packe, kann ich nur noch selber schuld sein. Wie gibt man per Mail eigentlich einen aus? Peter
Hallo, On Sat, 17 May 2003, Peter Lipp wrote:
Wie gibt man per Mail eigentlich einen aus?
*Peter gibt einen aus* Mir bitte einen Laphroaig! *g* Es gibt Anlaesse, wo man sich treffen kann ;) -dnh -- 116: Programm Sobald eine Datei von einem Virus infiziert werden kann, ist es ein Programm. (Markus Kuhn)
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hallo Peter Am Samstag, 17. Mai 2003 22:01 schrieb Peter Lipp:
Danke Euch allen. Wenn ich es mit den ganzen Infos jetzt nicht packe, kann ich nur noch selber schuld sein. Wie gibt man per Mail eigentlich einen aus? Versuchs mal damit ;-) http://www.gerkens.de/sternenfressen/
CU Thorsten -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2-rc1-SuSE (GNU/Linux) iD8DBQE+xq8Rs5R35vLkl/cRAjGoAJ4gXRqluCVu83IcOoM4KVpgi8/KsgCaAvdH CrfIXE7fTsNaR/73apP4F2Q= =X5o7 -----END PGP SIGNATURE-----
Hallo, * Peter Lipp textete am 17.05.03:
Einen hab ich noch: System.map finde ich nicht. Nach dem was zu lesen war, müßte es sich in /usr/src/linux/arch/boot/bzImage befinden.
? Du meinst sicher das Verzeichnis /usr/src/linux/arch/i386/boot bzImage ist der letzte kompilierte Kernel.
Das Verzeichnis bzImage wurde offenbar dort nicht angelegt.
Soll auch nicht. Du suchst /usr/src/linux/System.map Bei mir isse da jedenfalls. cu flo -- Die einzige relöevante Frage lautet doch hier: "Gibt es Keckse vor und nach dem Tode?" Nun Vor dem Tode ja! Aber was ist mit dem Leben danach? Wo sind sie denn da? Wo sind die KEEEEEEEEECKSE! [WoKo in dag°]
Hallo, * Peter Lipp textete am 16.05.03:
Am Donnerstag, 15. Mai 2003 15:49 schrieb Peter Lipp:
Kann ich es mit dem neues Kernel versuchen?
Warum nicht? Im schlimmsten Fall fährt er nicht hoch.
Ich würde ihn als vmlinuz-2.4.20 nach boot verschieben und in grub.menulist einen Titel nach linux aufnehmen "linux2_4" und auf den entsprechenden Kernel in boot verweisen. Reicht das?
Mit grub kenne ich mich nicht so aus, sollte aber eigentlich gehen. Jedenfalls kann ich hier mit lilo zur Zeit 4 verschiedene Kernel booten. Das sollte auch grub schaffen. Laß nur den laufenden Kernel in Ruhe, falls der andere nicht geht. cu flo --
Schon mal was von der Netiquette gehört? Ich verbitte mir diesen Tonfall![Stephan Windmüller und Robert Köhler in dtju]
participants (6)
-
David Haller -
Florian Gross -
Peter Lipp -
Philipp Thomas -
Thomas Hertweck -
Thorsten Körner