|
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
|
de.comp.os.unix.linux.infos - FAQ (section4)
Search the FAQ Archives
N - O - P - Q - R - S - T - U - V - W - X - Y - Z
de.comp.os.unix.linux.infos - FAQ (section4)
[ Usenet FAQs | Web FAQs | Documents | RFC Index | Schools ]
Comment about this article, ask questions, or add new information about this topic: