Archive-name: de/comp/linux/dcoul-faq/section4
Posting-frequency: monthly Last-modified: 2004-08-28 15:40:02 Version: CVS revision URL: http://www.dcoul.de/faq/ See reader questions & answers on this topic! - Help others by sharing your knowledge http://www.dcoul.de/faq/ _________________________________________________________________ 4. Fragen zum Kernel 4.1 Ich habe Linux gerade erst hochgefahren und fast mein gesamter Speicher ist schon belegt. Verbraucht Linux soviel Speicher? Linux versucht, den vorhandenen Speicher möglichst effizient zu nutzen. Daher wird der von Programmen zur Zeit nicht benötigte Speicher als Plattencache benutzt. Sobald ein Programm mehr Speicher anfordert, wird der Plattencache automatisch verkleinert und der freigewordene Speicher dem Programm zur Verfügung gestellt. Es ist also vollkommen normal, dass der Speicher immer sehr voll zu sein scheint. 4.2 Linux erkennt nur einen Teil meines Speichers. Wie kann ich das ändern? Du teilst einfach dem Kernel explizit mit, wie viel Speicher du hast, indem du einen Kernelparameter übergibst, bei 96 MB z.B. mem=96M. Wie Kernelparameter übergeben werden, ist im BootPrompt-HOWTO beschrieben. Aber Windows erkennt doch problemlos den ganzen Speicher? Zum Abfragen der Speichergröße gibt es verschiedene BIOS-Funktionen, int15/88, die älteste, kann nur Speichergrößen bis 64 MB übermitteln. Linux benutzt sie, wenn keine der "besseren" Funktionen implementiert ist. int15/e801 wird seit Kernel 2.0.36 (anno 1998) unterstützt und kann auch Speichergrößen über 64 MB zuverlässig zurückliefern, aktuelle BIOS (seit ca. 1999) bieten diese Funktion aber nicht mehr an. Kernel 2.4 verwendet daher wie Windows int15/e820, womit das Problem hoffentlich beseitigt ist. (Mittels fancy-memory-patch <http://www.pell.portland.or.us/~orc/Memory/> kann man auch älteren Kerneln die neue BIOS-Funktion beibringen.) int15/e801 und besonders int15/e820 melden nicht nur schlicht das obere Ende des Hauptspeichers zurück, sondern können z.B. auch über "Löcher" im Speicher (Memory Holes) und andere Dinge mehr informieren. Eine Beispielausgabe von Kernel 2.4.x: BIOS-provided physical RAM map: BIOS-e820: 000000000009fc00 @ 0000000000000000 (usable) BIOS-e820: 0000000000000400 @ 000000000009fc00 (usable) BIOS-e820: 0000000000010000 @ 00000000000f0000 (reserved) BIOS-e820: 0000000000010000 @ 00000000ffff0000 (reserved) BIOS-e820: 0000000003f00000 @ 0000000000100000 (usable) 4.3 Ich habe gehört, es gibt Linux auch auf anderen Plattformen wie z.B. DEC Alpha, Sun SPARC, MIPS oder m68k. Kann ich meine Linux-Programme auch auf diesen Plattformen ausführen? Grundsätzlich nein. Die verschiedenen Plattformen verwenden unterschiedliche Prozessoren und sind daher nicht binärkompatibel. Für die Alphas gibt es eine Intel-Emulation, mit der auch Linux-Programme für Intel-Prozessoren dort ausgeführt werden können, aber diese ist wohl noch nicht vollkommen ausgereift. Sofern zu einem Programm der Sourcecode vorhanden ist, stellt es jedoch in der Regel kein Problem dar, ihn auf einer anderen Plattform unter Linux zu kompilieren. Die verschiedenen Linux/68k-Varianten sind untereinander binärkompatibel, d.h. ein auf einem Amiga unter Linux/68k kompiliertes Programm läuft auch z.B. auf einem Atari TT unter Linux/68k und umgekehrt. 4.4 Warum zeigt mein Rechner einen geringeren (höheren) BogoMips-Wert an als ein Rechner mit einem anderen Prozessor, obwohl mein Rechner tatsächlich schneller (langsamer) ist? Der BogoMips-Wert ist kein Maß für die Geschwindigkeit des Rechners, daher auch die Bezeichnung _Bogo_, das kommt vom engl. Wort bogus, was unsinnig, falsch oder irreführend bedeutet. Der Wert ist vom verwendeten Prozessortyp abhängig und zwischen verschiedenen Prozessortypen nicht vergleichbar (beispielsweise liefert ein 486DX4-100 einen höheren BogoMips-Wert als ein Pentium 100, obwohl der Pentium deutlich schneller ist, noch extremer ist der Vergleich zwischen einem AMD-K5 und einem Pentium). Näheres dazu ist im BogoMips-Mini-HOWTO zu finden. 4.5 Unterstützt Linux FAT32 (das mit Win95b a.k.a. OSR2 eingeführte neue Dateisystem)? Ja, ab Kernel 2.0.35. Für ältere Kernelversionen gibt es entsprechende Patches, jedoch ist es ratsam, statt der Verwendung des Patches auf Kernel 2.0.35 oder neuer upzudaten. 4.6 Welchen Zweck hat die Datei /proc/kcore und warum belegt sie soviel Platz auf meiner Platte? Die Dateien in /proc sind nur virtuell, d.h. sie belegen keinen Plattenplatz, auch wenn sie scheinbar eine Länge haben. Der Inhalt der Dateien in /proc wird vom Kernel bei Bedarf generiert. /proc/kcore ist ein Abbild des Hauptspeichers, d.h. die Datei ist genauso groß, wie der vorhandenen Hauptspeicher (plus 4 KB). Das Proc-Dateisystem hat den Zweck, den Zugriff auf Systeminformationen mit normalen Dateioperationen zu ermöglichen, so dass man sie z.B. leicht in Skripten verwenden kann. 4.7 Ich habe einen Kernel mit Unterstützung für APM (advanced power management), aber es funktioniert nicht bzw. nicht korrekt. Die APM-Funktionen arbeiten in der Regel nur, wenn im BIOS des Rechners ebenfalls APM aktiviert wurde. Weitere Informationen zu APM im Allgemeinen und auf Laptops im Besonderen finden sich im Battery-Powered Mini-HOWTO, welches in den meisten Distributionen irgendwo unterhalb des Verzeichnisses /usr/doc liegt, sowie auf der Linux-Laptop-Page (vgl. Funktioniert Linux auf meinem Laptop?) 4.8 Ich kann keinen Kernel mehr kompilieren: nach make zImage meldet das System System is too big. Try using bzImage or modules. Die Meldung besagt, dass das erzeugte Kernel-Image zu groß ist. Bei der traditionellen Methode der Kernelerzeugung darf der resultierende Kernel maximal 512KB groß sein, ist er größer, kann er von der Initialisierungsroutine nicht mehr korrekt entpackt werden. Um dieses Problem zu lösen, gibt es zwei Alternativen: entweder man erzeugt mehr Treiber als Module und verkleinert damit das erzeugte Kernel-Image oder man verwendet statt make zImage (bzw. make zlilo oder make zdisk) make bzImage (respektive bzlilo oder bzdisk). Dabei wird ein anderes Speicherlayout verwendet, welches auch größere Kernel-Images zulässt. Die Bezeichnung bzImage steht dabei für big zImage, hat also nichts mit bzip2 zu tun. Heutzutage ist es weitgehend unproblematisch, generell make bzImage statt make zImage zu verwenden, lediglich ältere LILO- und Loadlin-Versionen können damit nicht umgehen. 4.9 Seit Kernel 2.2.15 funktioniert BattleNet über meinen Linux-Router mit Masquerading nicht mehr. In Kernel 2.2.15 wurde eine Variable sysctl_ip_masq_udp_dloose eingeführt und standardmäßig auf 0 gesetzt. Dies verhindert nunmehr, dass für das Spiel notwendige UDP-Pakete in Richtung Windows-PC gelangen. Lösung: Stelle sicher, dass Port 6112/udp durch einen evtl. vorhandenen Paketfilter gelangt. Füge zusätzlich diese Zeile in dein Firewallscript oder in dein ip-up-Script ein: echo "2" > /proc/sys/net/ipv4/ip_masq_udp_dloose WARNUNG: Alan Cox bewertet dies als Sicherheitsrisiko. Diese Einstellung stellt allerdings ein Verhalten wieder her, das bis einschließlich Kernel 2.2.14 Standard war. Also Vorsicht damit! 4.10 Was bedeutet die Meldung mount fs type devpts not supported by Kernel? Mit der glibc-2.1 wurden neue Pseudo-Terminals eingeführt, die sich am Unix98-Standard orientieren und deshalb als Unix98-PTYs bezeichnet werden. Für deren Nutzung wurde ein zusätzliches Pseudo-Filesystem, devpts, geschaffen. Daher muss für die Verwendung von Unix98-PTYs bei der Kernelkonfiguration unter Character Devices der Punkt Unix98 PTY Support und unter Filesystems der Punkt /dev/pts filesystem for Unix98 PTYs aktiviert sein. 4.11 Ich möchte einen neuen Kernel compilieren, erhalte auf make menuconfig aber nur die Meldung make: *** No rule to make target `menuconfig'. Stop. Das kann mehrere Ursachen haben. Die einfachste Variante: man befindet sich nicht im Kernel-Source-Verzeichnis (im Normalfall /usr/src/linux). Falls doch, ist kein Kernelsource installiert und muss nachinstalliert werden. Für SuSE-Nutzer: anscheinend werden bei SuSE 6.2 die Kernelsourcen nicht mehr standardmäßig installiert, sofern sie bei der Installation nicht explizit ausgewählt wurden. 4.12 Was hat es mit den 2.5.x-Kerneln auf sich? Sollte man von 2.4.x updaten? Alle Kernel mit einer ungeraden Minor-Nummer (die Nummer an zweiter Stelle, also bei 2.5.x die 5) sind Entwickler-Kernel. Diese enthalten experimentelle Funktionen, lassen sich eventuell gar nicht kompilieren oder können im Extremfall auch Daten auf der Festplatte zerstören. Daher sollte man diese Kernel nur verwenden, wenn man wirklich weiß, was man tut. Für den Normaluser sind Entwicklerkernel ungeeignet und Beschwerden über Probleme mit Entwicklerkerneln werden in den de.comp.os.unix.linux-Newsgroups im Regelfall ignoriert. 4.13 Ich habe auf Kernel 2.6.x geupgradet und es werden keine Module mehr geladen. Für Kernel 2.6 sind die module-init-tools und nicht mehr die modutils für das Laden von Modulen zuständig. Installiere enweder ein vom Hersteller deiner deiner Distribution bereitgestelltes Paket oder kompiliere die Sourcen von ftp://ftp.kernel.org/pub/linux/kernel/people/rusty/modules/. Damit wirst du aber vermutlich nicht alle Probleme, die mit einem neuen Kernel auf dich zukommen, gelöst haben, lies Kernelquelltext/Documentation/Changes und überprüfe, ob du die erforderlichen Programme in den nötigen Versionen installiert hast. 4.14 Wie kann ich unter Linux mit Dateien größer 2 GB arbeiten? Zuerst einmal müssen die Programme, welche mit Dateien > 2 GB arbeiten sollen, andere Betriebssystemaufrufe verwenden als bisher (Natürlich kann man mit diesen trotzdem auch kleinere Dateien erzeugen), da der Zeiger für die Dateiposition von 32 auf 64 Bit gestiegen ist. Dies ist bei längst noch nicht allen Programmen der Fall. Dann müssen Kernel und glibc noch entsprechende Unterstützung anbieten. Auf einer 64-Bit Maschine (z.B. Alphastation) ist das bereits der Fall. Auf 32 Bit Maschinen wie i386 und PowerPC muss man dazu auf einen 2.4 Kernel (oder einen 2.2 Kernel entsprechend patchen) und eine glibc > 2.1.3 umsteigen. In Stichworten: * Kernel 2.4. (Oder einen 2.2er Kernel mit LFS-patch) * Glibc 2.1.3 oder glibc 2.2, die gegen die Header eines LFS-fähigen Kernels (s.o.) kompiliert ist. * Anwendungen, die LFS verwenden sollen, müssen entsprechend modifiziert worden sein * Ein Filesystem, das LFS unterstützt. Ext2, ReiserFS Genauer steht das alles auf http://www.suse.de/~aj/linux_lfs.html. 4.15 Ich habe einen neuen Kernel kompiliert, dieser bootet aber nicht, sondern gibt die Fehlermeldung Kmod: failed to exec /sbin/modprobe -s -k binfmt-464c, errno = 8 aus. Du hast beim Konfigurieren des Kernels Kernel support for ELF binaries CONFIG_BINFMT_ELF nicht ausgewählt. Diese Unterstützung für das unter Linux übliche Format von ausführbaren Programmen und Bibliotheken muss fest im Kernel einkompiliert sein und nicht als Modul, da insbesondere modprobe und insmod, die für das Laden von Kernelmodulen nötig sind, im ELF-Format vorliegen. 4.16 Seit dem Upgrade auf Kernel 2.4 verbraucht der Prozess kapm-idled den Großteil der CPU-Leistung. Wenn dein Linux Kernel mal nicht mit irgendwas beschäftigt ist, sprich ein paar Mikrosekunden lang kein Prozess was erledigt haben möchte ist der Kernel "idle" (im Leerlauf). (z.B: alle Prozesse schlafen und warten auf ein bestimmtes Event, wie das Beenden einer I/O-Operation auf der Festplatte, also auf den Interrupt vom HDD-Controller o.ä.) Hast du nun APM (Advanced Power Management) aktiviert und wird es auch von deiner Hardware unterstützt, so weckt der Kernel nach einer bestimmten Zeit, die er idle ist, den "kapm-idled" Daemon (siehe "d" am Ende des Namens), der wiederum über einen APM BIOS Call die Hardware in "idle" (Powersaving) versetzt, was dann dazu führt, dass während dieser Phase, in der der Kernel eh nichts zu tun hat, Strom gespart werden kann (o.ä.), was vor allem bei Notebooks sehr hilfreich sein kann. Die Aussage, der APM-idle Daemon "verballere" deine knappe CPU-Leistung, ist damit also vollkommen unsinnig, da der kapm-idled immer nur dann dran kommt, wenn der Kernel eh eine gewisse Zeit lang nichts zu tun hat. Aber wenn es dich beruhigt, kannst du es auch ausschalten oder es gleich aus dem Kernel heraus lassen beim nächsten neuen Kernel. Dafür musst du die Option CONFIG_APM_CPU_IDLE deaktivieren. 4.17 Wie viel Swapspace brauche ich? Swapspace dient dazu, den verfügbaren Arbeitsspeicher zu vergrößern, d.h. Festplattenspeicher als RAM-Ersatz zu benützen. Wie viel man davon braucht, ist abhängig vom Nutzungsprofil und der Kernelversion. Insgesamt sollte soviel zur Verfügung stehen, dass nie mehr benötigt wird. Da Linux sehr unwillig reagiert, wenn der Speicher ausgeht (es werden der Reihe nach Prozesse gekillt.), sollte du den Swapspace großzügig bemessen. Als grobe Faustregel kann daher Swap = RAM dienen. Wie groß darf eine einzelne Swappartition bzw. Swapdatei sein? Bis einschließlich Kernel 2.0.* gab es eine Beschränkung auf 128MB, seit Kernel 2.2 liegt sie bei 2 GB. Swappartition oder Swapdatei? Eine Swappartition ist prinzipiell schneller, da der umständliche Zugriff über das Dateisystem, auf dem Swapdatei liegt, weg fällt; allerdings kann dieser Gewinn durch ungünstige Platzierung der Swappartition zunichte gemacht werden (Swap am einen Ende der Festplatte, Daten am anderen, der Festplattenkopf muss dauernd hin und her schwenken.). Siehe Multi-Disk HOWTO. 4.18 Seit dem Upgrade auf Kernel 2.4 zeigt /proc/meminfo immer 0 Byte Shared Memory an. Wegen interner Änderungen kann der Kernel diesen Wert nicht mehr billig berechnen, um kompatibel zu alten Utilities zu bleiben, gibt er daher immer 0 aus. Siehe http://www.tux.org/lkml/#s14-3. Damit POSIX Shared Memory nutzbar ist, muss bei der Kernelkompilation Virtual memory file system support aktiviert werden und das entsprechende Filesystem muss gemountet werden. Bis Kernel 2.4.3 lautet der entsprechende Eintrag in /etc/fstab none /dev/shm shm defaults 0 0, ab 2.4.4 (und für frühere Kernel mit tmpfs-patch) tmpfs /dev/shm tmpfs defaults 0 0. POSIX Shared Memory wird momentan nur von wenigen meist kommerziellen Programmen (SAP) verwendet, wesentlich häufiger wird SYSV-shmem verwendet, welches auch ohne Mounten von tmpfs verwendet werden kann und über dessen Nutzung das Programm ipcs Aufschluss gibt. 4.19 Seit dem Upgrade auf Kernel 2.4 kann ich bestimmte Hosts im Internet nicht mehr erreichen. Das kann daran liegen, dass dein Kernel Explicit Congestion Notification (ECN) verwendet, damit kann man in den Headern der IP-Pakete Informationen darüber, ob die Leitung ausgelastet ist, mit übertragen. Leider gibt es noch Router oder Firewalls, die damit nicht zurechtkommen, und solche Pakete nicht weiterleiten, die Rechner dahinter sind daher nicht erreichbar. Du kannst mit cat /proc/sys/net/ipv4/tcp_ecn den Status von ECN überprüfen, 0 bedeutet aus, 1 ein. Lösungsmöglichkeiten: * Kernel mit TCP Explicit Congestion Notification support CONFIG_INET_ECN N kompilieren * ECN beim Booten deaktivieren, trage einfach net/ipv4/tcp_ecn = 0 in /etc/sysctl.conf ein. Debian verwendet modifizierte Kernelsourcen, die als Alternative die Möglichkeit bieten, mit Disable ECN support by default CONFIG_INET_ECN_DISABLED Y ECN in den Kernel einzubauen, ohne es automatisch zu aktivieren. Lesetipps: * RFC3168 4.20 Was bedeutet Journaling-Filesystem? Welches Dateisystem ist das beste? Journaling funktioniert so: Jeder Schreibzugriff auf das Dateisystem wird zuerst im Journal bzw. Transaktionslog vorgemerkt, wenn die Daten später wirklich ins Dateisystem eingetragen wurden, wird der entsprechende Eintrag im Journal als erledigt markiert. Das Transaktionslog wird nicht gecacht sondern synchron geschrieben. Wenn der Computer jetzt mittendrin abstürzt, geht der fsck (File System Check) viel schneller und einfacher: Man schaut einfach im Journal nach, welche Daten noch zu schreiben sind, und macht das. Unvollständige Einträge im Journal werden entfernt. Beim klassischen fsck muss man dagegen das ganze Dateisystemen darauf untersuchen, ob noch irgendwo durch halbfertige Schreibvorgänge kaputte Daten liegen. Der Nachteil ist, dass diese zusätzliche Komplexität ein wenig Platz auf der Festplatte und Rechenzeit kostet. Die Frage nach dem besten Dateisystem ist schwer zu beantworten, alle haben ihre Vor- und Nachteile: * ext2: Es ist das Älteste und daher ohne Zweifel das am Besten getestete, daher ist es extrem stabil, außerdem gibt es mit fsck.ext2 ein funktionierendes Reparaturprogramm. Ext2 ist aber kein Journaling-FS. Ext2 und ext3 sind bei Verzeichnissen mit sehr vielen Dateien wesentlich langsamer als die anderen Dateisysteme. * ext3: Das ist einfach ext2+Journaling. Es ist daher geringfügig langsamer als ext2. Die großen Vorteile im Vergleich den anderen J-FS sind, dass es gegenüber ext2 nur ganz wenig neuen (und daher möglicherweise fehlerträchtigen) Code enthält und dass es kompatibel zu ext2 ist: Man kann ohne Datenverlust von ext2 zu ext3 konvertieren, außerdem kann man ext3-Dateisysteme z.B. mit älteren Kerneln einfach auch als ext2 mounten. * ReiserFS <http://www.namesys.com/>: Es ist das Journalling-FS, das schon am längsten im Linux-Kernel enthalten ist und daher auch über eine recht große Anwenderbasis verfügt. Weil es gänzlich anders als ext2 ist, gab es etliche Inkompabilitäten z.B. im Zusammenhang mit NFS. Quota-Support liegt nur als separater Kernelpatch vor. ReiserFS kann bei sehr vielen kleinen Dateien viel Platz sparen, da es nicht für jede einzelne Datei eine ganze Anzahl Blöcke belegt. * XFS/Linux <http://oss.sgi.com/projects/xfs/>: Port des bewährten Dateisystem XFS von IRIX auf Linux. XFS bietet alles was das Herz begehrt (inklusive Quota und ACL) und ist auf IRIX seit 1994 im Einsatz. Das Projekt liegt als externer Kernelpatch vor, der Linux Port ist noch recht jung, über seine Stabilität kann man daher noch keine definitiven Aussagen machen. * JFS <http://oss.software.ibm.com/developerworks/opensource/jfs/>: Port des Dateisystems JFS von OS/2 auf Linux. Auf Grund seines Entwicklungsstandes nur mäßig interessant. Lesetipps: * mount (8) * http://bulmalug.net/body.phtml?nIdNoticia=642 <http://bulma.net/body.phtml?nIdNoticia=642> * http://freshmeat.net/articles/view/212/ <http://freshmeat.net/articles/view/212/> * http://www.redhat.com/support/wpapers/redhat/ext3/why.html <http://www.redhat.com/support/wpapers/redhat/ext3/why.html> 4.21 Inzwischen ist Kernel 2.6 freigegeben worden, soll ich den neuen Kernel verwenden, was muss ich beachten? Ja, der neue Linux-Kernel ist da - aber langsam, es gibt einiges, was vor einem Update zu bedenken ist: * Was versprichst du Dir von dem neuen Kernel konkret? Warum möchtest du ihn einsetzen? * Bist du in der Lage herauszufinden, welche zusätzlichen Programme oder neuen Programmversionen zu diesem Kernel benötigt werden? Lies Kernelquelltext/Documentation/Changes! * Bist du in der Lage, die geforderten Programm(versionen) zu finden und zu installieren? * Bedenke, dass die von den Distributoren üblicherweise standardmäßig verwendeten Kernel gepatcht sind und damit bestimmte zusätzliche Funktionen haben, die du evtl. auch nutzt. Diese Funktionalitäten sind mit dem neuen Kernel evtl. nicht mehr vorhanden. Wenn du die ersten drei Fragen nicht wirklich sicher beantworten kannst, solltest du auf ein Update so lange verzichten, bis der Hersteller deiner Distribution eine für 2.6 angepasste Version bereitstellt. Abgesehen von neuen Programmversionen sind beim Upgrade auch noch Änderungen an der Modul- (Sound, CD/DVD, etc.) und Systemkonfiguration (sysfs, X11 ohne nice, Bootparameter, etc.) nötig. Das "post-halloween document" Änderungen im Linuxkernel 2.6 <http://www.kubieziel.de/computer/halloween-german.html> zählt die wichtigsten Änderungen auf. _________________________________________________________________ Build: 28.08.2004 User Contributions:
[ Usenet FAQs | Web FAQs | Documents | RFC Index ]
Send corrections/additions to the FAQ Maintainer: feedback01@dcoul.de
Last Update March 27 2014 @ 02:11 PM
|
Comment about this article, ask questions, or add new information about this topic: