/ : Das Wurzelverzeichnis

Wenn der Systemkern sich in / befindet, empfehlen wir für Linux die Namen vmlinux oder vmlinuz, die auch in aktuellen Quellpaketen von Linux benutzt werden.

/bin : Wesentliche Kommandos (für alle Benutzer)

Wenn Linux-Systeme sie benötigen, plazieren sie folgende zusätzliche Dateien in /bin:

• setserial

/dev : Gerätedateien

Die folgenden Geräte muss es unter /dev geben:

	Hintergrund
	Vorhergehende Versionen des FHS stellten strengere Anforderungen an /dev. Es dürfen jetzt weitere Geräte in /dev vorhanden sein. Gerätedateien dürfen auch symbolische Links auf andere Gerätedateien sein, die sich in /dev oder Unterverzeichnissen von /dev befinden. Es gibt keine Einschränkungen die Haupt- oder Nebengerätenummern betreffend.

/etc : Rechnerspezifische Systemeinstellungen

Wenn Linux-Systeme sie benötigen, plazieren sie folgende zusätzliche Dateien in /etc:

• lilo.conf

/lib64 und /lib32 : 64/32-Bit-Bibliotheken (architekturspezifisch)

Für die 64-Bit-Architekturene PPC64, s390x, sparc64 und AMD64 müssen die 64-Bit-Bibliotheken in /lib64 und die 32-Bit-Bibliotheken (bzw. die 31-Bit_bibliothken für s390) in /lib plaziert werden.

Für die 64-Bit-Architekture IA64 gehören die 64-Bit-Bibliotheken nach /lib.

Hintergrund

Dies ist eine Verfeinerung der generellen Regel für /lib<Suffix> und /usr/lib<Suffix>. Die Architekturen von PPC64, s390x, sparc64 und AMD64 unterstützen sowohl 32-Bit- (für s390 richtiger: 31-Bit-) als auch 64-Bit-Programme. Dadurch, dass /lib für 32-Bit-Programme benutzt wird, funktionieren auch die bereits vorhandenen 32-Bit-Programme - und das sind sicher viele - ohne Änderungen weiter. Beim IA64 wird das anders gehandhabt, weil dort 32-Bit-Programme (und -Bibliotheken) als veraltet gelten.

/proc : Virtuelles Dateisystem für Kern- und Prozessinformationen

Das proc-Dateisystem ist der De-fakto-Standard in Linux für die Handhabung von Prozess- und Systeminformationen, also nicht /dev/kmem oder andere ähnliche Methoden. Wir empfehlen wärmstens, diese Methode zum Speichern und für den Abruf von Prozess-, Kern- Hauptspeicherinformationen zu nutzen.

/sbin : Wesentliche Systemkommandos

Linux-Systeme plazieren folgende zusätzlichen Dateien in /sbin:

• e2fs-Kommandos ("Second Extended Filesystem"):

  • badblocks

  • dumpe2fs

  • e2fsck

  • mke2fs

  • mklost+found

  • tune2fs

• Einrichter ("map installer") des Systemladers (optional):

  • lilo

Optionale Dateien für /sbin:

• Statisch lauffähige Programme:

  • ldconfig

  • sln

  • ssync

  Das statische ln (sln) und das statische sync (ssync) sind nützlich, wenn mal etwas schiefgeht. Die zunächst wichtigeste Funktion von sln, nämlich fehlerhafte symbolische Links unterhalb von /lib zu reparieren (etwa nach einem schlecht organisierten Systemupdate), hat nicht mehr diese Bedeutung seitdem es das Programm ldconfig (üblicherweise in /usr/sbin) gibt, das uns beim Aktualisieren der dynamischen Bibliotheken bei der Hand nimmt. Das statische sync ist in mancher Notsituation nützlich. Man beachte, dass die genannten Kommandos statisch gebundene ("linked") Versionen der Standardkommandos ln und sync sein können, aber nicht müssen.

  ldconfig ist optionaler Bestandteil von /sbin, weil ein Betreiber sich dafür entscheiden kann, ldconfig beim Systemstart, anstatt nur beim Aktualisieren der Bibliotheken, einzusetzen. (Es ist noch nicht klar, ob es von Vorteil ist, ldconfig bei jedem Systemstart einzusetzen, oder nicht.) Jedenfalls möchten es viele für die folgenden (gar so üblichen) Situationen zur Hand haben:

  1. Gerade habe ich /lib/<Datei> gelöscht.

  2. Ich kann den Namen der Bibliothek nicht finden, weil ls dynamisch gebunden wurde, weil ich eine Shell benutze, die kein ls eingebaut hat und weil ich die Alternative "echo *" nicht kenne.

  3. Ich habe das statische sln-Kommando, aber ich weiß nicht, wie ich den Link nennen soll.

• Verschiedenes:

  • ctrlaltdel

  • kbdrate

  Um mit einigen Tastaturen zurechtzukommen, die wegen einer zu hohen Wiederholrate unbrauchbar sind, kann auf manchen Systemen kbdrate in /sbin zur Verfügung gestellt werden.

  Weil die Reaktion des Kerns auf die Tastenkombination Strg-Alt-Entf üblicherweise ein sofortiger Systemneustart ist, ist es ratsam, dieses Verhalten zu unterbinden, bevor das Wurzeldateisystem im Schreib-Lese-Modus eingebunden wird. Einige init-Verfahren sind dazu in der Lage, andere benötigen das Programm ctrlaltdel, das deshalb auf manchen Systemen unter /sbin zur Verfügung gestellt wird.

/usr/include : Header-Dateien für C-Programme

Folgende symbolischen Links werden benötigt, wenn ein C- oder ein C++-Compiler installiert ist - aber nur für Systeme, die nicht auf glibc basieren.

    /usr/include/asm -> /usr/src/linux/include/asm-<Architektur>
    /usr/include/linux -> /usr/src/linux/include/linux

/usr/src : Quellen

Für Systeme, die auf glibc basieren, gibt es keine weitergehenden Richtlinien zu diesem Verzeichnis. Für Systeme, die auf dem Vorläufer von glibc, der Linux-libc basieren, gelten folgende Regeln und folgender Hintergrund:

Der einzige Quellcode, der an einer bestimmten Stelle gespeichert werden soll, ist der des Linux-Systemkerns. Der wird abgelegt unter /usr/src/linux.

Wenn ein C- oder C++-Compiler installiert ist, aber nicht der komplette Quellcode des Linuxkerns, dann müssen die Include-Dateien des Kern-Quellcodes in folgenden Verzeichnissen sein:

    /usr/src/linux/include/asm-<Architektur>
    /usr/src/linux/include/linux

<Architektur> benennt dabei die Systemarchitektur.

/usr/src/linux darf ein symbolischer Link zum Verzeichnis der Kernquellen sein.

	Hintergrund
	Wichtig ist, dass die Include-Dateien für den Kern sich in /usr/src/linux und nicht in /usr/include befinden, sodass es keine Probleme gibt, wenn der Systemadministrator zum ersten Mal den Kern aktualisiert ("upgrade").

/var/spool/cron : cron- und at-Jobs

Dieses Verzeichnis enthält die variablen Daten für die Programme cron und at.