system.map nach /boot kopieren?
beim kompilieren eines neuen kernels entsteht in /usr/src/linux die datei System.map. kann es sein, dass man diese datei nach /boot kopieren muss, damit beim nächsten booten alles richtig funktioniert? weil nach dem kompilieren von 2.4.1 ist in meinem verzeichnis /boot immer noch lediglich die System.map und noch ein problem: beim ausführen von lilo kommt die meldung: Warning: Bios drive 0x82 may not be accessible Was hat das zu sagen? danke schön! uwe
Hi, On Mon, 12 Feb 2001, uwe wrote:
beim kompilieren eines neuen kernels entsteht in /usr/src/linux die datei System.map.
kann es sein, dass man diese datei nach /boot kopieren muss, damit beim nächsten booten alles richtig funktioniert?
Ja!
weil nach dem kompilieren von 2.4.1 ist in meinem verzeichnis /boot immer noch lediglich die System.map
Nach X-, old-, menue- config make dep clean bzImage modules modules_install cp System.map /boot/System.mapX (X = Kernelversion) cp arch/i386/boot/bzImage /boot/vmlinuzX (X = Kernelversion) /etc/lilo.conf anpassen und lilo azsführen. Siehe auch das Multikernel miniHOWTO von David www.dhaller.de/linux (aus dem kopp, david berichtige mich falls nötig)
und noch ein problem: beim ausführen von lilo kommt die meldung: Warning: Bios drive 0x82 may not be accessible Was hat das zu sagen?
Das dein BIOS deine Festplatten anders mappt als lilo. Hast du ein mischsystem (IDE & SCSI)? Schau mal hier http://sdb.suse.de/de/sdb/html/ke_eide-scsi.html -- Hendrik Vogelsang aka Henne mailto: mickey@naturalbornkiller.de When will I learn? The answers to life's problems aren't at the bottom of a bottle. They're on TV! -- Homer Simpson There's No Disgrace Like Home # random sigs made with fortune
cp System.map /boot/System.mapX (X = Kernelversion)
coool! das dürfte die lösung für ne menge probleme sein :) DANKE
Warning: Bios drive 0x82 may not be accessible Was hat das zu sagen?
Das dein BIOS deine Festplatten anders mappt als lilo. Hast du ein mischsystem (IDE & SCSI)? Schau mal hier
ich habe ein reines IDE-system, allerdings habe ich zur unterstützung einer scsi-karte (treiber sym53c416.o) für nen diascanner SCSI-support und SCSI-generic-support fest einkompiliert (ehm - den hab ich allerdings unter linux noch nicht ans laufen gebracht) sollte ich bas besser als modul eincompilieren, damit die warnmeldung wieder verschwindet? uwe
Hi, On Mon, 12 Feb 2001, uwe wrote:
cp System.map /boot/System.mapX (X = Kernelversion)
coool! das dürfte die lösung für ne menge probleme sein :) DANKE
Nicht wirklich. Das booten sollte auch ohne klappen also die System.map ist kein allheilmittel. Worum gehts denn?
Warning: Bios drive 0x82 may not be accessible Was hat das zu sagen?
Das dein BIOS deine Festplatten anders mappt als lilo. Hast du ein mischsystem (IDE & SCSI)? Schau mal hier
ich habe ein reines IDE-system, allerdings habe ich zur unterstützung einer scsi-karte (treiber sym53c416.o) für nen diascanner SCSI-support und SCSI-generic-support fest einkompiliert (ehm - den hab ich allerdings unter linux noch nicht ans laufen gebracht)
sollte ich bas besser als modul eincompilieren, damit die warnmeldung wieder verschwindet?
Ne ich meinte Plattentechnisch. Von wo willst du denn booten? Henne -- Hendrik Vogelsang aka Henne mailto: mickey@naturalbornkiller.de Fry: what if i refused? Leila: u will be fired.... Fry: fine Leila: ..out of a cannon into the sun. Futurama - Space Pilot 3000 # random sigs made with fortune
Hi, * On Monday, February 12, 2001 at 21:40, uwe wrote:
beim kompilieren eines neuen kernels entsteht in /usr/src/linux die datei System.map.
kann es sein, dass man diese datei nach /boot kopieren muss, damit beim nächsten booten alles richtig funktioniert?
Solltest Du. (Was nicht heißt, daß Dein System ohne nicht läuft). "man klogd" erzählt mehr zu diesem Thema - unter anderem (war mir bis jetzt neu): | If a symbol file is not explicitly specified the following | filenames will be tried: | /boot/System.map | /System.map | /usr/src/linux/System.map Demnach sollte es auch reibungsfrei funktionieren, wenn Du die System.map nicht umkopierst - ich würde es aber trotzdem machen.
weil nach dem kompilieren von 2.4.1 ist in meinem verzeichnis /boot immer noch lediglich die System.map
und noch ein problem: beim ausführen von lilo kommt die meldung: Warning: Bios drive 0x82 may not be accessible Was hat das zu sagen?
Daß das BIOS möglicherweise auf das Laufwerk 0x82. nicht zugreife kann. Ich schätze mal Du hast 3 IDE-Platten und willst von /dev/hdc booten. lilo will Dir mitteilen, daß nicht jedes BIOS von der 3. Platte booten kann. Adalbert
uwe schrieb am 12.02.2001 um 21:40:27 +0100: Hallo uwe,
beim kompilieren eines neuen kernels entsteht in /usr/src/linux die datei System.map.
ja.
kann es sein, dass man diese datei nach /boot kopieren muss, damit beim nächsten booten alles richtig funktioniert?
nein.[1]
weil nach dem kompilieren von 2.4.1 ist in meinem verzeichnis /boot immer noch lediglich die System.map
mv /boot/System.map /boot/System-2.2.18 mv /boot/vmlinuz /boot/vmlinuz-2.2.18 so mach ich es. So muß man es aber nicht machen! mv /usr/src/linux/System.map /boot mv /usr/src/linux/arch/i386/boot/bzImage /boot/vmlinuz [1] das muss ist nicht richtig. Man sollte es tun. Siehe auch "man 8 klogd" und /KERNEL ADDRESS RESOLUTION suchen. Bis denne, Michael -- ------------------------------------------ Michael Schulz, Institut für Geophysik, Universtät Münster ------------------------------------------
Am Dienstag, 13. Februar 2001 09:16 schrieb Michael Schulz: [...]
mv /boot/System.map /boot/System-2.2.18 mv /boot/vmlinuz /boot/vmlinuz-2.2.18
so mach ich es. So muß man es aber nicht machen!
Angenommen, man macht das so. Bedeutet das dann, wenn ich mit lilo den Kernel vmlinuz-2.2.18 starte auch die System-2.2.18 benutzt wird?
mv /usr/src/linux/System.map /boot mv /usr/src/linux/arch/i386/boot/bzImage /boot/vmlinuz
[1] das muss ist nicht richtig. Man sollte es tun. Siehe auch "man 8 klogd" und /KERNEL ADDRESS RESOLUTION suchen.
Dazu auch noch eine Frage: Es geht ja scheinbar darum, numerische Adressangaben mit Hilfe der System.map aufzulösen. Wer macht dass denn nun? Im Ernstfall ksymoops oder klogd selbst? Ich werde da nicht so ganz schlau draus... -- mfg Peter Kuechler Umlandverband Frankfurt Systemadministrator
Hallo, On Die, 13 Feb 2001, Peter Kuechler wrote:
Am Dienstag, 13. Februar 2001 09:16 schrieb Michael Schulz: [...]
mv /boot/System.map /boot/System-2.2.18 mv /boot/vmlinuz /boot/vmlinuz-2.2.18
so mach ich es. So muß man es aber nicht machen!
Angenommen, man macht das so. Bedeutet das dann, wenn ich mit lilo den Kernel vmlinuz-2.2.18 starte auch die System-2.2.18 benutzt wird?
Nein, denn:
mv /usr/src/linux/System.map /boot mv /usr/src/linux/arch/i386/boot/bzImage /boot/vmlinuz
Wenn eine /boot/System.map existiert, dann wird diese genommen. Erst wenn es keine gibt, wird eine System.map<gleiches Anhaengsel wie das Image> genommen. Wie man das ganze aber hinbekommt steht auf http://www.dhaller.de/linux/multikernel.html CU David -- "There is hopeful symbolism in the fact that flags do not wave in a vacuum." -- Arthur C. Clarke
Peter Kuechler fiel in einem Moment der Erleuchtung ein:
Am Dienstag, 13. Februar 2001 09:16 schrieb Michael Schulz:
[...]
mv /boot/System.map /boot/System-2.2.18 mv /boot/vmlinuz /boot/vmlinuz-2.2.18
so mach ich es. So muß man es aber nicht machen!
Angenommen, man macht das so. Bedeutet das dann, wenn ich mit lilo den Kernel vmlinuz-2.2.18 starte auch die System-2.2.18 benutzt wird?
Nein, nicht ganz: Dem Kernel ist es völlig egal, wie er heisst. Das ist nur wichtig für den Bootloader. Es wird versucht die für den Kernel passende System-map zu laden: also System.map-`uname -r`. Man möge mich korrigieren, aber bei mir funzt es, und meine Kernel haben teilweise schreckliche Namen :-) Beispiel: mein Kernel heisst Kernel-2.4.1-pre9-nfsd System.map-2.4.1-pre9 gehört dazu hier aus der boot.msg: --------- Inspecting /boot/System.map-2.4.1-pre9 Loaded 13938 symbols from /boot/System.map-2.4.1-pre9. Symbols match kernel version 2.4.1. Loaded 190 symbols from 9 modules. --------- Zum Rest AFAIR: den klogd braucht der syslog um überhaupt halbwegs aussagekräftige Meldungen zu fabrizieren (in den messages). ksymoops ist dann speziell für die oopses um die oops-Meldungen (wenn mal einer passiert ist) spezielle den Kernel-Strukturen zurückzupuzzlen. Dabei gehts um die Zahlen-kolonnen, die beim oops ausgespuckt werden. *null Anspruch auf Richtigkeit/Vollständigkeit* hier noch die schöne Beschreibung von David: http://www.dhaller.de/linux/multikernel.html -- Mathias Weigt
Peter Kuechler schrieb am 13.02.2001 um 11:46:09 +0100: Hallo Peter,
Am Dienstag, 13. Februar 2001 09:16 schrieb Michael Schulz:
[...]
mv /boot/System.map /boot/System-2.2.18 mv /boot/vmlinuz /boot/vmlinuz-2.2.18
so mach ich es. So muß man es aber nicht machen!
Angenommen, man macht das so. Bedeutet das dann, wenn ich mit lilo den Kernel vmlinuz-2.2.18 starte auch die System-2.2.18 benutzt wird?
bei mir ja. Nur ich bin mir nicht sicher ob das jetzt was mit dem Namen zu tun hat, oder ob das nicht über ein uname ermittelt wird?
mv /usr/src/linux/System.map /boot mv /usr/src/linux/arch/i386/boot/bzImage /boot/vmlinuz
[1] das muss ist nicht richtig. Man sollte es tun. Siehe auch "man 8 klogd" und /KERNEL ADDRESS RESOLUTION suchen.
Dazu auch noch eine Frage:
Es geht ja scheinbar darum, numerische Adressangaben mit Hilfe der System.map aufzulösen. Wer macht dass denn nun? Im Ernstfall ksymoops oder klogd selbst? Ich werde da nicht so ganz schlau draus...
für die oops ist ksymoops da. Für die "normalen" Meldungen die auch in den Messages erscheinen brauch der klogd das wohl um zumindest einigermaßen verständliche Meldungen zu erzeugen. Bis denne, Michael -- ------------------------------------------ Michael Schulz, Institut für Geophysik, Universtät Münster ------------------------------------------
Hallo SuSE-Liste,
wenn sich User per ssh einwählen können
On Tue, 13 Feb 2001, Soan Sewa wrote:
Hallo SuSE-Liste, wenn sich User per ssh einwählen können
das kommt doch drauf an, was Du für User hast, die sich anmelden, Du mußt nur die Rechte der user entsprechend beschränken. Eine Möglichkeit ist auch, abzutesten, ob es solche user sind, und Ihnen rbash (bash -r) als Shell anzudrehen (restricted shell, kein cd und so...) und ein paar nette aliase für die "gefährlichen" Kommandos... -- may the tux be with You! Joerg Thuemmler sysadmin@vordruckleitverlag.de
participants (10)
-
Adalbert Michelic -
David Haller -
Henne Vogelsang -
Joerg Thuemmler -
Mathias Weigt -
Michael Schulz -
Peter Kuechler -
Soan Sewa -
u-roller＠t-online.de -
Volker Tanner