Hallo Liste, ich habe leider einen Rechner mit geringem Festplattenplatz, so um die 300 MB Gesamtkapazität. Derzeit hat der noch 5 MB übrig. Das reicht leider nicht, um die Kernelquellen zu installieren. Gibt es eine Möglichkeit, wie ich auf meinem anderen Rechner, der erstens schneller ist, zweitens mehr Festplattenkapazität hat. Der Kernel kompilieren kann (das sollte nicht das Problem sein) und danach auf den anderen Rechner zu installieren. Beim installieren, fangen bei mir die Probleme an. In Sachen Kernel kompilieren kenne ich mich ja schon aus, aber was ist mit den Modules und den anderen Sachen. Wie und wo liegen die, und wie und wo müssen die hin? Meine Rechner sind über Netzwerk miteinander verbunden, und der NFS läuft. Soll heißen, ich kann die Verzeichnisse des Rechners, der den Kernel kompilieren soll freigeben. Leider habe ich nicht den blasesten Schimmer wie ich die Installation von Hand erledige. Normalerweise erledigen ich das immer mit folgenden Befehlen: make bzImage, modules_install, bzlilo. Wie funkt das von Hand? Ach so das wichtigste zum Schluß: Kernel 2.2.5 Suse 6.1 Für Anregungen immer dankbar. -- M.f.G. Marcus Registered Linux-User:136595 Mail: Netscanner@gmx.de ICQ:28762595 Bitte keine CC Danke! --------------------------------------------------------------------- To unsubscribe, e-mail: suse-linux-unsubscribe@suse.com For additional commands, e-mail: suse-linux-help@suse.com
On Thu, 30 Sep 1999, Marcus Maul wrote:
ich habe leider einen Rechner mit geringem Festplattenplatz, so um die 300 MB Gesamtkapazität. Derzeit hat der noch 5 MB übrig. Das reicht leider nicht, um die Kernelquellen zu installieren.
Gibt es eine Möglichkeit, wie ich auf meinem anderen Rechner, der erstens schneller ist, zweitens mehr Festplattenkapazität hat. Der Kernel kompilieren kann (das sollte nicht das Problem sein) und danach auf den anderen Rechner zu installieren.
Beim installieren, fangen bei mir die Probleme an. In Sachen Kernel kompilieren kenne ich mich ja schon aus, aber was ist mit den Modules und den anderen Sachen. Wie und wo liegen die, und wie und wo müssen die hin? Meine Rechner sind über Netzwerk miteinander verbunden, und der NFS läuft. Soll heißen, ich kann die Verzeichnisse des Rechners, der den Kernel kompilieren soll freigeben.
Leider habe ich nicht den blasesten Schimmer wie ich die Installation von Hand erledige. Normalerweise erledigen ich das immer mit folgenden Befehlen: make bzImage, modules_install, bzlilo.
Wie funkt das von Hand?
Kernel konfigurieren, mit der üblichen Umsicht ;) Besonders Rootfilesystem nicht vergessen. Dann make dep clean zImage modules Wenn Du eine andere Kernelversion hast dann kannst Du ein make modules_install machen. Die Module landen dann in /lib/modules/kernelversion. Sonst benenn das aktuelle Verzeichnis einfach temporär um. Das neue Verzeichnis kopieren auf den anderen Rechner. Die neue System.map und arch/i386/boot/zImage kopieren. Alles z.B. nach /boot packen. Es mach Sinn mit symlinks zu arbeiten. vmlinux -> vmlinux-2.2.10 System.map -> System.map-2.2.10 Dann einfach eine zusätzliche Konfiguration in lilo.conf anlegen, von Hand oder per YaST. lilo aufrufen Rebooten und hoffen das das Rootfilesystem wirklich drin ist. Wenn alles glatt geht kannst Du die neue lilo Konfiguration an erste Stelle schieben. Gruss Olaf -- erde raute -- SuSE GmbH, Tel: +49-911-7405330 Mo/Do 13-18.00 Schanzaeckerstr. 10, Fax: +49-911-3206727 90443 Nuernberg, Email: olh@suse.de Germany WWW: http://www.suse.de/doku/ --------------------------------------------------------------------- To unsubscribe, e-mail: suse-linux-unsubscribe@suse.com For additional commands, e-mail: suse-linux-help@suse.com
Hallo Olaf! On Fri Oct 1 02:35:49 1999 CEST Olaf Hering wrote: <schnipp>
Die neue System.map und arch/i386/boot/zImage kopieren.
Ist die Sytem.map eigentlich nicht systemabhängig bzw. was macht die?
Ich dachte (wegen des Namens), das die ein mapping zwischen Rechner und
OS vornimmt - und das wäre doch auf jeden Rechner anders, oder?
Neugierig, Eike
--
\\|// LINUX wird nie zum meistinstallierten System - so
(@ @) oft wie man Win95 neu installieren darf!
----oOO---(_)--OOo-----
Hi Eike, On Fre, 01 Okt 1999, Eike Bernhardt wrote:
On Fri Oct 1 02:35:49 1999 CEST Olaf Hering wrote:
Die neue System.map und arch/i386/boot/zImage kopieren.
Ist die Sytem.map eigentlich nicht systemabhängig bzw. was macht die?
Nö, die System.map gehört jeweils zu dem Kernel mit dem sie erstellt wurde. make zImage erzeugt auch 'ne neue System.map.
Ich dachte (wegen des Namens), das die ein mapping zwischen Rechner und OS vornimmt - und das wäre doch auf jeden Rechner anders, oder?
Eher zwischen OS und OS :-) In der System.map stehen die Adressen für den Kernel wichtiger Variablen und Funktionen. Mit Hilfe der System.map versucht klogd nach einem Systemabsturz ("Kernel Ooops") herauszufinden in welcher Funktion der Fehler auftrat, und was in den globalen Variablen stand... CU, Stefan -- Stefan Giessler e-mail: stefan.Giessler@net-share.de Language shapes the way we think, and determines what we can think about. -- B.L.Whorf --------------------------------------------------------------------- To unsubscribe, e-mail: suse-linux-unsubscribe@suse.com For additional commands, e-mail: suse-linux-help@suse.com
Eike Bernhardt wrote:
Ist die Sytem.map eigentlich nicht systemabhängig bzw. was macht die?
Ich dachte (wegen des Namens), das die ein mapping zwischen Rechner und OS vornimmt - und das wäre doch auf jeden Rechner anders, oder?
Neugierig, Eike
Hallo Eike, Ja, die System.map ist *extrem* systemabhängig und BTW in der Regel geleichfalls überflüssig. Nein, das Ding ist kein mapping zwischen Rechner und OS. Vielmehr handelt es sich hierbei um die Symbol-tabelle deines Kernels. Und die Symbole brauchst Du eigentlich nur, wenn Du debuggen willst, sprich: (selbst entwickelte) Programmteile des Kernels zur Laufzeit untersuchen. Alles Klar ;-) ? mfG Klaus --------------------------------------------------------------------- To unsubscribe, e-mail: suse-linux-unsubscribe@suse.com For additional commands, e-mail: suse-linux-help@suse.com
Moin! On Sat Oct 02 14:59:10 1999 MEST Klaus Eltermann wrote:
Eike Bernhardt wrote:
Nein, das Ding ist kein mapping zwischen Rechner und OS. Vielmehr handelt es sich hierbei um die Symbol-tabelle deines Kernels. Und die Symbole brauchst Du eigentlich nur, wenn Du debuggen willst, sprich: (selbst entwickelte) Programmteile des Kernels zur Laufzeit untersuchen.
Alles Klar ;-) ?
Nun ja - dann kann man die also einfach bei einem Kernel, den man auf
einem großen Rechner kompiliert, auf einen kleinen Rechner
rüberkopieren, da sie im alltäglichen Betrieb nicht gebraucht wird,
right?
Das wäre sehr praktisch, mein kleiner 386er braucht doch ein wenig
lange, um nen Kernel zu basteln ;)
Tschau, Eike
--
\\|// LINUX wird nie zum meistinstallierten System - so
(@ @) oft wie man Win95 neu installieren darf!
----oOO---(_)--OOo-----
Mahlzeit!
Nun ja - dann kann man die also einfach bei einem Kernel, den man auf einem großen Rechner kompiliert, auf einen kleinen Rechner rüberkopieren, da sie im alltäglichen Betrieb nicht gebraucht wird, right?
Richtig.
Das wäre sehr praktisch, mein kleiner 386er braucht doch ein wenig lange, um nen Kernel zu basteln ;)
Tschau, Eike
Ich hab jetzt noch ein biss'l Recherche betrieben. Den einzigen Hinweis auf das Ding hab ich unter "/usr/doc/sdb/de/html/system_map.html" gefunden. Angeblich *kann* es bei einer nicht vorhandenen oder nicht zum Kernel korrespondierenden System.map zu einer Fehlermeldung beim booten kommen. Auch soll sich der DOSEMU u.U. beschweren. Nachdem der Text aber von Juni 1996 ist, habe ich das mal nachgeprüft: Jede System.map, die find gemeldet hat, runtergeschmissen (bis auf die aktuellste, nur umbenannt; man weiß ja nie ;-) ). Anschließend lilo, reboot, ein paar insmod's, lsmod's und modprobe's und den DOSEMU getestet. Alles problemlos. In den Quellen unter /usr/src/linux findet sich auch nur ein Zusammenhang zu PowerPC und SPARC-Rechnern. Ich bleibe also so lange dabei, bis mir jemand das Gegenteil beweist: Du brauchst das Ding für den normalen Betrieb nicht. :-) mfG Klaus --------------------------------------------------------------------- To unsubscribe, e-mail: suse-linux-unsubscribe@suse.com For additional commands, e-mail: suse-linux-help@suse.com
Moin! On Sun Oct 03 11:10:46 1999 MEST Klaus Eltermann wrote:
Das wäre sehr praktisch, mein kleiner 386er braucht doch ein wenig lange, um nen Kernel zu basteln ;)
Ich hab jetzt noch ein biss'l Recherche betrieben. Den einzigen Hinweis auf das Ding hab ich unter "/usr/doc/sdb/de/html/system_map.html" gefunden. ... Ich bleibe also so lange dabei, bis mir jemand das Gegenteil beweist: Du brauchst das Ding für den normalen Betrieb nicht. :-)
Danke! Da wird sich mein kleiner 386er freuen, wenn er sich nicht mit
Kernel 2.0.3x rumquälen muß.
Tschau, Eike
--
\\|// LINUX wird nie zum meistinstallierten System - so
(@ @) oft wie man Win95 neu installieren darf!
----oOO---(_)--OOo-----
* Klaus Eltermann (Klaus.Eltermann@t-online.de) [19991002 15:00]:
Ja, die System.map ist *extrem* systemabhängig und BTW in der Regel geleichfalls überflüssig.
Nein, das Ding ist kein mapping zwischen Rechner und OS. Vielmehr handelt es sich hierbei um die Symbol-tabelle deines Kernels. Und die Symbole brauchst Du eigentlich nur, wenn Du debuggen willst, sprich: (selbst entwickelte) Programmteile des Kernels zur Laufzeit untersuchen.
Tja, nur leider stimmt das so nicht ganz :) Richtig ist, das System.map die Symboltabelle des Kernels ist. Aber es gibt ein paar Dinge die ohne Sie nicht so gut laufen. So liest z.B. klogd beim Starten die Datei. Und auch die Verwendung von ksymoops ist ohne System.map sinnlos. Ersteres hat keinen Bezug zum Debuggen, letzteres nur bedingt. Philipp --------------------------------------------------------------------- To unsubscribe, e-mail: suse-linux-unsubscribe@suse.com For additional commands, e-mail: suse-linux-help@suse.com
Moin! On Mon Oct 04 04:40:23 1999 MEST Philipp Thomas wrote:
* Klaus Eltermann (Klaus.Eltermann@t-online.de) [19991002 15:00]:
Nein, das Ding ist kein mapping zwischen Rechner und OS. Vielmehr handelt es sich hierbei um die Symbol-tabelle deines Kernels. Und die Symbole brauchst Du eigentlich nur, wenn Du debuggen willst, sprich: (selbst entwickelte) Programmteile des Kernels zur Laufzeit untersuchen.
Tja, nur leider stimmt das so nicht ganz :) Richtig ist, das System.map die Symboltabelle des Kernels ist.
Ist diese Symboltabelle aber nun abhängig von der verwendeten Hardware,
soll heißen kann ich z.B. einen Kernel für einen 386er mit ISA-NIC auf
einem Dual-Pentium mit PCI-NIC bauen und die dabei auf dem Pentium
entstandene Sytem.map auf dem 386er einsetzen?
Tschau, Eike
--
\\|// LINUX wird nie zum meistinstallierten System - so
(@ @) oft wie man Win95 neu installieren darf!
----oOO---(_)--OOo-----
Moin!
N'Abend
Ist diese Symboltabelle aber nun abhängig von der verwendeten Hardware, soll heißen kann ich z.B. einen Kernel für einen 386er mit ISA-NIC auf einem Dual-Pentium mit PCI-NIC bauen und die dabei auf dem Pentium entstandene Sytem.map auf dem 386er einsetzen?
Nö, sie ist nicht hardwareabhängig. Sie ist ein Verzeichnis des kompilierten Kernels. Die Hardware wird durch die Treiber in der Software abgebildet. Du kompilierst sie mit in den Kernel oder lädst sie als Module; aber das kennst Du ja schon ;-) Die Verbindung zwischen Hard- und Software wird durch die Auswahl der Treiber gebildet. Auf eine spezielle Hardware passen sich die Module selbst an (autoprobe; PnP) oder man gibt ihnen Boot-/Startparameter mit (Interrupt/IO-Adresse). Der Kernel ist nicht auf die System.map angewiesen.
Tschau, Eike
mfG Klaus --------------------------------------------------------------------- To unsubscribe, e-mail: suse-linux-unsubscribe@suse.com For additional commands, e-mail: suse-linux-help@suse.com
Philipp Thomas wrote:
Hallo Philipp,
Tja, nur leider stimmt das so nicht ganz :) Richtig ist, das System.map die Symboltabelle des Kernels ist. Aber es gibt ein paar Dinge die ohne Sie nicht so gut laufen. So liest z.B. klogd beim Starten die Datei. Und auch die Verwendung von ksymoops ist ohne System.map sinnlos.
Also, klogd ist der "Kernel log daemon". Er benutzt die System.map, um beim Systemcrash den Inhalt des IP in einer Kernelfunktion zu lokalisieren. Der KSymOops benutzt die System.map in gleicher Weise, indem man ihn mit einer Kernel-Oops -Meldung füttert. Beide haben Pech, wenn der crash in Modul stattfindet. Damit die dann was finden, muß man die System.map nochmal aufbereiten. Im Prinzip sind also beide da, um Kernelmeldungen (im Falle eines Falles) in 'human readable' Form zu bringen. Das System weiß, wo seine Prozeduren/Variablen liegen. Wenn ich also auf einen der beiden angewiesen bin, bin ich einem Fehler auf der Spur, sprich beim Debuggen. (Auch wenn es sich nur um das erste Mittel handelt, bevor ich den gdb ansetze ;-) ) In einem System mit begrenzten Resourcen werde ich also weder den einen noch den anderen im täglichen Betrieb benötigen. (Was anderes ist es, wenn wir über M$WinNN diskutieren; BlueScreen gehört zum Standard) Überzeugt? :-) mfG Klaus
Ersteres hat keinen Bezug zum Debuggen, letzteres nur bedingt.
Philipp
--------------------------------------------------------------------- To unsubscribe, e-mail: suse-linux-unsubscribe@suse.com For additional commands, e-mail: suse-linux-help@suse.com
--------------------------------------------------------------------- To unsubscribe, e-mail: suse-linux-unsubscribe@suse.com For additional commands, e-mail: suse-linux-help@suse.com
participants (6)
-
eike.bernhardt＠gmx.de -
Klaus.Eltermann＠t-online.de -
Mailings-Suse＠gmx.de -
olh＠suse.de -
pthomas＠suse.de -
sgiessler＠gmx.net