Vor dem 3.1-RELEASE benötigte man nur ein Floppy-Image, floppies/boot.flp, um FreeBSD zu installieren. Seit dem 3.1-RELEASE haben wir jedoch Unterstützung für eine Vielfalt von Hardware hinzugefügt, weshalb man nun für 3.x- und 4.x-RELEASE zwei Floppy-Images floppies/kernel.flp und floppies/mfsroot.flp benötigt. Diese Images müssen mit Hilfe von Werkzeugen wie fdimage oder dd(1) auf Disketten kopiert werden.

Falls Sie selbst die einzelnen Distributionen herunterladen müssen (um z.B. von einem DOS-Dateisystem aus zu installieren), empfehlen wir, sich die folgenden Distributionen zu besorgen:

• bin

• manpages

• compat*

• doc

• src/ssys.*

Vollständige Instruktionen für dieses Vorgehen und ein wenig mehr zur Installation generell finden Sie im Handbucheintrag zur Installation von FreeBSD.

Eine 3,5-Zoll (1,44MB) Diskette kann 1474560 Byte an Daten fassen und das Boot-Image ist exakt 1474560 Byte groß.

Häufige Fehler bei der Erstellung der Boot-Diskette sind:

• Bei der Benutzung von FTP das Floppy-Image nicht im Binär-Modus herunterzuladen.

  Einige FTP-Clients benutzen als Voreinstellung den ASCII-Modus und versuchen, alle Zeilenendezeichen an das Zielsystem anzupassen. Dadurch wird das Boot-Image in jedem Fall unbrauchbar. Überprüfen Sie die Größe des heruntergeladenen Boot-Images: falls sie nicht exakt mit der auf dem Server übereinstimmt, hat das Herunterladen nicht richtig funktioniert.

  Abhilfe: geben Sie binary an der FTP-Eingabeaufforderung ein, nach dem Sie mit dem Server verbunden sind und bevor Sie das Image herunterladen.

• Die Benutzung des DOS-Befehls copy (oder eines entsprechendes Werkzeugs der grafischen Benutzeroberfläche), um das Boot-Image auf die Diskette zu übertragen.

  Programme wie copy sind hier unbrauchbar, weil das Image zur direkten Übertragung erstellt wurde. Das Image stellt den gesamten Disketteninhalt dar, Spur für Spur, und nicht eine gewöhnliche Datei. Sie müssen es ``roh'' mit speziellen Werkzeugen (z.B. fdimage oder rawrite) übertragen, wie es in der Installationsanleitung zu FreeBSD beschrieben ist.

Installationsanleitungen finden Sie im Handbucheintrag zur Installation von FreeBSD.

Sie werden einen 386er oder besseren PC mit 5MB oder mehr Hauptspeicher und mindestens 60MB Festplattenspeicher benötigen. Es läuft mit einer einfachen MDA Grafikkarte, aber um X11R6 zu benutzen, benötigen Sie eine VGA- oder bessere Videokarte.

Lesen Sie auch den Abschnitt Kapitel 2

FreeBSD 2.1.7 war die letzte FreeBSD-Version, die auf einem 4MB-System installiert werden konnte. Neuere FreeBSD-Versionen, wie 2.2, benötigen mindestens 5MB zur Installation auf einem neuen System.

Alle FreeBSD-Versionen, einschließlich 3.0, laufen zwar mit 4MB Hauptspeicher, lediglich ihr Installationsprogramm läuft nicht mit 4MB. Wenn Sie möchten, können Sie für den Installationsvorgang zusätzlichen Hauptspeicher hinzufügen, und nachdem das System installiert ist, wieder auf 4MB zurückgehen. Sie können Ihre Festplatte auch jederzeit in ein System mit >4MB einbauen, dort installieren und sie dann wieder umbauen.

Es gibt auch Situationen, in denen FreeBSD 2.1.7 nicht mit 4 MB zu installieren ist. Um genau zu sein: man kann es nicht mit 640 kB Basis- + 3MB erweitertem Speicher installieren. Falls ihr Motherboard einiges vom ``verlorenen'' Speicher aus der 640kB - 1MB Region verschieben kann, könnten Sie trotzdem in der Lage sein, FreeBSD 2.1.7 zu installieren.

Versuchen Sie in Ihr BIOS-Setup zu gelangen und suchen Sie nach einer ``remap'' Option. Aktivieren Sie sie. Sie sollten das ROM shadowing ebenfalls ausschalten.

Es könnte einfacher sein, 4 weitere MB nur für die Installation zu benutzen, einen benutzerdefinierten Kernel nur mit den benötigten Optionen zu generieren und dann die 4 MB wieder auszubauen.

Sie können auch 2.0.5 installieren und anschließend Ihr System mit der ``upgrade'' Option des 2.1.7 Installationsprogramms nach 2.1.7 migrieren.

Wenn Sie nach der Installation einen benutzerdefinierten Kernel generieren, wird er mit 4 MB laufen. Irgend jemand hat es geschafft, mit 2 MB zu booten (allerdings war das System nahezu unbrauchbar :-))

Zur Zeit gibt es keine Möglichkeit, nur die angepaßten Installationsdisketten zu erstellen. Sie müssen sich eine ganz neues Release erstellen, das Ihre Installationsdiskette enthält.

Befolgen Sie diese Instruktionen, um sich eine angepaßte Ausgabe zu erstellen.

Sehen Sie sich Die Multi-OS-Seite an.

Installieren Sie zuerst Windows 95/98, dann FreeBSD. Der Bootmanager von FreeBSD kann dann entweder Win95/98 oder FreeBSD booten. Falls Sie Windows 95/98 nach FreeBSD installieren, wird es, ohne zu fragen, Ihren Bootmanager überschreiben. Lesen Sie den nächsten Abschnitt, falls das passieren sollte.

Es gibt drei Möglichkeiten, den FreeBSD-Bootmanager neu zu installieren:

• Unter DOS wechseln Sie in das Verzeichnis tools/ Ihrer FreeBSD-Distribution und suchen nach bootinst.exe. Rufen sie es so auf:

      ...\TOOLS> bootinst.exe boot.bin
                   
  

  und der Bootmanager wird neu installiert.

• Booten Sie FreeBSD wieder mit der Bootdiskette und wählen Sie den Menueeintrag Custom Installation. Wählen Sie Partition. Wählen Sie das Laufwerk, auf dem sich der Bootmanager befand (wahrscheinlich der erste Eintrag) und wenn Sie in den Partitioneditor gelangen, wählen Sie als aller erstes (nehmen Sie z.B. keine Änderungen vor) (W)rite. Sie werden nach einer Bestätigung gefragt, antworten ja und vergessen Sie nicht, in der Bootmanager-Auswahl ``Boot Manager'' auszuwählen. Hierdurch wird der Bootmanager wieder auf die Festplatte geschrieben. Verlassen Sie nun das Installationsmenue und rebooten wie gewöhnlich von der Festplatte.

• Booten Sie FreeBSD wieder mit der Bootdiskette (oder der CD-ROM) und wählen Sie den Menüpunkt ``Fixit''. Wählen Sie die für Sie passende Option, entweder die Fixit-Diskette oder die CD Nummer 2 (die Option ``live'' Filesystem). Wechseln Sie zur Fixit-Shell und geben Sie den folgenden Befehl ein:

      Fixit# fdisk -B -b /boot/boot0 bootdevice
                   
  

  Als bootdevice müssen Sie das von Ihrem System verwendete Gerät angeben, z.B. ad0 (erste IDE-Platte), ad4 (erste IDE-Platte an einem zusätzlichen Controller), da0 (erste SCSI-Platte), usw.

Ein Fehler in den ersten BIOS-Versionen dieser Geräte führt dazu, daß sie die von FreeBSD genutzte Partition für eine Suspend-To-Disk-Partition halten. Wenn das BIOS dann versucht, diese Partition auszuwerten, hängt sich das System auf.

Laut IBM [1] wurde der Fehler wurde in den folgenden BIOS-Versionen behoben:

Es ist möglich, daß neuere Version des IBM BIOS den Fehler wieder enthalten. Dieser Beitrag von Jacques Vidrine auf der Mailingliste <mobile@freebsd.org> beschreibt eine Technik, die Ihnen weiterhelfen könnte, wenn Ihr IBM Laptop mit FreeBSD nicht bootet und Sie eine neuere oder ältere BIOS-Version einspielen können.

Wenn Ihr Thinkpad über eine ältere BIOS-Version verfügt und Sie das BIOS nicht aktualisieren können, ist eine der möglichen Lösungen, FreeBSD zu installieren, die Partitions-ID zu ändern und danach neue Bootblocks zu installieren, die mit der geänderten ID umgehen können.

Zunächst müssen Sie die Maschine so weit wiederherstellen, daß sie über den Selbst-Test hinauskommt. Dazu ist es erforderlich, daß das System beim Start keine Partitions-ID auf seiner primären Festplatte findet. Eine Variante ist, die Platte auszubauen und vorübergehend in einem älteren Thinkpad (z.B. dem Thinkpad 600) oder (mit einem passenden Adapter) in einen normalen PC einzubauen. Sobald dies erfolgt ist, können Sie die FreeBSD-Partition löschen und die Festplatte wieder in das Thinkpad einbauen. Das Thinkpad sollte jetzt wieder starten können.

Danach können Sie mit der nachfolgend beschriebenen Anleitung eine funktionsfähige FreeBSD-Installation erhalten.

Was Sie machen müssen, wenn Sie FreeBSD und OpenBSD parallel installieren wollen, sollten Sie zu Übungszwecken einfach einmal selbst herausfinden.

Ältere Versionen von FreeBSD enthielten ein Programm namens bad144, das die defekten Sektoren automatisch verlagerte. Da diese Funktion aber von modernen IDE-Platten selbstständig durchgeführt wird, wurde bad144 in der Version 3.0 aus dem System entfernt. Wenn Sie FreeBSD 3.0 oder neuer installieren wollen, sollten Sie sich eine neue Festplatte zulegen. Falls Sie dazu nicht bereit sind, müssen Sie FreeBSD 2.X verwenden.

Wenn Ihnen bei einer modernen IDE-Platte defekte Sektoren gemeldet werden, wird die Platte mit großer Wahrscheinlichkeit innerhalb kurzer Zeit vollständig ausfallen, da die Meldung ein Zeichen dafür ist, daß die für die Korrektur reservierten Sektoren bereits verbraucht wurden. Wir raten Ihnen, die Platte auszutauschen.

Falls Sie ein SCSI-Laufwerk mit beschädigten Blöcken besitzen, lesen Sie diese Antwort.

Falls Sie beobachten, daß ihr Rechner sich bis zum Stillstand abmüht oder spontan rebootet, während Sie versuchen, von der Installationsdiskette zu booten, sollten Sie sich drei Fragen stellen:

1. Haben Sie eine brandneue, frisch formatierte, fehlerfreie Diskette benutzt (günstigerweise eine brandneue, direkt aus dem Karton und nicht eine Diskette aus einem Magazin, das schon seit drei Jahren unter Ihrem Bett lag)?

2. Haben Sie das Floppy-Image im Binär- (oder Image) Modus heruntergeladen? (Schämen Sie sich nicht. Sogar die besten unter uns haben wenigstens einmal Binärdateien versehentlich im ASCII-Modus heruntergeladen!)

3. Falls Sie Windows 95 oder Windows 98 benutzen, haben Sie es heruntergefahren und fdimage bzw. rawrite in einfachem, reinem DOS neu gestartet? Es scheint, daß diese Betriebssysteme Programme stören, die direkt auf Hardware schreiben, wie es das Erstellungsprogramm für die Diskette tut; selbst bei der Ausführung des Programms in einem DOS-Fenster in der grafischen Benutzeroberfläche kann dieses Problem auftreten.

Es wurde auch darüber berichtet, daß Netscape Probleme beim Herunterladen der Bootdisketten verursacht. Es ist also wahrscheinlich besser, einen anderen FTP-Client zu benutzen, wenn möglich.

Dieses Problem wird üblicherweise durch ein falsch konfiguriertes CD-ROM verursacht. Bei vielen PCs ist das CD-ROM der Slave am zweiten IDE-Controller, ein Master ist nicht vorhanden. Laut Spezifikation ist diese Konfiguration illegal, aber Windows verletzt die Spezifikation und das BIOS ignoriert sie, wenn es von einem CD-ROM booten soll. Daher konnten Sie zwar vom CD-ROM booten, während FreeBSD es nicht für die Installation nutzen kann.

Um dieses Problem zu lösen, müssen Sie entweder das CD-ROM als Master an den IDE-Controller anschließen oder dafür sorgen, daß an dem vom CD-ROM genutzten IDE-Controller das CD-ROM als Slave und ein anderes Gerät als Master angeschlossen ist.

Falls Sie 2.1.7R von Band installieren, müssen Sie bei der Erstellung des Bandes eine tar-Blockgröße von 10 (5120 Byte) verwenden. Die standard tar-Blockgröße beträgt 20 (10240 Byte) und Bänder, die mit diesem Standardwert erstellt worden sind, können nicht zur Installation von 2.1.7R verwendet werden. Diese Bänder verursachen einen Fehler, der besagt, daß die Satzlänge zu groß ist.

Besorgen Sie sich ein Laplink-Kabel. Stellen Sie sicher, daß Sie einen Kernel mit lpt-Treiberunterstützung haben.

    # dmesg | grep lp
    lpt0 at 0x378-0x37f irq 7 on isa
    lpt0: Interrupt-driven
    lp0: TCP/IP capable interface
             

Schließen Sie das Kabel an die parallelen Schnittstellen an.

Konfigurieren Sie die Netzwerkschnittstellenparameter für lp0 auf beiden Seiten als root. Falls Sie z.B. die Rechner max und moritz miteinander verbinden wollen

                     max <-----> moritz
    IP-Adresse    10.0.0.1      10.0.0.2
             

Auf max geben Sie ein

    # ifconfig lp0 10.0.0.1 10.0.0.2
             

Auf moritz geben Sie ein

    # ifconfig lp0 10.0.0.2 10.0.0.1
             

Das ist alles! Lesen Sie bitte auch die Manuals lp(4) und lpt(4).

Sie sollten die Rechner auch in die Datei /etc/hosts eintragen

         127.0.0.1               localhost.my.domain localhost
         10.0.0.1                max.my.domain max
         10.0.0.2                moritz.my.domain moritz
             

So überprüfen, Sie, ob es funktioniert:

auf max:

    # ifconfig lp0
    lp0: flags=8851<UP,POINTOPOINT,RUNNING,SIMPLEX,MULTICAST> mtu 1500
            inet 10.0.0.1 --> 10.0.0.2 netmask 0xff000000
    # netstat -r
    Routing tables
    
    Internet:
    Destination        Gateway            Flags     Refs     Use     Netif Expire
    moritz              max              UH          4   127592       lp0
    # ping -c 4 moritz
    PING moritz (10.0.0.2): 56 data bytes
    64 bytes from 10.0.0.2: icmp_seq=0 ttl=255 time=2.774 ms
    64 bytes from 10.0.0.2: icmp_seq=1 ttl=255 time=2.530 ms
    64 bytes from 10.0.0.2: icmp_seq=2 ttl=255 time=2.556 ms
    64 bytes from 10.0.0.2: icmp_seq=3 ttl=255 time=2.714 ms
    
    --- moritz ping statistics ---
    4 packets transmitted, 4 packets received, 0% packet loss
    round-trip min/avg/max/stddev = 2.530/2.643/2.774/0.103 ms
             

Verbinden Sie die beiden Computer hierzu mit einem Laplink-Kabel:

Lesen Sie auch diesen Hinweis auf der Mobile-Computing-Seite.

Anmerkung: Unter der ``Geometrie'' einer Festplatte verstehen wir die Anzahl Zylinder, Schreib-/Leseköpfen und Sektoren/Spur auf einer Festplatte - im folgenden werde ich hierfür kurz C/H/S schreiben. Das BIOS des PCs berechnet mit diesen Angaben, auf welche Bereiche der Festplatte es für Schreib-/Lesezugriffe zugreifen muß).

Aus einigen Gründen scheint dies für sehr viel Verwirrung zu sorgen. Zunächsteinmal ist die physikalische Geometrie eines SCSI-Laufwerks vollkommen irrelevant, da FreeBSD mit Blöcken arbeitet. Tatsächlich gibt es ``die'' physikalische Geometrie nicht, da die Sektordichte auf einer Festplatte variiert - was die Hersteller als die ``wahre'' physikalische Geometrie bezeichnen, ist im allgemeinen die Geometrie, die aufgrund ihrer Ergebnisse im geringsten ungenutzten Speicher resultiert. Bei IDE-Platten arbeitet FreeBSD mit C/H/S-Angaben, aber alle modernen Laufwerke wandeln diese intern ebenfalls in Blocknummern um.

Wichtig ist nur die logische Geometrie. Das BIOS kann die logische Geometrie der Festplatte abfragen; die erhaltenen Daten werden dann vom BIOS bei Zugriffen auf die Festplatte genutzt. Da FreeBSD das BIOS benutzt, während es bootet, ist es sehr wichtig, daß diese Angaben richtig sind. Insbesondere müssen alle Betriebssysteme mit derselben Geometrie arbeiten, falls Sie mehr als ein Betriebssystem auf einer Festplatte haben, andernfalls werden Sie ernsthafte Bootprobleme bekommen!

Bei SCSI-Festplatten hängt die zu verwendende Geometrie davon ab, ob der Extended Translation Support auf Ihrem Controller eingeschaltet ist (oft auch als ``Unterstützung für DOS-Platten >1GB'' oder ähnlich bezeichnet). Falls sie ausgeschaltet ist, benutzen Sie N Zylinder, 64 Köpfe und 32 Sektoren/Spur, wobei N die Kapazität der Festplatte in MB ist. Zum Beispiel sollten für eine 2GB Festplatte 2048 Zylinder, 64 Köpfe und 32 Sektoren/Spur angegeben werden.

Falls sie eingeschaltet ist (was oft der Fall ist, um bestimmte Einschränkungen von MSDOS zu umgehen) und die Plattenkapazität mehr als 1GB beträgt, benutzen Sie M Zylinder, 63 Sektoren/Spur (*nicht* 64) und 255 Köpfe, wobei 'M' der Plattenkapazität in MB, dividiert durch 7,844238 entspricht (!). Also würde unsere 2GB Beispielplatte 261 Zylinder, 63 Sektoren/Spur und 255 Köpfe haben.

Falls Sie sich hier nicht sicher sind oder FreeBSD während der Installation die Geometrie nicht richtig erkennt, hilft es normalerweise, eine kleine DOS-Partition auf der Festplatte anzulegen. Die richtige Geometrie sollte dann erkannt werden (Sie können die Partition jederzeit im Partitioneditor entfernen, falls Sie sie nicht behalten möchten, oder Sie nutzen sie zur Programmierung von Netzwerkkarten oder ähnlichem).

Alternativ wird ein frei verfügbares Programm pfdisk.exe (im Unterverzeichnis tools auf der FreeBSD-CDROM oder den unterschiedlichen FTP-Servern) mit FreeBSD verbreitet, das dazu genutzt werden kann, herauszufinden, welche Geometrie die anderen Betriebssysteme auf der Festplatte verwenden. Diese Geometrie können Sie im Partitioneditor eingeben.

Ja. Sie müssen sicherstellen, daß Ihre Rootpartition innerhalb der ersten 1024 Zylinder liegt, damit das BIOS den Kernel von Ihr booten kann. (Beachten Sie, daß es sich um eine Einschränkung durch das BIOS des PCs handelt und nicht durch FreeBSD).

Für ein SCSI-Laufwerk bedeutet dies normalerweise, daß sich die Rootpartition in den ersten 1024MB befindet (oder in den ersten 4096MB, falls die Extended Translation eingeschaltet ist - siehe die vorherige Frage). Der entsprechende Wert für IDE ist 504MB.

FreeBSD erkennt den Ontrack Plattenmanager und berücksichtigt ihn. Andere Plattenmanager werden nicht unterstützt.

Falls Sie die Festplatte nur mit FreeBSD benutzen wollen, brauchen Sie keinen Plattenmanager. Wenn Sie Sie die Platte einfach in der vom BIOS maximal unterstützten Größe (normalerweise 504 Megabyte) konfigurieren, sollte FreeBSD erkennen, wieviel Platz Sie tatsächlich haben. Falls Sie eine alte Festplatte mit einem MFM-Controller verwenden, könnte es sein, daß Sie FreeBSD explizit angeben müssen, wieviele Zylinder es benutzen soll.

Falls Sie die Festplatte mit FreeBSD und einem anderen Betriebssystem nutzen wollen, sollten Sie auch in der Lage sein, ohne einen Plattenmanager auszukommen: stellen sie einfach sicher, daß sich die Bootpartition von FreeBSD und der Bereich für das andere Betriebssystem in den ersten 1024 Zylindern befinden. Eine 20 Megabyte Bootpartition sollte völlig genügen, wenn Sie einigermaßen sorgfältig arbeiten.

Dies ist ein klassischer Fall von Konflikten bei den verwendeten Plattengeometrien von FreeBSD und DOS oder anderen Betriebssystemen. Sie werden FreeBSD neu installieren müssen. Bei Beachtung obiger Instruktionen wird in den meisten Fällen alles funktionieren.

Dies ist ein weiteres Symptom für das bereits in der vorherigen Frage beschriebene Problem. Ihre Einstellungen zur Geometrie im BIOS und in FreeBSD stimmen nicht überein! Falls Ihr Controller oder BIOS Zylinderumsetzung (oft als ``>1GB drive support'' bezeichnet), probieren Sie eine Umsetzung dieser Einstellung und Neuinstallation von FreeBSD.

Im allgemeinen nicht. Wir empfehlen jedoch dringend die Installation des base Source-Kit, das viele der hier erwähnten Dateien enthält und des sys (Kernel) Source-Kit, das den Quellcode für den Kernel enthält. Außer dem Programm zur Konfiguration des Kernels (config(8)) gibt es im System nichts, zu dessen Funktion der Quellcode erforderlich ist. Mit Ausnahme der Kernelquellen ist unsere Build-Struktur so aufgebaut, daß Sie den Quellcode von überall her per NFS read-only mounten und dennoch neue Binaries erstellen können. (Wegen der Einschränkung bezüglich der Kernelquellen empfehlen wir, diese nicht direkt nach /usr/src zu mounten, sondern irgendwoanders hin mit passenden symbolischen Links, um die Toplevel-Struktur des Quellbaumes zu duplizieren.)

Die Quellen verfügbar zu haben und zu wissen, wie man ein System mit ihnen erstellt, wird es Ihnen wesentlich einfacher machen, zu zukünftigen Ausgaben von FreeBSD zu wechseln.

Um einen Teil der Quellen auszuwählen, verwenden Sie den Menuepunkt Custom, wenn Sie sich im Menue Distributions des Systeminstallationstools befinden.

Ursprünglich war die Erstellung eines neuen Kernels bei fast jeder Installation von FreeBSD erforderlich, aber neuere Ausgaben haben von der Einführung eines weitaus benutzerfreundlicheren Kernelkonfigurationswerkzeugs profitiert. Geben Sie am FreeBSD Boot-Prompt (boot:) -c ein, um in ein visuelles Konfigurationsmenue zu gelangen. Dieses Programm ermöglicht Ihnen die Konfiguration der Kerneleinstellungen für die gebräuchlichsten ISA-Karten.

Es wird weiterhin empfohlen, früher oder später einen neuen Kernel zu erstellen, der nur die benötigten Treiber enthält, um ein wenig Hauptspeicher zu sparen, aber für die meisten Systeme ist dies ist nicht länger erforderlich.

FreeBSD benutzt standardmäßig MD5 zur Verschlüsselung der Paßwörter. Es wird angenommen, daß diese Methode sicherer ist als das traditionell benutzte Verfahren, das auf dem DES Algorithmus basierte. Es ist immer noch möglich, DES-Paßwörter zu benutzen, wenn Sie die Datei mit den Paßwörtern mit älteren System austauschen müssen. Ältere System verstehen meist nur das unsichere Verfahren, dieses steht Ihnen zur Verfügung, wenn Sie mit sysinstall die ``crypto'' Distribution installieren. Sie können auch die crypto Sourcecodes installieren, wenn Sie Ihr System über die Sourcen aktualisieren. Das für neue Paßwörter benutzte Verschlüsselungsverfahren wird über die Einstellung ``passwd_format'' in /etc/login festgelegt. Die möglichen Werte sind entweder ``des'' (falls installiert) oder ``md5''. Weitere Informationen über die Einstellungen für den Login erhalten Sie in login.conf(5).

Falls Sie ein IDE-Zip- oder Jaz-Laufwerk eingebaut haben, entfernen Sie es und versuchen Sie es erneut. Solche Laufwerke könnten dem Bootvorgang stören. Nach der Installation des Systems können Sie das Laufwerk wieder einbauen. Dieser Fehler wird hoffentlich in einer späteren Version behoben werden.

Dieser Fehler beruht auf Unstimmigkeiten zwischen den Festplatteninformationen im Bootblock und denen im Kernel. Der Fehler tritt normalerweise auf IDE-Systemen mit zwei Festplatten auf, bei denen die Festplatten als Master- oder Single-Device auf separaten IDE-Controllern angeschlossen sind und FreeBSD auf der Platte am zweiten Controller installiert wurde. Der Bootblock vermutet, daß das System auf wd1 (der zweiten BIOS-Platte) installiert ist, während der Kernel der ersten Platte auf dem zweiten Controller die Gerätekennung wd2 zuteilt. Der Kernel versucht nach der Geräteüberprüfung die vom Bootblock angenommene Bootdisk wd1 zu mounten, obwohl sie in Wirklichkeit wd2 heißt - und scheitert.

Tun Sie folgendes, um dieses Problem zu beheben:

1. Wenn Sie FreeBSD 3.3 oder neuer benutzen, müssen Sie das System rebooten und Enter drücken, wenn die Meldung Booting kernel in 10 seconds; hit [Enter] to interrupt erscheint. Dadurch gelangen Sie in den Boot Loader.

   Geben Sie nun root_disk_unit="disk_number" ein. disk_number hat den Wert 0, wenn FreeBSD auf dem Master des ersten IDE-Controllers installiert wurde; 1, wenn FreeBSD auf dem Slave des ersten IDE-Controllers installiert wurde; 2, wenn FreeBSD auf dem Master des zweiten IDE-Controllers installiert wurde; und 3, wenn FreeBSD auf dem Slave des zweiten IDE-Controllers installiert wurde.

   Nach der Eingabe von boot sollte Ihr System jetzt korrekt starten.

   Damit Sie dieses Ritual nicht bei jedem Start des Systems durchführen müssen, sollten Sie die Zeile root_disk_unit="disk_number" in die Datei /boot/loader.conf.local eintragen.

2. Wenn Sie FreeBSD 3.2 oder eine ältere Version benutzen, geben Sie am Prompt Boot: 1:wd(2,a)kernel ein und betätigen Sie die Enter-Taste. Wenn das System nun startet, führen Sie den Befehl echo "1:wd(2,a)kernel" > /boot.config aus, um diese Bootzeichenfolge zur Voreinstellung zu machen.

3. Stellen Sie eine ununterbrochene Folge der Festplatten her, indem Sie die FreeBSD-Platte am ersten IDE-Controller anschließen.

4. Erstellen Sie einen neuen Kernel: modifizieren Sie die wd-Konfigurationszeilen wie folgt:

       controller      wdc0    at isa? port "IO_WD1" bio irq 14 vector wdintr
       disk            wd0     at wdc0 drive 0
       # disk          wd1     at wdc0 drive 1 # Kommentieren Sie diese Zeile aus
       
       controller      wdc1    at isa? port "IO_WD2" bio irq 15 vector wdintr
       disk            wd1     at wdc1 drive 0 # Ändern Sie wd2 in wd1
       disk            wd2     at wdc1 drive 1 # Ändern Sie wd3 in wd2
                    
   

   Installieren Sie den neuen Kernel. Falls sie Ihre Festplattenanschlüsse umgesteckt haben und die alte Konfiguration wiederherstellen möchten, stecken Sie die Anschlüsse wie gewünscht um und rebooten Sie. Ihr System sollte nun fehlerfrei booten.

Es werden maximal 4 Gigabyte Hauptspeicher unterstützt. Details zu einer entsprechenden, getesteten Konfiguration finden Sie unter Konfiguration von WCArchive. Seien Sie vorsichtig, wenn Sie soviel Hauptspeicher in Ihrem Rechner benutzen möchten. Benutzen Sie ggfs. ECC-Speicher und Module mit neun (statt der üblichen 18) Chips, um die kapazitive Belastung zu reduzieren.

Theoretisch liegt das Limit für ffs-Dateisysteme bei 8 Terabyte (2G-Blöcke) oder 16TB für die Standard-Blockgröße von 8k. In der Praxis setzt die Software das Limit auf 1 Terabyte herab, aber durch Modifikationen sind auch Dateisysteme mit 4 Terabyte möglich (und existieren auch).

Die maximale Größe einer einzelnen ffs-Datei liegt bei ungefähr 1G Blöcken (4TB, falls die Blockgröße 4k beträgt).

Wenn die im Dateisystem verwendete Blockgröße 4k beträgt, wird mit dreifacher Indirektion gearbeitet und die Limitierung sollte durch die höchste Blocknummer erfolgen, die mit dreifacher Indirektion dargestellt werden kann (ungefähr 1k^3 + 1k^2 + 1k). In Wirklichkeit liegt das Limit aber bei der (falschen) Anzahl von 1G-1 Blocknummern im Dateisystem. Die maximale Anzahl Blocknummern müßte 2G-1 sein. Es gibt einige Fehler für Blocknummern nahe 2G-1, aber solche Blocknummern sind bei einer Blockgröße von 4k unerreichbar.

Bei Blocknummern von 8k und größer sollte das Limit bei 2G-1 Blocknummern liegen, aber tatsächlich liegt es bei bei 1G-1 Blocknummern. Außer unter -STABLE sind Blöcke in der dritten Indirektion unerreichbar, wodurch das Limit auf die durch zweifache Indirektion maximal darstellbare Blocknummer reduziert wird (ca. (Blockgröße/4)^2 + (Blockgröße/4)). Unter -CURRENT könnte die Überschreitung dieser Grenze Probleme verursachen. Die Verwendung der korrekten Grenze von 2G-1 verursacht Probleme.

Ich habe mehrere virtuelle auf Disketten :-). Die maximale Dateigröße hat nicht unbedingt etwas mit der maximalen Plattengröße zu tun. Die maximale Plattengröße beträgt 1TB. Es ist ein Feature, daß die Dateigröße die Plattengröße übersteigen kann.

Durch das folgende Beispiel wird eine Datei der Größe 8T-1 erstellt, die insgesamt 32k Plattenplatz (3 indirekte Blöcke und ein Datenblock) auf einer kleinen Rootpartition in Anspruch nimmt. Dieser dd-Befehl setzt ein dd-Programm voraus, das große Dateien unterstützt.

    % cat foo
    df .
    dd if=/dev/zero of=z bs=1 seek=`echo 2^43 - 2 | bc` count=1
    ls -l z
    du z
    df .
    % sh foo
    Filesystem  1024-blocks     Used    Avail Capacity  Mounted on
    /dev/da0a         64479    27702    31619    47%    /
    1+0 records in
    1+0 records out
    1 bytes transferred in 0.000187 secs (5346 bytes/sec)
    -rw-r--r--  1 bde  bin  8796093022207 Sep  7 16:04 z
    32  z
    Filesystem  1024-blocks     Used    Avail Capacity  Mounted on
    /dev/da0a         64479    27734    31587    47%    /
             

Bruce Evans, September 1998

Sie können den zu bootenden Kernel direkt im zweiten Schritt angeben, indem Sie eine beliebige Taste drücken, wenn das | erscheint und bevor der Loader startet. Genauer: Sie haben die Kernelquellen erneuert, und von dort ein neues Kernel-Builtin installiert, ohne make world auszuführen. Das geht nicht - führen Sie make world aus.

Wir raten Ihnen dringend, dazu einen der Snapshots zu verwenden. Die Snapshots von 4-STABLE sind auf releng4.FreeBSD.org verfügbar.

Wenn Sie den Quellcode für das Update benutzen wollen, finden Sie im FreeBSD Handbuch weitere Informationen.

In einem ``Sicherheits-Profil'' werden verschiedene Einstellungen zusammengefaßt, mit denen das gewüschte Verhältnis zwischen Sicherheit und Benutzerfreundlichkeit hergestellt werden soll. Um dies zu erreichen, werden bestimmte Dienste und Features entweder aktiviert oder deaktiviert. Nutzt man ein strengeres Sicherheits-Profil, werden weniger Dienste automatisch gestartet. Dies ist eines der Grundprinzipien der Sicherheit: Benutze nichts, was nicht unbedingt benutzt werden muß.

Bitte beachten Sie, daß die Sicherheits-Profile nur Voreinstellungen sind. Sie können nach der Installation von FreeBSD alle Dienste einzeln aktivieren oder deaktivieren, indem Sie die die entsprechenden Optionen in /etc/rc.conf hinzufügen bzw. ändern. Weitere Informationen erhalten Sie in der Onlinehilfe rc.conf(5).

In der Tabelle sind die Auswirkungen der Sicherheits-Profile zusammengefaßt. Jedes Sicherheits-Profil belegt eine Zeile, die beinflußten Dienste bzw. Optionen stehen in den Spalten.

FreeBSD unterstützt EIDE- und SCSI-Laufwerke (mit kompatiblen Controllern - siehe folgenden Abschnitt), sowie alle Laufwerke, die die original ``Western Digital''-Schnittstelle (MFM, RLL, ESDI und natürlich IDE) benutzen. Ein paar Controller mit proprietären Schnittstellen könnten nicht laufen: halten Sie sich an WD1002/3/6/7-Schnittstellen und Clones.

Sie finden eine vollständige Liste im Handbuch.

Jedes an einem unterstützten Controller angeschlossene SCSI-Laufwerk wird unterstützt.

Die folgenden proprietären CD-ROM-Schnittstellen werden ebenfalls unterstützt:

• Mitsumi LU002 (8bit), LU005 (16bit) und FX001D (16bit 2x Speed).

• Sony CDU 31/33A

• Sound Blaster Non-SCSI CD-ROM

• Matsushita/Panasonic CD-ROM

• ATAPI compatible IDE CD-ROMs

Von allen Nicht-SCSI-Laufwerken ist bekannt, daß sie im Vergleich zu SCSI-Laufwerken extrem langsam sind. Einige ATAPI-CDROMs könnten nicht funktionieren.

Ab 2.2 unterstützt die FreeBSD-CDROM von BSDi das direkte Booten von CD.

FreeBSD unterstützt alle ATAPI-kombatiblen IDE CD-R und CD-RW Brenner. Wenn Sie FreeBSD ab Version 4.0 benutzen, werfen Sie einen Blick in die Onlinehilfe zu burncd(8). Wenn Sie eine ältere Version von FreeBSD benutzen, sollten Sie sich die Beispiele in /usr/share/examples/atapi ansehen.

FreeBSD unterstützt ebenfalls SCSI CD-R und CD-RW Brenner. Installieren und benutzen Sie das Paket cdrecord aus der Ports-Sammlung. Dazu müssen Sie allerdings das Gerät pass mit in Ihren Kernel aufnehmen.

FreeBSD unterstützt natürlich alle gängigen SCSI-ZIP-Laufwerke. Ihr ZIP-Laufwerk darf nur mit den SCSI-Ziel-IDs 5 oder 6 laufen, aber Sie können sogar davon booten, falls das BIOS Ihres Hostadapters dies unterstützt. Es ist nicht bekannt, welche Hostadapter das Booten von anderen Zielen als 0 oder 1 erlauben; daher werden Sie in ihren Handbüchern nachsehen müssen, wenn Sie dieses Merkmal benutzen möchten.

ATAPI (IDE) Zip-Laufwerke werden von FreeBSD 2.2.6 und späteren Versionen unterstützt.

Seit Version 3.0 unterstützt FreeBSD ZIP-Laufwerke, die an der parallel Schnittstelle angeschlossen sind. Falls Sie eine genügend aktuelle Version benutzen, sollten Sie überprüfen, ob Ihr Kernel die folgenden Treiber enthält: scbus0, da0, ppbus0 und vp0 (der GENERIC-Kernel enthält alle, außer vp0). Wenn diese Treiber vorhanden sind, sollte das Laufwerk an der parallelen Schnittstelle als /dev/da0s4 verfügbar sein. Zip-Datenträger können mit mount /dev/da0s4 /mnt ODER (DOS-formatierte) mount_msdos /dev/da0s4 /mnt gemountet werden.

Lesen Sie auch diese Anmerkung zu Wechseldatenträgern und diese zur ``Formatierung''.

Abgesehen von der IDE-Version der EZ-Laufwerke, handelt es sich ausschließlich um SCSI-Geräte. Unter FreeBSD müßten sie sich also alle wie SCSI-Platten und das IDE-EZ-Laufwerk müßte sich wie ein IDE-Laufwerk verhalten.

Ich bin mir nicht sicher, wie gut FreeBSD den Wechsel der Datenträger während des Betriebs unterstützt. Sie werden die Laufwerke vor einem Datenträgerwechsel natürlich unmounten und sicherstellen müssen, daß externe Einheiten während des Bootens eingeschaltet sind, damit FreeBSD sie erkennen kann.

Lesen Sie auch diesen Hinweis zur ``Formatierung''.

Es existiert eine Liste der unterstützten Karten im Abschnitt Verschiedene Geräte des Handbuchs.

Von einigen nicht NoName-Nachbauten ist ebenfalls bekannt, daß sie funktionieren, speziell von den AST-kompatiblen.

In sio(4) finden Sie weitere Informationen zur Konfiguration solcher Karten.

Die Unterstützung für USB-Geräte ist seit FreeBSD 3.1 Bestandteil des Systems. Die Unterstützung war allerdings nicht ganz ausgereift; einige der Probleme konnten bis zur Veröffentlichung von FreeBSD 3.2 nicht behoben werden. Wenn Sie die Treiber für USB-Tastaturen selbst testen möchten, sollten Sie den unten aufgeführten Anweisungen folgen:

Nach einem Neustart des Systems ist die AT-Tastatur als /dev/kbd0 und die USB-Tastatur als /dev/kbd1 verfügbar. Dies gilt natürlich nur, wenn beide Tastaturen angeschlossen sind; falls nur die USB-Tastatur angeschlossen ist, ist diese als /dev/ukbd0 verfügbar.

Wenn Sie die USB-Tastatur an der Systemkonsole benutzen wollen, müssen Sie dies dem System explizit mitteilen. Dazu muß das folgende Kommando während des Systemstarts ausgeführt werden:

    # kbdcontrol -k /dev/kbd1 < /dev/ttyv0 > /dev/null
             

Wenn Sie nur die USB-Tastatur angeschlossen haben, ist diese als /dev/kbd0 verfügbar; daher muß in diesem Fall das folgende Kommando benutzt werden:

    # kbdcontrol -k /dev/kbd0 < /dev/ttyv0 > /dev/null
             

Tragen Sie dieses Kommando in Datei /etc/rc.i386 ein.

Sobald Sie diese Schritte durchgeführt haben, sollte die USB-Tastatur ohne weitere Änderungen auch unter X benutzbar sei.

Zur Zeit kann es noch Probleme geben, wenn Sie eine USB-Tastatur im laufenden Betrieb einstecken oder abziehen. Um Probleme zu vermeiden, sollten Sie die Tastatur anschließen, bevor Sie das System anschalten und die Tastatur nicht abziehen, solange das System noch läuft.

Weitere Informationen erhalten Sie in ukbd(4).

FreeBSD unterstützt die Busmaus und InPort-Busmaus von Herstellern wie Microsoft, Logitech und ATI. Der Bus-Gerätetreiber ist bei FreeBSD 2.x standardmäßig im GENERIC-Kernel eingebunden; ab Version 3.0 müssen Sie ihn selbst in die Konfigurationsdatei für Ihren angepaßten Kernel einbinden. Fügen Sie die folgende Zeile in Ihre Konfigurationsdatei ein, falls Sie sich einen angepaßten Kernel mit dem Busmaustreiber erstellen

FreeBSD 3.0 und ältere Versionen

    device mse0 at isa? port 0x23c tty irq5 vector mseintr
             

FreeBSD 3.X außer 3.0

    device mse0 at isa? port 0x23c tty irq5
             

FreeBSD 4.X

    device mse0 at isa? port 0x23c irq5
             

Die Busmaus wird üblicherweise zusammen mit einer speziellen Karte ausgeliefert. Sie könnte es Ihnen ermöglichen, andere Werte für die Port-Adresse und den Interrupt zu setzen. Weitere Informationen finden Sie in Handbuch zu Ihrer Maus und in der mse(4) Manualpage.

Falls Sie eine spätere FreeBSD-Version als 2.2.5 benutzen, ist der entsprechende Treiber psm im Kernel enthalten und aktiviert. Der Kernel sollte Ihre PS/2-Maus beim Booten erkennen.

Wenn Sie eine gerigfügig frühere Version von FreeBSD benutzen (2.1.x oder höher), können Sie den Treiber während der Installation einfach im Kernelkonfigurationsmenue aktivieren, oder später mit der Option -c am Bootprompt boot:. Da der Treiber standardmäßig deaktiviert ist, werden Sie ihn also explizit aktivieren müssen.

Falls Sie eine ältere FreeBSD-Version benutzen, müssen Sie folgende Zeile in Ihre Kernelkonfigurationsdatei einfügen und den Kernel neu kompilieren.

FreeBSD 3.0 und ältere Versionen

    device psm0 at isa? port "IO_KBD" conflicts tty irq 12 vector psmintr
             

FreeBSD 3.1 und neuere Versionen:

    device psm0 at isa? tty irq 12
             

Ab FreeBSD 4.0:

    device psm0 at atkbdc? irq 12
             

Lesen Sie den Handbucheintrag zur Kernelkonfiguration, falls Sie sich mit der Erstellung eines Kernels nicht auskennen.

Wenn Sie den Kernel soweit haben, daß er psm0 beim Booten korrekt erkennt, stellen Sie sicher, daß sich im Verzeichnis /dev ein Eintrag für psm0 befindet. Durch Eingabe von

    # cd /dev; sh MAKEDEV psm0
             

können Sie einen erstellen, wenn Sie als root angemeldet sind.

Falls Sie den standard Konsoltreiber syscons benutzen, können Sie den Mauszeiger auf Textkonsolen zum Kopieren und Einfügen von Text verwenden. Starten Sie den Mausdämon moused und schalten Sie den Mauszeiger auf der virtuellen Konsole ein:

    # moused -p /dev/xxxx -t yyyy
    # vidcontrol -m on
             

xxxx bezeichnet hierbei den Gerätename der Maus und yyyy das Protokoll. Unterstützte Protokolle finden Sie in der moused(8) Manualpage.

Wahrscheinlich wollen Sie den Mausdämon automatisch beim Booten starten. In Version 2.2.1 müssen Sie hierzu die folgenden Variablen in /etc/sysconfig setzen:

    mousedtype="yyyy"
    mousedport="xxxx"
    mousedflags=""
             

In den Versionen 2.2.2 bis 3.0 müssen Sie die folgenden Variablen in /etc/rc.conf setzen.

    moused_type="yyyy"
    moused_port="xxxx"
    moused_flags=""
             

Wenn Sie eine PS/2-Maus besitzen und FreeBSD 3.1 (oder neuer) benutzen, brauchen Sie nur die Zeile moused_enable="YES" in die Datei /etc/rc.conf einzutragen.

Falls Sie den Mausdämon auf allen virtuellen Bildschirmen anstatt nur während des Bootens auf der Konsole benutzen wollen, tragen Sie außerdem folgendes in /etc/rc.conf ein.

    allscreens_flags="-m on"
             

Beginnend mit FreeBSD 2.2.6 ist der Mausdämon in der Lage, das richtige Protokoll automatisch zu erkennen, falls es sich nicht um ein relativ altes serielles Mausmodell handelt. Geben Sie auto als Protokoll an, um die automatische Erkennung zu aktivieren.

Während der Mausdämon läuft, muß der Zugriff auf die Maus zwischen dem Mausdämon und anderen Programmen, wie z.B. X Windows koordiniert werden. Lesen Sie auch einen anderen Abschnitt zu diesem Thema.

Wenn Sie es geschafft haben, den Mausdämon zu starten (siehe vorherigen Abschnitt), halten Sie die linke Maustaste gedrückt und bewegen Sie die Maus, um einen Textabschnitt zu markieren. Dann drücken Sie die mittlere oder rechte Maustaste, um ihn an der Cursorposition einzufügen.

In den Versionen 2.2.6 und späteren bewirkt das Drücken der mittleren Maustaste das Einfügen des Textes. Das Drücken der rechten Maustaste ``erweitert'' den markierten Textabschnitt. Evtl. möchten Sie Tasten umbelegen oder die mittlere Taste emulieren, falls Ihre Maus keine hat. Details hierzu finden Sie in der moused(8) Manualpage.

Die Unterstützung für USB-Geräte ist seit FreeBSD 3.1 Bestandteil des Systems. Die Unterstützung war allerdings nicht ganz ausgereift; einige der Probleme konnten bis zur Veröffentlichung von FreeBSD 3.2 nicht behoben werden. Wenn Sie die Treiber für USB-Mäuse selbst testen möchten, sollten Sie den unten aufgeführten Anweisungen folgen:

Weitergehende Informationen zum Thema "Maus und X" erhalten Sie hier.

Zur Zeit kann es noch Probleme geben, wenn Sie eine USB-Maus im laufenden Betrieb einstecken oder abziehen. Um Probleme zu vermeiden, sollten Sie die Maus anschließen, bevor Sie das System anschalten und die Maus nicht abziehen, solange das System noch läuft.

Unglücklicherweise lautet die Antwort: ``Vielleicht''. Solche Mäuse mit zusätzlichen Extras erfordern in den meisten Fällen spezielle Treiber. Wenn der Gerätetreiber für die Maus oder das Anwendungsprogramm keine spezielle Unterstützung für die Maus bietet, wird sie sich wie eine gewöhnliche Maus mit zwei oder drei Knöpfen verhalten.

Ob und wie Sie das Rad unter X nutzen können, können Sie im passenden Abschnitt der FAQ erfahren.

Die bis einschließlich FreeBSD 3.2 genutzte Version des Treibers für PS/2-Mäuse unterstützt einige Mäuse nicht richtig. Dazu gehört die Logitech M-S48 und deren OEM-Version. Wenden Sie die folgenden Patch auf /sys/i386/isa/psm.c an und erzeugen Sie einen neuen Kernel.

    Index: psm.c
    ===================================================================
    RCS file: /src/CVS/src/sys/i386/isa/Attic/psm.c,v
    retrieving revision 1.60.2.1
    retrieving revision 1.60.2.2
    diff -u -r1.60.2.1 -r1.60.2.2
    --- psm.c      1999/06/03 12:41:13     1.60.2.1
    +++ psm.c      1999/07/12 13:40:52     1.60.2.2
    @@ -959,14 +959,28 @@
         sc->mode.packetsize = vendortype[i].packetsize;
    
         /* set mouse parameters */
    +#if 0
    +    /*
    +     * A version of Logitech FirstMouse+ won't report wheel
    movement,
    +     * if SET_DEFAULTS is sent...  Don't use this command.
    +     * This fix was found by Takashi Nishida.
    +     */
         i = send_aux_command(sc->kbdc, PSMC_SET_DEFAULTS);
         if (verbose >= 2)
           printf("psm%d: SET_DEFAULTS return code:%04x\n", unit, i);
    +#endif
         if (sc->config & PSM_CONFIG_RESOLUTION) {
             sc->mode.resolution
               = set_mouse_resolution(sc->kbdc,
    -              (sc->config & PSM_CONFIG_RESOLUTION) - 1);
    +                                 (sc->config & PSM_CONFIG_RESOLUTION) - 1);
    +    } else if (sc->mode.resolution >= 0) {
    +      sc->mode.resolution
    +          = set_mouse_resolution(sc->kbdc, sc->dflt_mode.resolution);
    +    }
    +    if (sc->mode.rate > 0) {
    +      sc->mode.rate = set_mouse_sampling_rate(sc->kbdc, sc->dflt_mode.rate);
         }
    +    set_mouse_scaling(sc->kbdc, 1);
    
         /* request a data packet and extract sync. bits */
         if (get_mouse_status(sc->kbdc, stat, 1, 3) < 3)
             

Dieses Problem sollte ab FreeBSD 3.3 nicht mehr auftreten.

Bitte lesen Sie die Antwort zur vorherigen Frage und sehen Sie sich diese Anmerkung auf der Mobile-Computing-Seite an.

FreeBSD unterstützt SCSI-, QIC-36- (mit QIC-02-Schnittstelle) und QIC-40/80-Bandlaufwerke (diskettenbasiert). Hierzu gehören auch 8-mm (aka Exabyte) und DAT-Laufwerke. Die QIC-40/80-Laufwerke sind bekanntlich sehr langsam.

Einige der frühen 8-mm-Laufwerke sind nicht besonders kompatibel zu SCSI-2 und könnten unter FreeBSD nicht einwandfrei funktionieren.

FreeBSD 2.2 untestützt SCSI-Wechsler mit dem Gerät ch und dem Befehl chio. Datails zum Betrieb des Wechslers können Sie in der Manualpage chio(1) finden.

Falls Sie nicht AMANDA oder ein anderes Produkt benutzen, das den Wechsler bereits kennt, bedenken Sie, daß die Programme nur wissen, wie sie ein Band von einem Punkt zu einem anderen bewegen müssen. Sie selbst müssen sich also merken, in welchem Einschub sich ein Band befindet und zu welchem Einschub das Band, das sich gerade im Laufwerk befindet, zurück muß.

FreeBSD unterstützt die Soundkarten SoundBlaster, SoundBlaster Pro, SoundBlaster 16, Pro Audio Spectrum 16, AdLib und Gravis UltraSound. MPU-401 und kompatible MIDI-Karten werden begrenzt unterstützt. Ebenso werden Karten, die der Microsoft Sound System-Spezifikation entsprechen, durch den pcm-Treiber unterstützt.

Sie können den folgenden Befehl jedesmal nach dem Booten ausführen:

    # mixer pcm 100 vol 100 cd 100
             

Sie finden im Abschnitt Ethernet-Karten des Handbuchs eine vollständige Liste.

Anmerkung: Dies betrifft nur Besitzer von 386/486SX/486SLC - andere Maschinen haben in ihrer CPU einen integriert.

Im allgemeinen wird das keine Probleme verursachen, aber es gibt Gelegenheiten bei denen es Sie betreffen wird - entweder bei der Performance oder bei der Genauigkeit der Emulation (lesen Sie den Abschnitt über Gleitpunkt-Emulation). Insbesondere wird das Zeichnen von Bögen in X SEHR langsam sein. Es wird dringend empfohlen, daß Sie sich einen mathematischen Co-Prozessor kaufen - er ist sein Geld wert.

Im Handbuch finden Sie eine Liste von anderen unterstützten Geräten.

Auf einigen Rechnern unterstützt FreeBSD APM. Suchen Sie bitte in der Kernelkonfigurationdatei LINT nach dem Wort APM.

Einige Micron Motherboards besitzen eine nicht-konforme PCI-BIOS-Implementierung. Sie bereitet Kummer, wenn FreeBSD bootet, weil PCI-Geräte nicht an der angegebenen Adresse konfiguriert werden.

Deaktivieren Sie ``Plug and Play Operating System'' im BIOS, um dieses Problem zu beheben. Weitere Informationen können unter http://cesdis.gsfc.nasa.gov/linux/drivers/vortex.html#micron gefunden werden.

Die Chips der neueren Adaptec AIC789-Serie werden unter dem CAM SCSI System unterstützt, das sein Debut in 3.0 gemacht hat. Patches für 2.2-STABLE befinden sich in ftp://ftp.de.FreeBSD.org/pub/FreeBSD/development/cam/. Eine Bootdiskette mit CAM-Erweiterung ist unter http://people.FreeBSD.org/~abial/cam-boot/ erhältlich. Lesen Sie in beiden Fällen die Datei README, bevor Sie beginnen.

Sie werden die PnP-ID Ihres Modems in die PnP-ID-Liste des seriellen Treibers aufnehmen müssen. Erstellen Sie einen neuen Kernel mit dem Eintrag controller pnp0 in der Konfigurationsdatei und rebooten Sie Ihr System, um die Plug & Play-Unterstützung zu aktivieren. Der Kernel wird nun alle PnP-IDs der gefundenen Geräte ausgeben. In der Datei /sys/i386/isa/sio.c finden Sie ab Zeile 2777 (ca.) eine Tabelle, in der Sie die PnP-ID des Modems eintragen müssen. Suchen Sie die Zeichenfolge SUP1310 in der Struktur siopnp_ids[], um die Tabelle zu finden. Erstellen Sie den Kernel nochmals, installieren Sie ihn, rebooten Sie, und Ihr Modem sollte erkannt werden.

Möglicherweise müssen Sie in der boot-time-Konfiguration die PnP-Geräte manuell mit einem pnp-Befehl ähnlich

    pnp 1 0 enable os irq0 3 drq0 0 port0 0x2f8
             

konfigurieren, damit das Modem erkannt wird.

• Erstellen Sie einen Kernel mit options COMCONSOLE.

• Erstellen Sie /boot.config mit -P als einzigem Text in der Datei.

• Ziehen Sie das Tastaturkabel aus dem Rechner.

• Lesen Sie /usr/src/sys/i386/boot/biosboot/README.serial zur Information.

Einige Micron Motherboards besitzen eine nicht-konforme PCI-BIOS-Implementierung, die die PCI-Geräte nicht an den angegebenen Adressen konfiguriert. Hierdurch entstehen Probleme, wenn FreeBSD bootet.

Deaktivieren Sie die Option ``Plug and Play Operating System'' im BIOS, um das Problem zu umgehen.

Weitere Informationen zu diesem Problem gibt es unter dem URL: http://cesdis.gsfc.nasa.gov/linux/drivers/vortex.html#micron.

SMP wird erst ab Version 3.0 unterstützt. SMP ist im Standardkernel (GENERIC) nicht aktiviert; wenn Sie SMP verwenden wollen, müssen Sie einen angepaßten Kernel erstellen. Die dazu notwendigen Optionen können Sie der Datei /sys/i386/conf/LINT entnehmen.

Schalten Sie im BIOS die Option ``boot virus protection'' aus.

SCSI-Laufwerke sollten in der Lage sein, diese automatisch zu verlagern. Bei einigen Laufwerken ist diese Eigenschaft jedoch aus unerfindlichen Gründen bei der Auslieferung ausgeschaltet...

Um sie einzuschalten, müssen Sie den Page-Mode des ersten Gerätes editieren. Unter FreeBSD können Sie das (als root) mit folgendem Befehl tun

    # scsi -f /dev/rsd0c -m 1 -e -P 3
             

und die Werte für AWRE und ARRE von 0 auf 1 ändern:-

    AWRE (Auto Write Reallocation Enbld):  1
    ARRE (Auto Read Reallocation Enbld):  1
             

Die folgenden Abschnitte wurden von Ted Mittelstaedt eingesendet:

Bei IDE-Laufwerken sind fehlerhafte Blöcke normalerweise ein Zeichen für potentielle Probleme. Bei allen modernen IDE-Laufwerken ist eine interne Verlagerung von fehlerhaften Blöcken eingeschaltet. Heutzutage bieten alle IDE-Festplattenhersteller eine umfassende Garantie und tauschen Laufwerke mit fehlerhaften Blöcken um.

Falls Sie ein IDE-Laufwerk mit fehlerhaften Blöcken trotzdem weiterbenutzen möchten, können Sie versuchen, sich vom Hersteller ein IDE-Diagnoseprogramm herunterzuladen und dies über das Laufwerk laufen zu lassen. Manchmal können diese Programme so eingestellt werden, daß sie die Elektronik des Laufwerks dazu veranlassen, das Laufwerk nochmals nach fehlerhaften Blöcken zu durchsuchen und diese auszuschließen.

Auf ESDI-, RLL- und MFM-Laufwerken sind fehlerhafte Blöcke nichts ungewöhnliches und im allgemeinen kein Zeichen für Probleme. Auf einem PC übernehmen der Festplatten-Controller und das BIOS die Aufgabe, fehlerhafte Sektoren auszuschließen, was bei Betriebssystemen wie DOS, die das BIOS benutzen, um auf die Platte zuzugreifen, auch gut funktioniert. Die Festplattentreiber von FreeBSD benutzen allerdings nicht das BIOS, weshalb ein Mechanismus bad144 existiert, der diese Funktionalität ersetzt. bad144 arbeitet nur mit dem wd-Treiber (und wird damit von FreeBSD 4.x nicht unterstützt) und kann NICHT für SCSI benutzt werden. bad144 arbeitet, indem es alle gefundenen, fehlerhaften Sektoren in eine spezielle Datei schreibt.

Eine Einschränkung von bad144 ist, daß die Datei mit den fehlerhaften Sektoren auf die letzte Spur der Platte plaziert wird. Da diese Datei nun möglicherweise eine Liste von fehlerhaften Sektoren enthalten könnte, die am Anfang der Platte auftreten, wo sich möglicherweise die /kernel-Datei befindet, muß sie vom Bootstrap-Programm, das BIOS-Routinen benutzt, um den Kernel zu lesen, erreichbar sein. Das bedeutet, daß Platten, auf denen bad144 benutzt wird, 1024 Zylinder, 16 Köpfe und 63 Sektoren nicht überschreiten dürfen. Platten, die von bad144 verwaltet werden, sind also effektiv auf 500MB begrenzt.

Setzen Sie ``Bad Block Scanning'' während der Installation im fdisk-Menue einfach auf ON, um bad144 zu verwenden. Dies funktioniert bis zu FreeBSD 2.2.7. Die Platte darf nicht mehr als 1024 Zylinder besitzen. Generell wird empfohlen, daß die Festplatte vorher mindestens vier Stunden in Betrieb war, um ihr die Möglichkeit zur thermischen Ausdehnung und Spurversetzung zu geben.

Falls eine Platte mehr als 1024 Zylinder besitzt (wie z.B. große ESDI-Laufwerke), benutzt der Controller einen speziellen Übersetzungsmodus, um den Betrieb unter DOS zu ermöglichen. Der wd-Treiber kennt diese Übersetzungsmodi, WENN Sie die ``translated''-Geometrie mit dem ``set geometry''-Befehl in fdisk eingeben. Sie dürfen NICHT den "dangerously dedicated"-Modus zur Erstellung der FreeBSD-Partition verwenden, weil dieser die Geometrie ignoriert und obwohl fdisk Ihre überschriebene Geometrie benutzen wird, ist die wahre Größe der Platte noch bekannt und es wird versucht, eine zu große FreeBSD-Partition zu erstellen. Wenn die Plattengeometrie in die übersetzte Geometrie geändert worden ist, dann MUß die Partition manuell durch Angabe der Blockanzahl erstellt werden.

Sie können mit dem ESDI-Controller auch kurzerhand eine große ESDI-Platte erstellen, diese dann mit DOS booten und als DOS-Partition formatieren. Anschließend booten Sie mit dem FreeBSD-Installationsprogramm und im fdisk-Menue notieren Sie sich die Blockgröße und die Anzahl Blöcke der DOS-Partition. Dann ändern Sie die Geometrie in die gleiche, wie die von DOS verwendete, löschen die DOS-Partition und erstellen eine ``kooperative'' FreeBSD-Partition mit der gleichen Blockgröße, die Sie zuvor notiert haben. Machen Sie die Partition nun bootfähig und schalten Sie Bad Block Scanning ein. Während der tatsächen Installation wird bad144 gestartet, bevor irgendwelche Dateisysteme erstellt werden (Sie können das mit Alt-F2 beobachten). Falls irgendwelche Probleme bei der Erstellung der Datei mit den fehlerhaften Sektoren auftreten sollten, haben Sie eine zu große Plattengeometrie eingestellt - rebooten Sie Ihr System und beginnen Sie von vorne (die Neupartitionierung und Formatierung unter DOS eingeschlossen).

Falls die Verlagerung fehlerhafter Blöcke aktiviert ist und Sie trotzdem fehlerhafte Blöcke bemerken, sollten Sie einen Austausch des Laufwerkes in Erwägung ziehen, da die fehlerhaften Blöcke mit der Zeit zunehmen werden.

Diese Information ist speziell für die 742a, könnte aber auch andere Buslogic-Karten einschließen (Bustek = Buslogic)

Es gibt zwei grundverschiedene ``Versionen'' der 742a-Karte. Das sind die Hardware-Revisionen A-G und Revisionen von H aufwärts. Der Revisionsbuchstabe befindet sich hinter der Fabriknummer am Rand der Karte. Auf der 742a befinden sich zwei Chips. Einer ist der BIOS-Chip, der andere der Firmware-Chip. FreeBSD achtet nicht darauf, welche BIOS-Version Sie haben, aber es achtet auf die Version des Firmware-Chips. Buslogic schickt Ihnen Upgrade-ROMS, wenn Sie sich an den technischen Support wenden. Die BIOS- und Firmware-Chips müssen als passende Paare ausgeliefert werden. Für Ihre Hardware-Revision benötigen Sie das aktuellste Firmware-ROM auf Ihrer Adapter-Karte.

Karten der Revision A-G akzeptieren BIOS/Firmware-Paare bis zu 2.41/2.21. Die Karten der Revisionen H und aufwärts akzeptieren die aktuellsten BIOS/Firmware-Paare 4.70/3.37. Der Unterschied der Firmware-Versionen ist, daß die 3.37-Firmware ``round robin'' unterstützt.

Auf den Buslogic-Karten befindet sich auch eine Seriennummer. Falls Sie eine Karte mit einer alten Hardwarerevisionsnummer besitzen, können Sie sich an die RMA-Abteilung von Buslogic wenden, Ihre Seriennummer angeben und versuchen, die Karte gegen eine neuere Hardwarerevision auszutauschen. Falls Ihre Karte nicht zu alt ist, wird dem Tausch zugestimmt werden.

Von FreeBSD 2.1 werden nur Firmwarerevisionen ab 2.21 aufwärts unterstützt. Wenn Sie eine ätere Firmwarerevision besitzen, wird Ihre Karte nicht als Buslogic-Karte erkannt. Sie könnte jedoch als Adaptec 1540 erkannt werden. Die früe Firmware von Buslogic enthält eine AHA1540 ``Emulation'', wovon bei EISA-Karten jedoch abzuraten ist.

Wenn sie eine Karte mit einer alten Hardwarerevisionsnummer besitzen und die 2.21-Firmware für sie bekommen, müssen Sie den Jumper W1 in die Position B-C setzen; die Voreinstellung ist A-B.

Hierbei handelt es sich um ein bekanntes Problem. Der auf dem Board befindliche EISA-SCSI-Controller auf dem HP Netserver belegt die EISA-Slotnummer 11, wodurch sich alle ``wirklichen'' EISA-Slots vor ihm befinden. Leider kollidiert der Adreßraum von EISA-Slots >=10 mit dem Adreßraum, der PCI zugeordnet ist und die Autokonfiguration von FreeBSD kann mit dieser Situation derzeit nicht besonders gut umgehen.

Die einfachste Alternative ist, diese Kollision einfach zu leugnen. Setzen Sie dazu die Kerneloption EISA_SLOTS auf den Wert 12. Konfigurieren und kompilieren Sie den Kernel, wie im Handbucheintrag zur Kernelkonfiguration beschrieben.

Dies bringt Ihnen natürlich das klassische Huhn-Ei-Problem, wenn Sie auf einer solchen Maschine installieren wollen. Um dieses Problem zu umgehen, existiert ein spezieller Hack in UserConfig. Benutzen Sie nicht die ``visuelle'' Schnittstelle, sondern die rohe Kommandozeilenschnittstelle. Geben Sie einfach

    eisa 12
    quit
             

am Prompt ein und Sie können Ihr System ganz normal installieren. Sie sollten auf jeden Fall einen angepaßten Kernel zu kompilieren und installieren.

Zukünftige Versionen werden hoffentlich eine passende Lösung für dieses Problem beinhalten.

Er ist fehlerhaft. Er kann Befehle auf beiden Kanälen nicht simultan behandeln.

Es gibt jetzt eine Abhilfe, die automatisch aktiviert wird, wenn Ihr System diesen Chip benutzt. Details finden Sie in der Manualpage zum Plattentreiber (man 4 wd).

Wenn bei Ihnen bereits FreeBSD 2.2.1 oder 2.2.2 mit einem CMD640-Controller läuft und Sie den zweiten Kanal benutzen möchten, erstellen Sie einen neuen Kernel mit options "CMD640". Dies ist seit 2.2.5 Voreinstellung.

Dies wird meistens durch einen Interruptkonflikt verursacht (z.B., wenn zwei Karten den selben Interrupt benutzen). Vor 2.0.5R war FreeBSD diesbezüglich tolerant und die Treiber für Netzwerkkarten funktionierten auch bei IRQ-Konflikten. Seit 2.0.5R werden IRQ-Konflikte jedoch nicht länger toleriert. Booten Sie mit der Option -c und ändern Sie die Einträge zu ed0/de0/... Ihrem Board entsprechend.

Wenn Sie den BNC-Anschluß Ihrer Netzwerkkarte benutzen, könnte es auch sein, daß es sich Geräte-Timeouts aufgrund fehlerhafter Terminierung handelt. Um dies zu überprüfen, verbinden Sie einen Terminator direkt mit der Netzwerkkarte (ohne Kabel) und beobachten Sie, ob die Fehlermeldungen verschwinden.

Einige NE2000 kompatible Karten melden diesen Fehler, wenn keine Verbindung am UTP-Eingang existiert oder wenn das Kabel nicht eingesteckt ist.

Sie müssen mount(8) mitteilen, was für ein Gerät Sie mounten wollen. Standardmäßig wird mount(8) den Typ ufs annehmen. Sie wollen ein CDROM-Dateisystem mounten und das tun Sie, indem Sie die Option -t cd9660 für mount(8) benutzen. Natürlich unter der Annahme, daß die CDROM ein ISO 9660-Dateisystem enthält, wie bei den meisten CDROMs. Ab 1.1R versteht FreeBSD auch automatisch die Rock Ridge Erweiterungen (lange Dateinamen).

Wenn sie zum Beispiel das CDROM-Gerät /dev/cd0c unter dem Dateinamen /mnt mounten wollen, müßten Sie:

    # mount -t cd9660 /dev/cd0c /mnt
             

eingeben.

Beachten Sie, daß Ihr Gerätename (/dev/cd0c in diesem Beispiel) abhängig von der CDROM-Schnittstelle unterschiedlich sein könnte. Die Option -t cd9660 bewirkt lediglich, daß der Befehl mount_cd9660 ausgeführt wird. Das obige Beispiel könnte also kürzer lauten:

    # mount_cd9660 /dev/cd0c /mnt
             

Das bedeutet im allgemeinen, daß sich keine CDROM im Laufwerk befindet, oder, daß das Laufwerk auf dem Bus nicht sichtbar ist. Legen sie etwas ins Laufwerk ein und/oder überprüfen Sie den Master/Slave-Status des Laufwerks, falls es sich um ein IDE (ATAPI) Laufwerk handelt. Bei einem CDROM-Laufwerk kann es einige Sekunden dauern, bis ein eingelegter Datenträger erkannt wird. Haben Sie also Geduld.

Manchmal kann ein SCSI-CDROM verfehlt werden, weil es nicht genügend Zeit hatte, auf einen Bus-Reset zu antworten. Falls Sie ein SCSI-CDROM besitzen, versuchen Sie, folgendes in Ihre Kernelkonfigurationsdatei einzufügen, und neu zu kompilieren:

    options "SCSI_DELAY=15"
             

Wahrscheinlich werden auf der CDROM die ``Joilet'' Erweiterungen für die Speicherung von Datei- und Verzeichnisnamen benutzt. Diese Erweiterung verlangt, daß alle Dateinamen im Unicode-Format (mit zwei Bytes pro Zeichen) abgespeichert werden. Eine Unicode-Erweiterung für den FreeBSD-Kernel ist zwar in Arbeit; da diese Erweiterung aber noch nicht fertig ist, hat der CD9660-Treiber keine Möglichkeit, die Zeichen korrekt zu dekodieren.

Für die Übergangszeit gibt es seit FreeBSD 4.3 eine Schnittstelle im CD9660-Treiber, über die zur Laufzeit eine passende Übersetzungstabelle geladen werden kann. Der Port sysutils/cd9660_unicode enthält passende Übersetzungstabelle für gängige Anwendungen.

[Anmerkung des Übersetzers: Es geht hier nicht um die deutschen Sonderzeichen, da diese schon im normalen ISO-8859-1 enthalten sind. Die Probleme treten auf, wenn man z.B. russische CDs (CP1251) verwendet.]

Falls es sich um einen parallelen Drucker handelt und das einzige Problem ist, daß er schrecklich langsam ist, probieren Sie, den Druckerausgang in den ``gepollten'' Modus zu setzen:

    # lptcontrol -p
             

Von einigen neueren HP-Druckern wird behauptet, daß sie im Interruptmodus nicht korrekt arbeiten, anscheinend wegen eines (noch nicht genau verstandenen) Timing-Problems.

Das Signal 11 wird generiert, wenn ein Prozeß versucht, auf Speicher zuzugreifen, obwohl er vom Betriebssystem dazu nicht befugt wurde. Wenn Ihnen das scheinbar zufällig immer wieder passiert, sollten Sie der Sache einmal auf der Grund gehen.

Das Problem hat in der Regel eine der folgenden Ursachen:

1. Wenn das Problem nur in einer bestimmten Applikation auftritt, die Sie selbst entwickeln, dann ist es wahrscheinlich ein Fehler in Ihren Sourcen.

2. Wenn das Problem in einem Teil von FreeBSD auftritt, könnte es natürlich auch ein Fehler sein; aber in der überwiegenden Zahl der Fälle werden diese Probleme gefunden und behoben, bevor die typischen Leser der FAQ (wir) diese Teile der Sourcen benutzen können (dafür gibt es schließlich -current).

Wenn der Fehler auftritt, wenn Sie ein Programm compilieren aber dabei immer wieder an anderer Stelle auftritt, dann ist das ein ganz eindeutiger Hinweis, daß das Problem *nicht* bei FreeBSD liegt.

Nehmen wir zum Beispiel an, daß Sie ``make buildworld'' ausführen und die Compilierung von ls.c in ls.o abbricht. Wenn Sie nochmal "make buildworld" durchführen und die Compilierung an der gleichen Stelle abbricht, handelt es sich um einen Fehler in den Sourcen. Aktualisieren Sie Ihre Sourcen und versuchen Sie es noch einmal. Wenn der Fehler jedoch an einer anderen Stelle auftritt, liegt das Problem mit an Sicherheit grenzender Wahrscheinlichkeit bei Ihrer Hardware.

Was Sie tun sollten:

Im ersten Fall können Sie einen Debugger wie z.B. gdb benutzen, um die Stelle im Programm zu finden, an der auf eine falsche Adresse zugegriffen wird und danach den Fehler beheben.

Im zweiten Fall müssen Sie sicherstellen, daß das Problem nicht von Ihrer Hardware verursacht wird.

Typische Ursachen dafür sind unter anderem:

1. Es könnte sein, daß Ihren Festplatten zu warm wird: Überprüfen Sie, ob die Lüfter in Ihrem Gehäuse noch funktionieren, damit Ihre Festplatten (und andere Hardware) nicht heißlaufen.

2. Der Prozessor überhitzt, weil Sie Ihn übertaktet haben oder der CPU-Kühler ausgefallen ist. Sie müssen sicherstellen, daß Sie Ihre Hardware unter den Bedingungen betreiben, für die sie spezifiziert ist, zumindestens während Sie versuchen, das Problem zu lösen. Mit anderen Worten: Betreiben Sie Ihre CPU mit der normalen Taktfrequenz.

   Wenn Sie übertakten, sollten Sie daran denken, daß ein langsames System deutlich billiger ist als ein defektes System. Die große Masse hat nicht sehr häufig Mitgefühl mit Problemen bei übertakteten System, auch wenn Sie es für ungefährlich halten.

3. Unzuverlässiger Speicher: Wenn Sie mehr als ein SIMM/DIMM installiert haben, sollten Sie sie alle ausbauen und die Maschine testweise mit jedem SIMM oder DIMM einzeln betreiben. So können Sie feststellen, ob die Ursache ein einzelnes SIMM/DIMM oder auch eine Kombination von Modulen ist.

4. Zu optimistische Einstellung des Mainboards: In Ihrem BIOS und mit den Jumpern auf dem Mainboard können Sie diverse Timings ändern. In den meisten Fällen reichen die Defaults aus, aber manchmal kann es durch zu wenig wait states, die Einstellung ``RAM Speed: Turbo'' oder ähnliches zu merkwürdigen Problemen kommen. Ein möglicher Ansatz ist, die BIOS defaults zu laden, allerdings könnte es sinnvoll sein, die aktuellen Einstellungen vorher zu notieren.

5. Schlechte oder fehlerhafte Stromversorgung des Mainboards: Wenn Sie unbenutzte Steckkarten, Platten oder CD-ROMs in Ihrem System haben, sollten Sie sie testweise ausbauen oder die Stromversorgung abziehen. Dadurch können Sie prüfen, ob Ihr Netzteil eventuell mit einer geringeren Last besser zurechtkommt. Sie können auch testweise ein anderes, am besten ein leistungsfähigeres, Netzteil ausprobieren. Wenn Sie zur Zeit ein 250W-Netzteil benutzen, sollten Sie testweise ein 300W-Netzteil einbauen.

Die sollten ebenfalls die SIG11 FAQ (unten aufgeführt) lesen, da sie gute Erklärungen für alle diese Probleme enthält (allerdings aus Linux-Sicht). Sie erklärt ebenfalls, warum sowohl Programme als auch Geräte zur Speicherprüfung fehlerhaften Speicher teilweise nicht erkennen.

Wenn alle diese Schritte nicht helfen, ist es möglich, daß Sie einen Fehler in FreeBSD gefunden haben. Folgen Sie einfach den Anweisungen für die Erstellung eines Problem Reports.

Es existiert eine ausführliche FAQ hierzu unter der SIG11-Problem-FAQ

Dies ist ein bekanntes Problem mit der ATI Mach 64 Videokarte. Das Problem besteht darin, daß diese Karte die Adresse 2e8 benutzt und die vierte serielle Schnittstelle ebenfalls. Aufgrund eines Fehlers (einer Besonderheit?) im sio(4)-Treiber wird diese Schnittstelle angesprochen, auch wenn Sie gar keine vierte serielle Schnittstelle besitzen und sogar, wenn sie sio3 (die vierte Schnittstelle), die normalerweise diese Adresse verwendet, deaktivieren.

Bis der Fehler behoben ist, können Sie folgende Abhilfe verwenden:

1. Geben Sie am Bootprompt -c ein. (Dies bringt den Kernel in den Konfigurationsmodus).

2. Deaktivieren Sie sio0, sio1, sio2 und sio3 (alle). Auf diese Weise wird der sio-Treiber nicht aktiviert und das Problem tritt nicht mehr auf.

3. Geben Sie exit ein, um den Bootvorgang fortzusetzen.

Falls sie in der Lage sein wollen Ihre seriellen Schnittstellen zu benutzen, müssen Sie einen neuen Kernel mit folgenden Modifikationen erstellen: suchen Sie in /usr/src/sys/i386/isa/sio.c nach der Zeichenkette 0x2e8 und löschen Sie sie und das vorhergehende Komma (nicht das folgende Komma). Nun folgen Sie der normalen Prozedur zur Erstellung eines neuen Kernels.

Auch nach Anwendung dieser Maßnahmen könnte es sein, daß Ihr X Windows-System nicht einwandfrei funktioniert. Wenn dies der Fall ist, stellen Sie sicher, daß es sich bei der von Ihnen benutzten X Windows-Version mindestens um XFree86 3.3.3 oder höher handelt. Diese Version und höhere besitzen eine integrierte Unterstützung für Mach64-Karten und sogar einen dedizierten X-Server für sie.

Aufgrund der Art und Weise, wie FreeBSD die Hauptspeichergröße vom BIOS mitgeteilt bekommt, kann es lediglich 16-Bit Werte in kByte-Größe (65535 kByte = 64MB) erkennen (oder weniger... einige BIOSe setzen die Hauptspeichergröß auf 16MB). Falls Sie mehr als 64MB besitzen, wird FreeBSD versuchen, das zu erkennen, was aber nicht immer funktioniert.

Um dieses Problem zu umgehen, müssen Sie die untenstehende Kerneloption verwenden. Es gibt einen Weg, vollständige Hauptspeicherinformationen vom BIOS zu erhalten, aber in den Bootblöcken ist nicht genügend Platz dafür vorhanden. Wenn der Platzmangel in den Bootblöcken eins Tages behoben ist, werden wir die erweiterten BIOS-Funktionen dazu nutzen, die vollständigen Hauptspeicherinformationen zu erhalten... aber zur Zeit sind wir auf die Kerneloption angewiesen.

options "MAXMEM=n"

Hierbei ist n Ihre Hauptspeichergröße in Kilobyte. Bei einer 128 MB-Maschine müßten Sie 131072 benutzen.

Anmerkung: Die Nachricht kann auch mb_map too small! lauten.

Diese Meldung zeigt an, daß der virtuelle Speicher für Netzwerkpuffer (spezieller mbuf-Cluster) aufgebraucht ist. Sie können die für mbuf verfügbare Größe an VM erhöhen, indem Sie

options "NMBCLUSTERS=n"

in Ihre Kernelkonfigurationsdatei einfügen, wobei n, abhängig davon, wieviele gleichzeitige TCP-Verbindungen Sie unterstützen müssen, eine Zahl aus dem Bereich 512-4096 ist. Ich würde Ihnen empfehlen, 2048 zu probieren - das sollte Sie von solchen Paniksituationen vollkommen befreien. Sie können die Anzahl der zugeordneten/benutzten mbuf-Cluster im System mit netstat -m beobachten. Der voreingestellte Wert für NMBCLUSTERS ist 512 + MAXUSERS * 16.

Die Logik, die versucht, veraltete /var/db/kvm_*.db-Dateien zu erkennen, versagt manchmal und die Benutzung einer unpassenden Datei kann zu Paniksituationen führen.

Falls das passiert, rebooten Sie im Single-User-Modus und löschen Sie die Dateien:

    # rm /var/db/kvm_*.db
             

Dies ist ein Konflikt mit einem Ultrastor SCSI Hostadapter.

Rufen Sie während des Bootprozesses das Kernelkonfigurationsmenue auf und deaktivieren Sie uha0, welches das Problem verursacht.

Dies wird in der Sendmail-FAQ wie folgt beantwortet:-

        * Ich erhalte "Local configuration error" Meldungen, wie:

        553 relay.domain.net config error: mail loops back to myself
        554 <user@domain.net>... Local configuration error

        Wie kann ich dieses Problem lösen?

        Sie haben durch die Benutzung einer MX-Zeile eingestellt, daß
        Mail für die Domäne (z.B. domain.net) an einen speziellen
        Host (in diesem Fall relay.domain.net) weitergeleitet wird,
        aber der Relay-Host erkennt sich selbst nicht als
        domain.net.  Fügen Sie domain.net in /etc/sendmail.cw
        (falls Sie FEATURE(use_cw_file) benutzen) oder "Cw domain.net"
        in /etc/sendmail.cf ein.
            

Die aktuelle Version der Sendmail-FAQ wird nicht mehr mit dem Sendmail-Release verwaltet. Sie wird jedoch regelmäßig nach comp.mail.sendmail, comp.mail.misc, comp.mail.smail, comp.answers und news.answers gepostet. Sie können auch eine Kopie per Email bekommen, indem Sie eine Mail mit dem Inhalt send usenet/news.answers/mail/sendmail-faq an <mail-server@rtfm.mit.edu> schicken.

Die entfernte Maschine scheint den Terminaltyp auf etwas anderes als den Typ cons25, der von FreeBSD verlangt wird, zu setzen.

Es gibt mehrere mögliche Abhilfen für dieses Problem:

• Setzen Sie die Shell-Variable TERM nach dem Einloggen auf der entfernten Maschine auf ansi oder sco, sofern die entfernte Maschine diese Terminaltypen kennt.

• Benutzen Sie einen VT100-Emulator wie screen auf der FreeBSD-Console. screen bietet Ihnen die Möglichkeit, mehrere gleichzeitige Sitzungen von einem Bildschirm aus laufen zu lassen. Es ist ein sehr nettes Programm. Jedes screen-Fenster verhält sich, wie ein VT100-Terminal, weshalb die Variable TERM am entfernten Ende auf vt100 gesetzt werden sollte.

• Installieren Sie den Eintrag cons25 in der Bildschirmdatenbank der entfernten Maschine. Wie das zu geschehen hat, hängt vom Betriebssystem der entfernten Maschine ab. Das Systemadministrationshandbuch für das entfernte System sollte Ihnen hierbei helfen können.

• Starten Sie einen X-Server auf der FreeBSD-Seite und benutzen Sie einen X-basierten Terminalemulator wie xterm oder rxvt, um sich auf der entfernten Maschine einzuloggen. Die Variable TERM auf dem entfernten Host sollte auf xterm oder vt100 gesetzt werden.

Dies kann durch verschiedene Hardware- und/oder Softwareprobleme in Verbindung mit Interrupts verursacht werden. Das kann aufgrund von Fehlern sein, aber es kann auch durch die Eigenarten bestimmter Geräte passieren. TCP/IP über die parallele Schnittstelle mit einer großen MTU laufen zu lassen, ist ein sicherer Weg, um dieses Problem zu provozieren. Grafikbeschleuniger können es auch verursachen. In diesem Fall sollten Sie zunächst die Interrupteinstellungen der Karte überprüfen.

Ein Seiteneffekt dieses Problems sind Prozesse, die mit der Meldung ``SIGXCPU exceeded cpu time limit'' abbrechen.

Für FreeBSD 3.0 und spätere ab dem 29. Nov. 1998: Falls das Problem nicht anders gelöst werden kann, besteht die Lösung darin, diese sysctl-Variable zu setzen:

    # sysctl -w kern.timecounter.method=1
             

Das bedeutet zwar Performanceeinbußen, aber in Anbetracht der Ursache für dieses Problem werden Sie das wahrscheinlich nicht bemerken. Fall das Problem weiter bestehen bleibt, lassen sie die sysctl-Variable auf 1 stehen und setzen Sie die Option NTIMECOUNTER im Kernel auf immer höhere Werte. Wenn Sie irgendwann NTIMECOUNTER=20 erreicht haben sollten, ist das Problem nicht gelöst. Die Interrupts auf Ihrer Maschine sind für eine verläßliche Zeiterhaltung nicht zu gebrauchen.

Dieser Effekt tritt auf, wenn Sie FreeBSD 3.x und eine PCI Soundkarte haben. Das Gerät pcm0 ist für ISA Soundkarten reserviert; wenn Sie eine PCI Soundkarte haben, werden Sie diese Meldung erhalten und Ihre Karte wird als pcm1 eingebunden.

Wenn Sie eine PCI Sounkarte haben, müssen Sie das Gerät snd1 statt des üblichen snd0 verwenden:

    # cd /dev
    # ./MAKEDEV snd1
             

Dieses Problem tritt in FreeBSD 4.x nicht mehr auf, da große Anstrengungen unternommen wurden, diese Version PnP-orientiert zu machen. In FreeBSD 4.x ist das Gerät pcm0 nicht mehr für ISA-Karten reserviert.

FreeBSD 4.x ist deutlich PnP-orientierter und das führt leider dazu, daß einige PnP-Geräte (wie z.B. Soundkarten und interne Modems) nicht mehr funktionieren, obwohl Sie von FreeBSD 3.x noch erkannt wurden.

Die Gründe für dieses Verhalten werden in der unten zitierten Mail von Mail von Peter Wemm erklärt. Diese Mail stammt von der Mailingliste freebsd-questions und war eine Antwort auf eine Frage bezüglich eines internen Modem, das nach dem Update auf FreeBSD 4.x nicht mehr erkannt wurde. Die Kommentare in [] wurden eingefügt, um an einigen Stellen die Bezüge klarstellen.

Das PnP-Bios hat es [das Modem] vorkonfiguriert und es dann im Adreßraum liegenlassen, daher haben es die alten ISA-Erkennungsroutinen [in 3.x] ``gefunden''.

In 4.0 sind die ISA-Routinen deutlich PnP-orientierter. Es war möglich [in 3.x], daß eine ISA-Erkennungsroutinen ein ``zugelaufenes'' Gerät fand; während die PnP-Treiber zwar die ID erkannten, das Gerät aber wegen des Ressourcekonfliktes nicht nutzen konnten. Daher werden die programmierbaren Karten zunächst einmal abgeschaltet, um diese doppelte Erkennung vermeiden zu können. Das bedeutet allerdings auch, daß die Treiber die PnP-ID kennen muß, um PnP-Hardware unterstützen zu können. Wir haben uns vorgenommen, den Benutzern eine einfachere Möglichkeit zur Manipulation dieser Informationen zur Verfügung zu stellen.

Damit Ihr Gerät wieder funktioniert, müssen Sie seine PnP-ID herausfinden und die ID in die Listen eintragen, die zur Erkennung von PnP-Geräten genutzten werden. Zu diesem Zweck wird das Gerät mit pnpinfo(8) analysiert. Das Beispiel zeigt die Ausgaben von pnpinfo(8) für ein internes Modem:

    # pnpinfo
    Checking for Plug-n-Play devices...
    
    Card assigned CSN #1
    Vendor ID PMC2430 (0x3024a341), Serial Number 0xffffffff
    PnP Version 1.0, Vendor Version 0
    Device Description: Pace 56 Voice Internal Plug & Play Modem
    
    Logical Device ID: PMC2430 0x3024a341 #0
            Device supports I/O Range Check
    TAG Start DF
        I/O Range 0x3f8 .. 0x3f8, alignment 0x8, len 0x8
            [16-bit addr]
        IRQ: 4  - only one type (true/edge)
             

[weitere TAG Zeilen gestrichen]

    TAG End DF
    End Tag
    
    Successfully got 31 resources, 1 logical fdevs
    -- card select # 0x0001
    
    CSN PMC2430 (0x3024a341), Serial Number 0xffffffff
    
    Logical device #0
    IO:  0x03e8 0x03e8 0x03e8 0x03e8 0x03e8 0x03e8 0x03e8 0x03e8
    IRQ 5 0
    DMA 4 0
    IO range check 0x00 activate 0x01

Sie benötigen die Information aus der Zeile ``Vendor ID'' ganz im Anfang. Die in Klammern ausgegebene Hexadezimale Zahl (0x3024a341 in diesem Beispiel) ist die PnP ID und die unmittelbar davor stehende Zeichenkette (PMC2430) ist eine eindeutige Herstellerkennung. Diese Informationen müssen in die Datei /usr/src/sys/isa/sio.c eingetragen werden.

Sie sollten zunächst ein Backup von sio.c anlegen, falls irgendwas schiefgehen sollte. Sie werden auch einen Patch erzeugen müssen, um ihn zusammen mit Ihrem PR einzusenden. (Sie wollten doch einen PR schreiben, oder etwa nicht?) Öffnen Sie nun sio.c mit einem Editor und suchen Sie nach der Zeile

    static struct isa_pnp_id sio_ids[] = {
            

und blättern Sie dann nach unten, um die passende Stelle für Ihr Gerät zu finden. Unten finden Sie Beispiel für die Einträge, diese sind nach der Herstellerkennung sortiert. Diese sollte in dem Kommentar auf der rechten Seite aufgenommen werden, dazu kommt die Gerätebeschreibung (Device Description) aus der Ausgabe von pnpinfo(8):

    {0x0f804f3f, NULL},     /* OZO800f - Zoom 2812 (56k Modem) */
    {0x39804f3f, NULL},     /* OZO8039 - Zoom 56k flex */
    {0x3024a341, NULL},     /* PMC2430 - Pace 56 Voice Internal Modem */
    {0x1000eb49, NULL},     /* ROK0010 - Rockwell ? */
    {0x5002734a, NULL},     /* RSS0250 - 5614Jx3(G) Internal Modem */
            

Fügen Sie die hexadezimale Gerätekennung an der richtigen Stelle ein, speichern Sie die Datei ab, erzeugen Sie einen neuen Kernel und starten Sie Ihr System neu. Ihr Gerät sollte nun wie bei FreeBSD 3.x als sio Gerät erkannt werden.

Das Programm sucht nach einem speziellen Symbol im Kernel, kann es aber aus irgendeinem Grunde nicht finden. Dieser Fehler wird von einem dieser Probleme verursacht:

• Ihr Kernel und die sonstigen Programme (das ``userland'') sind nicht mehr auf dem gleichen Stand. Mit anderen Worten, Sie haben zwar einen neuen Kernel erzeugt, aber kein installworld (oder umgekehrt); darum weicht die Symboltabelle von dem ab, was die Anwendung erwartet. Wenn dies der Fall, müssen Sie lediglich die noch fehlenden Schritte des Upgrades durchführen. Die richtige Vorgehensweise kann /usr/src/UPDATING entnommen werden.

• Um Ihren Kernel zu laden, benutzen Sie nicht /boot/loader, sondern laden ihn direkt mit boot2 (siehe boot(8)). Es ist zwar nicht immer ein Fehler, /boot/loader zu umgehen; allerdings ist in der Regel besser dazu geeignet, die Symbole des Kernels für normale Anwendungen verfügbar zu machen.

Das Symptom: Nach dem Aufbau des TCP-Verbindung vergeht einige Zeit, bis endlich die Abfrage des Paßwortes (bzw. der Login-Prompt bei Telnet) erscheint.

Das Problem: In den meisten Fällen versucht der Server in der Zwischenzeit, die IP-Adresse des Clients in einen Rechnernamen zu übersetzen. Viele Server (darunter die Telnet und SSH Server von FreeBSD) machen das, um den Hostnamen z.B. für spätere Verwendung durch den Systemadministrator in eine Protokolldatei schreiben zu können.

Die Lösung: wenn das Problem bei jedem Server auftritt, den Sie von Ihrem Computer (dem Client) ansprechen, dann wird das Problem vom Client verursacht. Wenn das Problem aber nur auftritt, wenn jemand Ihren Rechner (den Server) anspricht, dann liegt die Ursache beim Server.

Wenn das Problem vom Client verursacht wird, müsssen Sie die Einträge im DNS korrigieren, damit der Server Ihre IP-Adresse übersetzen kann. Wenn das Problem in Ihrem lokalen Netzwerk auftritt, sollten Sie es als Problem des Servers behandeln und weiterlesen; wenn es allerdings im Internet auftritt, werden Sie sich wahrscheinlich an Ihrem ISP wenden müssen, damit dieser das Problem für Sie korrigiert.

Wenn das Problem vom Server verursacht wird und Sie sich in einem lokalen Netzwerk befinden, dann müssen Sie Ihren Server so konfigurieren, daß er die lokal genutzen IP-Adressen in Rechnernamen übersetzen kann. Weitere Informationen erhalten Sie in den Onlinehilfen zu hosts(5) and named(8). Wenn dieses Problem im Internet auftritt, könnte die Ursache auch darin liegen, daß die Namensauflösung auf dem Server nicht funktioniert. Versuchen Sie, einen anderen Hostnamen wie z.B. www.yahoo.com aufzulösen. Wenn das nicht funktioniert, liegt das Problem bei Ihrem System.

Diese Fehlermeldung besagt, daß Sie die zur Verfügung stehenden File-Handles des Systems verbraucht haben. Die im Speicher stehende entsprechende Tabelle ist voll.

Die Lösung:

Erhöhen Sie den Wert der Kernel-Variable kern.maxfiles.

    # sysctl -w kern.maxfiles=n

Wählen Sie ein für Ihre Anforderungen passendes n. Jede geöffnete Datei, jeder Socket und jeder FIFO verbrauchen je ein File-Handle. Ein großer Fileserver kann durchaus mehr als zehntausend (10.000+) File-Handles benötigen; dies hängt davon ab, welche und wie viele Dienste gleichzeitig genutzt werden.

Die Voreinstellung für die Anzahl der File-Handles wird in der Kernel-Konfiguration festgelegt:

    maxusers        32

Wenn Sie den Wert der Variablen maxusers erhöhen, steigt kern.maxfiles proportional mit.

Sie können den aktuellen Wert von kern.maxfiles mit dem folgenden Kommando abfragen:

    # sysctl kern.maxfiles
    kern.maxfiles: 1064
             

Ihr Laptop verfügt über mehr als eine Uhr und FreeBSD benutzt leider die falsche.

Starten Sie dmesg(8) und achten Sie auf die Zeilen, in denen das Wort Timecounter vorkommt. Die von FreeBSD benutzte Uhr steht in der letzten Zeile, mit an Sicherheit grenzender Wahrscheinlichkeit wird es TSC sein.

    # dmesg | grep Timecounter
     Timecounter "i8254"  frequency 1193182 Hz
     Timecounter "TSC"  frequency 595573479 Hz

Sie können das überprüfen, indem Sie den Wert der Systemvariablen kern.timecounter.hardware abfragen.

    # sysctl kern.timecounter.hardware
     kern.timecounter.hardware: TSC

Es ist durchaus möglich, daß das BIOS die TSC Uhr ändert, um beispielsweise den CPU-Takt zu während des Batteriebetrieb zu ändern, oder im Stromsparmodus; leider bemerkt FreeBSD diese Änderungen nicht und daher scheint die Uhr falsch zu gehen.

In diesem Beispiel ist die Uhr i8254 ebenfalls verfügbar; um sie auszuwählen, muß ihr Name in die Systemvariable kern.timecounter.hardware geschrieben werden.

    # sysctl -w kern.timecounter.hardware=i8254
     kern.timecounter.hardware: TSC -> i8254

Die Uhrzeit Ihres Laptops sollte nun genauer funktionieren.

Damit diese Änderung automatisch beim Start des Systems durchgeführt wird, müssen Sie die folgende Zeile in die /etc/sysctl.conf eintragen.

    kern.timecounter.hardware=i8254

Der Bootloader von FreeBSD erkennt die Geometrie Ihrer Festplatte nicht richtig. Sie müssen die Geometrie manuell festlegen, wenn sie mit fdisk FreeBSD-Bereiche erzeugen oder ändern.

Die richtigen Werte für die Geometrie können Sie im BIOS des Rechners ablesen. Achten Sie auf die Anzahl der Zylinder, Köpfe und Sektoren für Ihre Festplatte.

Im fdisk von sysinstall(8) müssen Sie G eingeben, um die Geometrie zu definieren.

Sie erhalten eine Dialogbox, in der Sie die Anzahl der Zylinder, Köpfe und Sektoren eingeben können. Verwenden Sie die Angaben des BIOS und setzen Sie Schrägstriche zwischen die Zahlen.

5000 Zylinder, 250 Köpfe and 60 Sektoren würden also als 5000/250/60 eingegeben.

Schließen Sie die Eingabe mit Enter ab und drücken Sie W, um die neue Partitionstabelle auf die Festplatte schreiben zu lassen.

Starten Sie sysinstall(8) und wählen Sie Configure, dann Fdisk. Wählen Sie die Platte, auf der sich der Boot Manager befand, mit der Leertaste aus. Drücken Sie W, um die Änderungen auf die Platten schreiben zu lassen. Nun erscheint eine Abfrage, welcher Bootmanager installiert werden soll. Wählen Sie diesen an und er wird wieder installiert.

• BSDi bietet eine FreeBSD-Version von VistaSource ApplixWare 5 an.

  ApplixWare ist eine umfassende Sammlung von Büroanwendungen, die eine Textverarbeitung, eine Tabellenkalkulation, ein Programm für Vorträge, ein Vektorzeichenprogramm und diverse andere Programme beinhaltet.

  Sie können die FreeBSD-Version von ApplixWare online bestellen.

• Die Linux-Version von StarOffice läuft unter FreeBSD problemlos. Die einfachste Möglichkeit zur Installation der Linux-Version von Staroffice ist die Benutzung der FreeBSD Ports. Zukünfte Versionen der im Sourcecode vorliegenden Variante OpenOffice sollten auch problemlos funktionieren.

Um die günstigste ELF-Motiv 2.1.20 Distribution für FreeBSD (entweder i386 oder Alpha) zu bekommen, wenden Sie sich bitte an Apps2go.

Es gibt zwei Distributionen, die ``developement edition'' und die ``runtime edition'' (wesentlich günstiger). Diese Distributionen enthalten:

• OSF/Motif manager, xmbind, panner, wsm.

• Development-Kit mit uil, mrm, xm, xmcxx, Include- und Imake-Dateien.

• Statische und dynamische ELF-Bibliotheken (zur Benutzung mit FreeBSD 3.0 und höher).

• Demonstrations-Applets.

Achten Sie darauf, daß Sie bei der Bestellung angeben, daß Sie die FreeBSD-Version von Motif möchten (vergessen Sie auch nicht, die Architektur anzugeben)! Von Apps2go werden auch Versionen für NetBSD und OpenBSD verkauft. Dieses Produkt ist zur Zeit nur zum Download per FTP verfügbar.

Eine Motif 2.1-Distribution für FreeBSD im ELF- oder a.out-Format ist bei Metro Link erhältlich.

Diese Distribution enthält:

• OSF/Motif manager, xmbind, panner, wsm.

• Development-Kit mit uil, mrm, xm, xmcxx, Include- und Imake-Dateien.

• Statische und dynamische Bibliotheken (verlangen Sie ELF zur Verwendung unter FreeBSD ab 3.0 und oder a.out zur Verwendung unter FreeBSD bis einschließlich 2.2.8).

• Demonstrations-Applets.

• Vorformatierte Manualpages.

Achten Sie darauf, bei der Bestellung anzugeben, daß Sie die FreeBSD-Version von Motiv möchten! Metro Link vertreibt auch Versionen für Linux. Dieses Produkt ist entweder als CDROM oder zum Download per FTP erhätlich.

Eine Motif 2.0 Distribution für FreeBSD im a.out-Format gibt es bei Xi Graphics.

Diese Distribution enthält:/

• OSF/Motif manager, xmbind, panner, wsm.

• Development-Kit mit uil, mrm, xm, xmcxx, Include- und Imake-Dateien.

• Statische und dynamische Bibliotheken (zur Verwendung unter FreeBSD 2.2.8 und frühere).

• Demonstrations-Applets.

• Vorformatierte Manualpages.

Achten Sie darauf, bei der Bestellung anzugeben, daß Sie die FreeBSD-Version von Motiv möchten! Xi Graphics verkauft auch Versionen für BSDI und Linux. Dieses Produkt ist derzeit ein Satz von vier Disketten... zukünftig wird es eine einheitliche CD-Distribution geben, wie beim CDE.

Xi Graphics hat einmal CDE für FreeBSD verkauft, tut es aber nicht mehr.

KDE ist ein Open-Source X11-Desktop, das CDE in vielen Punkten ähnelt. Eventuell gefällt Ihnen auch das "Look and Feel" von xfce. KDE und xfce sind über das Ports-System von FreeBSD verfügbar.

Ja, Xi Graphics und Metro Link vertreiben beschleunigte X-Produkte für FreeBSD und andere Intel-basierte Systeme.

Das Angebot von Metro Link besteht aus einem leistungsfähigen X-Server, der einfache Konfiguration unter Verwendung von Werkzeugen aus der FreeBSD-Paketsammlung und Unterstützung für den parallelen Einsatz mehrerer Videokarten bietet. Es wird nur in binärer Form über ein bequemes FTP-Download vertrieben. Ganz zu schweigen davon, daß das Angebot von Metro Link zum sehr günstigen Preis von 39 Dollar erhältlich ist.

Metro Link bietet auch Motif für FreeBSD sowohl im ELF-, als auch im a.out-Format an (siehe oben).

Das Angebot von Xi Graphics besteht aus einem leistungsfähigen X-Server, der einfache Konfiguration und Unterstützung für den parallelen Einsatz mehrerer Videokarten bietet. Es wird in binärer Form in einer einheitlichen Diskettendistribution für FreeBSD und Linux vertrieben. XI Graphics bietet auch leistungsfähige X-Server, die auf die Unterstützung von Laptops zugeschnitten sind.

Es gibt ein kostenloses ``Kompatibilitäts-Demo'' der Version 5.0.

Xi Graphics vertreibt auch Motif und CDE für FreeBSD (siehe oben).

Ja! Lesen Sie den Abschnitt kommerzielle Anbieter auf der FreeBSD-Web-Seite.

Schauen Sie auch im Abschnitt Datenbanken der Ports-Sammlung nach.

Ja. Die folgenden Seiten beschreiben genau, wie Linux-Oracle unter FreeBSD einzustellen ist:

• http://www.scc.nl/~marcel/howto-oracle.html

• http://www.lf.net/lf/pi/oracle/install-linux-oracle-on-freebsd

Werfen Sie bitte einen Blick auf die Ports-Seite, um Informationen über die nach FreeBSD portierten Softwarepakete zu erhalten. Die Liste enthält zur Zeit 3400 Einträge und wächst täglich. Schauen Sie hier also öfter nach oder melden Sie sich bei der Mailingliste freebsd-announce an, um sich regelmäßig über Änderungen zu informieren.

Die meisten Ports sind für die Zweige 2.2, 3.0 und 4.x erhältlich; viele von ihnen sollten auch auf 2.1.x-Systemen laufen. Jedesmal, wenn ein FreeBSD-Release erstellt wird, wird auch ein Snapshot des Port-Baumes vom Zeitpunkt des Releases in das Verzeichnis ports/ eingefügt.

Wir unterstützen auch das Konzept von ``Packages'' - im Grunde genommen nicht mehr als gezippte Binärdistributionen mit ein wenig zusätzlicher Intelligenz zur Ermöglichung angepaßter Installationen. Ein Package kann leicht installiert und wieder deinstalliert werden, ohne, daß man etwas über wissen muß, welche Dateien es enthält.

Benutzen Sie das Paketinstallationsmenue in /stand/sysinstall (unter dem Menuepunkt post-configuration) oder führen Sie den Befehl pkg_add(1) mit den speziellen Paketdateien aus, die Sie installieren möchten. Paketdateien können für gewöhnlich an der Endung .tgz erkannt werden und diejenigen, die über eine CDROM-Distribution verfügen, haben auf ihrer CD ein Verzeichnis packages/All, das solche Dateien enthält. Für verschiedene FreeBSD-Versionen können sie von folgenden Adressen auch über das Netz heruntergeladen werden:

oder von Ihrem nächstgelegenen Mirror.

Beachten Sie, daß nicht alle Ports als Package verfügbar sind, da ständig neue hinzugefügt werden. Es ist immer eine gute Idee, sich regelmäßig auf der ftp.de.FreeBSD.org Masterseite darüber zu informieren, welche Packages verfügbar sind.

Weil der POSIX-Standard definiert, daß es so eine Shell geben muß.

Die ausführlichere Antwort: Viele Leute müssen Shell-Programme schreiben, die auf vielen verschiedenen Systemen nutzbar sein müssen. Aus diesem Grund enthält der POSIX-Standard eine sehr detaillierte Definition der Shell und der Hilfsprogramme. Die meisten Programme werden für die Bourne Shell geschrieben; außerdem nutzen mehrere wichtige Schnittstellen (make(1), system(3), popen(3) und ihre Entsprechungen in höheren Programmiersprachen wie Perl und Tcl) die Bourne Shell, um Befehle auszuführen. Da die Bourne Shell an so vielen Stellen und so häufig genutzt wird, muß sie die folgenden Anforderungen erfüllen: Schneller Start, ein klar definiertes Verhalten und ein möglichst geringer Speicherverbrauch.

Wir haben bei der vorliegenden Implementierung versucht, möglichst viele dieser Anforderungen zu erfüllen. Um /bin/sh nicht zu groß werden zu lasen, haben wir viele der Annehmlichkeiten der anderen Shells weggelassen. Aus diesem Grund gibt es in den Ports die luxuriöseren Shells wie bash, scsh, tcsh und zsh. Vergleichen Sie einfach mal den Speicherverbrauch der verschiedenen Shells, indem Sie ps -u aufrufen und sich die Angaben in den Spalten ``VSZ'' und ``RSS'' ansehen.

Sie versuchen, ein Package für 2.2 oder neuer auf einem 2.1.x-System laufen zu lassen. Bitte lesen Sie den vorherigen Abschnitt und besorgen Sie sich den passenden Port/das passende Package für Ihr System.

Sie haben versehentlich ein Package für ein 4.X- oder 5.X-System heruntergeladen und versucht, es auf einem 2.X- oder 3.X-System zu benutzen. Bitte besorgen Sie sich die für ihr System korrekte Version des Packages.

Sie haben keinen mathematischen Co-Prozessor, richtig? Sie werden den alternativen mathematischen Emulator zu Ihren Kernel hinzufügen müssen; tun Sie das, indem Sie die folgende Zeile in Ihre Kernelkonfigurationsdatei einfügen, wodurch der Emulator in den Kernel kompiliert wird:

    options GPL_MATH_EMULATE
             

Sie müssen zunächst den letzten Abschnitt der Datei /etc/sysconfig (oder /etc/rc.conf) editieren und die folgende Variable auf YES setzen:

    # Set to YES if you want ibcs2 (SCO) emulation loaded at startup
    ibcs2=NO
             

Hierdurch wird das Kernelmodul ibcs2 beim Hochfahren geladen.

Dann müssen Sie /compat/ibcs2/dev so einrichten:

    lrwxr-xr-x  1 root  wheel         9 Oct 15 22:20 X0R@ -> /dev/null
    lrwxr-xr-x  1 root  wheel         7 Oct 15 22:20 nfsd@ -> socksys
    -rw-rw-r--  1 root  wheel         0 Oct 28 12:02 null
    lrwxr-xr-x  1 root  wheel         9 Oct 15 22:20 socksys@ -> /dev/null
    crw-rw-rw-  1 root  wheel   41,   1 Oct 15 22:14 spx
             

socksys kann einfach auf /dev/null zeigen, um open & close eine reguläre Datei vorzutäuschen. Der code in -CURRENT wird sich um den Rest kümmern. Dieses Vorgehen ist wesentlich sauberer, als bisher. Falls Sie den Treiber spx für lokale Socket-X-Verbindungen möchten, definieren Sie SPX_HACK, wenn Sie das System kompilieren.

Ein idealer Startpunkt nach der Installation des Packages oder Ports INN ist Dave Barr's INN-Seite, wo Sie die INN-FAQ finden.

Benutzen Sie den Port! Im Ports-Verzeichnis gibt es eine vorbereitete Version von Apache.

Ja. Schauen Sie bitte hier http://www.de.FreeBSD.org/java/ nach.

Wenn Sie eine FreeBSD-Version benutzen, die deutlich älter als das aktuelle -CURRENT oder -STABLE ist, könnte es sein, daß Sie ein Ports-Upgrade-Kit von http://www.de.FreeBSD.org/ports/ benötigen. Wenn Sie auf dem neuesten Stand sind, könnte es sein, daß jemand eine Änderung des Ports durchgeführt hat, die für -CURRENT funktioniert, den Port für -STABLE aber unbrauchbar gemacht hat. Bitte senden Sie einen Fehlerbericht mit dem Befehl send-pr(1). Von der Ports-Sammlung wird nämlich erwartet, daß sie sowohl auf -CURRENT als auch auf -STABLE funktioniert.

Wenn Sie aout-Anwendungen wie den Netscape-Navigator auf einer ELF-basierten Maschine wie 3.1-R oder spätere laufen lassen möchten, werden Sie /usr/libexec/ld.so und einige aout-Bibliotheken benötigen. Sie sind in der Distribution compat22 enthalten. Benutzen Sie /stand/sysinstall oder install.sh im Unterverzeichnis compat22, um sie zu installieren. Lesen Sie auch die ERRATAs für 3.1-R und 3.2-R.

Leider gibt es keine einfache Methode, um die installierten Ports zu aktualisieren. Sie können mit pkg_version ein Script erzeugen, das die installieren Ports mit einer neueren Version aus der Ports-Sammlung ersetzt:

    # pkg_version -c > /tmp/myscript

Das so erzeugte Script muß manuell geändert werden, bevor es benutzt wird. Die aktuelle Version von pkg_version erzwingt dies, indem sie ein exit an den Anfang des Scripts setzt.

Sie sollten die Ausgaben des Scripts abspeichern, da sie Ihnen melden werden, welche Ports von den dem gerade aktualisierten Port abhängen. Es ist möglich, daß diese auch aktualisiert werden müssen. Der typische Fall, in dem ein Update erforderlich ist, ist eine Änderung der Versionsnummer einer shared library; in diesem Fall müssen die abhängigen Ports neu übersetzt werden, damit sie die neue Library nutzen.

Wenn Ihr System rund um die Uhr läuft, kann es jede Woche automatisch eine Liste der Ports erzeugen, die wahrscheinlich aktualisert werden müssen. Fügen Sie dazu weekly_status_pkg_enable="YES" in /etc/periodic.conf ein.

Überhaupt nicht! Lesen Sie den Abschnitt zur Kernelkonfiguration im Handbuch.

Lassen Sie mich raten. Sie haben npx0 aus Ihrer Konfigurationsdatei entfernt, weil Sie keinen mathematischen Co-Prozessor besitzen, richtig? Falsch! :-) npx0 ist zwingend erforderlich. Auch, wenn Sie keinen mathematischen Co-Prozessor besitzen, müssen Sie das Gerät npx0 einbinden.

Sie haben Ihren Kernel wahrscheinlich im Debug Modus erstellt. Ein Debug-Kernel enthält viele zusätzliche Informationen für die Fehlersuche, daher ist er so groß. Bitte beachten Sie, daß die Verwendung eines Debug-Kernels bei FreeBSD 3.0 und neueren Version die Performance des Systems nicht oder nur minimal reduziert; außerdem ist es für den Fall einer system panic sehr praktisch, einen Debug-Kernel zur Hand zu haben.

Wenn Ihnen allerdings der Plattenplatz ausgeht oder Sie einfach rein prinzipiell keinen Debug-Kernel benutzen wollen, müssen die beiden folgenden Bedingungen erfüllt sein:

• Die Konfigurationsdatei für Ihren Kernel darf die folgende Zeile nicht enthalten:

      makeoptions DEBUG=-g
  

• Sie dürfen config nicht mit dem Parameter -g starten.

Sollten Sie sich nicht an diese Einschränkungen halten, wird Ihr Kernel im Debug-Modus erstellt. Solange Sie sich an diese Einschränkungen halten, können Sie Ihren Kernel ganz normal erstellen und die Größe des Kernels sollte deutlich sinken. Ein normaler Kernel ist nur 1.5 MByte bis 2 MByte groß.

Wenn ich einen Kernel mit Unterstützung für serielle Multi-Port-Schnittstellen kompiliere, bekomme ich den Hinweis, daß nur der erste Port geprüft wird und die restlichen auf Grund von Interrupt-Konflikten übersprungen werden. Wie kann ich das Beheben?

Das Problem besteht darin, daß in FreeBSD Code integriert ist, um den Kernel vor Abstürzen aufgrund von Hardware- oder Software-Konflikten zu bewahren. Behoben wird es, indem die IRQ-Angaben für alle Ports, bis auf einen ausgelassen werden. Hier ist ein Beispiel:

    #
    # Multiport high-speed serial line - 16550 UARTS
    #
    device sio2 at isa? port 0x2a0 tty irq 5 flags 0x501 vector siointr
    device sio3 at isa? port 0x2a8 tty flags 0x501 vector siointr
    device sio4 at isa? port 0x2b0 tty flags 0x501 vector siointr
    device sio5 at isa? port 0x2b8 tty flags 0x501 vector siointr
             

Es gibt eine Reihe von möglichen Ursachen für dieses Problem:

• Sie benutzen die neuen Kommandos make buildkernel und make installkernel nicht, obwohl die Sourcen auf Ihrem System nicht zum laufenden System passen (z.B. benutzen Sie die Sourcen von 4.3-RELEASE auf einem System mit 4.0-RELEASE). Wenn Sie ein Upgrade durchführen wollen, sollten Sie /usr/src/UPDATING lesen, beachten Sie insbesondere den Abschnitt ``COMMON ITEMS'' gegen Ende des Dokuments.

• Sie benutzen zwar make buildkernel und make installkernel, aber Sie haben nicht darauf geachtet, daß vorher ein komplettes make buildworld durchgelaufen sein muß. Um seine Arbeit erledigen zu können, benötigt make buildkernel Dateien, die von make buildworld erzeugt werden.

• Auch wenn Sie FreeBSD-STABLE verwenden, ist es durchaus möglich, daß Sie die Sourcen genau zum falschen Zeitpunkt aktualisiert haben: Während Sie gerade modifiziert wurden oder kurzzeitig fehlerhaft waren. Eine absolute und vollständige Garantie, daß Sie die Sourcen compilieren können, gibt es nur für die Releases, bei FreeBSD-STABLE ist das nicht immer so. Wenn Sie es noch nicht versucht haben, sollten Sie ihre Source nochmals aktualisieren. Es ist denkbar, daß der von Ihnen genutzte Server zur Zeit Probleme hat, benutzten Sie daher testweise auch einmal einen anderen Server.

Für die Versionen 2.0.5R bis 2.2.1R heißt die primäre Konfigurationsdatei /etc/sysconfig. Alle Optionen müssen in dieser Datei angegeben werden und andere Dateien wie /etc/rc und /etc/netstart übernehmen sie einfach hieraus.

Sehen Sie in die Datei /etc/sysconfig und ändern Sie die Werte entsprechend Ihrem System. Diese Datei enthält Kommentare, die die möglichen Einstellungen erklären.

In den Versionen nach 2.2.1 und 3.0 erhielt /etc/sysconfig den aussagekräftigeren Namen rc.conf(5) und die Syntax wurde bei dieser Gelegenheit auch etwas bereinigt. /etc/netstart wurde ebenfalls in /etc/rc.network umbenannt, so daß alle Dateien nun mit dem Befehl cp /usr/src/etc/rc* /etc kopiert werden können.

Seit FreeBSD 3.1 ist rc.conf als /etc/defaults/rc.conf verfügbar. Ändern Sie diese Datei nicht! Wenn Sie den Wert einer der in /etc/defaults/rc.conf gesetzten Variablen ändern wollen, sollten Sie die entsprechende Zeile an die Datei /etc/rc.conf anfügen und sie dort ändern.

Wenn Sie zum Beispiel den ab FreeBSD 3.1 mitgelieferten DNS Server named aktivieren wollen, müssen Sie lediglich das folgende Kommando eingeben:

    # echo named_enable="YES" >> /etc/rc.conf
             

Wenn Sie in FreeBSD 3.1 und späteren Versionen lokale Server starten wollen, müssen Sie passende Shellscripts im Verzeichnis /usr/local/etc/rc.d/ ablegen. Die Dateien müssen als ausführbar markiert sein und die Endung .sh haben. Wenn Sie FreeBSD 3.0 oder eine noch ältere Version benutzen, müssen Sie die Datei /etc/rc.local ändern.

Die Datei /etc/rc.serial dient zur Initialisierung serieller Schnittstellen (z.B. Einstellung der Schnittstelleneigenschaften usw.).

Die Datei /etc/rc.i386 dient für Intel-spezifische Einstellungen wie iBCS2-Emulation oder Konfiguration der PC-Systemkonsole.

Benutzen Sie den Befehl adduser(8) und für kompliziertere Fälle den Befehl pw(8).

Benutzen Sie den Befehl rmuser(8), um einen Benutzer wieder zu löschen. Sie können hierzu auch pw(8) benutzen.

Lesen Sie das Tutorial zur Festplattenformatierung unter www.de.FreeBSD.org.

Ob es sich um ein Wechsellaufwerk handelt, um ein ZIP- oder ein EZ-Laufwerk (oder sogar ein Diskettenlaufwerk, wenn Sie es auf diese Weise benutzen möchten), oder um eine neue Festplatte - wenn es einmal installiert und vom System erkannt ist und Sie Ihre Kassete/Diskette/was_auch_immer eingelegt haben, ist das Vorgehen bei allen Geräten ziemlich ähnlich.

(dieser Abschnitt basiert auf Mark Mayo's ZIP-FAQ)

Wenn es sich um ein ZIP- oder Diskettenlaufwerk handelt, und sich bereits ein DOS-Dateisystem darauf befindet, können Sie einen Befehl wie diesen für eine Diskette benutzen:

    # mount -t msdos /dev/fd0c /floppy
             

oder diesen:

    # mount -t msdos /dev/da2s4 /zip
             

für eine ZIP-Disk mit der Herstellerkonfiguration.

Benutzen Sie bei anderen Platten fdisk oder /stand/sysinstall, um herauszufinden, wie sie konfiguriert sind.

Die restlichen Beispiele sind für ein ZIP-Laufwerk unter da2, der dritten SCSI-Platte.

Wenn es sich nicht um eine Diskette oder eine Wechselplatte handelt, die Sie mit anderen Leuten austauschen wollen, ist es wahrscheinlich besser, ein BSD-Dateisystem darauf zu installieren. Hierdurch bekommen Sie Unterstützung für lange Dateinamen, eine mindestens doppelt so hohe Leistungsausnutzung und wesentlich höhere Stabilität. Zunächst müssen Sie die Partitionen/Dateisysteme auf DOS-Ebene nochmals erstellen. Sie können entweder fdisk(8) oder /stand/sysinstall benutzen, oder, bei einem kleinen Laufwerk, dem Sie eine Unterstützung für mehrere Betriebssysteme nicht zumuten wollen, entfernen Sie einfach die komplette FAT Partitionstabelle (Slices) und benutzen Sie einfach die BSD-Partitionierung:

    # dd if=/dev/zero of=/dev/rda2 count=2
    # disklabel -Brw da2 auto
             

Sie können disklabel oder /stand/sysinstall benutzen, um mehrere BSD-Partitionen zu erstellen. Dies werden Sie sicherlich bei einer fest eingebauten Platte wollen, aber bei einem Wechsellaufwerk wie einem ZIP ist das wahrscheinlich irrelevant.

Zum Schluß erstellen Sie ein neues Dateisystem - dieses befindet sich auf unserem ZIP-Laufwerk und belegt die gesamte Platte:

    # newfs /dev/rda2c
             

anschließend mounten Sie es:

    # mount /dev/da2c /zip
             

Und sicherlich ist es keine schlechte Idee, eine Zeile ähnlich der folgenden in die Datei /etc/fstab einzufügen, damit Sie in Zukunft nur mount /zip einzugeben brauchen:

    /dev/da2c /zip ffs rw,noauto 0 0
             

Die übliche Ursache dieses Problems ist, daß Sie die crontab des Systems (/etc/crontab) geändert und dann mit crontab(1) installiert haben:

    # crontab /etc/crontab

Diese Vorgehensweise ist falsch. Die crontab des Systems hat ein anderes Format als die crontabs für die einzelnen Benutzer, die mit crontab(1) aktualisiert werden (genauere Informationen über die Unterschiede erhalten Sie in crontab(5)).

Wenn Sie so vorgegangen sind, ist die zweite crontab einfach nur eine Kopie von /etc/crontab, allerdings im falschen Format. Löschen Sie sie mit dem folgenden Befehl:

    # crontab -r

Wenn Sie /etc/crontab wieder ändern müssen, sollten Sie einfach gar nichts tun, um cron(8) über die Änderung zu informieren, er erkennt die Änderung automatisch.

Wenn Sie ein Kommando jeden Tag, jede Woche oder jeden Monat ausführen lassen wollen, ist es wahrscheinlich einfacher, wenn Sie entsprechende Shell-Scripte in /usr/local/etc/periodic ablegen. Diese werden dann von periodic(8) zusammen mit den anderen regelmäßigen Tätigkeiten ausgeführt.

Der eigentliche Grund für den Fehler ist die Tatsache, daß die crontab des Systems ein zusätzliches Feld enthält; dieses Feld gibt an, mit welcher Benutzerkennung der Befehl ausgeführt werden soll. In der mitgelieferten crontab ist das bei allen Einträgen die Benutzerkennung root. Wenn diese Datei als die crontab des Benutzers username (die nicht mit der crontab des Systems identisch ist) verwendet wird, hält cron(8) die Zeichenkette root für den Namen des zu startenden Programmes, aber dieses Programm gibt es nicht.

Das ist ein Sicherheits-Feature. Wenn Sie mit su(1) zum Account root (oder jedem anderen Account mit Super-User-Privilegien) wechseln wollen, müssen Sie ein Mitglied der Gruppe wheel sein. Wenn es dieses Feature nicht gäbe, könnte jeder, der einen Account auf dem System hat und zufällig das Paßwort für root erfährt, mit Super-User-Rechten auf das System zugreifen. Durch dieses Feature ist die Lage anders, wenn Sie nicht Mitglied von wheel sind, können Sie nicht einmal versuchen, daß Paßwort einzugeben.

Um einem Benutzer zu erlauben, mit su(1) root zu werden, müssen Sie ihn nur in die Gruppe wheel eintragen.

Wenn Sie aufgefordert werden, den Pfadnamen der Shell einzugeben, drücken Sie einfach ENTER. Geben Sie danach mount / ein, um das root Dateisystem im Schreib/Lese-Modus zu mounten. Sie werden wahrscheinlich auch mount -a -t ufs ausführen müssen, um das Dateisystem mit Ihrem Lieblingseditor zu mounten. Wenn Ihr Lieblingseditor auf einem Netzwerklaufwerk liegt, müssen Sie entweder das Netzwerk von Hand konfigurieren oder einen Editor benutzen, der auf einem lokalen Laufwerk vorhanden ist, z.B. ed(1).

Wenn Sie einen bildschirmorientierten Editor wie zum Beispiel vi(1) oder emacs(1) benutzen wollen, werden Sie auch den Befehl export TERM=cons25 ausführen müssen, damit diese Editoren die richtigen Einstellungen aus der Datenbank termcap(5) übernehmen.

Sobald Sie diese Schritte ausgeführt, können Sie den Fehler in der /etc/rc.conf ganz normal beheben. Die Fehlermeldungen, die Ihnen unmittelbar nach den Startmeldungen des Kernels angezeigt wurden, sollten Ihnen die Nummer der Zeile mit dem Fehler melden.

Die erweiterten DOS-Partitionen befinden sich hinter ALLEN primären Partitionen. Wenn sich zum Beispiel eine Partition ``E'' als sekundäre DOS-Partition auf Ihrem zweiten SCSI-Laufwerk befindet, müssen Sie die speziellen Dateien für ``Slice 5'' im Verzeichnis /dev erstellen und dann /dev/da1s5 mouten:

    # cd /dev
    # ./MAKEDEV da1s5
    # mount -t msdos /dev/da1s5 /dos/e
             

Digital UNIX-UFS-CDROMs können unter FreeBSD direkt gemountet werden. Das Mounten von Partitionen von Digital UNIX und anderen Systemen, die UFS unterstützen, könnte schwieriger sein, abhängig von den Details der Plattenpartitionierung des betreffenden Betriebssystems.

Linux: 2.2 und spätere unterstützen ext2fs-Partitionen. Unter mount_ext2fs(8) finden Sie weitere Informationen.

NT: Es gibt einen NTFS-Treiber, der nur Lesezugriffe gestattet. Weitere Informationen finden Sie im Tutorium von Mark Ovens unter http://ukug.uk.freebsd.org/~mark/ntfs_install.html.

Für weitere Informationen zu diesem Thema wären wir sehr dankbar.

Diese Prozedur unterscheidet sich für die Systeme 2.2.x and 3.x (mit dem dreistufigen Bootprozeß) geringfügig.

Das grundsätzliche Vorgehen besteht darin, daß Sie den ersten Sektor Ihrer eigentlichen FreeBSD-Rootpartition in eine Datei auf der DOS/NT-Partition kopieren. Angenommen, sie nennen die Datei etwa c:\bootsect.bsd (durch c:\bootsect.dos inspiriert), dann können Sie die Datei c:\boot.ini etwa wie folgt editieren:

    [boot loader]
    timeout=30
    default=multi(0)disk(0)rdisk(0)partition(1)\WINDOWS
    [operating systems]
    multi(0)disk(0)rdisk(0)partition(1)\WINDOWS="Windows NT"
    C:\BOOTSECT.BSD="FreeBSD"
    C:\="DOS"
             

Bei 2.2.x-Systemen wird für diese Prozedur angenommen, daß DOS, NT, FreeBSD oder was auch immer, in den entsprechenden Partitionen auf derselben Platte installiert wurden. Das untenstehende Beispiel wurde auf einem System getestet, auf dem DOS & NT in der ersten und FreeBSD in der zweiten fdisk-Partition installiert waren. Zusätzlich wurde FreeBSD so installiert, daß es von seiner Partition bootet, und nicht vom MBR.

Mounten Sie eine DOS-formatierte Diskette (falls Sie nach NTFS gewechselt haben) oder die FAT-Partition z.B. unter /mnt.

    # dd if=/dev/rda0a of=/mnt/bootsect.bsd bs=512 count=1
             

Rebooten Sie mit DOS oder NT. Benutzer von NTFS kopieren nun die Dateien bootsect.bsd und/oder bootsect.lnx von der Diskette nach C:\. Ändern Sie die Attribute (Rechte) von boot.ini mit:

    C:\>attrib -s -r c:\boot.ini
             

Editieren Sie nun die Datei und fügen Sie die entsprechenden Einträge aus dem obigen boot.ini-Beispiel hinzu und setzen dann wieder die alten Attribute:

    C:\>attrib +s +r c:\boot.ini
             

Falls FreeBSD vom MBR bootet, restaurieren Sie den MBR mit dem DOS-Befehl fdisk, nachdem Sie FreeBSD so umkonfiguriert haben, daß es von seiner Partition bootet.

Für die FreeBSD-Systeme 3.x ist die Prozedur etwas einfacher.

Falls FreeBSD auf derselben Platte, wie die NT-Bootpartition installiert ist, kopieren Sie einfach /boot/boot1 nach C:\BOOTSECT.BSD. Falls FreeBSD auf einer anderen Platte installiert ist, wird /boot/boot1 nicht funktionieren; Sie brauchen in diesem Fall /boot/boot0.

/boot/boot0 muß mit sysinstall installiert werden. Wählen Sie dazu den FreeBSD-Bootmanager aus, wenn Sie gefragt werden, ob sie einen Bootmanager installieren wollen. Dieser Schritt ist notwendig, weil /boot/boot0 eine leere Partitionstabelle enthält, die von sysinstall ausgefüllt wird, bevor /boot/boot0 in den MBR kopiert wird.

Wenn der Bootmanager von FreeBSD gestartet wird, merkt er sich das zuletzt gestartet Betriebssystem, indem er dessen Partition als aktiv markiert. Danach kopiert er sich selbst (alle 512 Bytes) in den MBR. Wenn Sie also einfach /boot/boot0 nach C:\BOOTSECT.BSD kopieren, würde der Bootmanager eine leere Partitionstabelle (mit einem als aktiv markiertem Eintrag) in den MBR kopieren.

Falls sich FreeBSD und Linux auf derselben Platte befinden, folgen Sie einfach den Installationsanweisungen von LILO zum booten eines Nicht-Linux-Betriebssystems. Ganz knapp sind dies:

Booten Sie Linux und fügen Sie die folgenden Zeilen in die Datei /etc/lilo.conf ein:

    other=/dev/hda2
    table=/dev/hda
    label=FreeBSD
             

(hierbei wird angenommen, daß Ihre FreeBSD-Partition Linux unter /dev/hda2 bekannt ist; ändern Sie dies entsprechend Ihren Einstellungen). Führen Sie nun als root den Befehl lilo aus und Sie sind fertig.

Falls FreeBSD sich auf einer anderen Platte befindet, müssen Sie loader=/boot/chain.b zu den LILO-Angaben hinzufügen. Zum Beispiel:

    other=/dev/dab4
    table=/dev/dab
    loader=/boot/chain.b
    label=FreeBSD
             

In einigen Fällen könnte es sein, daß Sie beim FreeBSD-Bootloader die BIOS-Laufwerksnummer angeben müssen, um von der zweiten Platte booten zu können. Wenn Ihre FreeBSD-SCSI-Platte vom BIOS zum Beispiel als BIOS-Platte 1 erkannt wird, müssen Sie am Prompt des FreeBSD-Bootloaders eingeben:

    Boot: 1:da(0,a)/kernel
             

Seit Version 2.2.5 können Sie boot(8) so konfigurieren, daß das beim Booten automatisch geschieht.

Das Linux+FreeBSD mini-HOWTO ist ein guter Ratgeber bei Fragen zur Interaktion von FreeBSD und Linux.

Installieren Sie LILO am Anfang Ihrer Linux-Bootpartition, anstatt im Master Boot Record. Sie können LILO dann von BootEasy aus booten.

Wenn Sie Windows-95 und Linux benutzen, wird das ohnehin empfohlen, um es einfacher zu machen, Linux wieder zu booten, wenn es nötig werden sollte, daß Sie Windows95 neu installieren (Windows95 ist ein eifersüchtiges Betriebssystem, das kein anderes Betriebssystem im Master Boot Sektor duldet).

Die Installationsprozedur bietet Ihnen zwei verschiedene Methoden, Ihre Festplatte(n) zu partitionieren. Die Standardmethode macht sie kompatibel zu anderen Betriebssystemen auf derselben Maschine, indem fdisk-Tabelleneinträge (unter FreeBSD ``slices'' genannt) mit einem FreeBSD-Eintrag, in dem eigene Partitionen untergebracht werden, benutzt werden. Optional kann ausgewählt werden, ob ein Boot-Selektor installiert werden soll, um zwischen den möglichen Betriebssystemen auf der/den Platte(n) wechseln zu können. Bei der zweiten Methode wird die gesamte Platte für FreeBSD genutzt und nicht versucht, kompatibel zu anderen Betriebssystemen zu sein.

Nun, warum wird es ``gefährlich'' genannt? Eine Platte in diesem Modus enthält nichts, was von normalen PC-Hilfsprogrammen als gültige fdisk-Tabelle betrachtet werden würde. Abhängig von der Qualität ihres Designs werden sie sich bei Ihnen beschweren, sobald sie mit einer solchen Platte in Kontakt kommen, oder noch schlimmer, sie könnten den Bootstrap von FreeBSD beschädigen, ohne Sie zu fragen oder darauf hinzuweisen. Hinzu kommt, daß vom Layout von ``dangerously dedicated'' Platten bekannt ist, daß es viele BIOSe verwirrt, einschließlich solcher von AWARD (wie es z.B. im HP Netserver oder Micronics-Systemen, sowie vielen anderen zu finden ist) und Symbios/NCR (für die bekannte 53C8xx-Reihe von SCSI-Controllern). Dies ist keine vollständige Liste - es gibt weitere. Symptome für diese Verwirrung sind ``read error''-Meldungen, die vom FreeBSD-Bootstrap ausgegeben werden, wenn es sich selbst nicht finden kann, sowie Systemabstürze beim Booten.

Warum gibt es diesen Modus dann überhaupt? Es spart ein paar kByte an Plattenplatz und kann echte Probleme verursachen, die zu einer Neuinstallation führen. Die Ursprünge des ``Dangerously dedicated'' Modus liegen in der Absicht, eines der häufigsten Probleme, das Erstinstallierer von FreeBSD plagt, zu verhindern - die BIOS-Werte für die ``Geometrie'' einer Festplatte auf der Festplatte selbst anzupassen.

``Geometrie'' ist ein veraltetes Konzept, das aber immer noch die Grundlage für die Interaktion zwischen dem PC-BIOS und den Festplatten ist. Wenn das Installationsprogramm von FreeBSD Slices erstellt, muß es sich die Lage dieser Slices auf der Festplatte in einer Art merken, die damit übereinstimmt, wie das BIOS erwartet, sie zu finden. Wenn das falsch geschieht, werden Sie nicht in der Lage sein, zu booten.

Durch den ``Dangerously dedicated'' Modus wird versucht, dies zu umgehen, indem das Problem vereinfacht wird. In einigen Fällen klappt das zwar, aber er ist eher als allerletzter Ausweg gedacht - in 99 von 100 Fällen gibt es bessere Möglichkeiten, das Problem zu lösen.

Wie vermeiden Sie also die Notwendigkeit zum ``DD'' Modus, wenn Sie installieren? Beginnen Sie, indem Sie sich notieren, welche Geometrie das BIOS für Ihre Platten benutzt. Sie können erreichen, daß der Kernel sie beim Booten ausgibt, indem Sie -v an der Eingabeaufforderung boot: angeben, oder boot -v im Loader verwenden. Kurz bevor das Installationprogramm startet, wird der Kernel eine Liste mit den BIOS-Geometrien ausgeben. Keine Panik - warten Sie, bis das Installationsprogramm gestartet wurde und benutzen Sie Scrollback, um die Zahlen zu lesen. Typischerweise befinden sich die BIOS-Platten in derselben Reihenfolge, wie FreeBSD Ihre Platten auflistet - zuerst IDE, dann SCSI.

Wenn Sie Ihre Festplatte in Slices unterteilen, überprüfen Sie, ob die Plattengeometrie, die im FDISK-Menue angegeben ist, korrekt ist (d.h. mit den Einstellungen im BIOS übereinstimmen). Falls die Werte nicht stimmen, benutzen Sie g, um sie zu korrigieren. Diese Schritte sind nötig, wenn sich absolut nichts auf der Festplatte befindet, oder, wenn die Festplatte vorher in einem anderen System benutzt worden ist. Beachten Sie, daß dies nur für die Festplatte nötig ist, von der Sie booten wollen. Mit weiteren vorhandenen Platten wird FreeBSD sich problemlos zurechtfinden.

Wenn Sie es geschafft haben, daß das BIOS und FreeBSD in der Festplattengeometrie übereinstimmen, dann sind Ihre Probleme ziemlich sicher vorüber - ohne, daß es nötig gewesen wäre, den ``DD''-Modus zu benutzen. Falls sie jedoch immer noch mit der gefürchteten ``read error''-Meldung begrüßt werden sollten, wenn Sie versuchen, zu booten, wird es Zeit, daß Sie Ihre Finger kreuzen und es einfach versuchen - es gibt nichts mehr zu verlieren.

Um eine ``dangerously dedicated'' Festplatte wieder für einen normalen PC brauchbar zu machen, gibt es zwei Möglichkeiten. Die erste ist, ausreichend viele NULL-Bytes in den MBR zu schreiben, um irgendwelche nachfolgenden Installation glauben zu machen, daß es sich um eine leere Festplatte handelt. Sie können das zum Beispiel so tun:

    # dd if=/dev/zero of=/dev/rda0 count=15
             

Alternativ installiert der undokumentierte DOS-Befehl

    C:\> fdisk /mbr
             

einen neuen Master-Boot-Record, d.h. der BSD-Bootstrap wird zestört.

Der beste Weg ist, Ihre Swap-Partition zu vergrößern, oder sie nutzen diese bequeme Ausrede, um eine weitere Festplatte einzubauen. Eine gebräuchliche Faustregel ist, einen etwa doppelt so großen Swap-Bereich zu nutzen, wie Hauptspeicher vorhanden ist. Falls Sie jedoch nur über sehr wenig Hauptspeicher verfügen, werden Sie wahrscheinlich einen größeren Swap-Bereich konfigurieren wollen. Es ist auch sinnvoll, genügend Swap-Bereich im Hinblick auf geplante zukünftige Hauptspeichererweiterungen zu konfigurieren, damit Sie sich später nicht mit der Konfiguration Ihres Swap-Bereiches herumärgern müssen.

Das Hinzufügen eines Swap-Bereichs auf einer separaten Platte, ist effizienter, als einfach einen Swap-Bereich auf derselben Platte hinzuzufügen. Wenn Sie zum Beispiel Quellcode auf einer Platte kompilieren und der Swap-Bereich sich auf einer anderen Platte befindet, geschieht das viel schneller, als wenn beides, Swapping und Kompilierung auf derselben Platte stattfinden würden. Das trifft ganz besonders auf SCSI-Platten zu.

Wenn Sie mehrere Festplatten besitzen, lohnt es sich für gewöhnlich, auf jeder einzelnen einen Swap-Bereich zu konfigurieren, auch, wenn das bedeutet, einen Swap-Bereich auf einer bereits verwendeten Platte einzurichten. Typischerweise sollte jede schnelle Platte in Ihrem System mit etwas Swap-Bereich konfiguriert werden. FreeBSD unterstützt standardmäßig bis zu vier interleaved Swap-Geräte. Bei der Konfiguration mehrerer Swap-Bereiche werden sie grundsätzlich alle mit derselben Größe anlegen wollen, aber manchmal verwenden Benutzer eine größere primäre Swap-Partition, um einen Hauptspeicherauszug vom Kernel darin aufnehmen zu können. Ihre primäre Swap-Partition muß mindestens so groß wie der Hauptspeicher sein, um einen Hauptspeicherauszug vom Kernel aufnehmen zu können.

IDE-Laufwerke können keinen gleichzeitigen Zugriff auf beide Laufwerke auf demselben Kanal zuzulassen (FreeBSD unterstützt nicht den Modus 4, also ist jeglicher Lese-/Schreibzugriff auf IDE-Platten ``programmiert''). Trotzdem ist es empfehlenswert, Ihren Swap-Bereich auf einem separaten Laufwerk anzulegen; die Laufwerke sind so günstig, daß es nicht lohnt, sich darüber Gedanken zu machen.

Swapping über NFS ist nur zu empfehlen, wenn Sie keine lokale Platte zum Swappen besitzen. Bei FreeBSD-Versionen vor 4.x ist Swapping über NFS langsam und ineffizient, aber erstaunlich schnell bei Versionen größer oder gleich 4.0. Dennoch wird es durch die verfügbare Bandbreite des Netzes begrenzt sein und belastet den NFS-Server zusätzlich.

Hier ist ein Beispiel für einen VN-Swap-Bereich von 64MB (/usr/swap0, Sie können natürlich jeden beliebigen Namen benutzen).

Stellen Sie sicher, daß Ihr Kernel mit der Zeile

    pseudo-device   vn 1   #Vnode driver (turns a file into a device)
             

in Ihrer Konfigurationsdatei erstellt worden ist. Der Standard-Kernel enthält sie bereits.

1. Erstellen Sie ein vn-Gerät

       # cd /dev
       # sh ./MAKEDEV vn0
                    
   

2. Erstellen Sie eine Swap-Datei (/usr/swap0)

       # dd if=/dev/zero of=/usr/swap0 bs=1024k count=64
                    
   

3. Setzen Sie geeignete Zugriffsrechte für (/usr/swap0)

       # chmod 0600 /usr/swap0
                    
   

4. Aktivieren Sie die Swapdatei in /etc/rc.conf

       swapfile="/usr/swap0"   # Set to name of swapfile if aux swapfile desired.
                    
   

5. Rebooten Sie die Maschine

Um die Swapdatei direkt zu aktivieren, geben Sie folgendes ein:

    # vnconfig -e /dev/vn0b /usr/swap0 swap
             

Bitte sehen Sie im Handbucheintrag über Drucker nach. Es sollte die meisten Ihrer Probleme behandeln. Lesen sie den Handbucheintrag über Drucker.

Einige Drucker benötigen einen auf dem Rechner laufenden Treiber, um drucken zu können. Diese sogenannten ``WinPrinter'' oder ``GDI-Drucker'' werden von FreeBSD nicht unterstützt und an diesem Zustand wird sich wohl auch nichts ändern. Wenn Ihr Drucker nicht unter DOS oder Windows NT 4.0 verwendet werden kann, handelt es sich um einen "WinPrinter" und wird in der Regel auch nicht unter FreeBSD funktionieren. Ihre einzige Chance, einen dieser Drucker nutzen können, ist der Port ports/print/pnm2ppa. Die Beschreibung enthält die Aussage:

Dieses programm nutzt zur Ausgabe das PPA (Printer Performance Architecture) Protokoll. Dieses Protokoll wird von einigen "nur-Windows"-Druckern von HP benutzt, zum Beispiel den Modellreihen HP Deskjet 820C, the HP DeskJet 720, and the HP DeskJet 1000.[...]

WWW: http://pnm2ppa.sourceforge.net/

Das Programm kbdcontrol bietet eine Option zum Laden einer Tastaturzuordnungsdatei. Unter /usr/share/syscons/keymaps befinden sich einige Tastaturzuordnungsdateien. Wählen Sie die zu Ihrem System passende aus und laden Sie sie:

    # kbdcontrol -l uk.iso
             

Die beiden Erweiterungen /usr/share/syscons/keymaps und .kbd werden von kbdcontrol(1) angenommen.

Dies kann in der Datei /etc/sysconfig (oder rc.conf(5)) eingestellt werden. Lesen Sie die entsprechenden Hinweise in dieser Datei.

Seit 2.0.5-RELEASE befindet sich alles, was mit Textfonts und Tastaturzuordnung zu tun hat, im Verzeichnis /usr/share/examples/syscons.

Die folgenden Zuordnungen werden derzeit unterstützt:

• Belgisch ISO-8859-1

• Brasilianische Tastatur 275 Codeseite 850

• Brasilianische Tastatur 275 ISO-8859-1

• Dänisch Codeseite 865

• Dänisch ISO-8859-1

• Französisch ISO-8859-1

• Deutsch Codeseite 850

• Deutsch ISO-8859-1

• Italienisch ISO-8859-1

• Japanisch 106

• Japanisch 106x

• Lateinamerikanisch

• Norwegisch ISO-8859-1

• Polnisch ISO-8859-2 (für Programmierer)

• Russisch Codeseite 866 (alternativ)

• Russisch koi8-r (shift)

• Russisch koi8-r

• Spanisch ISO-8859-1

• Schwedisch Codeseite 850

• Schwedisch ISO-8859-1

• Schweizer Deutsch ISO-8859-1

• Vereinigtes Königreich Codeseite 850

• Vereinigtes Königreich ISO-8859-1

• Vereinigte Staaten von Amerika ISO-8859-1

• Vereinigte Staaten von Amerika dvorak

• Vereinigte Staaten von Amerika dvorakx

Die nachfolgende Erklärung stammt aus einer Mail auf der Mailingliste freebsd-current.

• Benutzen Sie keine Quotas für /,

• Erstellen Sie die Quotas-Datei in dem Dateisystem, für das die Quotas gelten sollen, z.B.:

  Filesystem	Quota file
  /usr	/usr/admin/quotas
  /home	/home/admin/quotas
  ...	...

Das Symptom hierfür ist:

    # ccdconfig -C
    ccdconfig: ioctl (CCDIOCSET): /dev/ccd0c: Inappropriate file type or format
             

Das geschieht für gewöhnlich, wenn Sie versuchen, die Partitionen c, die standardmäß vom Typ unbenutzt sind, zu verbinden. Der ccd-Treiber verlangt Partitionen vom Typ FS_BSDFFS. Editieren Sie den Plattenlabel der Platten, die Sie zu verknüpfen versuchen und ändern Sie die Typen der Partitionen in 4.2BSD.

Das Symptom hierfür ist:

    # disklabel ccd0
    (hier wird etwas vernünftiges ausgegeben; versuchen wir nun, es zu editieren)
    # disklabel -e ccd0
    (editiern, speichern, beenden)
    disklabel: ioctl DIOCWDINFO: No disk label on disk;
    use "disklabel -r" to install initial label
             

Der Grund ist, daß der von ccd zurückgelieferte Plattenlabel ein ``vorgetäuschter'' ist, der sich nicht wirklich auf der Platte befindet. Sie können das Problem beheben, indem Sie ihn explizit zurückschreiben, wie z.B. hier:

    # disklabel ccd0 > /tmp/disklabel.tmp
    # disklabel -Rr ccd0 /tmp/disklabel.tmp
    # disklabel -e ccd0
    (nun wird es funktionieren)
             

Ja, FreeBSD unterstützt IPC im Stil von System V einschließlich gemeinsamen Speicher, Nachrichten und Semaphoren. Zur Aktivierung müssen Sie die folgenden Zeilen in Ihre Kernelkonfigurationsdatei einfügen:

    options    SYSVSHM
    options    SYSVSHM          # enable shared memory
    options    SYSVSEM          # enable for semaphores
    options    SYSVMSG          # enable for messaging
             

Kompilieren und installieren Sie einen neuen Kernel.

Die sendmail-Konfiguration, die mit FreeBSD ausgeliefert wird, ist für Sites geeignet, die direkt ans Internet angeschlossen sind. Sites, die ihre Mail per UUCP austauschen wollen, müssen eine andere sendmail-Konfigurationsdatei installieren.

Die manuelle Bearbeitung von /etc/sendmail.cf ist nur etwas für Puristen. Sendmail Version 8 bietet die neue Möglichkeit der Generierung von Konfigurationsdateien über eine Vorverarbeitung mit m4(1), wobei die tatsächliche, händische Konfiguration auf einer höheren Abstraktionsstufe stattfindet. Sie sollten die Konfigurationsdateien unter /usr/src/usr.sbin/sendmail/cf benutzen.

Für den Fall, daß Sie Ihr System nicht mit dem kompletten Quellcode installiert haben, wurden die nötigen Dateien zur Konfiguration von sendmail in einer separaten Quelldistribution für Sie extrahiert. Wenn Sie Ihre CD-ROM gemountet haben, müssen Sie die folgenden Schritte ausführen:

    # cd /cdrom/src
    # cat scontrib.?? | tar xzf - -C /usr/src contrib/sendmail
             

Keine Panik, das sind nur ein paar hundert Kilobyte. Die Datei README im Verzeichnis cf kann zur grundlegenden Einführung in die m4-Konfiguration dienen.

Zur Zustellung über UUCP sind Sie am besten damit beraten, das mailertable-Feature zu nutzen. Es stellt eine Datenbank dar, auf deren Basis sendmail Entscheidungen zum Routing treffen kann.

Zunächst müssen Sie Ihre .mc-Datei erstellen. Das Verzeichnis /usr/src/usr.sbin/sendmail/cf/cf ist die Basis für diese Dateien. Sehen Sie sich um, es gibt bereits einige Beispiele. Wenn Sie Ihre Datei foo.mc genannt haben, müssen Sie die folgenden Befehle ausführen, um sie in eine gültige sendmail.cf umzuwandeln, ist:

    # cd /usr/src/usr.sbin/sendmail/cf/cf
    # make foo.cf
    # cp foo.cf /etc/sendmail.cf
             

Eine typische .mc-Datei könnte so aussehen:

    include(`../m4/cf.m4')
    VERSIONID(`Your version number')
    OSTYPE(bsd4.4)
    
    FEATURE(nodns)
    FEATURE(nocanonify)
    FEATURE(mailertable)
    
    define(`UUCP_RELAY', your.uucp.relay)
    define(`UUCP_MAX_SIZE', 200000)
    
    MAILER(local)
    MAILER(smtp)
    MAILER(uucp)
    
    Cw    your.alias.host.name
    Cw    youruucpnodename.UUCP
             

Die Einstellungen nodns und nocanonify werden die Benutzung von DNS bei der Zustellung von Mails verhindern. Die Klausel UUCP_RELAY wird aus seltsamen Gründen benötigt - fragen Sie nicht, warum. Setzen Sie dort einfach den Namen eines Hosts ein, der in der Lage ist, Adressen mit der Pseudodomäne .UUCP zu behandeln; wahrscheinlich werden Sie dort den Relayhost Ihres ISP eintragen.

Wenn Sie soweit sind, müssen Sie die Datei /etc/mailertable erzeugen. Hierzu wieder ein typisches Beispiel:

    #
    # makemap hash /etc/mailertable.db < /etc/mailertable
    #
    horus.interface-business.de   uucp-dom:horus
    .interface-business.de        uucp-dom:if-bus
    interface-business.de         uucp-dom:if-bus
    .heep.sax.de                  smtp8:%1
    horus.UUCP                    uucp-dom:horus
    if-bus.UUCP                   uucp-dom:if-bus
    .                             uucp-dom:
             

Wie Sie sehen können, handelt es sich um einen Teil einer realen Datei. Die ersten drei Zeilen behandeln spezielle Fälle, in denen an Domänen adressierte Mails nicht über die Standard-Route versendet werden sollen, sondern zu einem UUCP-Nachbarn, um den Zustellweg ``abzukürzen''. Die nächsten Zeilen behandeln Mails Rechner in der Domain, die im lokalen Ethernetz verwendet wird. Diese Mails können direkt per SMTP zugestellt werden. Schließlich werden die UUCP-Nachbarn in der Notation mit der Pseudodomäne .UUCP aufgeführt, um die Standardregeln mit uucp-neighbour!recipient zu überschreiben. Die letzte Zeile besteht stets aus einem einzelnen Punkt, der als Ihr Universalgateway in die Welt dient. Alle Knoten hinter dem Schlüsselwort uucp-dom: müssen gültige UUCP-Nachbarn sein, was Sie mit dem Befehl uuname überprüfen können.

Als Erinnerung daran, daß diese Datei in eine DBM-Datenbankdatei konvertiert werden muß, bevor sie benutzt werden kann, sollte der Befehl hierzu als Kommentar am Anfang der mailertable plaziert werden. Sie müssen den Befehl jedesmal ausführen, wenn Sie Ihre Mailertable geändert haben.

Abschließender Hinweis: wenn Sie unsicher sind, ob bestimmte Mailrouten funktionieren, erinnern Sie sich an die Option -bt von sendmail. Sie startet sendmail im Adreß-Testmodus; geben Sie einfach 0, gefolgt von der Adresse, für die Sie das Routing testen möchten, ein. Die letzte Zeile nennt Ihnen den benutzten Mailagenten, den Zielhost, mit dem dieser Agent aufgerufen wird und die (ggfs. übersetzte) Adresse. Verlassen Sie diesen Modus, indem Sie Control-D eingeben.

    % sendmail -bt
    ADDRESS TEST MODE (ruleset 3 NOT automatically invoked)
    Enter <ruleset> <address>
    > 0 foo@interface-business.de
    rewrite: ruleset  0   input: foo @ interface-business . de
    ...
    rewrite: ruleset  0 returns: $# uucp-dom $@ if-bus $: foo \
    < @ interface-business . de >
    > ^D
             

Wenn Sie eine feste IP-Adresse haben, müssen Sie die Standardeinstellungen wahrscheinlich gar nicht ändern. Stellen Sie Ihren Hostnamen entsprechend Ihrem zugeordneten Internetnamen ein und sendmail übernimmt das übrige.

Wenn Sie eine dynamische IP-Adresse haben und eine ppp-Wählverbindung zum Internet benutzen, bekommen Sie wahrscheinlich eine Mailbox auf dem Mailserver Ihres ISPs zugeordnet. Lassen Sie uns annehmen, die Domäne ihres ISPs sei myISP.com und Ihr Benutzername user; außerdem nehmen wir an, daß Sie Ihre Maschine bsd.home genannt haben und, daß Ihr ISP ihnen gesagt hat, daß Sie relay.myISP.com als Mail-Relayhost benutzen können.

Um Mails aus Ihrer Mailbox abzuholen, müssen Sie einen entsprechenden Programm installieren. Fetchmail ist eine gute Wahl, weil es viele verschiedene Protokolle unterstützt. Für gewöhnlich wird von Ihrem ISP POP3 zur Verfügung gestellt werden. Falls sie sich dafür entschieden haben, user-ppp zu nutzen, können Sie durch folgenden Eintrag in der Datei /etc/ppp/ppp.linkup Ihre Mails automatisch abholen lassen, wenn eine Verbindung zum Netz aufgebaut wird:

    MYADDR:
            !bg su user -c fetchmail
             

Falls Sie (wie unten gezeigt) sendmail benutzen, um Mails an nicht-lokale Benutzer zu versenden, fügen Sie den Befehl

    !bg su user -c "sendmail -q"
             

nach dem oben gezeigten Eintrag ein. Das veranlaßt sendmail, Ihre ausgehenden Mails zu verarbeiten, sobald eine Verbindung zum Internet aufgebaut wird.

Ich nehme an, daß auf bsd.home ein Benutzer user existiert; erstellen Sie auf bsd.home im Heimatverzeichnis von user eine Datei .fetchmailrc:

    poll myISP.com protocol pop3 fetchall pass MySecret;
             

Ich brauche wohl nicht zu erwähnen, daß diese Datei für niemandem außer user lesbar sein sollte, weil sie das Passwort MySecret enthält.

Um Mails mit dem richtigen from:-Header zu versenden, müssen Sie sendmail mitteilen, daß es user@myISP.com und nicht user@bsd.home benutzen soll. Evtl. möchten Sie auch, daß sendmail alle Mails über relay.myISP.com versendet, um eine schnellere Übertragung von Mails zu gewährleisten.

Die folgende .mc-Datei sollte ausreichen:

    VERSIONID(`bsd.home.mc version 1.0')
    OSTYPE(bsd4.4)dnl
    FEATURE(nouucp)dnl
    MAILER(local)dnl
    MAILER(smtp)dnl
    Cwlocalhost
    Cwbsd.home
    MASQUERADE_AS(`myISP.com')dnl
    FEATURE(allmasquerade)dnl
    FEATURE(masquerade_envelope)dnl
    FEATURE(nocanonify)dnl
    FEATURE(nodns)dnl
    define(`SMART_HOST', `relay.myISP.com')
    Dmbsd.home
    define(`confDOMAIN_NAME',`bsd.home')dnl
    define(`confDELIVERY_MODE',`deferred')dnl
             

Im vorherigen Abschnitt finden Sie Details dazu, wie Sie aus dieser .mc-Datei eine Datei sendmail.cf erstellen können. Vergessen Sie auch nicht, sendmail neu zu starten, nachdem Sie sendmail.cf verändert haben.

Keine Panik. toor ist ein ``alternativer'' Account für den Super-User (wenn man root rückwärts schreibt, erhält man toor). Früher wurde er nur erzeugt, wenn die Shell bash(1) installiert wurde, heute wird er auf jeden Fall erzeugt. Dieser Account ist für die Verwendung mit einer alternativen Shell vorgesehen; damit ist es nicht mehr erforderlich, die Shell von root zu ändern. Dies ist wichtig, wenn eine Shell verwendet wird, die nicht zum Lieferumfang von FreeBSD gehört, zum Beispiel aus einem Port oder einem Package. Diese Shells werden in der Regel in /usr/local/bin installiert und dieses Verzeichnis liegt standardmäßig auf einem anderem Filesystem. Wenn die Shell von root in /usr/local/bin liegt und /usr (oder das Filesystem, auf dem /usr/local/bin liegt) nicht gemountet werden kann, kann sich root nicht mehr einloggen, um das Problem zu beheben. Es ist allerdings möglich, das System zu rebooten und das Problem im Single-User Modus zu lösen, da man hier gefragt wird, welche Shell benutzt werden soll.

Einige Anwender benutzen toor mit einer alternativen Shell für die tägliche Arbeit und nutzen root (mit der Standard-Shell) für den Single-User Modus und für Notfälle. Standardmäßig kann man sich nicht als toor anmelden, da der Account kein gültiges Paßwort hat; Sie müssen sich also als root anmelden und ein Paßwort für toor setzen, wenn Sie diesen Account benutzen wollen.

Keine Panik! Starten Sie Ihr System einfach neu und geben Sie boot -s an der Eingabeaufforderung Boot: ein (bei FreeBSD-Versionen vor 3.2 nur -s), um in den Einzelbenutzermodus zu gelangen. Bei der Frage danach, welche Shell benutzt werden soll, drücken Sie einfach ENTER. Nun erscheint die Eingabeaufforderung #. Geben Sie mount -u / ein, um Ihr Root-Dateisystem für Lese- und Schreibzugriffe zu remounten und dann mount -a, um alle Dateisysteme zu remounten. Mit passwd root können Sie das Rootpasswort ändern und mit exit können Sie mit dem Booten fortfahren.

Falls Sie syscons (den Standard-Treiber für die Konsole) unter FreeBSD ab 2.2.7-RELEASE benutzen, erstellen und installieren Sie einen neuen Kernel mit der Zeile

    options SC_DISABLE_REBOOT

in der Konfigurationsdatei. Falls Sie den Konsolen-Treiber PCVT unter FreeBSD seit 2.2.5-RELEASE benutzen, benutzen Sie stattdessen die folgende Kernelkonfigurationszeile:

    options PCVT_CTRL_ALT_DEL

Editieren Sie bei älteren Versionen von FreeBSD die Tastenzuordnungsdatei, die Sie für die Konsole verwenden und ersetzen Sie die Schlüsselworte boot durch nop. Die standard Tastenzuordnungsdatei heißt /usr/share/syscons/keymaps/us.iso.kbd. Es könnte sein, daß Sie /etc/rc.conf explizit instruieren müssen, diese Tastenzuordnungsdatei zu laden, um die Änderungen wirksam werden zu lassen. Falls Sie eine andere Tastenzuordnung für Ihr Land verwenden, müssen Sie natürlich diese editieren.

Benutzen Sie einfach diesen Perl-Befehl:

    % perl -i.bak -npe 's/\r\n/\n/g' file ...
             

file ist/sind die zu verarbeitende(n) Datei(en). Die Änderungen erfolgen in der Originaldatei, die zuvor mit der Erweiterung .bak gesichert wird.

Alternativ können Sie den Befehl tr(1) benutzen:

    % tr -d '\r' < dos-text-file > unix-file
             

dos-text-file ist die Datei, die den Text im DOS-Format enthält und unix-file wird die konvertierte Ausgabe enthalten. Diese Möglichkeit könnte etwas schneller sein, als die Benutzung von Perl.

Benutzen Sie killall(1).

Der Fehler stammt vom verteilten Authentifizierungssystem Kerberos. Das Problem ist nicht ernsthaft, aber störend. Sie können entweder su mit der Option -K benutzen, oder Kerberos deinstallieren, wie in der nächsten Frage beschrieben.

Um Kerberos aus dem System zu entfernen, müssen Sie die bin-Distribution der von Ihnen benutzen RELEASE neu installieren. Wenn Sie die CDROM besitzen, können Sie sie mounten (wir nehmen an, unter /cdrom) und folgende Schritte ausführen:

    # cd /cdrom/bin
    # ./install.sh
             

Alternativ können Sie alle Zeilen mit "MAKE_KERBEROS" aus der /etc/make.conf entfernen und dann ein make world durchführen.

Wenn Sie viele Benutzer von telnet, ssh, X oder screens haben, könnte es sein, daß Ihnen die Pseudo-Terminals ausgehen. So fügen Sie weitere hinzu:

Es gibt kein Gerät snd. Diese Bezeichnung ist nur ein Sammelbegriff für die diversen Geräte, die zusammen das Soundsystem von FreeBSD bilden, wie zum Beispiel mixer, sequencer, und dsp.

So erzeugen Sie diese Geräte:

    # cd /dev
    # sh MAKEDEV snd0
             

Gehen Sie in den Einzelbenutzermodus und dann zurück in den Mehrbenutzermodus.

Geben Sie auf der Konsole folgendes ein:

    # shutdown now
    (Hinweis: ohne -r oder -h)
    # return
    # exit
             

``Sandkasten'' (sandbox) ist ein Ausdruck aus dem Bereich Sicherheit. Er hat zwei Bedeutungen:

• Ein Programm, das innerhalb virtueller Wände ausgeführt wird. Wenn ein Angreifer über eine Sicherheitslücke in diesen Programm einbricht, verhindern diese Wände ein tieferes Vordringen in das System.

  Man sagt: Der Prozeß kann innerhalb der Wände ``spielen'', d.h. nichts, was der Prozeß in Bezug auf die Ausführung von Code tut, kann die Wände durchbrechen. Es ist also keine detailierte Revision des Codes erforderlich, um gewisse Aussagen über seine Sicherheit machen zu können.

  Die Wände könnten z.B. eine Benutzerkennung sein. Dies ist die Definition, die in den Manualpages security und named benutzt wird.

  Nehmen Sie zum Beispiel den Dienst ntalk (siehe auch /etc/inetd.conf). Dieser Dienst ist früher mit der Benutzerkennung root gelaufen; nun läuft er mit der Benutzerkennung tty. Der Benutzer tty ist ein Sandkasten, der dazu gedacht ist, es jemandem, der über ntalk erfolgreich in das System eingebrochen ist, schwer zu machen, über diese Benutzerkennung hinaus vorzudringen.

• Ein Prozeß, der sich innerhalb einer simulierten Maschine befindet. Dies ist etwas fortgeschrittener; grundsätzlich bedeutet es, daß jemand, der in der Lage ist, in einen Prozeß einzudringen, annehmen könnte, er könnte weiter in die Maschine eindringen, tatsächlich aber nur in eine Simulation der Maschine einbricht und keine echten Daten verändert.

  Der gängigste Weg, dies zu erreichen, ist, in einem Unterverzeichnis eine simulierte Umgebung zu erstellen und den Prozeß in diesem Verzeichnis mit chroot auszuführen (d.h. für diesen Prozeß ist / dieses Verzeichnis und nicht das echte / des Systems).

  Eine weitere gebräuchliche Anwendung ist, ein untergeordnetes Dateisystem nur mit Leserechten zu mounten, und dann darüber eine Dateisystemebene zu erstellen, die einem Prozeß einen scheinbar schreibberechtigten Blick in das Dateisystem gibt. Der Prozeß mag glauben, daß er in der Lage ist, diese Dateien zu verändern, aber nur der Prozeß sieht diesen Effekt - andere Prozeß im System natürlich nicht.

  Es wird versucht, diese Art von Sandkasten so transparent zu gestalten, daß der Benutzer (oder Hacker) nicht realisiert, daß er sich in ihm befindet.

UNIX implementiert zwei Arten von Sandkästen - eine auf Prozeßebene und die andere auf der Ebene der Benutzerkennung.

Jeder UNIX-Prozeß ist vollständig von jedem anderen UNIX-Prozeß abgeschirmt. Ein Prozeß kann den Adreßraum eines anderen Prozesses nicht modifizieren. Das ist anders als bei Windows, wo ein Prozeß leicht den Adreßraum eines anderen überschreiben kann, was zu einem Absturz führt.

Ein UNIX-Prozeß gehört einer bestimmten Benutzerkennung. Falls die Benutzerkennung nicht die von root ist, dient sie dazu, den Prozeß von Prozessen anderer Benutzer abzuschirmen. Die Benutzerkennung wird außerdem dazu genutzt, Daten auf der Festplatte abzuschirmen.

Die Sicherheitsstufen sind ein Sicherheitsmechanismus, der im Kernel angesiedelt ist. Wenn die Sicherheitsstufe einen positiven Wert hat, verhindert der Kernel die Ausführung bestimmter Tätigkeiten; nicht einmal der Super-User (also root) darf sie durchführen. Zur Zeit können über die Sicherheitsstufen unter anderem die folgenden Tötigkeiten geblockt werden:

• Änderungen bestimmter Dateiattribute, wie zum Beispiel schg (das "system immutable" Attribut)

• Schreibender Zugriff auf die Speicherbereiche des Kernels mittels /dev/mem und /dev/kmem.

• Laden von Kernel-Modulen.

• Änderungen an den Firewall-Regeln.

Um die eingestellte Sicherheitstufe eines aktiven Systems abzufragen, reicht das folgende einfache Kommando:

    # sysctl kern.securelevel

Die Ausgaben wird den Namen der sysctl(8)-Variablen (in diesem Fall kern.securelevel) und eine Zahl enthalten. Die Zahl ist der aktuelle Wert der Sicherheitsstufe. Wenn die Zahl positiv (größer als Null) ist, sind zumindestens einige der Schutzmaßnahmen aktiviert.

Sie können die Sicherheitsstufe eines laufenden Systems nicht verringern, da dies den Mechanismus wertlos machen würden. Wenn Sie eine Tätigkeit ausführen müssen, bei der die Sicherheitsstufe nicht-positiv sein muß (z.B. ein installworld oder eine Änderung der Systemzeit), dann müssen Sie die entsprechende Einstellung in /etc/rc.conf ändern (suchen Sie nach den Variablen kern_securelevel und kern_securelevel_enable) und das System rebooten.

Weitere Informationen über die Sicherheitstufen und genaue Informationen, was die Einstellungen bewirken, können Sie der Online-Hilfe init(8) entnehmen.

Normale Benutzer können dazu berechtigt werden, Geräte zu mounten. Das geht so:

Alle Benutzer können nun /dev/fd0 auf ein Verzeichnis, das ihnen gehört, mounten:

    % mkdir ~/my-mount-point
    % mount -t msdos /dev/fd0 ~/my-mount-point
             

Die zur Gruppe operator gehörenden Benutzer können nun /dev/cd0c auf ein Verzeichnis, das ihnen gehört, mounten:

    % mkdir ~/my-mount-point
    % mount -t msdos /dev/cd0c ~/my-mount-point
             

Das Unmounten des Gerätes ist simpel:

    % umount ~/my-mount-point
             

Die Aktivierung von vfs.usermount hat jedoch negative Auswirkungen auf Sicherheitsaspekte. Ein besserer Weg, um auf MSDOS-formatierte Datenträger zuzugreifen, ist die Benutzung des Packages mtools aus der Ports-Sammlung.

Die beste Methode ist, das Betriebssystem auf der neuen Platte neu zu installieren und danach die Daten zu verschieben. Wenn Sie -stable über eine Release hinaus genutzt haben oder eine Release aktualiert haben, ist das sehr empfehlenwert. Sie können auf beiden Platten boot0cfg(8) installieren und die beiden Versionen so lange parallel betreiben, bis Ihnen die neue Konfiguation gefällt. Wenn Sie dies tun wollen, können Sie im übernächsten Absatz erfahren, wie sie Ihre Daten verschieben können.

Falls Sie sich entscheiden, das nicht zu tun, müssen Sie Ihre neue Platte partitionieren und labeln. Benutzen Sie dafür entweder /stand/sysinstall oder fdisk(8) und disklabel(8). Weiterhin sollten Sie mit boot0cfg(8) auf beiden Platten booteasy installieren, damit Sie in der Lage sind, das alte und das neue System abwechselnd zu starten, nachdem der Kopiervorgang abgeschlossen ist. Im Formatting-Media Tutorial finden Sie weitere Informationen zu diesen Schritten.

Nachdem Sie die neue Platte eingerichtet haben, können Sie Ihre Daten verschieben. Dummerweise können Sie die Daten nicht einfach. Dinge wie die Gerätedateien (in /dev) und Symbolische Links führen dazu, daß das in die Hose geht. Sie mützen Programme benutzen, die damit umgehen können, und das sind dump(8) and tar(1). Es wird empfohlen, die Daten im single user mode zu verschieben, aber das ist nicht unbedingt notwendig.

Sie sollten auf gar keinen Fall etwas anderes als dump(8) und restore(8) benutzen, um Ihr root file system zu verschieben. Es könnte auch mit tar(1) funktionieren - oder auch nicht. Sie sollten ebenfalls dump(8) und restore(8) benutzen, wenn Sie eine komplette Partition auf eine andere, leere Partition verschieben. Um die Daten einer Partition mit dump auf eine andere Partition zu verschieben, müssen Sie die folgenden Schritte ausführen:

Wenn Sie zum Beispiel root auf /dev/ad1s1a verschieben wollen und diese zur Zeit auf /mnt gemountet ist, bedeutet das:

     # newfs /dev/ad1s1a
     # mount /dev/ad1s1a
     # cd /mnt
     # dump 0uaf - / | restore xf -
             

Wenn Sie Ihre Partitionen umorganisieren wollen, also zum Beispiel aus eine alte in zwei neue aufteilen wollen oder zwei alte zu einer neuen zusammenfassen wollen, dann wird es frührer oder später vorkommen, daß Sie nur einen Verzeichnisbaum verschieben wollen. Da dump(8) nur ganze Dateisysteme bearbeitet, können Sie es dafür nicht nutzen. Hier sollten Sie tar(1) verwenden. Um mit tar(1) /old nach /new zu verschieben, müssen Sie diesen Befehl eingeben:

    # (cd /old; tar cf - .) | (cd /new; tar xpf -)
             

Wenn unter /old andere Dateisysteme gemountet sind und Sie weder die Daten auf diesen Dateisystem verschieben noch die anderen Dateisysteme unmounten wollen, müssen das erste tar(1) mit dem Parameter l aufrufen:

    # (cd /old; tar clf - .) | (cd /new; tar xpf -).
             

Eventuell gefallen Ihnen cpio(1), pax(1) oder cpdup (ports/sysutils/cpdup) besser als tar(1).

Kurze Antwort: Das ist nur ein anderer Name. RC ist die Abkürzung für ``Release Candidate''. Es bedeutet, daß eine neue Release bevorsteht. Und -BETA bedeutet bei FreeBSD normalerweise, daß die Sourcen zur Vorbereitung auf eine Release ``eingefroren'' wurden.

Ausführliche Antwort: Bei FreeBSD gibt es zwei Quellen für Releases. Die Major Releases wie 3.0-RELEASE und 4.0-RELEASE werden aus dem aktuellen Stand des Hauptzweiges der Entwicklung (besser und kürzer als -CURRENT bekannt) erzeugt. Minor Releases wie 3.1-RELEASE or 4.2-RELEASE stammen aus dem aktiven -STABLE Zweig. Seit 4.3-RELEASE gibt es es nun auch einen eigenen Zweig für jede Release, der für die Leute gedacht ist, die ein sehr konservativ weiterentwickeltes System benötigen (im Normalfall also nur Updates aus dem Bereich Sicherheit).

Bevor in einem Zweig eine Release erfolgt, muß in diesem Zweig ein bestimmter Prozeß ablaufen. Ein Teil dieses Prozesses ist der ``code freeze'', der Stop der Weiterentwicklung. Sobald dieser Schritt erfolgt ist, wird der Name des Zweiges geändert, um anzuzeigen, daß demnächst eine Release erfolgen wird. Wenn der Zweig zum Beispiel 4.0-STABLE genannt wurde, wird der Name in 4.1-BETA geändert, um dies zu verdeutlichen. Weiterhin ist das ein Zeichen, daß jetzt besonders intensiv getestet werden sollte. In dieser Phase können Fehler im Sourcecode noch korrigiert werden. Wenn der Sourcecode so weit ``gereift'' ist, daß eine Release erstellt werden kann, wird der Name in 4.1-RC geändert, um genau dies anzuzeigen. In dieser Phase können nur noch extrem wichtige Korrekturen aufgenommen werden. Sobald die Release (in diesem Beispiel 4.1-RELEASE) erfolgt ist, wird der Zweig in 4.1-STABLE umbenannt.

Kurze Antwort: Ihre Sicherheitseinstellung (der securelevel) ist wahrscheinlich größer als 0. Sie müssen das System neu starten und den Kernel im Single-User Modus installierten.

Ausführliche Antwort: Wenn die Sicherheitseinstellung größer als 0 ist, erlaubt Ihnen FreeBSD nicht, die Systemflags zu ändern. Um den aktuellen Securelevel zu ermitteln, können Sie das folgende Kommando benutzen:

    # sysctl kern.securelevel

Sie können die Sicherheitseinstellung nicht verringern, Sie müssen das System neu starten und den Kernel im Single-User Mode installieren oder die Sicherheitseinstellung in /etc/rc.conf ändern und dann das System neu starten. Weitere Detail zur Sicherheitseinstellung erhalten Sie in init(8), weitere Informationen zur rc.conf erhalten Sie in /etc/defaults/rc.conf und rc.conf(5).

Kurze Antwort: Ihre Sicherheitseinstellung (der securelevel) ist wahrscheinlich größer als 1. Sie müssen das System neu starten und die Systemzeit im Single-User Modus verstellen.

Ausführliche Antwort: Wenn die Sicherheitseinstellung größer als 1 ist, erlaubt Ihnen FreeBSD nicht, die Systemzeit zu ändern. Um den aktuellen Securelevel zu ermitteln, können Sie das folgende Kommando benutzen:

    # sysctl kern.securelevel

Sie können die Sicherheitseinstellung nicht verringern, Sie müssen das System neu starten und die Systemzeit im Single-User Mode ändern oder die Sicherheitseinstellung in /etc/rc.conf ändern und dann das System neu starten. Weitere Detail zur Sicherheitseinstellung erhalten Sie in init(8), weitere Informationen zur rc.conf erhalten Sie in /etc/defaults/rc.conf und rc.conf(5).

Nein, das Programm hat keinen Fehler und es verbraucht auch nicht 256 MByte Speicher. Das Programm hat nur eine Vorliebe dafür, einen übertrieben großen Speicherbereich in seinen eigenen Adreßraum zu projizieren. Von einem rein technischen Standpunkt aus ist das nichts verwerfliches, allerdings verwirrt es Programme wie top(1) und ps(1).

rpc.statd(8) projiziert seine Statusdatei (die in /var liegt) in seinen Adreßraum. Um die Probleme zu vermeiden, die bei einer Verößerung dieser Projektion entstehen könnte, wird gleich ein mölichst großer Speicherbereich benutzt. Dies kann man sehr schön im Sourcecode sehen: Die Längenangabe beim Aufruf von mmap(2) ist 0x10000000, ein sechzehntel des Adreßraums bei IA32, oder genau 256 MByte.

Sie betreiben Ihr System mit einer erhöhten Sicherheitsstufe. Senken Sie die Sicherheitsstufe und versuchen Sie es dann noch einmal. Weitere Informationen erhalten Sie im FAQ Eintrag über Sicherheitsstufe und in der Online-Hilfe init(8).

Der einfachste Weg ist der, daß Sie während der Installation angeben, daß Sie X benutzen möchten.

Lesen Sie dann die Dokumentation zum Tool xf86config, das Sie bei der Konfiguration von XFree86(tm) speziell für Ihre Grafikkarte/Maus/etc. unterstützt.

Evtl. möchten Sie sich auch den Xaccel-Server ansehen. Nähere Details finden Sie in den Abschnitten über Xi Graphics oder Metro Link.

Sie haben die Sicherheitsstufe (den securelevel) ihres Systems erhört, richtig? Es ist tatsächlich nicht möglich, X zu starten, wenn die Sicherheitsstufe erhöht wurde. Warum das so ist, können Sie in init(8) nachlesen.

Die Frage ist also eigentlich, was Sie anders machen sollten. Sie haben zwei Möglichkeiten: Setzen Sie die Sicherheitstufe wieder zurück auf 0 (die Einstellung erfolgt in der Regel in /etc/rc.conf) oder starten Sie xdm(1) während des Starts des Systems, bevor die Sicherheitsstufe erhöht wird.

Der Abschnitt F: 8.8. enthält Informationen darüber, wie Sie xdm(1) beim Start des Systems starten können.

Wenn Sie syscons (den Standard-Konsoltreiber) benutzen, können Sie FreeBSD so konfigurieren, daß auf jedem virtuellen Bildschirm ein Mauszeiger unterstützt wird. Um Konflikte mit X zu vermeiden, unterstützt syscons ein virtuelles Gerät mit dem Namen /dev/sysmouse. Über dieses virtuelle Gerät können andere Programme alle Mausbewegungen und Mausclicks im MouseSystems-Format mitlesen. Falls Sie Ihre Maus auf einer oder mehreren virtuellen Konsolen und X benutzen wollen, sollten Sie zunächst F: 2.11. lesen und dann moused installieren.

Die Datei /etc/XF86Config sollte die folgenden Einträge enthalten:

    Section        Pointer
    Protocol       "SysMouse"
    Device         "/dev/sysmouse"
    .....
             

Diese Variante kann für XFree86 3.3.2 und neuere Versionen benutzt werden. Wenn Sie eine ältere Versionen verwenden, muß als Protocol dagegen MouseSystems benutzt werden.

Einige Leute ziehen es vor, unter X /dev/mouse zu benutzen. Hierzu sollte /dev/mouse nach /dev/sysmouse gelinkt werden:

    # cd /dev
    # rm -f mouse
    # ln -s sysmouse mouse
             

Ja. Allerdings müssen Sie die X-Anwendungen anpassen. Weitere Informationen erhalten Sie auf der Homepage von Colas Nahaboo (http://www.inria.fr/koala/colas/mouse-wheel-scroll/).

Wenn Sie das Programm imwheel benutzen wollen, müssen Sie folgenden Arbeiten durchführen.

1. Umsetzung der Rad-Bewegung

   Das Programm imwheel übersetzt die Maustasten 4 und 5 in normale Tastaturkommandos. Sie müssen also nur dafür sorgen, daß die Bewegung des Rades vom Maustreiber als Betätigung der Maustaten 4 und 5 übersetzt werden. Es gibt zwei Möglichkeiten, dieses Ziel zu erreichen. Zum einen kann die Übersetzung von moused(8) durchgeführt werden, zum zweiten kann der X-Server diese Aufgabe übernehmen.

   1. Umsetzung durch moused(8)

      Damit moused(8) die Umsetzung vornimmt, müssen Sie ihn lediglich mit dem zusätzlichen Parametern -z 4 starten. Wenn Sie zum Beispiel moused(8) mit dem Befehl moused -p /dev/psm0 gestartet haben, würde der neue Befehl moused -p /dev/psm0 -z 4 lauten. Wenn Sie moused(8) über einen Eintrag in der Datei /etc/rc.conf automatisch beim Start des Systems starten lassen, müssen Sie in der /etc/rc.conflediglich die Einstellung moused_flags um -z 4 ergänzen.

      Nun müssen Sie X darüber informieren, daß Sie eine Maus mit 5 Tasten haben. Fügen sie dazu die Zeile Buttons 5 in den Abschnitt ``Pointer'' der Datei /etc/XF86Config ein. Das Beispiel zeigt, wie ein solcher Abschnitt aussehen könnte.

      Beispiel 8-1. Abschnitt ``Pointer'' für XFree86 3.3.x für Mäuse mit Rad und Umsetzung durch moused

          Section "Pointer"
             Protocol        "SysMouse"
             Device          "/dev/sysmouse"
             Buttons         5
          EndSection
                             
      

      Beispiel 8-2. Abschnitt ``InputDevice'' für Rad-Mäuse in der XF86Config von XFree86 4.X mit automatischer Protokollerkennung und Übersetzung der Maustasten

          Section "InputDevice"
             Identifier      "Mouse1"
             Driver          "mouse"
             Option          "Protocol" "auto"
             Option          "Device" "/dev/psm0"
             Option          "Buttons" "5"
             Option          "ZAxisMapping" "4 5"
          EndSection
                             
      

      Beispiel 8-3. ``.emacs'' Konfiguration für seitenweises Blättern mit einer Rad-Maus

          ;; wheel mouse
          (global-set-key [mouse-4] 'scroll-down)
          (global-set-key [mouse-5] 'scroll-up)
                             
      

   2. Umsetzung durch den X-Server

      Wenn Sie moused(8) nicht benutzen oder die Umsetzung nicht von moused(8) vornehmen lassen wollen, kann diese Aufgabe auch vom X-Server übernommen werden. Dazu sind einige Änderungen an der Datei /etc/XF86Config notwendig. Zunächst müssen Sie das von Ihrer Maus verwendete Protokoll herausfinden. Die meisten Radmäuse verwenden das ``IntelliMouse'' Protokoll. XFree86 unterstützt allerdings auch andere Protokolle, zum Beispiel das von der Logitech Mouseman+ verwendete ``MouseManPlusPS/2''. Wenn Sie das Protokoll ermittelt haben, müssen Sie eine entsprechende Protocol-Zeile in den Abschnitt ``Pointer'' aufnehmen.

      Zum zweiten müssen Sie dem X-Server mitteilen, daß er die Bewegung des Rades in Betätigungen der Tasten 4 und 5 umsetzen soll. Dazu dient die Option ZAxisMapping.

      Wenn Sie zum Beispiel moused(8) nicht verwenden und eine IntelliMouse an den PS/2 Mausport angeschlossen haben, müßte in Ihrer /etc/XF86Config die folgenden Angaben stehen.

      Beispiel 8-4. Abschnitt ``Pointer'' der Datei XF86Config für eine Rad-Maus und Umsetzung durch den X-Server

          Section "Pointer"
             Protocol        "IntelliMouse"
             Device          "/dev/psm0"
             ZAxisMapping    4 5
          EndSection
                             
      

2. Installation von imwheel

   Der nächste Schritt ist die Installation von imwheel über die Ports. Das Programm ist ein Teil der Kategorie x11. imwheel übersetzt die Bewegungen des Rades in Tastendrücken. Es könnte zum Beispiel Bild auf an ein Programm senden, wenn Sie das Rad nach vorne bewegen. Imwheel benutzt eine Konfigurationsdatei, die den Bewegungen des Rades die zu simulierenden Tastendrücke zuordnet. Damit ist es möglich, verschiedenen Anwendungen die jeweils "richtigen" Tastendrücke zu senden. Ein Prototyp der Konfigurationsdatei für imwheel wird unter dem Namen /usr/X11R6/etc/imwheelrc installiert. Wenn Sie die Konfiguration von imwheel an die von Ihnen verwendeten Programme anpassen wollen, erzeugen Sie eine Kopie der Datei mit dem Namen ~/.imwheelrc und tragen Sie ihre Anpassungen dort ein. Das Format der Datei wird in imwheel(1) erklärt.

3. Anpassung von Emacs an with Imwheel (Optional)

   Wenn Sie emacs oder Xemacs benutzen, müssen Sie einen kleinen Abschnitt in die Datei ~/.emacs einfügen. Für emacs müssen Sie die folgenden Zeilen anfügen:

   Beispiel 8-5. Nutzung von Emacs mit Imwheel

       ;;; For imwheel
       (setq imwheel-scroll-interval 3)
       (defun imwheel-scroll-down-some-lines ()
         (interactive)
         (scroll-down imwheel-scroll-interval))
       (defun imwheel-scroll-up-some-lines ()
         (interactive)
         (scroll-up imwheel-scroll-interval))
       (global-set-key [?\M-\C-\)] 'imwheel-scroll-up-some-lines)
       (global-set-key [?\M-\C-\(] 'imwheel-scroll-down-some-lines)
       ;;; end imwheel section
                      
   

   Wenn Sie Xemacs verwenden, müssen stattdessen die folgenden Zeilen an Ihre ~/.emacs anfügen:

   Beispiel 8-6. Nutzung von Xemacs mit Imwheel

       ;;; For imwheel
       (setq imwheel-scroll-interval 3)
       (defun imwheel-scroll-down-some-lines ()
         (interactive)
         (scroll-down imwheel-scroll-interval))
       (defun imwheel-scroll-up-some-lines ()
         (interactive)
         (scroll-up imwheel-scroll-interval))
       (define-key global-map [(control meta \))] 'imwheel-scroll-up-some-lines)
       (define-key global-map [(control meta \()] 'imwheel-scroll-down-some-lines)
       ;;; end imwheel section
                      
   

4. Imwheel ausführen

   Sie brauchen nach der Installation einfach nur imwheel in einem xterm einzugben, um das Programm zu starten. Das Programm läuft dann im Hintergrund und ist sofort aktiv. Wenn Sie imwheel ständig benutzen wollen, sollten Sie es einfach in Ihre .xinitrc oder .xsession eintragen. Falls imwheel Warnungen über ``PID files'' ausgeben sollte, können Sie diese ignorieren, da Sie nur die Linux-Version von imwheel betreffen.

Versuchen Sie, die Num-Lock-Taste auszustellen.

Falls Ihre Num-Lock-Taste beim Booten standardmäßig eingeschaltet ist, sollten Sie die folgende Zeile in den Abschnitt Keyboard der Datei XF86Config einfügen:

    # Let the server do the NumLock processing.  This should only be
    # required when using pre-R6 clients
        ServerNumLock
             

Mit virtuellen Konsolen können Sie mehrere simultane Sitzungen auf einer Maschine laufen lassen, ohne so komplizierte Dinge wie die Einrichtung eines Netzwerkes oder die Benutzung von X zu benötigen.

Wenn das System startet, wird es nach der Anzeige aller Bootmeldungen eine Eingabeaufforderung auf dem Bildschirm anzeigen. Sie können dann auf der ersten virtuellen Konsole Ihren Benutzernamen und das Passwort eingeben und anfangen, zu arbeiten (oder zu spielen!).

Gelegentlich möchten Sie möglicherweise eine weitere Sitzung starten wollen, vielleicht, um die Dokumentation zu einem Programm, das Sie gerade benutzen, einzusehen, oder, um Ihre Mails zu lesen, während Sie auf das Ende einer FTP-Übertragung warten. Drücken Sie einfach Alt-F2 (halten Sie die Alt-Taste gedrückt und drücken Sie die Taste F2) und Sie gelangen zur Anmelde-Aufforderung auf der zweiten ``virtuellen Konsole''! Wenn Sie zurück zur ersten Sitzung möchten, drücken Sie Alt-F1.

Die standard Installation von FreeBSD bietet drei aktivierte virtuelle Konsolen (acht ab der Version 3.3) und Alt-F1, Alt-F2 und Alt-F3 wechseln zwischen diesen virtuellen Konsolen.

Um mehr von ihnen zu aktivieren, editieren Sie /etc/ttys und fügen Einträge für ttyv4 bis zu ttyvc nach dem Kommentar zu ``virtuellen Terminals'' ein:

    # Edit the existing entry for ttyv3 in /etc/ttys and change
    # "off" to "on".
    ttyv3   "/usr/libexec/getty Pc"         cons25  on secure
    ttyv4   "/usr/libexec/getty Pc"         cons25  on secure
    ttyv5   "/usr/libexec/getty Pc"         cons25  on secure
    ttyv6   "/usr/libexec/getty Pc"         cons25  on secure
    ttyv7   "/usr/libexec/getty Pc"         cons25  on secure
    ttyv8   "/usr/libexec/getty Pc"         cons25  on secure
    ttyv9   "/usr/libexec/getty Pc"         cons25  on secure
    ttyva   "/usr/libexec/getty Pc"         cons25  on secure
    ttyvb   "/usr/libexec/getty Pc"         cons25  on secure
             

Benutzen Sie so wenig oder soviele, wie Sie möchten. Je mehr virtuelle Terminals Sie benutzen, desto mehr Ressourcen werden gebraucht; das kann wichtig sein, wenn Sie 8MB RAM oder weniger besitzen. Sie können auch secure in insecure ändern.

Der einfachste Weg, eine Konsole zu deaktivieren, ist, sie auszuschalten. Wenn Sie zum Beispiel die oben erwähnte volle Zuordnung aller 12 Terminals hätten, müßten Sie die Einstellung für das virtuelle Terminal 12 von:

    ttyvb   "/usr/libexec/getty Pc"         cons25  on secure
             

in:

    ttyvb   "/usr/libexec/getty Pc"         cons25  off secure
             

ändern.

Wenn Ihre Tastatur nur über zehn Funktionstasten verfügt, bedeutet das:

    ttyv9   "/usr/libexec/getty Pc"         cons25  off secure
    ttyva   "/usr/libexec/getty Pc"         cons25  off secure
    ttyvb   "/usr/libexec/getty Pc"         cons25  off secure
             

(Sie können diese Zeilen auch einfach löschen.)

Nachdem Sie die Datei /etc/ttys geändert haben, besteht der nächste Schritt darin, sicherzustellen, daß Sie genügend Geräte für virtuelle Terminal haben. Der einfachste Weg, dies zu tun, ist:

    # cd /dev
    # ./MAKEDEV vty12
             

Die einfachste (und sauberste) Möglichkeit, die virtuellen Konsolen zu aktivieren, ist, zu rebooten. Wenn Sie jedoch auf keinen Fall rebooten möchten, können Sie auch einfach das X Window System herunterfahren und als root

    # kill -HUP 1
             

ausführen.

Es ist unbedingt erforderlich, daß Sie das X Window System vollständig herunterfahren, falls es läuft. Falls Sie es nicht tun, könnte es sein, daß sich ihr System nach der Eingabe des kill-Befehls aufhängt.

Benutzen Sie Ctrl+Alt+Fn um auf eine virtuelle Konsole umzuschalten. Mit Ctrl+Alt+F1 würden Sie zur ersten virtuellen Konsole umschalten.

Sobald Sie auf eine virtuelle Konsole umgeschaltet haben, können Sie ganz normal Alt+Fn benutzen, um zwischen den einzelnen virtuellen Konsolen umzuschalten.

Um zu Ihrer X-Sitzung zurückzukehren, müssen Sie auf die virtuelle Konsole umschalten, auf der X läuft. Wenn Sie X über der Eingabeaufforderung gestartet haben (z.B. mit startx), benutzt X die nächste freie virtuelle Konsole und nicht die Konsole, von der es gestartet wurde. Wenn Sie acht aktive virtuelle Konsole haben, dann wird X die neunte benutzen und Sie können mit Alt+F9 umschalten.

Es gibt zwei Denkansätze, wie xdm zu starten ist. Bei dem einen wird xdm von /etc/ttys aus gestartet, wobei das mitgelieferte Beispiel benutzt wird, während xdm bei dem anderen Ansatz einfach in rc.local oder von einem Skript X.sh im Verzeichnis /usr/local/etc/rc.d aus gestartet wird. Beide Ansätze sind gleichwertig und der eine wird in Situationen funktionieren, in denen der andere es nicht tut. In beiden Fällen ist das Ergebnis das gleiche: X liefert eine graphische Anmeldeaufforderung.

Die ttys-Methode hat den Vorteil, daß dokumentiert ist, auf welchem vty X gestartet wird und der Neustart des X-Servers beim Abmelden an init übergeben wird. Die rc.local-Methode erleichtert ein Killen von xdm, falls Probleme beim Start des X-Servers auftreten sollten.

Beim Laden von rc.local sollte xdm ohne irgendwelche Argumente (d.h. als Daemon) gestartet werden. xdm muß gestartet werden NACHDEM getty läuft, andernfalls entsteht ein Konflikt zwischen getty und xdm und die Konsole bleibt gesperrt. Der beste Weg, um dies zu vermeiden, ist, das Skript für etwa zehn Sekunden anzuhalten und dann xdm zu starten.

Wenn Sie xdm durch einen Eintrag in /etc/ttys starten lassen, kann es zu einem Konflikt zwischen xdm und getty kommen. Um dieses Problem zu vermeiden, sollten Sie die Nummer des vt in die Datei /usr/X11R6/lib/X11/xdm/Xservers eintragen.

    :0 local /usr/X11R6/bin/X vt4

Diese Zeile führt dazu, daß der X Server /dev/ttyv3 nutzt. Die beiden Zahlen weichen voneinander ab: Der X-Server beginnt die Zählung der vty bei 1, während der FreeBSD-Kernel bei 0 beginnt.

Wenn Sie X mit startx starten, werden die Zugriffsrechte für /dev/consolenicht geändert, was dazu führt, daß Dinge wie xterm -C und xconsole nicht funktionieren.

Das hängt damit zusammen, wie die Zugriffsrechte für die Konsole standardmäßig gesetzt sind. Auf einem Mehrbenutzersystem möchte man nicht unbedingt, daß jeder Benutzer einfach auf die Systemkonsole schreiben kann. Für Benutzer, die sich auf einer Maschine direkt mit einem VTY anmelden, existiert die Datei fbtab(5), um derartige Probleme zu lösen.

In Kürze: sorgen Sie dafür, daß sich eine nicht auskommentierte Zeile der Form

    /dev/ttyv0 0600 /dev/console
             

in der Datei /etc/fbtab befindet. Das sorgt dafür, daß wer auch immer sich auf /dev/ttyv0 anmeldet, auch die Konsole besitzt.

Alle X-Server müssen mit der ID root laufen, um direkt auf die Videohardware zuzugreifen. Die älteren Versionen von XFree86 (bis einschließlich 3.3.6) installierten alle mitgelieferten Server so, daß sie automatisch unter ID root ausgeführt werden (setuid to root). Dies stellt natürlich eine Gefahrenquelle dar, da die X-Server große, komplexe Programme sind. Alle neueren Version von XFree86 installieren die Server aus genau diesem Grund nicht mehr "setuid root".

Es ist natürlich nicht tragbar, den X-Server immer mit der ID root laufen zu lassen; auch aus Gründen der Sicherheit ist es keine gute Idee. Es gibt zwei Möglichkeiten, um X auch als normaler Benutzer starten zu können. Die erste ist die Verwendung von xdm oder eines ähnlichen Programms; die zweite ist die Benutzer von Xwrapper.

xdm ist ein ständig laufendes Programm, mit dem Logins über eine graphische Benutzeroberfläche sind. Es wird normalerweise beim Systemstart initialisiert und für die Authentifizierung der Benutzer und den Start ihrer Sitzungen verantwortlich. Es ist also die graphische Entsprechnung von getty und login. Weitere Informationen zum Thema xdm finden Sie in der XFree86 Dokumentation und dem entsprechenden FAQ-Eintrag.

Xwrapper ist eine ``Hülle'' für den X-Server. Mit diesem kleinen Utility ist es möglich, manuell den X-Server zu starten und weiterhin eine annehmbare Sicherheit zu haben. Das Tools prüft, ob die per Kommandozeile übergebenen Argumente halbwegs sinnvoll sind. Wenn dies der Fall ist, startet es den entsprechenden X-Server. Wenn Sie (aus welchem Grund auch immer) keine graphische Anmeldung wollen, ist Xwrapper die optimale Lösung. Wenn Sie die vollständige Ports-Sammlung installiert haben, finden Sie das Tool im Verzeichnis /usr/ports/x11/wrapper.

Ihre Maus und der Maustreiber sind etwas aus der Synchronisation geraten.

Bis einschließlich Version 2.2.5 sorgt ein Wechsel von X zu einer virtuellen Konsole und wieder zurück für eine erneute Synchronisation. Falls das Problem öfter auftritt, können Sie die folgende Zeile in Ihre Kernelkonfigurationsdatei einfügen und den Kernel neu erstellen.

    options PSM_CHECKSYNC
             

Lesen Sie den Abschnitt über die Erstellung eines Kernels, falls Sie keine Erfahrung mit der Erstellung eines Kernels haben.

Mit dieser Option sollten geringere Chancen für Synchronisationsprobleme zwischen der Maus und dem Treiber bestehen. Falls sie jedoch weiterhin auf das Problem stoßen, drücken Sie eine der Maustasten, während Sie die Maus nicht bewegen, um die Maus und den Treiber neu zu synchronisieren.

Beachten Sie, daß diese Option leider nicht auf allen Systemen funktioniert und das ``tap'' Merkmal eines am PS/2-Mausanschluß angeschlossenen ALPS GlidePoint Gerätes beeinträchtigt.

Ab Version 2.2.6 erfolgt die Überprüfung der Synchronisation etwas besser und ist ein Standard im PS/2-Maustreiber. Es sollte sogar mit GlidePoint funktionieren. (Da der Code zur Überprüfung ein standard Merkmal geworden ist, gibt es die Option PSM_CHECKSYNC in diesen Versionen nicht mehr.) In seltenen Fällen kann es jedoch sein, daß der Treiber fälschlicherweise Synchronisationsprobleme meldet und Sie in den Kernelmeldungen folgendes sehen:

    psmintr: out of sync (xxxx != yyyy)
             

und Ihre Maus nicht richtig zu funktionieren scheint.

Falls das passiert, deaktivieren Sie den Code zur Überprüfung der Synchronisation, indem Sie die Treiberangaben für den PS/2-Maustreiber auf 0x100 setzen. Rufen Sie UserConfig durch Angabe der Option -c am Boot-Prompt auf:

    boot: -c
             

Geben sie dann in der Kommandozeile von UserConfig folgendes ein:

    UserConfig> flags psm0 0x100
    UserConfig> quit
             

Es wurde berichtet, daß einige Modelle der PS/2-Mäuse von MouseSystems nur funktionieren, wenn sie im ``hochauflösenden'' Modus betrieben werden. Andernfalls springt der Mauszeiger sehr oft in die linke obere Ecke des Bilschirms.

Leider gibt es hierzu keine Abhilfe für die Versionen 2.0.X und 2.1.X. Verwenden Sie bei den Versionen 2.2 bis 2.2.5 den folgenden Patch für die Datei /sys/i386/isa/psm.c und erstellen Sie den Kernel neu. Lesen Sie den Abschnitt über die Erstellung eines Kernels, falls Sie keine Erfahrung mit der Erstellung eines Kernels haben.

    diff -u psm.c.orig psm.c
    @@ -766,6 +766,8 @@
         if (verbose >= 2)
        log(LOG_DEBUG, "psm%d: SET_DEFAULTS return code:%04x\n",
            unit, i);
    +    set_mouse_resolution(sc->kbdc, PSMD_RES_HIGH);
    +
     #if 0
         set_mouse_scaling(sc->kbdc);    /* 1:1 scaling */
         set_mouse_mode(sc->kbdc);       /* stream mode */
             

Spezifizieren Sie ab Version 2.2.6 das Flag 0x04 für den Maustreiber, um die Maus in den hochauflösenden Modus zu bringen. Rufen Sie UserConfig durch Angabe der Option -c am Boot-Prompt auf:

    boot: -c
             

Geben sie dann in der Kommandozeile von UserConfig folgendes ein:

    UserConfig> flags psm0 0x04
    UserConfig> quit
             

Lesen Sie den vorigen Abschnitt über eine andere mögliche Ursache für Probleme mit der Maus.

Imake.tmpl ist Teil des Imake-Paketes, ein Standardwerkzeug zur Erstellung von X-Applikationen. Imake.tmpl ist ebenso, wie viele Header-Dateien, die zur Erstellung von X-Applikationen benötigt werden, in der Distribution xprog enthalten. Sie können Sie per sysinstall oder aber manuell mit den X Distributionsdateien installieren.

Benutzen Sie den Befehl xmodmap -e "pointer = 3 2 1" in Ihrer .xinitrc oder .xsession.

Kurz vor der Herausgabe von FreeBSD 3.1 wurde ein neues Feature eingefügt, das die Anzeige von ``Splash-Screens'' während der Bootmeldungen erlaubt. Die Splash-Screens dürfen derzeit nur Bitmaps mit 256-Farben (*.BMP) oder ZSoft-PCX-Dateien *.PCX) sein. Damit sie mit normalen VGA-Karten dargestellt werden können, darf die Größe 320x200 Bildpunkte nicht überschreiten. Wenn Sie in ihrem Kernel die VESA-Unterstützung eingebunden haben, beträgt die maximale Größe 1024x768 Pixel. Beachten Sie, daß die VESA-Unterstützung die Kerneloption VM86 benötigt, um in den Kernel eingebunden werden zu können. Die derzeitige VESA-Unterstützung kann entweder direkt durch die Kernelkonfigurationsoption VESA in den Kernel eingebunden werden, oder durch das Laden des VESA-Moduls kld während des Bootens.

Um eine Splash-Screen zu benutzen, müssen Sie die Startdateien, die den Bootprozeß von FreeBSD kontrollieren, modifizieren. Diese Dateien haben sich vor der Herausgabe von FreeBSD 3.2 geändert, so daß nun zwei Möglichkeiten zum Laden einer Splash-Screen existieren:

• FreeBSD 3.1

  Der erste Schritt besteht darin, eine Bitmap-Version Ihrer Splash-Screen zu finden. Von Version 3.1 werden nur Windows-Bitmap Splash-Screens unterstützt. Wenn Sie die Splash-Screen Ihrer Wahl gefunden haben, kopieren Sie sie nach /boot/splash.bmp. Als nächstes benötigen Sie eine Datei /boot/loader.rc, die die folgenden Zeilen enthält:

      load kernel
      load -t splash_image_data /boot/splash.bmp
      load splash_bmp
      autoboot
                   
  

• seit FreeBSD 3.2

  Außer der zusätzlichen Unterstützung von PCX Splash-Screens bietet FreeBSD 3.2 eine einfachere Möglichkeit, den Bootprozeß zu konfigurieren. Wenn Sie möchten, können Sie auch die obige Methode für FreeBSD 3.1 benutzen. Falls Sie das tun und PCX verwenden möchten, dann ersetzen Sie splash_bmp durch splash_pcx. Falls Sie aber die neuere Bootkonfiguration benutzen möchten, müssen Sie eine Datei /boot/loader.rc erstellen, die die folgenden Zeilen enthält:

      include /boot/loader.4th
      start
                   
  

  und eine Datei /boot/loader.conf, die die folgenden Zeilen enthält:

      splash_bmp_load="YES"
      bitmap_load="YES"
                   
  

  Dies setzt voraus, daß Sie /boot/splash.bmp als Ihren Splash-Screen benutzen. Wenn Sie lieber eine PCX-Datei benutzen wollen, dann kopieren Sie sie nach /boot/splash.pcx, erstellen Sie eine Datei /boot/loader.rc, wie oben beschrieben und eine Datei /boot/loader.conf, die folgendes enthält:

      splash_pcx_load="YES"
      bitmap_load="YES"
      bitmap_name="/boot/splash.pcx"
                   
  

Alles, was Sie nun brauchen, ist ein Splash-Screen. Hierzu können Sie durch die Gallerie bei http://www.baldwin.cx/splash/ surfen.

Ja, Sie müssen lediglich mit xmodmap(1) festlegen, welche Aktion diese Tasten auslösen sollen.

Unter der Annahme, daß alle ``Windows(tm)'' Tastaturen dem Standard entsprechen, lauten die Keycodes für die drei Tasten

• 115 - Windows(tm) Taste zwischen den Alt- und Strg-Tasten auf der linken Seite

• 116 - Windows(tm) Taste rechts von der Alt-Gr-Taste

• 117 - Menü-Taste, links von der rechten Strg-Taste

Nach der folgenden Anweisung erzeugt die linke Windows(tm)-Taste ein Komma.

    # xmodmap -e "keycode 115 = comma"
             

Sie werden Ihren Window Manager wahrscheinlich neu starten müssen, damit diese Einstellung wirksam wird.

Um die neue Belegung der Windows(tm)-Tasten automatisch beim Start von X zu erhalten, könnten Sie entsprechende xmodmap Anweisungen in ihre ~/.xinitrc einfügen. Die bevorzugte Variante ist aber, eine Datei mit dem Namen ~/.xmodmaprc zu erzeugen, die nur die Parameter für den Aufruf von xmodmap enthält. Wenn Sie mehrere Tasten umdefinieren wollen, muß jede Definition in eine eigene Zeile gesetzt werden. Weiterhin müssen Sie in Ihrer ~/.xinitrc noch die folgende Zeile einfügen:

    xmodmap $HOME/.xmodmaprc
             

Sie könnten die drei Tasten zum Beispiel mit den Funktionen F13, F14 und F15 belegen. Dadurch ist es sehr einfach, diese Tasten mit nützlichen Funktionen eines Programmes oder Desktops zu verknüpfen.

Falls Sie das auch tun wollen, sollten in Ihrer ~/.xmodmaprc die folgenden Anweisungen stehen.

    keycode 115 = F13
    keycode 116 = F14
    keycode 117 = F15
             

Falls Sie zum Beispiel fvwm2 benutzen, können Sie ihn so einstellen, daß F13 das Fenster unter dem Mauszeiger minimiert bzw. maximiert. F14 holt das Fenster unter dem Mauszeiger in den Vordergrund bzw. ganz nach hinten, wenn es bereits im Vordergrund ist. F15 öffnet das Arbeitsplatz (Programme) Menü, auch wenn der Cursor nicht auf den Hintergrund zeigt. Dies ist extrem praktisch, wenn der gesamte Bildschirm von Fenster belegt wird; als kleiner Bonus gibt es sogar einen Zusammenhang zwischem dem Symbol auf der Taste und der durchgeführten Aktion.

Dieses Verhalten kann man mit den folgenden Einträgen in der Datei ~/.fvwmrc erhalten:

    Key F13        FTIWS    A        Iconify
    Key F14        FTIWS    A        RaiseLower
    Key F15        A        A        Menu Workplace Nop
             

``Diskless Booting'' bedeutet, daß die FreeBSD-Maschine über ein Netzwerk gebootet wird und die notwendigen Dateien von einem Server anstatt von der Festplatte liest. Vollständige Details finden Sie im Handbucheintrag über Diskless Booting

Internetstandards und gute Ingenieurtechniken verbieten uns, in FreeBSD standardmäßig eine Paketweiterleitung zu aktivieren. Sie können dieses Feature aber aktivieren, indem Sie in /etc/rc.conf die folgende Variable auf YES setzen:

    gateway_enable=YES          # Set to YES if this host will be a gateway
             

Diese Option setzt die sysctl-Variable net.inet.ip.forwarding auf 1.

In den meisten Fällen werden Sie auch einen Routing-Dæmon laufen lassen müssen, um andere Systeme in Ihrem Netzwerk über Ihren Router zu informieren. FreeBSD enthält den standard Routing-Daemon routed(8), für komplexere Situationen möchten Sie evtl. GaTeD ausprobieren (erhältlich von http://www.gated.org/), der FreeBSD vom Stand 3_5Alpha7 unterstützt.

Wir müssen sie allerdings warnen, daß FreeBSD selbst in dieser Konfiguration nicht alle Internet-Standards für Router erfüllt. Für normale Anwendungszwecke kommt es diesen Standard aber ausreichend nahe.

Personen, die diese Frage stellen, haben typischerweise zwei PCs zu Hause: einen mit FreeBSD und einen mit Win95; die Idee ist, die FreeBSD-Maschine an das Internet anzubinden und dann in der Lage zu sein, von der Windows95-Maschine aus über die FreeBSD-Maschine auf das Internet zuzugreifen. Das ist tatsächlich nur ein Spezialfall der vorherigen Frage.

... und die Antwort ist JA! Das user-mode ppp von FreeBSD kennt die Option -nat. Wenn Sie ppp mit der Option -nat starten, in /etc/rc.conf die Variable gateway_enable auf YES setzen und ihre Windows-Maschine korrekt konfigurieren, sollte das hervorragend funktionieren.

Ausführlichere Informationen zur Konfiguration finden Sie im Pedantic PPP Primer von Steve Sims.

Wenn Sie Kernel-Mode PPP verwenden oder ihre Verbindung zum Internet über Ethernet realisiert wurde, müssen Sie natd verwenden. Weitere Informationen dazu finden Sie im Abschnitt über natd.

Es existiert ein Konflikt zwischen der Datei cdefs.h in der Distribution und der, die mit FreeBSD ausgeliefert wird. Löschen Sie compat/include/sys/cdefs.h einfach.

Ja. Lesen Sie die Manualpages slattach(8), sliplogin(8), pppd(8) und ppp(8). ppp(8) und pppd(8) liefern Unterstützung sowohl für eingehende, als auch ausgehende Verbindungen. sliplogin(8) behandelt ausschließlich eingehende Verbindungen und slattach(8) behandelt ausschließlich ausgehende Verbindungen.

Diese Programme werden im Abschnitt PPP und SLIP des Handbuchs beschrieben.

Falls Sie nur durch einen ``Shell-Account'' Zugang zum Internet haben, sehen Sie sich einmal das Package slirp an. Es kann Ihnen (eingeschränkten) Zugang zu Diensten wie ftp und http direkt von Ihrer lokalen Maschine aus ermöglichen.

Falls Sie ein lokales Subnetz (oder mehrere lokale Maschinen) besitzen, aber von Ihrem Internetprovider nur eine einzige (evtl. auch dynamisch zugeteilte) IP-Adresse zugewiesen bekommen haben, sehen Sie sich einmal das Programm natd(8) an. natd ermöglicht es Ihnen, ein vollständiges Subnetz mit nur einer einzigen IP-Adresse an das Internet anzubinden.

Das Programm ppp(8) verfügt mit der eingebauten Option -nat über eine ähnliche Funktionalität. In beiden Fällen wird die Alias-Bibliothek libalias(3) verwendet.

Bei Berkley-basierten Netzwerkimplementationen kann nur vom Kernel-Code aus direkt auf Netzwerkkarten zugegriffen werden. Zur weiteren Information lesen Sie bitte die Datei /etc/rc.network und die Manualpages zu den unterschiedlichen Netzwerkprogrammen, die dort erwähnt werden. Falls Sie danach total verwirrt sind, sollten Sie sich ein Buch besorgen, das die Netzwerkadministration auf einem anderen BSD-ähnlichen Betriebssystem beschreibt; mit wenigen signifikanten Ausnahmen gleicht die Netzwerkadministration auf FreeBSD im Grunde der auf SunOS 4.0 oder Ultrix.

Benutzen Sie netmask 0xffffffff in Ihrer ifconfig-Befehlszeile, wie z.B.:

    # ifconfig ed0 alias 204.141.95.2 netmask 0xffffffff
             

Wenn Sie die anderen Anschlüsse benutzen möchten, müssen Sie einen zusätzlichen Parameter in der ifconfig(8)-Befehlszeile spezifizieren. Der Standard-Anschluß ist link0. Um den AUI-Anschluß anstelle des BNC-Anschlusses zu verwenden, benutzen Sie link2. Diese Angaben sollten durch Benutzung der Variablen ifconfig_* in der Datei /etc/rc.conf spezifiziert werden.

Gewisse PC-Netzwerkkarten sind (um es gelinde auszudrücken) besser als andere und können manchmal Probleme mit netzwerkintensiven Anwendungen wie NFS verursachen.

Weitere Informationen zu diesem Thema finden Sie im Handbucheintrag zu NFS.

Einige Versionen des NFS-Codes von Linux akzeptieren Mount-Requests nur von einem privilegierten Port. Versuchen Sie

    # mount -o -P linuxbox:/blah /mnt
             

Sun Workstations mit SunOS 4.X akzeptieren Mount-Requests nur von einem privilegierten Port. Versuchen Sie

    # mount -o -P sunbox:/blah /mnt
             

Die häufigste Ursache für dieses Problem ist, daß Sie die folgende Passage aus exports(5) nicht oder nicht richtig verstanden haben:

Jede Zeile in dieser Datei (außer den mit einem # beginnenden Kommentarzeilen) definiert den Mount Point und die Einstellungen für den Export innerhalb eines Dateisystems auf dem Server, für einen oder mehrere andere Rechner (Anmerkung des Übersetzers: Clients). Jeder Rechner darf für jedes lokale Dateisystem nur ein mal erwähnt werden und es darf für jedes Dateisystem des Servers nur einen Defaulteintrag geben, der dann für alle anderen Rechner gilt.

Um dies zu verdeutlichen, folgt ein Beispiel eines typischen Fehlers. Wenn alles oberhalb von /usr Teil eines einzigen Dateisystems ist (es also keine Mounts oberhalb von /usr gibt), ist die folgende Datei nicht korrekt:

    /usr/src   client
    /usr/ports client
             

Es gibt zwei Zeilen, die Einstellungen für das gleiche Dateisystem (/usr) und den gleichen Host (client) definieren. Die richtige Variante wäre:

    /usr/src /usr/ports  client
             

Um die zitiere Passage anders auszudrücken: Die Einstellungen für den Export eines Filesystems an einen anderen Host (globale Exporte werden wie ein anderer Host behandelt) müssen alle in einer Zeile erfolgen. Ja, das schränkt ihre Möglichkeiten für den Export von Dateisystemen ein, wenn Sie keine häßlichen Krücken einbauen wollen. Für die meisten Benutzer ist dies allerdings kein Problem.

Es folgt ein Beispiel einer legalen Export-Datei; dabei sind /usr und /exports lokale Dateisysteme:

    # Export src and ports to client01 and client02, but only
    # client01 has root privileges on it
    /usr/src /usr/ports -maproot=0    client01
    /usr/src /usr/ports               client02
    # The "client" machines have root and can mount anywhere
    # up /exports. The world can mount /exports/obj read-only
    /exports -alldirs -maproot=0      client01 client02
    /exports/obj -ro
             

Versuchen Sie, die TCP-Erweiterung in /etc/rc.conf zu deaktivieren, indem Sie die folgende Variable auf NO setzen:

    tcp_extensions=NO
             

Xylogic's Annex-Maschinen arbeiten hier auch fehlerhaft und Sie müssen die obige Änderung benutzen, um über Sie Verbindungen herzustellen.

Multicast-Host-Funktionen werden seit FreeBSD 2.0 standardmäßig voll unterstützt. Wenn Sie Ihre Maschine als Multicast-Router betreiben wollen, müssen Sie Ihren Kernel mit der Option MROUTING rekompilieren und mrouted starten. Seit Version 2.2 startet FreeBSD mrouted beim Booten, wenn die Variable mrouted_enable in der Datei /etc/rc.conf auf "YES" gesetzt ist.

MBONE-Tools sind in ihrer eigenen Ports-Kategorie mbone verfügbar. Schauen Sie dort nach, wenn Sie die Konferenztools vic und vat suchen!

Weitere Informationen finden Sie im Mbone Information Web.

Hier ist eine von Glen Foster zusammengetragene Liste mit einigen aktuellen Ergänzungen:

    Hersteller      Modell
    ----------------------------------------------
    ASUS            PCI-L101-TB
    Accton          ENI1203
    Cogent          EM960PCI
    Compex          ENET32-PCI
    D-Link          DE-530
    Dayna           DP1203, DP2100
    DEC             DE435, DE450
    Danpex          EN-9400P3
    JCIS            Condor JC1260
    Linksys         EtherPCI
    Mylex           LNP101
    SMC             EtherPower 10/100 (Modell 9332)
    SMC             EtherPower (Modell 8432)
    TopWare         TE-3500P
    Znyx            (2.2.x) ZX312, ZX314, ZX342, ZX345, ZX346, ZX348
                    (3.x) ZX345Q, ZX346Q, ZX348Q, ZX412Q, ZX414, ZX442,
                          ZX444, ZX474, ZX478, ZX212, ZX214 (10mbps/hd)
             

Sie werden wahrscheinlich feststellen, daß der Host sich tatsächlich in einer anderen Domäne befindet; wenn Sie sich zum Beispiel in foo.bar.edu befinden und einen Host namens mumble in der Domäne bar.edu erreichen wollen, werden Sie den fully-qualified Domainnamen mumble.bar.edu, anstatt nur mumble benutzen müssen.

Traditionell war dies bei BSD-BIND-Resolvern erlaubt. Die aktuelle Version von bind, die mit FreeBSD ausgeliefert wird, ermöglicht jedoch nicht mehr die standardmäßige Abkürzung von nicht-fully-qualified Domainnamen für andere als ihre eigene Domäne. Ein nicht-qualifizierter Host mumble muß also entweder als mumble.foo.bar.edu gefunden werden, oder er wird in der Hauptdomäne gesucht.

Dies unterscheidet sich vom vorherigen Verhalten, wo die Suche über mumble.bar.edu und mumble.edu fortgesetzt wurde. Werfen Sie einen Blick in RFC 1535, um zu erfahren, warum dies als schlechter Stil oder sogar als eine Sicherheitslücke betrachtet wurde.

Als Abhilfe können Sie die Zeile

    search foo.bar.edu bar.edu
             

anstelle der vorherigen

    domain foo.bar.edu
             

in Ihre Datei /etc/resolv.conf einfügen. Stellen Sie jedoch sicher, daß die Suchreihenfolge nicht über die ``Grenze zwischen lokaler und öffentlicher Administration'', wie RFC 1535 sie nennt, hinausreicht.

Dieses Problem kann auftreten, wenn Sie einen Kernel mit der Option IPFIREWALL erstellt haben. Während der Entwicklung von FreeBSD 2.1.7 wurde die Semantik dieser Option geändert: Seit dieser Version ist alles verboten, was nicht explizit erlaubt ist.

Falls sie Ihr System unbeabsichtigt als Firewall fehlkonfiguriert haben, können Sie die Netzwerkfunktionalität wiederherstellen, indem Sie als root folgendes eingeben:

    # ipfw add 65534 allow all from any to any
             

Sie können in /etc/rc.conf auch firewall_type="open" setzen.

Weitere Informationen über die Konfiguration einer FreeBSD-Firewall finden Sie im Handbuch-Abschnitt.

Die Antwort auf diese Frage hängt hauptsächlich von Ihrem Rule-Set und der Prozessorgeschwindigkeit ab. Für die meisten Anwendungen, die mit Ethernetzen und kleinen Rule-Sets arbeiten, ist die Antwort: unbedeutend. Diejenigen, die tatsächliche Messungen zur Befriedigung ihrer Neugierde brauchen, sollten weiterlesen.

Die folgenden Messungen wurden mit 2.2.5-STABLE auf einem 486-66 durchgeführt. IPFW wurde modifiziert, um die Zeit zu messen, die in der Routine ip_fw_chk verbracht wurde. Das Ergebnis wurde nach jeweils 1000 Paketen auf der Konsole ausgegeben.

Getestet wurden zwei Regelsätze mit jeweils 1000 Regeln. Der erste Satz wurde zur Demonstration eines Szenarios im schlimmsten Fall zusammengestellt, indem die folgende Regel wiederholt wurde:

    # ipfw add deny tcp from any to any 55555
             

Dies demonstriert den schlimmsten Fall, indem dafür gesorgt wird, daß die meisten von IPFW's Paketüberprüfungsroutinen ausgeführt werden, bevor letztlich entschieden wird, daß die Regel für das Paket nicht zutrifft (wegen der virtuellen Portnummer). Auf die 999. Iteration dieser Regel folgte ein allow ip from any to any.

Der zweite Regelsatz wurde so zusammengestellt, daß die Überprüfung der Regeln schnell abbricht:

    # ipfw add deny ip from 1.2.3.4 to 1.2.3.4
             

Die nichtzutreffende IP-Adresse für die obige Regel sorgt dafür, daß diese Regeln sehr schnell übersprungen werden. Wie zuvor war die 1000. Regel ein allow ip from any to any.

Der Verarbeitungsmehraufwand pro Paket im ersten Fall war ungefähr 2,703 ms/Paket, oder grob 2,7 Mikrosekunden pro Regel. Das theoretische Limit für die Verarbeitung von Paketen liegt also etwa bei 370 Paketen pro Sekunde. Bei einem 10Mbps Ethernet und einer Paketgröße von ~1500 Byte könnte man nur eine 55,5% ige Ausnutzung der Bandbreite erreichen.

Im letzteren Fall wurde jedes Paket in ungefähr 1,172 ms verarbeitet, oder grob 1,2 Mikrosekunden pro Regel. Das theoretische Limit für die Verarbeitung von Paketen läge hier bei etwa 853 Paketen pro Sekunde, was ein 10Mbps Ethernet auslasten könnte.

Die übermäßige Anzahl der getesteten Regeln und die Beschaffenheit dieser Regeln liefern kein realistisches Szenario -- sie wurden lediglich benutzt, um die hier vorgestellten Meßergebnisse zu generieren. Hier sind einige Dinge, die bei der Erstellung eines effizienten Regelsatzes beachtet werden sollten:

• Setzen Sie frühzeitig eine established-Regel, um den Großteil des TCP-Verkehrs abzufangen. Setzen Sie keine allow tcp-Anweisungen vor diese Regel.

• Plazieren Sie häufig angestoßene Regeln im Regelsatz vor solche, die weniger häufig benutzt werden (natürlich, ohne die Toleranz der Firewall zu verändern). Sie können herausfinden, welche Regeln am häufigsten benutzt werden, indem Sie die Paketstatistik mit ipfw -a l untersuchen.

Der wahrscheinlichste Grund ist, daß Sie Network Address Translation (NAT) brauchen und nicht die einfache Weiterleitung von Pakete. Die ``fwd'' Anweisung macht genau das, was da steht: Sie leitet Pakete weiter; die Daten in den Paketen werden aber nicht verändert. Ein Beispiel:

    01000 fwd 10.0.0.1 from any to foo 21

Wenn ein Paket mit dem Ziel foo die Maschine mit dieser Regel erreicht, wird das Paket an 10.0.0.1 weitergeleitet; die Zieladresse im Paket lautet aber immer noch foo! Die Zieladresse wird nicht in 10.0.0.1 geändert. Die meisten Rechner werden allerdings Pakete verwerfen, wenn die Zieladresse des Paketes nicht mit der Adresse des Rechners übereinstimmt. Das ist der Grund, warum eine ``fwd'' Regel oft nicht den Effekt hat, den der Benutzer wollte. Dieses Verhalten ist aber kein Fehler, sondern erwünscht.

Wenn Sie einen Dienst auf eine andere Maschine umleiten wollen, sollten Sie sich den FAQ-Eintrag über die Umleitung von Diensten oder die Online-Hilfe zu natd(8) durchlesen. Auch in der Ports Sammlung sind diverse Hilfsprogramme für diesen Zweck enthalten.

Sie können FTP-Requests (und andere Dienste) mit dem Package socket umleiten, das im Ports-Tree in der Kategorie ``sysutils'' verfügbar ist. Ersetzen sie die Befehlszeile für den Dienst einfach so, daß stattdessen socket aufgerufen wird, zum Beispiel so:

    ftp stream tcp nowait nobody /usr/local/bin/socket socket ftp.foo.com ftp
             

wobei ftp.foo.com und ftp entsprechend der Host und der Port sind, wohin umgeleitet werden soll.

Für FreeBSD gibt es zwei Bandbreiten-Managementtools. ALTQ gibt es umsonst; Bandwidth Manager von Emerging Technologies ist ein kommerzielles Produkt.

Wahrscheinlich nicht. FreeBSD benutzt seit Version 3.0 eine Version von BIND, die einen Port mit einer hohen, zufälligen Nummer für den Versand von Anfragen nutzt. Wenn Sie Port 53 für abgehende Anfragen nutzen wollen, um durch eine Firewall zu kommen oder sich einfach nur besser zu fühlen, können die folgenden Zeilen in /etc/namedb/named.conf eintragen.

    options {
            query-source address * port * 53;
    };

Wenn Sie möchten, können Sie statt * auch eine einzelne IP-Adresse eintragen, um die Dinge noch weiter einzuschränken.

Ach übrigens, herzlichen Glückwunsch. Es ist eine sehr gute Angewohnheit, die Ausgaben von sockstat durchzusehen und auf merkwürdige Dinge zu achten.

Der Berkeley-Paket-Filter (bpf(4)) muß in den Kernel eingebunden werden, bevor er von einem Programme aus genutzt werden kann. Fügen Sie folgendes zu Ihrer Kernelkonfigurationsdatei hinzu und erstellen Sie einen neuen Kernel:

    pseudo-device bpfilter     # Berkeley Packet Filter
             

Zweitens müssen Sie nach dem Rebooten den Device Node erstellen. Führen Sie dazu die folgenden Befehle aus:

    # cd /dev
    # sh MAKEDEV bpf0
             

Weitere Informationen zur Erstellung von Geräten finden Sie im Handbucheintrag über Device Nodes.

Benutzen Sie das Package sharity light aus der Ports-Sammlung.

Mit dieser Meldung teilt Ihnen der Kernel mit, daß irgend jemand versucht, ihn zur Generierung von zu vielen ICMP oder TCP reset (RST) Antworten zu provozieren. ICMP Antworten sind oft das Ergebnis von Verbindungsversuchen zu unbenutzen UDP ports. TCP resets werden generiert, wenn jemand versucht, eine Verbindung zu einem ungenutzten TCP Port aufzubauen. Die Meldungen können unter anderem durch die folgenden Ereignisse ausgelöst werden:

• Denial of Service (DoS) Angriffe mit der Brechstange (und nicht durch Angriffe mit einzelnen Paketen, die gezielt eine Schwachstelle des Systems ausnutzen sollen).

• Port Scans, bei denen versucht wird, Verbindungen zu einer großen Anzahl von Ports (und nicht nur einigen bekannten Ports) herzustellen.

Die erste Zahl gibt an, wieviele Pakete vom Kernel ohne das Limit versendet worden wären; die zweite Zahl gibt das Limit an. Sie können das Limit mit Hilfe der sysctl-Variable net.inet.icmp.icmplim einstellen. Im Beispiel wird das Limit auf 300 Packete pro Sekunde gesetzt:

    # sysctl -w net.inet.icmp.icmplim=300
             

Wenn Sie zwar die Begrenzung nutzen möchten, aber die Meldungen nicht in Ihren Logfiles sehen möchten, können Sie die Meldungen mit der sysctl-Variable net.inet.icmp.icmplim_output abschalten:

    # sysctl -w net.inet.icmp.icmplim_output=0
             

Falls Sie die Begrenzung ganz abschalten wollen, können Sie die Sysctl-Variable net.inet.icmp.icmplim auf 0. Wir raten Ihnen aus den oben genannten Gründen dringend von diesem Schritt ab.

Sie sollten zuerst ppp(8) (die Manualpage zu ppp) und den Abschnitt zu ppp im Handbuch lesen. Aktivieren Sie das Logging mit folgendem Befehl:

    set log Phase Chat Connect Carrier lcp ipcp ccp command
             

Dieser Befehl kann an der Eingabeaufforderung von ppp eingegeben oder in die Konfigurationsdatei /etc/ppp/ppp.conf eingetragen werden (der beste Ort hierfür ist der Anfang des Abschnitts default. Stellen Sie sicher, daß die Datei /etc/syslog.conf die folgenden Zeilen enthält:

    !ppp
    *.*              /var/log/ppp.log
             

und, daß die Datei /var/log/ppp.log existiert. Sie können nun über die Logfiles eine Menge darüber herausfinden, was geschieht. Es macht nichts, wenn die Einträge in den Logfiles Ihnen gar nichts sagen. Wenn Sie jemandem um Hilfe bitten müssen, könnten sie für ihn von Nutzen sein.

Falls Ihre ppp-Version den set log Befehl nicht versteht, sollten Sie sich die neueste Version herunterladen. Sie kann auf Freebsd-Version 2.1.5 und höher erstellt werden.

Das liegt meistens daran, daß Ihr Rechnername nicht aufgelöst werden kann. Um dieses Problem zu lösen, müssen Sie sicherstellen, daß die Datei /etc/hosts von Ihrem Resolver zuerst genutzt wird. Dazu muß in der Datei /etc/host.conf der Eintrag hosts an die erste Stelle gesetzt werden. Erstellen Sie dann einfach für Ihren lokalen Rechner einen Eintrag in der Datei /etc/hosts. Falls Sie kein lokales Netzwerk besitzen, ändern Sie die localhost-Zeile:

    127.0.0.1    foo.bar.com foo localhost
             

Andernfalls fügen Sie einfach einen weiteren Eintrag für Ihren lokalen Recher hinzu. Weitere Details finden Sie in den betreffenden Manualpages.

Wenn Sie fertig sind sollten Sie ping -c1 `hostname` erfolgreich ausführen können.

Überprüfen Sie zunächst, ob Sie einen Standard-Gateway eingestellt haben. Wenn Sie netstat -rn ausführen, sollten Sie zwei Einträge ähnlich den folgenden sehen:

    Destination        Gateway            Flags     Refs     Use     Netif Expire
    default            10.0.0.2           UGSc        0        0      tun0
    10.0.0.2           10.0.0.1           UH          0        0      tun0
             

Hier wird angenommen, daß Sie die Adressen aus dem Handbuch, der Manualpage oder aus der Datei ppp.conf.sample benutzt haben. Falls Sie keine Standardroute haben, kann es daran liegen, daß Sie eine alte Version von ppp benutzen, die das Wort HISADDR in der Datei ppp.conf nicht versteht. Falls Ihre ppp-Version älter als 2.2.5 ist, ändern Sie die Zeile

    add 0 0 HISADDR
             

in

    add 0 0 10.0.0.2
             

Ein weiterer Grund dafür, daß die Zeile für die Standardroute fehlt, könnte der sein, daß Sie fälschlicherweise eine Standardroute in der Datei /etc/rc.conf (diese Datei hieß vor Version 2.2.2 /etc/sysconfig) eingetragen und die folgende Zeile in ppp.conf ausgelassen haben:

    delete ALL
             

Lesen Sie in diesem Fall den Abschnitt Abschließende Systemkonfiguration des Handbuchs.

Dieser Fehler beruht für gewöhnlich auf einem fehlenden Abschnitt

    MYADDR:
      delete ALL
      add 0 0 HISADDR
             

in Ihrer Datei /etc/ppp/ppp.linkup. Er ist nur notwendig, wenn Sie eine dynamische IP-Adresse besitzen oder die Adresse Ihres Gateways nicht kennen. Wenn Sie den interaktiven Modus benutzen, können Sie folgendes eingeben, nachdem Sie in den packet mode gelangt sind (den Paket Modus erkennen Sie an PPP im Prompt):

    delete ALL
    add 0 0 HISADDR
             

Weitere Details finden Sie im Abschnitt PPP und Dynamische IP-Adressen des Handbuchs.

Der Standardtimeout für ppp beträgt drei Minuten. Er kann durch die Zeile

    set timeout NNN
             

eingestellt werden, wobei NNN die Inaktivität in Sekunden, bevor die Verbindung geschlossen wird, angibt. Falls NNN Null ist, wird die Verbindung niemals aufgrund eines Timeouts geschlossen. Es ist möglich, diesen Befehl in die Datei ppp.conf einzubinden, oder ihn an der Eingabeaufforderung im interaktiven Modus einzugeben. Durch eine Verbindung zum Server-Socket von ppp über telnet(1) oder pppctl(8) ist es auch möglich, den Timeout bei aktiver Verbindung anzupassen. Weitere Details finden Sie in der Manualpage ppp(8).

Falls Sie Link-Quality-Reporting (LQR) konfiguriert haben, ist es möglich, daß zu viele LQR-Pakete zwischen Ihrer Maschine und dem verbundenen Rechner verloren gehen. ppp folgert daraus, daß die Verbindung nicht in Ordnung ist und schließt sie. Vor FreeBSD Version 2.2.5 war LQR standardmäßig aktiviert; nun ist es standardmäßig deaktiviert. Es kann durch folgende Zeile deaktiviert werden:

    disable lqr
             

Wenn die Qualität Ihrer Telefonleitung zu schlecht oder bei Ihrem Anschluß die Option (Telekomdeutsch: das Leistungsmerkmal) Anklopfen aktiviert ist, kann es manchmal vorkommen, daß Ihr Modem auflegt, weil es (fälschlicherweise) annimmt, daß es das Trägersignal verloren hat.

Bei den meisten Modems gibt es eine Einstellmöglichkeit, um anzugeben, wie tolerant es gegenüber vorübergehenden Verlusten des Trägersignals sein soll. Bei einem USR Sportster wird dies zum Beispiel im Register S10 in Zehntelsekunden angegeben. Um Ihr Modem toleranter zu machen, können Sie zu Ihrem Wählbefehl die folgende Sende-Empfangs-Sequenz hinzufügen:

    set dial "...... ATS10=10 OK ......"
             

Weitere Information sollten Sie dem Handbuch Ihres Modems entnehmen können.

Viele Leute machen Erfahrungen mit hängenden Verbindungen ohne erkennbaren Grund. Als erstes muß festgestellt werden, welche Seite der Verbindung hängt.

Wenn Sie ein externes Modem benutzen, können Sie einfach versuchen, ping zu benutzen, um zu sehen, ob die TD-Anzeige aufleuchtet, wenn Sie Daten übertragen. Falls sie aufleuchtet (und die RD-Anzeige nicht), liegt das Problem am anderen Ende. Falls TD nicht aufleuchtet, handelt es sich um ein lokales Problem. Bei einem internen Modem müssen Sie den Befehl set server in Ihrer Datei ppp.conf benutzen. Stellen Sie über pppctl eine Verbindung zu ppp her, wenn die Verbindung hängt. Falls Ihre Netzwerkverbindung plötzlich wieder funktioniert (ppp wurde durch die Aktivität auf dem Diagnose-Socket wiederbelebt) oder Sie keine Verbindung bekommen (vorausgesetzt, der Befehl set socket wurde beim Start erfolgreich ausgeführt), handelt es sich um ein lokales Problem. Falls Sie eine Verbindung bekommen und die externe Verbindung weiterhin hängt, aktivieren Sie lokales asynchrones Logging mit set log local async und benutzen Sie ping von einem anderen Fenster oder Bildschirm aus, um die externe Verbindung zu benutzen. Das asynchrone Logging zeigt Ihnen, welche Daten über die Verbindung gesendet und empfangen werden. Falls Daten hinausgehen, aber nicht zurückkommen, handelt es sich um ein externes Problem.

Wenn Sie festgestellt haben, ob es sich um ein lokales oder um ein externes Problem handelt, haben Sie zwei Möglichkeiten:

Hier können Sie wenig tun. Die meisten ISPs werden ablehnen, Ihnen zu helfen, wenn Sie kein Betriebssystem von Microsoft benutzen. Sie können enable lqr in Ihrer Datei ppp.conf angeben, wodurch ppp ermöglicht wird, ein externes Versagen zu erkennen und aufzulegen, aber diese Erkennung ist relativ langsam und deshalb nicht besonders nützlich. Evtl. sagen Sie Ihrem ISP nicht, daß Sie ein eigenes ppp benutzen...

Versuchen Sie zunächst, jegliche Datenkompression auszuschalten, indem Sie folgendes zu Ihrer Konfiguration hinzufügen:

    disable pred1 deflate deflate24 protocomp acfcomp shortseq vj
    deny pred1 deflate deflate24 protocomp acfcomp shortseq vj
             

Stellen Sie nun wieder eine Verbindung her, um festzustellen, ob sich etwas geändert hat. Falls es nun besser läuft oder falls das Problem vollständig behoben ist, versuchen Sie durch schrittweises Ändern der Einstellungen festzustellen, welche Einstellung den Unterschied bewirkt. Hierdurch erhalten Sie schlüssige Fakten fuer ein Gespräch mit Ihrem ISP (andererseits wird hierdurch offensichtlich, daß Sie kein Microsoft-Produkt benutzen).

Aktivieren Sie asynchrones Logging und warten Sie, bis die Verbindung wieder hängt, bevor Sie sich an Ihren ISP wenden. Hierzu kann einiges an Plattenplatz nötig sein. Die Daten, die als letztes von dem Port gelesen wurden, könnten von Interesse sein. Für gewöhnlich handelt es sich um ASCII-Text, der sogar den Fehler beschreiben kann (``Memory fault, core dumped'').

Falls Ihr ISP hilfsbereit ist, sollte er in der Lage sein, an seinem Ende das Logging zu aktivieren und wenn das nächste Mal die Verbindung abbricht, könnte er Ihnen mitteilen, worin das Problem auf seiner Seite besteht. Gerne können Sie Details auch an Brian Somers <brian@FreeBSD.org> schicken, oder Ihren ISP bitten, sich direkt an ihn zu wenden.

In diesem Fall erstellen Sie am besten ppp neu, indem Sie CFLAGS+=-g und STRIP= am Ende des Makefiles einfügen und dann make clean && make && make install ausführen. Suchen Sie die Prozeßnummer von ppp mit ps ajxww | fgrep ppp, wenn ppp sich aufhängt und führen Sie gdb ppp PID aus. Am gdb-Prompt können Sie bt benutzen, um einen Auszug von Stack zu erhalten.

Senden Sie die Ergebnisse an <brian@Awfulhak.org>.

Bei Freebsd-Versionen vor 2.2.5 wartete ppp(8) darauf, daß der Partner das Line Control Protocol (LCP) initiiert. Viele ISPs starten nicht mit der Initiierung, sondern erwarten dies vom Client. Benutzen Sie die folgende Zeile, um ppp zu veranlassen, LCP zu initiieren:

    set openmode active
             

Nach dem Aufbau einer Verbindung kann es sein, daß Sie in der Logdatei gelegentlich Meldungen mit dem Hinweis ``magic is the same'' sehen. Manchmal sind diese Meldungen harmlos und manchmal bricht die eine oder andere Seite die Verbindung ab. Die meisten Implementationen von ppp können dieses Problem nicht handhaben und Sie werden wiederholte Konfigurationsanforderungen und -bestätigungen in der Logdatei finden, bis ppp schließlich aufgibt und die Verbindung beendet.

Dies geschieht normalerweise auf Servern mit langsamen Festplatten, bei denen ein getty auf dem Port ausgeführt und ppp nach dem Einloggen von einem Login-Skript oder einem Programm aus gestartet wird. Ich habe auch davon gehört, daß dies bei der Benutzung von slirp regelmäßig auftritt. Der Grund hierfür ist, daß das ppp auf der Client-Seite in der Zeit, die benötigt wird, getty zu beenden und ppp zu starten, bereits beginnt, Line Control Protocol (LCP) Pakete zu senden. Da ECHO auf dem Serverport weiterhin eingeschaltet ist, werden diese Pakete zum ppp auf der Client-Seite ``reflektiert''.

Ein Teil der LCP-Verhandlungen ist die Einrichtung einer "magic Number" für jede Seite der Verbindung, damit ``Echos'' erkannt werden können. Das Protokoll besagt, daß, wenn der Partner versucht, die gleiche "Magic Number" auszuhandeln, ein NAK zurückgesendet und eine neue "Magic Number" gewählt werden soll. Während der Server das ECHO eingeschaltet hat, sendet der Client LCP Pakete, sieht die gleiche "Magic Number" im reflektierten Paket und erzeugt ein NAK. Er sieht auch das reflektierte NAK (was bedeutet, daß ppp seine "Magic Number" ändern muß). Hierdurch wird eine Vielzahl von Änderungen der "Magic Number" hervorgerufen, die sich allesamt im tty-Puffer des Servers ansammeln. Sobald ppp auf dem Server startet, wird es mit Änderungen der "Magic Number" überflutet und entscheidet, daß es sich zur Genüge mit den LCP-Verhandlungen beschäftigt hat und gibt auf. Und während sich der Client noch darüber freut, daß er keine weiteren Reflexionen sieht, wird ihm gemeldet, daß der Server auflegt.

Dies kann verhindert werden, indem dem Parter durch die folgende Zeile in der Datei ppp.conf erlaubt wird, mit der Verhandlung zu beginnen:

    set openmode passive
             

Hierdurch wird ppp mitgeteilt, darauf zu warten, daß der Server mit den LCP-Verhandlungen beginnt. Einige Server starten jedoch nie mit der Verhandlungen; falls dies der Fall ist, können Sie folgendes tun:

    set openmode active 3
             

Hierdurch bleibt ppp für drei Sekunden passiv und fängt dann erst an, LCP-Anforderungen zu senden. Falls der Partner während dieser Zeit beginnt, Anforderungen zu senden, wird ppp direkt antworten und nicht erst, nachdem die drei Sekunden abgelaufen sind.

Es gibt eine Fehlfunktion in der Implementierung von ppp, die darin besteht, daß LCP-, CCP- & IPCP-Antworten nicht mit den ursprünglichen Anforderungen assoziiert werden. Für den Fall, daß eine Implementation von ppp mehr als sechs Sekunden langsamer ist, als die andere Seite, resultiert das darin, daß die andere Seite zwei weitere LCP-Konfigurationsanforderungen sendet, was fatale Auswirkungen hat.

Stellen Sie sich vor, wir hätten es mit zwei Implementierungen A und B zu tun. A beginnt unmittelbar nach der Verbindung, LCP-Anforderungen zu senden und B benötigt sieben Sekunden, zu starten. Wenn B startet, hat A bereits drei LCP-Anforderungen gesendet. Wir nehmen an, daß ECHO ausgeschaltet ist; andernfalls würden wir Probleme mit der "Magic Number" beobachten, wie bereits im vorherigen Abschnitt beschrieben. B sendet eine Anforderung und anschließend eine Bestätigung der ersten Anforderung von A. Dies führt dazu, daß A in den Zustand OPENED übergeht und eine Bestätigung (die erste) zurück an B sendet. In der Zwischenzeit sendet B zwei weitere Bestätigungen als Antwort auf die zusätzlichen Anforderungen, die von A gesendet worden sind, bevor B gestartet ist. B empfängt dann die erste Bestätigung von A und geht in den Zustand OPENED über. A empfängt die zweite Bestätigung von B, geht zurück in den Zustand REQ-SENT und sendet eine weitere (vierte) Anforderung entsprechend dem RFC. A empfängt dann die dritte Bestätigung und geht in den Zustand OPENED über. In der Zwischenzeit empfängt B die vierte Anforderung von A, wechselt in den Zustand ACK-SENT und sendet eine weitere (zweite) Anforderung und (vierte) Bestätigung entsprechend dem RFC. A erhält die Anforderung, geht in den Zustand REQ-SENT über, sendet eine weitere Anforderung, erhält unverzüglich die nächste Bestätigung und geht in OPENED über.

Das geht so weiter, bis eine Seite erkennt, daß man zu keinem Ergebnis gelangt und aufgibt.

Am besten verhindert man solche Situationen, indem man eine Seite als passiv konfiguriert, d.h. dafür sorgt, daß eine Seite darauf wartet, daß die andere mit den Verhandlungen beginnt. Das kann durch den Befehl

    set openmode passive
             

geschehen. Diese Option sollten Sie mit Vorsicht genießen. Folgenden Befehl sollten Sie benutzen, um die Wartezeit auf den Beginn der Verhandlungen des Partners von ppp zu begrenzen:

    set stopped N
             

Alternativ kann der Befehl

    set openmode active N
             

(wobei N die Wartezeit in Sekunden vor Beginn der Verhandlungen angibt) benutzt werden. Weitere Details finden Sie in den Manualpages.

Bei FreeBSD-Versionen vor 2.2.5 konnte es passieren, daß Ihre Verbindung kurz nach dem Aufbau deaktiviert wurde, weil ppp die Verhandlungen der Kompression Predictor1 falsch handhabte. Das passiert nur dann, wenn beide Seiten versuchen, ein unterschiedliches Kompressionsprotokoll (Compression Control Protocol (CCP)) auszuhandeln. Dieses Problem ist bereits behoben, falls Sie aber noch eine alte Version von ppp verwenden, können Sie es mit Hilfe der folgenden Zeile umgehen:

    disable pred1
             

Wenn Sie den Befehl shell oder ! benutzen, führt ppp eine Shell aus (falls Sie Argumente übergeben haben, führt ppp diese Argumente aus). ppp wartet auf die Beendigung des Befehls, bevor es seine Arbeit fortsetzt. Falls Sie versuchen, die ppp-Verbindung während der Programmausführung zu benutzen, wird es so aussehen, als wäre die Verbindung eingefroren. Das liegt daran, daß ppp auf die Beendigung des Befehls wartet.

Falls Sie solche Befehle verwenden möchten, benutzen Sie stattdessen den Befehl !bg. Hierdurch wird der angegebene Befehl im Hintergrund ausgeführt und ppp kann fortfahren, die Verbindung zu bedienen.

Es gibt keine Möglichkeit für ppp, automatisch festzustellen, ob eine direkte Verbindung beendet worden ist. Das liegt an den Leitungen, die bei einem seriellen Null-Modem-Kabel benutzt werden. Wenn Sie diese Art der Verbindung verwenden, sollte LQR immer aktiviert werden:

    enable lqr
             

LQR wird standardmäßig akzeptiert, wenn es vom Partner ausgehandelt wird.

Falls ppp unerwarteterweise wählt, müssen Sie den Grund herausfinden und Wählfilter (dfilters) einsetzen, um dies zu verhindern.

Benutzen Sie die folgende Zeile, um den Grund herauszufinden:

    set log +tcp/ip
             

Dadurch wird jeglicher Verkehr über die Verbindung geloggt. Wenn das nächste mal unerwartet eine Verbindung hergestellt wird, werden Sie den Grund zusammen mit einer hilfreichen Zeitangabe in der Logdatei finden.

Sie können nun das Wählen aufgrund dieser Bedingungen verhindern. Normalerweise wird diese Art von Problemen durch Anfragen an den DNS verursacht. Um zu verhindern, daß DNS-Anfragen den Aufbau der Verbindung hervorrufen (das verhindert nicht, daß Pakete über eine bestehende Verbindung gesendet werden), benutzen Sie die folgenden Zeilen:

    set dfilter 1 deny udp src eq 53
    set dfilter 2 deny udp dst eq 53
    set dfilter 3 permit 0/0 0/0
             

Dies ist nicht immer brauchbar, weil es effektiv Ihre Fähigkeit, auf Anforderung wählen zu können einschränkt - die meisten Programme müssen eine DNS-Anfrage durchführen, bevor Sie andere, das Netzwerk betreffenden Dinge tun können.

Im Fall von DNS sollten Sie versuchen, herauszufinden, welches Programm tatsächlich versucht, einen Hostnamen aufzulösen. Sehr oft handelt es sich hier um sendmail(8). Sie sollten sicherstellen, daß Sie sendmail in der Konfigurationsdatei sagen, daß keine DNS-Anfragen durchführen soll. Lesen Sie den Abschnitt zur Mail-Konfiguration, um Details zur Erstellung Ihrer eigenen Konfigurationsdatei und darüber, was dort angegeben werden sollte, zu erfahren. Sie könnten z.B. die folgende Zeile in Ihre .mc-Datei einfügen:

    define(`confDELIVERY_MODE', `d')dnl
             

Das veranlaßt sendmail dazu, alles in eine Warteschlange einzureihen, bis die Warteschlange verarbeitet wird (normalerweise wird sendmail mit -bd -q30m aufgerufen, was besagt, daß die Warteschlange alle 30 Minuten abgearbeitet wird) oder, bis ein sendmail -q ausgeführt wird (z.B. aus Ihrer Datei ppp.linkup heraus).

Ich sehe ständig folgende Fehler in meiner Logdatei:

    CCP: CcpSendConfigReq
    CCP: Received Terminate Ack (1) state = Req-Sent (6)
             

Das liegt daran, daß ppp versucht, die Komprimierung Predictor1 auszuhandeln und der Partner über keinerlei Komprimierung verhandeln will. Die Meldungen sind harmlos, aber wenn Sie sie beseitigen möchten, können Sie die Komprimierung Predictor1 auch lokal ausschalten:

    disable pred1
             

Unter FreeBSD 2.2.2 und frühere gab es einen Bug im Tun-Treiber, der ankommende Pakete die größer als die MTU der Tun-Schnittstelle sind, ablehnt. Der Empfang eines Paketes größer der MTU resultiert in einem IO-Fehler, der über syslogd geloggt wird.

Die ppp-Spezifikation besagt, daß eine MTU von 1500 immer als Minimum akzeptiert werden sollte, ungeachtet aller LCP-Verhandlungen. Es ist deshalb möglich, daß Sie die MTU auf unter 1500 herabsetzen, Ihr ISP wird trotzdem Pakete der Größe 1500 übertragen und Sie werden auf diese Fehlfunktion stoßen, die Ihre Verbindung lahmlegt.

Das Problem kann umgangen werden, indem unter FreeBSD 2.2.2 und früher niemals eine MTU von weniger als 1500 gesetzt wird.

Um alle Zeilen Ihrer ``Modemkonversation'' mitzuloggen, müssen Sie folgendes einstellen:

    set log +connect
             

Dies veranlaßt ppp(8) dazu, alles bis zur letzten angeforderten ``expext''-Zeile mitzuloggen.

Falls Sie die Geschwindigkeit Ihrer Verbindung erfahren möchten und PAP oder CHAP (und deshalb nach dem CONNECT im Wählskript nichts mehr zu ``chatten'' haben - kein set login-Skript), müssen Sie sicherstellen, daß Sie ppp anweisen, die gesamte CONNECT-Zeile zu ``erwarten'', etwa so:

    set dial "ABORT BUSY ABORT NO\\sCARRIER TIMEOUT 4 \"\" ATZ OK-ATZ-OK ATDT\\T TIMEOUT 60 CONNECT \\c \\n"
             

Hier bekommen wir unser CONNECT, senden nichts, erwarten dann einen Line-Feed, der ppp zwingt, die gesamte CONNECT-Antwort zu lesen.

ppp analysiert jede Zeile in Ihrer Konfigurationsdatei, damit es Zeichenketten wie z.B. set phone "123 456 789" korrekt interpretieren kann (und erkennen, daß es sich bei der Nummer tatsächlich nur um ein Argument handelt). Um das Zeichen " anzugeben, müssen Sie ihm einen Backslash (\) voranstellen.

Wenn der Chat-Interpreter jedes Argument analysiert, reinterpretiert er die Argumente, um irgendwelche speziellen Escape-Sequenzen wie z.B. \P oder \T (sehen Sie in die Manualpage) zu finden. Das Ergebnis dieser Doppelanalyse ist, daß Sie daran denken müssen, die richtige Anzahl an Escape-Zeichen zu verwenden.

Falls Sie tatsächlich das Zeichen \ z.B. zu Ihrem Modem senden möchten, brauchen Sie etwas ähnliches, wie:

    set dial "\"\" ATZ OK-ATZ-OK AT\\\\X OK"
             

woraus sich folgende Zeichen ergeben:

    ATZ
    OK
    AT\X
    OK
             

oder

    set phone 1234567
    set dial "\"\" ATZ OK ATDT\\T"
             

was folgende Zeichen ergibt:

    ATZ
    OK
    ATDT1234567
             

Weder ppp noch andere Programme sollten Core-Dumps erzeugen. Da ppp mit der effektiven Benutzerkennung 0 ausgeführt wird, wird das Betriebssystem ppp's Coreimage nicht auf die Festplatte schreiben, bevor es ppp beendet hat. Falls ppp jedoch tatsächlich aufgrund einer Speicherverletzung abbricht und Sie die aktuellste Version (siehe Anfang dieses Kapitels) benutzen, dann sollten Sie folgendes tun:

    % tar xfz ppp-*.src.tar.gz
    % cd ppp*/ppp
    % echo STRIP= >>Makefile
    % echo CFLAGS+=-g >>Makefile
    % make clean all
    % su
    # make install
    # chmod 555 /usr/sbin/ppp
             

Nun ist die installierte Version von ppp mit einem Debugger ausführbar. Sie können ppp nun nur noch als root ausführen, da alle vorherigen Zugriffsrechte aufgehoben worden sind. Achten Sie darauf, in welchem Verzeichnis Sie sich gerade befinden, wenn Sie ppp starten.

Wenn nun wieder eine Speicherverletzung auftreten sollte, wird ppp einen Speicherauszug erzeugen, den Sie in der Datei ppp.core finden. Sie sollten dann folgendes tun:

    % su
    # gdb /usr/sbin/ppp ppp.core
    (gdb) bt
    .....
    (gdb) f 0
    ....
    (gdb) i args
    ....
    (gdb) l
    .....
             

Mit Hilfe all dieser Informationen sollte es möglich sein, das Problem zu diagnostizieren.

Falls Sie mit dem Umgang mit gdb vertraut sind, könnten Sie weitere Einzelheiten herausfinden, z.B. wodurch der Fehler tatsächlich hervorgerufen wurde und die Adressen & Werte der betreffenden Variablen.

Dies war ein bekanntes Problem bei ppp-Konfigurationen, bei denen automatisch dynamische, lokale IP-Adressen mit dem Partner ausgehandelt werden. In der aktuellsten Version ist das Problem behoben - suchen Sie in den Manualpages nach iface.

Das Problem bestand darin, daß, wenn das erste Programm connect(2) aufruft, die IP-Adresse der tun-Schnittstelle dem Socketendpunkt zugeordnet wird. Der Kernel erstellt das erste ausgehende Paket und schreibt es in das tun-Gerät. ppp liest dann das Paket und baut eine Verbindung auf. Falls die Schnittstellenadresse sich nun aufgrund ppp's dynamischer Adreßzuordnung ändert, wird der originale Socketendpunkt ungültig. Alle weiteren Pakete, die zum Partner gesendet werden, werden für gewöhnlich verworfen. Selbst wenn sie nicht verworfen werden würden, würden alle Antworten nicht an den betreffenden Rechner gelangen, weil die IP-Adresse nicht mehr zu diesem Rechner gehört.

Theoretisch gibt es mehrere Möglichkeiten, dieses Problem anzugehen. Am schönsten wäre es, wenn der Partner die gleiche IP-Adresse wieder zuordnen würde, wenn möglich :-) Die derzeitige Version von ppp tut das, aber die meisten anderen Implementierungen nicht.

Die einfachste Maßnahme von unserer Seite wäre die, niemals die IP-Adresse der tun-Schnittstelle zu ändern, sondern stattdessen alle ausgehenden Pakete so zu ändern, daß als Absender-IP-Adresse anstelle der IP-Adresse der Schnittstelle die ausgehandelte IP-Adresse gesetzt wird. Das ist im wesentlichen das, was durch die Option iface-alias in der aktuellsten Version von ppp bewirkt wird (mit Unterstützung von libalias(3) und ppp's -nat Schalter) - alle Schnittstellenadressen werden beibehalten und auf die letzte ausgehandelte Adresse umgesetzt.

Eine andere Alternative (und wahrscheinlich die zuverlässigste) wäre die, einen Systemaufruf zu implementieren der die IP-Adressen aller verbundenen Sockets von einer Adresse in eine andere ändert. ppp würde diesen Aufruf benutzen, um die Sockets aller laufenden Programme zu ändern, nachdem eine neue IP-Adresse ausgehandelt worden ist. Der gleiche Systemaufruf könnte von DHCP-Clients benutzt werden, wenn sie gezwungen werden, einen re-bind() auf ihren Sockets auszuführen.

Noch eine andere Möglichkeit wäre die, das Aktivieren von Schnittstellen ohne IP-Adresse zu erlauben. Ausgehende Paketen würde die IP-Adressee 255.255.255.255 gegeben, bis der erste ioctl() mit SIOCAIFADDR erfolgt. Dies würde in der vollständigen Verbindung des Sockets resultieren. Es wäre die Aufgabe von ppp, die Absender-IP-Adresse zu ändern, allerdings nur dann, wenn sie 255.255.255.255 lautet und nur die IP-Adresse und IP-Prüfsumme müßten geändert werden. Dies wäre allerdings keine besonders elegante Lösung, da der Kernel fehlerhafte Pakete an eine unzureichend konfigurierte Schnittstelle senden würde, in der Annahme, daß andere Mechanismen in der Lage sind, diese Dinge rückwirkend zu beheben.

Der Grund dafür, daß Spiele und andere Programme nicht funktionieren, wenn libalias benutzt wird, ist der, daß der Rechner außerhalb des lokalen Netzes versucht, eine Verbindung aufzubauen und (unaufgefordert) UDP-Pakete an den Rechner innerhalb des lokalen Netzes zu senden. Die Software, die für die NAT zuständig ist, weiß nicht, daß sie diese Pakete an den internen Rechner weiterleiten soll.

Um dies zu beheben, stellen Sie zunächst sicher, daß die Software, mit der Sie Probleme haben, die einzige ist, die gerade läuft. Benutzen Sie dann entweder tcpdump auf der tun-Schnittstelle des Gateways oder aktivieren Sie auf dem Gateway das Logging von TCP/IP (set log +tcp/ip) unter ppp.

Wenn Sie nun das betreffende Programm starten, sollten Sie sehen, wie Pakete den Gateway-Rechner passieren. Wenn von außen etwas zurückkommt, wird es ignoriert (das ist das Problem). Merken Sie sich die Portnummer dieser Pakete und beenden Sie das betreffende Programm. Wiederholen Sie diesen Schritt einige Male, um festzustellen, ob die Portnummern konsistent sind. Falls dem so ist, wird die folgende Zeile im entsprechenden Abschnitt von /etc/ppp/ppp.conf dafür sorgen, daß das Programm funktioniert:

    nat port proto internalmachine:port port
             

wobei für proto entweder tcp oder udp zu setzen ist, internalmachine den Rechner bezeichnet, an den die Pakete geschickt werden sollen und port die betreffende Portnummer.

Sie können das Programm nicht auf einem anderen Rechner benutzen, ohne die obige Zeile abzuändern und die Benutzung des Programms auf zwei internen Rechnern steht außer Frage - schließlich sieht die Außenwelt Ihr gesamtes internes Netz so, als wäre es ein einzelner Rechner.

Falls die Portnummern nicht konsistent sind, gibt es drei weitere Optionen:

1. Ermöglichen Sie die Unterstützung durch libalias. Beispiele für ``spezielle Fälle'' finden Sie in /usr/src/lib/libalias/alias_*.c (alias_ftp.c ist ein schöner Prototyp). Hierzu gehört für gewöhnlich das Lesen bestimmter, erkannter, ausgehender Pakete, die Identifizierung der Instruktion, die den entfernten Rechner dazu veranlaßt, auf einem bestimmten (wahlfreien) Port eine Verbindung zurück zum lokalen Rechner herzustellen, sowie das Erstellen einer ``Route'' in der Aliastabelle, so daß nachfolgende Pakete wissen, wohin sie gehören.

   Dieses ist zwar die komplizierteste Lösung, aber die beste, die auch dafür sorgt, daß die Software auf mehreren Rechnern funktioniert.

2. Benutzen Sie einen Proxy. Die Applikation könnte z.B. socks5 unterstützen, oder (wie im Fall von ``cvsup'') eine Option ``passiv'' besitzen, die stets verhindert, daß verlangt wird, daß der Partner eine Verbindung zurück zur lokalen Maschine aufbaut.

3. Leiten Sie mit nat addr alles zur lokalen Maschine um. Dieses Vorgehen ähnelt dem mit einem Vorschlaghammer.

Noch nicht, aber hieraus könnte eine solche entstehen (falls Interesse besteht). In jedem Beispiel sollte internal durch die IP-Adresse der Maschine ersetzt werden, auf der das Spiel laufen soll.

• Asheron's Call

  nat port udp internal:65000 65000

  Konfigurieren Sie das Spiel manuell auf Port 65000 um. Wenn Sie von mehreren Rechner aus spielen wollen, weisen Sie jedem eine eindeutige Portnummer zu (also 65001, 65002, u.s.w.) und fügen Sie für jede Maschine eine eigene nat port Zeile ein.

• Half Life

  nat port udp internal:27005 27015

• PCAnywhere 8.0

  nat port udp internal:5632 5632

  nat port tcp internal:5631 5631

• Quake

  nat port udp internal:6112 6112

  Alternativ können sie wegen Proxyunterstützung für Quake unter www.battle.net nachsehen.

• Quake 2

  nat port udp internal:27901 27910

• Red Alert

  nat port udp internal:8675 8675

  nat port udp internal:5009 5009

FCS steht für Frame Check Sequence. Jedes ppp-Paket besitzt eine Checksumme, um sicherzustellen, daß die empfangenen Daten dieselben sind, wie die versendeten. Falls die FCS eines ankommenden Paketes fehlerhaft ist, wird das Paket verworfen und der Zähler HDLC FCS wird erhöht. Der HDLC-Fehlerwert kann durch den Befehl show hdlc angezeigt werden.

Falls Ihre Leitung schlecht ist (oder falls Ihr serieller Treiber Pakete verwirft), werden sie gelegentliche FCS-Fehler sehen. Normalerweise lohnt es sich nicht, sich hierüber Gedanken zu machen, obwohl das Kompressionsprotokoll hierdurch wesentlich langsamer wird. Wenn Sie ein externes Modem besitzen, stellen Sie sicher, daß Ihr Kabel ausreichend gegen Interferenzen abgeschirmt ist - das könnte das Problem beseitigen.

Falls Ihre Leitung einfriert, sobald die Verbindung steht, und viele FCS-Fehler auftreten, könnte das daran liegen, daß Ihre Leitung nicht 8-Bit-rein ist. Stellen Sie sicher, daß Ihr Modem keinen Software-Flow-Control (XON/XOFF) verwendet. Falls Ihre Datenschnittstelle Software-Flow-Control verwenden muß, benutzen Sie den Befehl set accmap 0x000a0000, um ppp zu sagen, daß es die Zeichen ^Q und ^S maskieren soll.

Ein weiterer Grund dafür, daß zu viele FCS-Fehler auftreten, könnte der sein, daß das andere Ende aufgehört hat, ppp zu sprechen. Aktivieren Sie async Logging, um festzustellen, ob es sich bei den eingehenden Daten tatsächlich um einen login- oder Shell-Prompt handelt. Wenn Sie am anderen Ende einen Shell-Prompt haben, ist es möglich, durch den Befehl close lcp ppp zu beenden, ohne die Verbindung zu beenden (ein folgender term-Befehl wird Sie wieder mit der Shell auf dem entfernten Rechner verbinden.

Falls nichts in Ihrer Logdatei darauf hindeutet, warum die Verbindung beendet wurde, sollten Sie den Administrator des externen Rechners (Ihren ISP?) fragen, warum die Sitzung beendet worden ist.

Vielen Dank an Michael Wozniak <mwozniak@netcom.ca> für die Erklärung und an Dan Flemming <danflemming@mac.com> für die Lösung für MacOS

Die Ursache des Problems ist ein sogenannter ``Black Hole Router''. MacOS und Windows 98 (und wahrscheinlich auch die anderen Betriebssysteme von Microsoft) senden TCP Pakete, bei denen zum einen die angeforderte Segmentgröße zu groß für einen PPPoE-Rahmen ist (die Default-MTU für Ethernet beträgt 1500 Byte) und bei denen das ``don't fragment'' Bit gesetzt ist (das ist bei TCP allerdings Standard). Außerdem sendet der Router beim Provider nicht die eigentlich notwendigen ``must fragment''-Meldungen zu dem Webserver, von dem Sie gerade eine Seite laden wollen. Es ist auch möglich, daß diese Meldung zwar erzeugt, aber danach von einem Firewall vor dem Webserver abgefangen wird. Wenn Ihnen dieser Webserver nun ein Paket schickt, das nicht in einen PPPoE-Rahmen paßt, dann verwirft der Router dieses Paket und die Seite wird nicht geladen (einige Seiten/Grafiken werden geladen, weil ihre Größe kleiner ist als die MSS). Dies scheint leider der Normalfall zu sein (wenn die Leute doch nur wüßten, wie man einen Router konfiguriert... stöhn...)

Eine der möglichen Lösungen für dieses Problem ist die Erzeugung des folgenden Schlüssels in der Registry des Windows-Clients:

    HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Class\NetTrans\0000\MaxMTU
             

Der Wert des Schlüssels sollte vom Typ String sein und ``1450'' betragen. Der korrekte Wert wäre eigentlich ``1464'', wenn die TCP-Pakete den PPPoE-Rahmen komplett ausfüllen sollen, aber mit ``1450'' erhalten Sie eine Sicherheitsreserve für andere evtl. genutzte IP-Protokolle. Wenn Sie Windows 2000 verwenden, müssen Sie dagegen den Schlüssel Tcpip\Parameters\Interfaces\ID der Netzwerkkarte\MTU benutzen.

Die Knowledge Base von Microsoft enthält weitere Informationen darüber, wie sie die MTU einer Windows-Maschine ändern, damit diese mit einem FreeBSD/NAT/PPPoE-Router korrekt zusammenarbeitet. Vom besonderen Interesse sind die Artikel ``Q158474 - Windows TCPIP Registry Entries'' und ``Q120642 - TCPIP & NBT Configuration Parameters for Windows NT''.

Mit den Bordmitteln von MacOS ist es leider nicht möglich, die TCP/IP-Einstellungen zu verändern. Es gibt jedoch kommerzielle Lösungen wie zum Beispiel OTAdvancedTuner (OT steht für OpenTransport, den TCP/IP-Stack von MacOS) von Sustainable Softworks, mit denen man die TCP/IP-Einstellungen bearbeiten kann. Wenn Sie als MacOS-Anwender NAT benutzen, sollten Sie im entsprechenden drop-down Menü den Punkt ip_interface_MTU auswählen und in der Dialogbox 1450 statt 1500 eingeben. Aktivieren Sie den Punkt Save as Auto Configure und klicken Sie danach auf Make Active.

ppp kennt seit Version 2.3 den Befehl enable tcpmssfixup, mit dem die MSS automatisch korrigiert wird. Wenn Sie einen ältere Version von ppp benutzen müssen, könnte der Port tcpmssd für Sie interessant sein.

Falls alles andere fehlschlägt, senden Sie möglichst umfangreiche Informationen, einschließlich Ihrer Konfigurationsdateien, wie Sie ppp starten, die relevanten Teile Ihrer Logdateien und die Ausgabe des Befehls netstat -rn (vor und nach Aufbau der Verbindung) an die Mailingliste <de-bsd-questions@de.FreeBSD.org> oder die Newsgroup de.comp.os.unix.bsd. Irgend jemand sollte Ihnen dann weiterhelfen.

Wenn der FreeBSD Kernel bootet, testet er die seriellen Schnittstellen, für die er konfiguriert wurde. Sie können entweder Ihrem System aufmerksam beim Booten zusehen und die angezeigten Nachrichten lesen, oder Sie führen den Befehl

    % dmesg | grep sio
             

aus, nachdem Ihr System hochgefahren ist und läuft.

Hier ist ein Beispiel einer Ausgabe nach dem oben genannten Befehl:

    si0: at 0x3f8-0x3ff irq 4 on isa
    si0: type 16550A
    si1: at 0x2f8-0x2ff irq 3 on isa
    si1: type 16550A
             

Es zeigt zwei serielle Schnittstellen. Die erste verwendet Port-Adresse 0x3f8, IRQ 4 und hat einen 16550A UART Chip. Die zweite benutzt ebenfalls einen 16550A UART, jedoch Port-Adresse 0x2f8 und IRQ 3. Modemkarten werden wie serielle Schnittstellen behandelt. Der einzige Unterschied ist, daß an diesen Schnittstellen immer ein Modem ``angeschlossen'' ist.

Der GENERIC Kernel beinhaltet Unterstützung für zwei serielle Schnittstellen, die den im Beispiel genannten Port und IRQ verwenden. Wenn diese Einstellungen nicht richtig für Ihr System sind, Sie Modemkarten hinzugefügt oder mehr serielle Schnittstellen haben als Ihre Kernel-Konfiguration zuläßt, konfigurieren Sie Ihren Kernel einfach neu. In dem Kapitel über die Kernelkonfiguration finden Sie mehr Details.

Die vorherige Frage sollte darauf eine Antwort geben.

Keine Sorge, die wurden mit den ttydX Geräten zusammengeführt. Sie müssen allerdings die alten Konfigurationsdateien ändern.

Die dritte serielle Schnittstelle, sio2 (bekannt als COM3 in DOS/Windows), ist /dev/cuaa2 für Geräte mit abgehenden Verbindungen und /dev/ttyd2 für Geräte mit eingehenden Verbindungen. Was ist der Unterschied zwischen den beiden Geräteklassen?

Sie benutzen ttydX für eingehende Verbindungen. Wird /dev/ttydX im blockierenden Modus geöffnet, wartet ein Prozeß darauf, daß das entsprechende cuaaX Gerät inaktiv und der Empfangssignalpegel [2] aktiv ist. Wird das cuaaX Gerät geöffnet, vergewissert es sich, daß die serielle Schnittstelle nicht bereits von dem ttydX Gerät in Gebrauch ist. Sollte die Schnittstelle verfügbar sein, ``stiehlt'' es sie von dem ttydX Gerät. Das cuaaX Gerät kümmert sich nicht um Trägersignalerkennung. Mit diesem Schema und einem automatisch antwortenden Modem, können sich Benutzer von außen einloggen, Sie können weiterhin mit dem selben Modem wählen und das System kümmert sich um die Konflikte.

Die Sektion über die Kernelkonfiguration bietet Informationen darüber, wie Sie Ihren Kernel konfigurieren. Für eine Karte mit mehreren seriellen Schnittstellen, schreiben Sie eine sio(4) Zeile für jede serielle Schnittstelle auf der Karte in die Kernel-Konfigurationsdatei. Aber achten Sie darauf, den IRQ und die Verktorbezeichnung nur in einem der Einträge zu plazieren. Alle seriellen Schnittstellen auf der Karte sollten sich einen IRQ teilen. Daher sollten Sie den IRQ nur beim letzten Eintrag angeben. Aktivieren Sie auch die COM_MULTIPORT Option.

Das folgende Beispiel ist geeignet für eine AST Karte mit 4 seriellen Schnittstellen, die IRQ 7 benutzt:

    options "COM_MULTIPORT"
    device sio4 at isa? port 0x2a0 tty flags 0x781
    device sio5 at isa? port 0x2a8 tty flags 0x781
    device sio6 at isa? port 0x2b0 tty flags 0x781
    device sio7 at isa? port 0x2b8 tty flags 0x781 irq 7 vector siointr
             

Die Flags zeigen an, daß die Master-Schnittstelle die Minor-Nummer 7 (0x700) hat, Diagnosen während des Bootens ermöglicht sind (0x080), und daß sich alle Schnittstellen einen IRQ teilen (0x001).

Noch nicht. Sie müssen für jede Karte einen anderen IRQ verwenden.

Das ttydX (oder cuaaX) Gerät ist das reguläre Gerät, das man in Anwendungen öffnet. Wenn ein Prozeß es öffnet, hat es die voreingestellten Terminal Eingabe/Ausgabe-Einstellungen. Sie können diese Einstellungen mit dem Befehl

    # stty -a -f /dev/ttyd1
             

ansehen. Wenn Sie die Einstellungen für dieses Gerät ändern, sind die Einstellungen gültig, bis das Gerät geschlossen wird. Wird es danach geöffnet, hat es wieder die vorgegebenen Einstellungen. Um Änderungen an den vorgegebenen Einstellungen vorzunehmen, können Sie das Anfangsstatus-Gerät öffnen und dessen Einstellungen anpassen. Um zum Beispiel den CLOCAL Modus, 8 Bits und XON/XOFF Datenflußkontrolle als Standard für ttyd5 einzustellen, geben Sie

    # stty -f /dev/ttyid5 clocal cs8 ixon ixoff
             

ein. Eine gute Stelle um dies zu tun ist in /etc/rc.serial. Jetzt hat eine Anwendung diese Einstellungen als Standardwerte, wenn sie ttyd5 öffnet. Die Anwendung kann die Einstellungen jedoch immer noch nach Belieben verändern.

Man aber kann auch bestimme Einstellungen davor schützen, von einer Anwendung verändert zu werden, indem man Veränderungen am ``lock state'' Gerät vornimmt. Um beispielsweise die Geschwindigkeit von ttyd5 auf 57600 bps festzusetzen:

    # stty -f /dev/ttyld5 57600
             

Wenn jetzt eine Anwendung ttyd5 öffnet und versucht die Geschwindigkeit zu verändern, wird diese bei 57600 bps bleiben.

Natürlich sollten Sie das Schreiben auf die Anfangsstatus- und lock state-Geräte nur root erlauben. Das MAKEDEV(8) Skript tut dies nicht, wenn es die Geräte-Einträge erstellt.

Also Sie wollen ein Internet Service Provider werden, ja? Als erstes brauchen Sie eines oder mehrere Modems, die automatisches Antworten beherrschen. Ihr Modem sollte auf Trägersignalerkennung reagieren und nicht fortlaufend die Leitung offen halten. Es muß auflegen und sich neu initialisieren können, wenn die ``Data Terminal Ready'' (DTR) Leitung ausgeschaltet wird. Es sollte wahrscheinlich RTS/CTS oder gar keine lokale Datenflußkontrolle benutzen. Zuletzt muß es eine konstante Geschwindigkeit zwischen dem Computer und sich selbst verwenden, aber es sollte (um die Anrufer freundlich zu behandeln) eine Geschwindigkeit zwischen sich und dem entfernten Modem aushandeln können.

Für viele Modems, die mit dem Hayes Befehlssatz kompatibel sind, erzeugt der folgende Befehl diese Einstellungen und legt sie im nicht-flüchtigen Speicher ab:

    AT &C1 &D3 &K3 &Q6 S0=1 &W

Die Sektion über das Senden von AT-Befehlen bietet weitere Informationen, wie man diese Einstellungen vornimmt, ohne zu einem MS-DOS Terminal Programm zu flüchten.

Als nächstes erstellen Sie einen Eintrag in /etc/ttys für das Modem. Diese Datei listet alle Schnittstellen auf, auf denen das Betriebssystem Einlogversuche erwartet. Fügen Sie eine solche Zeile hinzu:

    ttyd1 "/usr/libexec/getty std 57600" dialup on insecure
             

Diese Zeile bedeutet, daß an der zweiten seriellen Schnittstelle (/dev/ttyd1) ein Modem angeschlossen ist, das mit 57600 bps läuft und keine Parität besitzt (std.57600 aus /etc/gettytab). Der Terminal-Typ für diese Schnittstelle ist ``dialup'' (Einwahl). Die Schnittstelle ist eingeschaltet (on) und ``unsicher'' (unsecure) -- das bedeutet, man kann sich über diese Schnittstelle nicht als root einloggen. Für Einwahlanschlüsse wie diesen, benutzen Sie den ttydX Eintrag.

Es ist relativ geläufig, dialup als Terminal-Typ zu verwenden. Viele Benutzer richten in ihren .profile oder .login Dateien eine Abfrage für das eigentliche Terminal ein, wenn der Start-Typ dialup ist. Das Beispiel zeigt die Schnittstelle als unsicher und um über diese Schnittstelle root zu werden, müssen Sie sich als normaler Benutzer einloggen und su benutzen. Wenn sie secure (``sicher'') als Einstellung verwenden, kann sich root direkt einloggen.

Nachdem Sie Modifikationen in /etc/ttys vorgenommen haben, müssen Sie ein hangup oder HUP Signal an init(8) senden:

    # kill -HUP 1
             

Das bringt init dazu, die Datei /etc/ttys neu einzulesen. init startet dann an allen als eingeschaltet (on) markierten Schnittstellen die getty-Prozesse. Sie können herausfinden ob noch Logins für Ihre Schnittstelle verfügbar sind, wenn Sie folgendes eingeben:

    % ps -ax | grep '[t]tyd1'
             

Sie sollten etwas sehen, das so ähnlich aussieht wie:

    747 ?? I    0:00:04 /usr/libexec/getty std.57600 ttyd1
             

Wenn Sie einen anderen Computer als Terminal für Ihr FreeBSD System verwenden wollen, verbinden Sie die beiden seriellen Schnittstellen mit einem Nullmodem-Kabel. Wenn Sie ein ``echtes'' (Hardware-)Terminal benutzen, lesen Sie die Begleitinformationen.

Ändern Sie /etc/ttys wie oben angegeben. Wenn Sie zum Beispiel ein WYSE-50 Terminal mit der fünften seriellen Schnittstelle verbinden wollen, schreiben Sie einen Eintrag wie diesen:

    ttyd4 "/usr/libexec/getty std.38400" wyse50 on secure
             

Das Beispiel zeigt, daß die Schnittstelle an /dev/ttyd4 mit einem wyse50 Terminal mit 38400 bps und ohne Parität (std.38400 aus /etc/gettytab) verbunden ist und root Logins möglich sind (secure).

Vielleicht sind auf Ihrem System die Programme tip(1) und cu(1) nur von uucp und der Gruppe dialer ausführbar. Sie können die Gruppe dialer verwenden, um zu kontrollieren wer Zugriff auf Ihr Modem oder entfernte Systeme hat. Fügen Sie sich einfach selbst zur Gruppe dialer hinzu.

Als Alternative können Sie jeden Benutzer auf Ihrem System tip und cu verwenden lassen, dazu müssen Sie das folgende eingeben:

    # chmod 4511 /usr/bin/cu
    # chmod 4511 /usr/bin/tip
             

Eigentlich ist die Onlinehilfe für tip(1) nicht mehr aktuell. Es gibt einen eingebauten, allgemeinen Hayes Wähler. Verwenden Sie einfach at=hayes in /etc/remote.

Der Hayes Treiber ist nicht schlau genug, um ein paar der erweiterten Merkmale von neueren Modems zu erkennen -- Nachrichten wie BUSY, NO DIALTONE oder CONNECT 115200 verwirren ihn nur. Sie sollten diese Nachrichten mit Hilfe von ATX0&W abschalten, wenn Sie tip benutzen.

Das Anwahl-Timeout von tip beträgt 60 Sekunden. Ihr Modem sollte weniger verwenden, oder tip denkt, daß ein Kommunikationsfehler vorliegt. Versuchen Sie es mit ATS7=45&W.

Tatsächlich unterstützt die ausgelieferte Version von tip es noch nicht vollständig. Die Lösung ist tipconf.h im Verzeichnis /usr/src/usr.bin/tip/tip zu editieren. Dafür benötigen Sie natürlich die Quellcode Distribution.

Editieren Sie die Zeile #define HAYES 0 in #define HAYES 1 um. Dann führen Sie make und make install aus. Es sollte jetzt funktionieren.

Erstellen Sie einen sogenannten direct Eintrag in /etc/remote. Wenn Ihr Modem zum Beispiel an der ersten seriellen Schnittstelle, /dev/cuaa0, angeschlossen ist, dann fügen Sie die folgende Zeile hinzu:

    cuaa0:dv=/dev/cuaa0:br#19200:pa=none
             

Verwenden Sie die höchste bps Rate, die Ihr Modem in der br Fähigkeit unterstützt. Geben Sie dann tip cuaa0 ein und Sie sind mit Ihrem Modem verbunden.

Wenn auf Ihrem System keine /dev/cuaa0 Datei existiert, geben Sie folgendes ein:

    # cd /dev
    # sh MAKEDEV cuaa0
             

Oder benutzen Sie cu als root mit dem folgenden Befehl

    # cu -lline -sspeed
             

line steht für die serielle Schnittstelle (/dev/cuaa0) und speed für die Geschwindigkeit (57600). Wenn Sie mit dem Eingeben der AT Befehle fertig sind, beenden Sie mit ~..

Das <@> Zeichen in der Telefonnummerfähigkeit sagt tip, daß es in der Datei /etc/phones nach einer Nummer suchen soll. Aber <@> ist auch ein spezielles Zeichen in den Dateien, in denen Fähigkeiten beschrieben werden, wie /etc/remote. Schreiben Sie es mit einem '\' (backslash):

    pn=\@

Stellen Sie einen ``allgemeinen'' Eintrag in /etc/remote. Zum Beispiel:

    tip115200|Dial any phone number at 115200 bps:\
          :dv=/dev/cuaa0:br#115200:at=hayes:pa=none:du:
    tip57600|Dial any phone number at 57600 bps:\
          :dv=/dev/cuaa0:br#57600:at=hayes:pa=none:du:
             

Mit einem Befehl wie tip -115200 5551234 können Sie dann wählen. Sollten Sie cu(1) im Gegensatz zu tip(1) bevorzugen, verwenden Sie einen allgemeinen cu-Eintrag:

    cu115200|Use cu to dial any number at 115200bps:\
            :dv=/dev/cuaa1:br#57600:at=hayes:pa=none:du:
             

Zum Wählen können Sie dann cu 5551234 -s 115200 eingeben.

Schreiben Sie einen tip1200 oder einen cu1200 Eintrag, aber geben Sie auch die bps Rate an, die Ihr Modem wirklich unterstützt. Leider denkt tip(1), daß 1200 bps ein guter Standardwert ist und deswegen sucht es nach einem tip1200-Eintrag. Natürlich müssen Sie nicht wirklich 1200 bps benutzen.

Sie müssen nicht warten bis Sie verbunden sind, und jedesmal CONNECT Rechner eingeben, benutzen Sie tip's cm Fähigkeit. Sie können diese Einträge in /etc/remote verwenden:

    pain|pain.deep13.com|Forrester's machine:\
            :cm=CONNECT pain\n:tc=deep13:
    muffin|muffin.deep13.com|Frank's machine:\
            :cm=CONNECT muffin\n:tc=deep13:
    deep13:Gizmonics Institute terminal server:\
            :dv=/dev/cuaa2:br#38400:at=hayes:du:pa=none:pn=5551234:
             

Mit den Befehlen tip pain oder tip muffin können Sie eine Verbindungen zu den Rechnern pain oder muffin herstellen; mit tip deep13 verbinden Sie sich mit dem Terminal Server.

Das ist oft ein Problem, wenn eine Universität mehrere Telefonleitungen hat und viele tausend Studenten diese benutzen wollen.

Erstellen Sie einen Eintrag für Ihre Universität in /etc/remote und benutzen Sie <\@> für die pn Fähigkeit:

    big-university:\
            :pn=\@:tc=dialout
    dialout:\
            :dv=/dev/cuaa3:br#9600:at=courier:du:pa=none:
             

Listen Sie die Telefonnummern für die Universitäten in /etc/phones auf:

    big-university 5551111
    big-university 5551112
    big-university 5551113
    big-university 5551114
             

tip(1) testet jede der Nummern in der aufgelisteten Reihenfolge und gibt dann auf. Möchten Sie, daß tip beim Versuchen eine Verbindung herzustellen nicht aufgibt, lassen Sie es in einer while-Schleife laufen.

CTRL-P ist das voreingestellte Zeichen, mit dem eine Übertragung erzwungen werden kann und wird benutzt, um tip(1) zu sagen, daß das nächste Zeichen direkt gesendet werden soll und nicht als Fluchtzeichen interpretiert werden soll. Mit Hilfe der ~s Fluchtsequenz, mit der man Variablen setzen kann, können Sie jedes andere Zeichen als ``force''-Zeichen definieren.

Geben Sie ~sforce=zeichen ein und drücken sie Enter. Für zeichen können Sie ein beliebiges einzelnes Zeichen einsetzen. Wenn Sie zeichen weglassen, ist das ``force''-Zeichen ``nul'', das Sie mit CTRL-2 oder CTRL-SPACE eingeben können. Ein guter Wert für zeichen ist SHIFT+CTRL+6, welches ich erst auf ein paar Terminal-Servern in Benutzung gesehen habe.

Sie können das ``force''-Zeichen auch bestimmen, indem Sie in $HOME/.tiprc das folgende einstellen:

    force=single-char
             

Sie müssen CTRL-A eingegeben haben, das ``raise''-Zeichen von tip(1) das speziell für Leute mit defekten caps-lock Tasten eingerichtet wurde. Benutzen Sie ~s wie oben und setzen Sie die Variable ``raisechar'' auf etwas, das Ihnen angemessen erscheint. Tatsächlich kann die Variable auf das gleiche Zeichen wie das ``force''-Zeichen gesetzt werden, wenn Sie diese Fähigkeiten niemals benutzen wollen.

Hier ist ein Muster der .tiprc Datei, perfekt für emacs Benutzer die oft CTRL-2 und CTRL-A tippen müssen:

    force=^^
    raisechar=^^
             

Das ^^ steht für SHIFT-CTRL-6.

Wenn Sie mit einem anderen UNIX-System kommunizieren, können Sie Dateien senden und empfangen -- mit ~p (put) und ~t (take). Diese Befehle lassen cat(1) und echo(1) auf dem entfernten System laufen, um Dateien zu akzeptieren und zu senden. Die Syntax ist:

    ~p <local-file> [<remote-file>]
    ~t <remote-file> [<local-file>]
             

Es gibt keine Fehlerkontrolle, deshalb sollten Sie besser ein anderes Protokoll benutzen, wie zmodem.

Zuerst installieren Sie ein zmodem Programm aus der Ports-Sammlung (eines der beiden aus der comms-Kategorie, lrzsz oder rzsz).

Um Dateien zu empfangen, starten Sie das Programm zum Senden auf dem entfernten Computer. Drücken Sie dann Enter gefolgt von ~C rz (oder ~C lrz, wenn Sie lrzsz installiert haben), um diese lokal zu empfangen.

Um Dateien zu senden, starten Sie das Programm zum empfangen auf dem entfernten Computer. Drücken Sie dann Enter gefolgt von ~C sz Dateien (oder ~C lsz Dateien), um sie zum entfernten System zu senden.

Hauptplatinen und Karten mit Acer UARTs werden im FreeBSD sio test nicht richtig erkannt. Sie erhalten einen Patch von www.lemis.com, mit dem Sie das Problem beheben können.

Es sieht nur so aus, als ob FreeBSD mehr Swap benutzt, als Linux. Tatsächlich ist dies nicht der Fall. In dieser Hinsicht besteht der Hauptunterschied zwischen FreeBSD und Linux darin, daß FreeBSD vorbeugend vollkommen untätige, unbenutzte Seiten aus dem Hauptspeicher in den Swap-Bereich auslagert, um mehr Hauptspeicher für die aktive Nutzung zur Verfügung zu stellen. Linux tendiert dazu, nur als letzten Ausweg Seiten in den Swap-Bereich auszulagern. Die spürbar höhere Nutzung des Swap-Speichers wird durch die effizientere Nutzung des Hauptspeichers wieder ausgeglichen.

Beachten Sie, daß FreeBSD in dieser Hinsicht zwar vorbeugend arbeitet, es entscheidet jedoch nicht willkürlich, Seiten auszulagern, wenn das System vollkommen untätig ist. Deshalb werden Sie feststellen, daß nicht alle Seiten Ihres Systems ausgelagert wurden, wenn Sie morgens aufstehen, nachdem das System eine Nacht lang nicht benutzt worden ist.

Die Antwort ist ganz einfach: Freier Speicher ist verschwendeter Speicher. Der FreeBSD Kernel verwendet den von den Programmen nicht genutzten Speicher automatisch für den Plattencache. Die in top(1) für Inact, Cache und Buf gemeldeten Werte stehen alle für zwischengespeicherte Daten mit unterschiedlichem Alter. Wenn das System wiederholt auf Daten zugreifen muß, braucht es nicht auf die langsame Platte zuzugreifen, da die Daten noch zwischengespeichert sind. Dadurch erhöht sich die Performance. Ganz generell ist es ein gutes Zeichen, wenn top(1) einen kleinen Wert bei Free anzeigt, solange der Wert nicht extrem klein ist.

Anmerkung des Übersetzers: Mit ``extrem klein'' sind hier Werte unterhalb 512 KByte gemeint.

Um zu verstehen, warum FreeBSD das Format ELF benutzt, müssen Sie zunächst etwas über die drei gegenwärtig ``dominanten'' ausführbaren Formate für UNIX wissen:

• a.out(5)

  Das älteste und ``klassische'' UNIX-Objektformat. Es benutzt einen kurzen, kompakten Header mit einer magischen Nummer am Anfang, die oft benutzt wird, um das Format zu charakterisieren (weitere Details finden Sie unter a.out(5)). Es enthält drei geladene Segmente: .text, .data und .bss, sowie eine Symboltabelle und eine Stringtabelle.

• COFF

  Das Objektformat von SVR3. Der Header enthält nun eine "Sectiontable". Man kann also mit mehr als nur den Sections .text, .data und .bss arbeiten.

• ELF

  Der Nachfolger von COFF. Kennzeichnend sind mehrere Sections und mögliche 32-Bit- oder 64-Bit-Werte. Ein wesentlicher Nachteil: ELF wurde auch unter der Annahme entworfen, daß es nur ein ABI (Application Binary Interface) pro Systemarchitektur geben wird. Tatsächlich ist diese Annahme falsch - nicht einmal für die kommerzielle SYSV-Welt (in der es mindestens drei ABIs gibt: SVR4, Solaris, SCO) trifft sie zu.

  FreeBSD versucht, dieses Problem zu umgehen, indem ein Utility bereitgestellt wird, um ausführbare Dateien im ELF-Format mit Informationen über die ABI zu versehen, zu der sie passen. Weitere Informationen finden Sie in der Manualpage brandelf(1).

FreeBSD kommt aus dem ``klassischen'' Lager und verwendete traditionell das Format a.out(5), eine Technologie, die bereits über viele BSD-Releases hinweg eingesetzt und geprüft worden ist. Obwohl es bereits seit einiger Zeit möglich war, auf einem FreeBSD-System auch Binaries (und Kernel) im ELF-Format zu erstellen und auszuführen, wiedersetzte FreeBSD sich anfangs dem ``Druck'', auf ELF als Standardformat umzusteigen. Warum? Nun, als das Linux-Lager die schmerzhafte Umstellung auf ELF durchführte, ging es nicht so sehr darum, dem ausführbaren Format a.out zu entkommen, als dem unflexiblen, auf Sprungtabellen basierten Mechanismus für "Shared Libraries", der die Konstruktion von Shared Libraries für Hersteller und Entwickler gleichermaßen sehr kompliziert machte. Da die verfügbaren ELF-Werkzeuge eine Lösung für das Problem mit den Shared Libraries anboten und ohnehin generell als ``ein Schritt vorwärts'' angesehen wurden, wurde der Auffand für die Umstellung als notwendig akzeptiert und die Umstellung wurde durchgeführt.

Im Fall von FreeBSD ist der Mechanismus von Shared Libraries enger an den Mechanismus im Stil von Sun's SunOS angelehnt und als solcher sehr einfach zu verwenden. Seit Version 3.0 unterstützt FreeBSD ELF-Binaries jedoch offiziell als das Standardformat. Obwohl das ausführbare Format a.out uns gute Dienste geleistet hat, hat das GNU-Team, das den von uns verwendeten Compiler erstellt, die Unterstützung des a.out-Formats eingestellt. Dies zwang uns dazu, abweichende Versionen der Compiler und Linker beizubehalten und hinderte uns daran, Nutzen aus den aktuellen Entwicklungsergebnisen von GNU zu ziehen. Auch die Anforderungen von ISO-C++, besonders Konstruktoren und Destruktoren, haben zur Unterstützung von ELF in zukünftigen Versionen von FreeBSD geführt.

In alter, grauer Vorzeit gab es simple Hardware. Diese simple Hardware unterstützte ein einfaches, kleines System. a.out war absolut passend für die Aufgabe, Binaries auf diesem simplen System (eine PDP-11) darzustellen. Als UNIX von diesem simplen System portiert wurde, wurde auch das a.out-Format beibehalten, weil es für die frühen Portierungen auf Architekturen wie den Motorola 68000, VAXe usw. ausreichte.

Dann dachte sich ein schlauer Hardware-Ingenieur, daß wenn er Software zwingen könnte, einige Tricks anzustellen, es ihm möglich wäre, ein paar Gatter im Design zu sparen, und seinen CPU-Kern schneller zu machen. Obgleich es dazu gebracht wurde, mit dieser neuen Art von Hardware (heute als RISC bekannt) zu arbeiten, war a.out für diese Hardware schlecht geeignet. Deshalb wurde viele neue Formate entwickelt, um eine bessere Leistung auf dieser Hardware zu erreichen, als mit dem begrenzten, simplen a.out-Format. Dinge wie COFF, ECOFF und einige andere obskure wurden erdacht und ihre Grenzen untersucht, bevor die Dinge sich in Richtung ELF entwickelten.

Hinzu kam, daß die Größe von Programmen gewaltig wurden und Festplatten (und physikalischer Speicher) immer noch relativ klein waren. Also wurde das Konzept von Shared Libraries geboren. Das VM-System wurde auch immer fortgeschrittener. Obwohl bei jedem dieser Fortschritte das a.out-Format benutzt worden ist, wurde sein Nutzen mit jedem neuen Merkmal mehr und mehr gedehnt. Zusätzlich wollte man Dinge dynamisch zur Ausführungszeit laden, oder Teile ihres Programms nach der Initialisierung wegwerfen, um Hauptspeicher und/oder Swap-Speicher zu sparen. Programmiersprachen wurden immer fortschrittlicher und man wollte, daß Code automatisch vor der main-Funktion aufgerufen wird. Das a.out-Format wurde oft überarbeitet, um alle diese Dinge zu ermöglichen und sie funktionierten auch für einige Zeit. a.out konnte diese Probleme nicht ohne ein ständiges Ansteigen eines Overheads im Code und in der Komplexität handhaben. Obwohl ELF viele dieser Probleme löste, wäre es sehr aufwendig, ein System umzustellen, das im Grunde genommen funktionierte. Also mußte ELF warten, bis es aufwendiger war, bei a.out zu bleiben, als zu ELF überzugehen.

Im Laufe der Zeit haben sich die Erstellungswerkzeuge, von denen FreeBSD seine Erstellungswerkzeuge abgeleitet hat (speziell der Assembler und der Loader), in zwei parallele Zweige entwickelt. Im FreeBSD-Zweig wurden Shared Libraries hinzugefügt und einige Fehler behoben. Das GNU-Team, das diese Programme ursprünglich geschrieben hat, hat sie umgeschrieben und eine simplere Unterstützung zur Erstellung von Cross-Compilern durch beliebiges Einschalten verschiedener Formate usw. hinzugefügt. Viele Leute wollten Cross-Compiler für FreeBSD erstellen, aber sie hatten kein Glück, denn FreeBSD's ältere Sourcen für as und ld waren hierzu nicht geeignet. Die neuen GNU-Werkzeuge (binutils) unterstützen Cross-Compilierung, ELF, Shared Libraries, C++-Erweiterungen usw. Weiterhin geben viele Hersteller ELF-Binaries heraus und es ist gut, wenn FreeBSD sie ausführen kann. Und wenn es ELF-Binaries ausführt, warum dann auch noch a.out behalten? Es ist ein müdes, altes Pferd, daß sich für eine lange Zeit als nützlich erwiesen hat, aber es ist an der Zeit, es für seine langen, treuen Dienstjahre auf die Weide zu schicken.

ELF ist ausdrucksfähiger als a.out und gestattet eine bessere Erweiterbarkeit des Basissystems. Die ELF-Werkzeuge werden besser gewartet und bieten Unterstützung von Cross-Compilierung, was für viele Leute wichtig ist. ELF mag etwas langsamer sein, als a.out, aber zu versuchen, das zu messen, könnte schwierig werden. Es gibt unzählige Details, in denen sich die beiden Formate unterscheiden, wie sie Pages abbilden, Initialisierungscode handhaben usw. Keins davon ist sehr wichtig, aber es sind Unterschiede. Irgendwann wird die Unterstützung für Programme im a.out-Format aus dem GENERIC Kernel entfernt werden. Wenn es dann keinen oder kaum noch Bedarf für die Unterstützung dieses Formates gibt, werden die entsprechenden Routinen ganz entfernt werden.

Für symbolische Links gibt es keine separaten Zugriffsrechte und standardmäßig folgt chmod(1) dem Link nicht; die Zugriffsrechte für die Datei, auf die der symbolische Link zeigt, werden also nicht verändert. Wenn Sie eine Datei mit dem Namen foo und einen auf diese Datei zeigenden symbolischen Link mit dem Namen bar haben, wird das folgende Kommando niemals einen Fehler melden.

    % chmod g-w bar
             

Trotzdem werden die Zugriffsrechte für foo nicht geändert.

Hierzu müssen Sie entweder -H oder -L zusammen mit der Option -R benutzen. Weitere Informationen finden Sie in den Manualpages chmod(1) und symlink(7).

Sie denken vielleicht, daß es leicht sein sollte, UT_NAMESIZE zu ändern, das ganze System neu zu erstellen und das dann alles funktionieren müßte. Unglücklicherweise gibt es oft dutzende Applikationen und Utilities (einschließlich Systemwerkzeuge), bei denen kleine Zahlen (nicht immer 8 oder 9, sondern auch sonderbare, wie 15 und 20) in Strukturen und Puffern fest codiert sind. Hierdurch erhalten Sie nicht nur unbrauchbare Logdateien (weil variabel lange Sätze ausgegeben werden, wo Sätze fester Länge erwartet werden), sondern es kann dazu führen, daß Sun's NIS-Clients nicht mehr funktionieren und möglicherweise andere Probleme bei der Interaktion mit anderen UNIX-Systemen verursachen.

In FreeBSD 3.0 und späteren wurde die maximale Länge für Namen auf 16 Zeichen erweitert und die unterschiedlichen Utilities mit fest codierten Namenslängen wurden gefunden und bereinigt. Die Tatsache, daß hiervon so viele Bereiche des Systems betroffen waren, ist der Grund, warum diese Änderung nicht vor 3.0 durchgeführt worden ist.

Wenn Sie sich absolut sicher sind, daß Sie diese Art von Problemen selbst finden und bereinigen können, wenn und falls sie auftreten, dann können Sie die Länge von Loginnamen in früheren Versionen ändern, indem Sie /usr/include/utmp.h editieren und UT_NAMESIZE entsprechend ändern. Sie müssen MAXLOGNAME in /usr/include/sys/param.h auch entsprechend der Änderung von UT_NAMESIZE ändern. Schließlich, vergessen Sie nicht, daß /usr/include jedesmal aktualisiert wird, wenn Sie von den Sourcen aus Erstellen! Ändern Sie stattdessen die entsprechen Dateien in /usr/src/...

Ja, ab Version 3.0 können Sie die DOS-Emulation doscmd der Firma BSDi benutzen, die integriert und erweitert wurde. Schicken Sie eine Mail an The FreeBSD emulation discussion list, wenn Sie daran interessiert sind, an den laufenden Bemühungen teilzunehmen!

Für Systeme vor 3.0 gibt es ein nettes Utility pcemu in der Ports-Sammlung, das einen 8088 und genug BIOS-Dienste emuliert, um DOS-Applikationen im Textmodus auszuführen. Hierzu wird das X Window-System benötigt (erhältlich als XFree86).

Das FreeBSD-Projekt bietet zwar keinen freien Zugang zu seinen Servern an; andere Firmen bieten jedoch frei zugängliche Unix-Systeme. Die Kosten variieren und es kann sein, daß nicht alle Dienste zur Verfügung stehen.

Arbornet, Inc, auch als M-Net bekannt, bietet seit 1983 uneingeschränkten Zugang zu Unix-Systemen. Zunächst wurde eine Altos-Maschine mit System III benutzt, 1991 erfolgte dann der Wechsel zu BSD/OS. Im Juni 2000 erfolgte ein erneuter Wechsel, diesmal zu FreeBSD. M-Net bietet Zugang mit Telnet und SSH und den Zugang zur gesammten Software von FreeBSD. Allerdings ist der Zugriff auf das Netzwerk auf Mitglieder und Gönner beschränkt, die eine Spende an die nicht-kommerzielle Organisation geleistet haben. M-Net stellt zusätzlich ein Mailbox-System und einen interaktiven Chat zur Verfügung.

Grex bietet ein ganz ähnlichen Dienst wie M-Net an, dazu gehören auch das Mailbox-System und der interaktive Chat. Allerdings wird eine SUN4M mit SunOS benutzt.

Der Name SUP steht für Software Update Protocol und wurde von der CMU (Carnegie Mellon University) entwickelt, um ihre Entwicklungszweige zu synchronisieren. Wir haben es benutzt, um entfernte Sites mit unseren zentralen Quellcodeentwicklungen zu synchronisieren.

SUP ist nicht sehr bandbreitenfreundlich und wurde abgelöst. Die derzeit empfohlene Methode, um Ihren Quellcode auf dem neuesten Stand zu halten ist Handbucheintrag zu CVSup.

Q. Hat irgend jemand Temperaturmessungen durchgeführt, während FreeBSD läuft? Ich weiß, daß Linux cooler läuft, als DOS, aber niemals gesehen, daß FreeBSD erwähnt wurde. Es scheint sehr heiß zu laufen.

A. Nein, aber wir haben zahlreiche Geschmackstests mit verblendeten Freiwilligen durchgeführt, denen ausßerdem zuvor 250 Mikrogramm LSD-25 verabreicht wurden. 35% der Freiwilligen sagte, daß FreeBSD nach Orange schmeckte, Linux hingegen schmecke wie ``purple haze'' (Anm. d. Übersetzers: Song von Jimmy Hendrix und LSD-Marke). Keine der Gruppen hat besondere Abweichungen der Temperatur erwähnt. Eventuell hätten wir sämtliche Ergebnisse dieser Untersuchung fortwerfen sollen, als wir festgestellt haben, daß zu viele der Freiwillingen den Raum während der Tests verlassen haben und dadurch die Ergebnisse verfälscht haben. Wir glauben, daß die meisten der Freiwilligen nun bei Apple sind und an ihrer neuen ``scratch and sniff'' Oberfläche arbeiten. Es ist ein lustiges, altes Geschäft, in dem wir uns befinden!

Ernsthaft, FreeBSD und Linux benutzen beide die Instruktion HLT (halt), wenn das System untätig ist, wodurch der Energieverbrauch und dadurch die produzierte Wärme reduziert wird. Falls Sie auch noch APM (advanced power management) konfiguriert haben, kann FreeBSD Ihre CPU auch in einen Low-Power-Modus bringen.

Q. Gibt es irgend etwas ``seltsames'', das FreeBSD tut, wenn ich den Kernel kompiliere, das dazu führt, daß der Speicher ein kratzendes Geräusch macht? Bei der Kompilierung (und auch für einen kurzen Moment nach der Erkennung des Floppy-Laufwerks beim Hochfahren), kommt ein seltsames kratzendes Geräusch von etwas das die Speicherbänke zu sein scheinen.

A. Ja! In der BSD-Dokumentation finden Sie häufige Verweise auf ``Daemons'' und was die meisten Leute nicht wissen, ist, daß diese sich auf echte, nicht-körperlichen Wesen beziehen, die Besitz von Ihrem Computer ergriffen haben. Das kratzende Geräusch, das von Ihrem Speicher kommt, ist in Wirklichkeit hochtöniges Flüstern, das unter den Daemons ausgetauscht wird, während Sie entscheiden, wie Sie die verschiedenen Systemadministrationsaufgaben, am besten erledigen.

Wenn Sie das Geräusch stört, wird ein fdisk /mbr sie vertreiben, aber wundern Sie sich nicht, wenn sie feindlich reagieren und versuchen, Sie aufzuhalten. Wenn Sie während der Ausführung zu irgendeinem Zeitpunkt die teuflische Stimme von Bill Gates aus dem eingebauten Lautsprecher kommen hören, laufen Sie weg und sehen Sie sich auf keinen Fall um! Befreit von dem ausgleichenden Einfluß der BSD Dämonen sind die beiden Dämonen von DOS und Windows oft dazu in der Lage, die totale Kontrolle über Ihre Maschine für die ewige Verdammung Ihrer Seele zurückzuerlangen. Da Sie jetzt die Wahrheit kennen, würden Sie es vorziehen, sich an die Geräsche zu gewöhnen, wenn Sie die Wahl hätten.

MFC ist ein Acronym für ``Merged From -Current''. Es wird in den CVS-Logs benutzt, um zu kennzeichnen, wenn eine Änderung vom CURRENT-Zweig in den STABLE-Zweig übernommen worden ist.

Es steht für etwas in einer geheimen Sprache, das nur Mitglieder wissen können. Es kann nicht wörtlich übersetzt werden, aber wir können Ihnen sagen, daß die Übersetzung von BSD etwas zwischen ``Formel-1 Team'', ``Pinguine sind ein leckerer Imbiß'' und ``Wir haben einen besseren Sinn für Humor als Linux'' ist :-)

Ernsthaft, BSD ist ein Acronym für ``Berkley Software Distribution''. Das ist der Name, den die Berkley CSRG (Computer Systems Research Group) damals für ihre UNIX-Distribution gewählt hat.

Eine repo-copy (die Kurzform von ``repository copy'') bedeutet, daß Dateien direkt innerhalb des CVS repository kopiert wurden.

Wenn eine Datei an einen anderen Ort im Repository kopiert oder verschoben werden müsste, würde ein Comitter ohne repo-copy die neue Datei mit cvs add hinzufügen und die alte ggfs. mit cvs rm löschen.

Damit würden allerdings die Einträge in der History (die Einträge im CVS-Logfile) nicht mit übertragen. Da das FreeBSD Projekt diese Informationen allerdings für äußerst nützlich hält, wird eine repository copy durchgeführt. Bei diesem Vorgang wird einer der CVS-Meister die Dateien direkt innerhalb des Repository verschieben, statt das Programm cvs zu benutzen.

Die ganz, ganz kurze Antwort ist überhaupt nicht. Die etwas längere Antwort lautet: Nur weil Sie in der Lage sind, einen Fahrradschuppen zu bauen, müssen Sie noch lange nicht andere davon abhalten, nur weil Ihnen die Farbe gefällt. Dies ist natürlich eine Metapher dafür, daß Sie nicht eine Diskussion über jede kleine Änderung beginnen sollen, nur weil Sie das können. Einige Leute behaupten sogar, daß die Anzahl der (nutzlosen) Kommentare über eine Änderung umgekehrt proportional zu Ihrer Komplexität der Änderung ist.

Die noch längere und vollständigere Antwort ist, daß Poul-Henning Kamp <phk@FreeBSD.org> nach einen langen Diskussion über das Thema "Soll sleep(1) Sekundenbruchteile als Parameter akzeptieren?" eine lange Mail mit dem Titel ``A bike shed (any colour will do) on greener grass...'' schrieb. Die einschlägigen Teile der Nachricht lauteten:

Eintausendeinhundertundzweiundsiebzig:

Dreiundzwanzig, die sich bei -CURRENT beschweren, daß das Licht aus ist;

Vier, die behaupten, daß es sich um ein Konfigurationsproblem handelt und daß solche Dinge wirklich nach -questions gehören;

Drei, die PRs hierzu einreichen, einer von ihnen wird falsch unter DOC abgelegt und fristet sein Dasein im Dunkeln;

Einen, der eine ungetestete Glühbirne einreicht, wonach buildworld nicht mehr funktioniert, und sie dann fünf Minuten später wieder herausnimmt;

Acht, die die PR-Erzeuger beschimpfen, weil sie zu ihren PRs keine Patche hinzugefügt haben;

Fünf, die sich darüber beschweren, daß buildworld nicht mehr funktioniert;

Einunddreißig, die antworten, daß es bei ihnen funktioniert und daß sie cvsup wohl zu einigem ungünstigen Zeitpunkt durchgeführt haben;

Einen, der einen Patch für eine neue Glühbirne an -hackers schickt;

Einen, der sich beschwert, daß es vor drei Jahren Patches hierfür hatte, aber als er sie nach -CURRENT schickte, sind sie einfach ignoriert worden und er hatte schlechte Erfahrungen mit dem PR-System; nebenbei ist die vorgeschlagene Glühbirne nicht reflexiv;

Siebenunddreißig, die schreien, daß Glühbirnen nicht ins Basissystem gehören, daß Committer nicht das Recht haben, solche Dinge durchzuführen, ohne die Gemeinschaft zu konsultieren und WAS GEDENKT -CORE HIER ZU TUN!?

Zweihundert, die sich über die Farbe des Fahrradschuppens beschweren;

Drei, die darauf hinweisen, daß der Patch nicht mit style(9) übereinstimmt;

Siebzehn, die sich beschweren, daß die vorgeschlagene neue Glühbirne der GPL unterliegt;

Fünfhundertundsechsundachtzig, die sich in einen Streit über die vergleichbaren Vorteile der GPL, der BSD-Lizenz, der MIT-Lizenz, der NPL und der persönlichen Hygiene nichtgenannter FSF-Gründer verwickeln;

Sieben, die unterschiedliche Teile des Threads nach -chat und -advocacy weiterleiten;

Einer, der die vorgeschlagene Glühbirne einbaut, obwohl sie dunkler leuchtet, als die alte;

Zwei, die sie wieder ausbauen, und in einer wütenden Nachricht argumentieren, daß FreeBSD besser ganz im Dunkeln dasteht, als mit einer dämmerigen Glühbirne;

Sechsundvierzig, die sich lärmend wegen des Wiederausbaus der dämmerigen Glühbirne streiten und eine Erklärung von -core verlangen;

Elf, die eine kleinere Glühbirne beantragen, damit sie in ihr Tamagotchi paßt, falls wir irgendwann beschließen, FreeBSD auf diese Plattform zu portieren;

Dreiundsiebzig, die sich über die SNR auf -hackers und -chat beschweren und aus Protest abmelden;

Dreizehn, die "unsubscribe", "How do I unsubscribe?", oder "Please remove me from the list", gefolgt von der üblichen Fußzeile abschicken;

Einen, der eine funktionierende Glühbirne einbaut, während alle zu beschäftigt damit sind, mit jedem zu streiten, um es zu bemerken;

Einunddreiß, die herausstellen, daß die neue Glühbirne 0,364% heller leuchten würde, wenn sie mit TenDRA kompiliert werden würde (obwohl sie ein einen Würfel umgeformt werden müßte) und daß FreeBSD deshalb nach TenDRA, anstatt nach EGCS wechseln sollte;

Einen, der sich beschwert, daß bei der neuen Glühbirne die Verkleidung fehlt;

Neun (einschließlich der PR-Ersteller), die fragen "Was ist MFC?";

Siebenundfünfzig, die sich zwei Wochen, nachdem die Birne gewechselt worden ist, darüber beschweren, daß das Licht aus war.

Nik Clayton <nik@FreeBSD.org> hat hinzugefügt:

Ich habe ziemlich hierüber gelacht.

Und dann dachte ich: "Halt, sollte in dieser Liste nicht irgendwo 'Einer, der es dokumentiert' sein?"

Und dann wurde ich erleuchtet :-)

This entry is Copyright (c) 1999 Dag-Erling C. Smørgrav <des@FreeBSD.org>. Please do not reproduce without attribution.

Derzeit existieren drei aktive/halbaktive Zweige im FreeBSD-CVS-Repository (im Zweig RELENG_2 erfolgen vielleicht noch zwei Änderungen pro Jahr, daher gibt es nur drei aktive Entwicklungszwenige:

• RELENG_2_2 bzw. 2.2-STABLE

• RELENG_3 bzw. 3.X-STABLE

• RELENG_4 bzw. 4-STABLE

• HEAD bzw. -CURRENT oder 5.0-CURRENT

HEAD ist keine wirkliche Bezeichnung für einen Zweig, wie die anderen beiden. Es ist lediglich eine symbolische Konstante für ``den aktuellen, nicht verzweigten Entwicklungsstrom'', auf den wir uns einfach als ``-CURRENT'' beziehen.

Zur Zeit ist ``-CURRENT'' der 5.0 Entwicklungsstrom und der 4-STABLE-Zweig RELENG_4 wurde im März 2000 von ``-CURRENT'' abgespalten.

Der 2.2-STABLE-Zweig RELENG_2_2 verließ -CURRENT im November 1996, die Weiterentwicklung wurde fast vollständig eingestellt.

Um ein Release zu erstellen, müssen Sie drei Dinge tun: erstens müssen Sie einen Kernel benutzen, der das Gerät vn(4) enthält. Fügen Sie folgendes in ihre Kernelkonfigurationsdatei ein und erstellen Sie einen neuen Kernel:

    pseudo-device vn         #Vnode driver (verwandelt eine Datei in ein Gerät)
             

Zweitens müssen Sie das vollständige CVS-Repository zur Hand haben. Sie können hierzu CVSUP benutzen. Sie müssen in den Konfigurationsdateien für cvsup als Release cvs verwenden und alle evtl. vorhandenen tag= und date= Zeilen entfernen:

    *default prefix=/home/ncvs
    *default base=/a
    *default host=cvsup.FreeBSD.org
    *default release=cvs
    *default delete compress use-rel-suffix
    
    ## Main Source Tree
    src-all
    src-eBones
    src-secure
    
    # Other stuff
    ports-all
    www
    doc-all
             

Benutzen Sie dann cvsup -g supfile, um all die guten Bits auf Ihren Rechner zu saugen...

Schließlich brauchen Sie eine Menge freien Plattenplatz für die Erstellung. Angenommen, er befindet sich unter /some/big/filesystem und entsprechend dem obigen Beispiel befindet sich das CVS-Repository unter /home/ncvs:

    # setenv CVSROOT /home/ncvs # or export CVSROOT=/home/ncvs
    # cd /usr/src
    # make buildworld
    # cd /usr/src/release
    # make release BUILDNAME=3.0-MY-SNAP CHROOTDIR=/some/big/filesystem/release
             

Ein vollständiges Release wird nun unter /some/big/filesystem/release erstellt. Wenn der Vorgang abgeschlossen ist, finden Sie unter /some/big/filesystem/release/R/ftp eine vollständige FTP-fähige Installlation. Falls Sie Ihren SNAP von einem anderen Zweig als -CURRENT erstellen wollen, können Sie auch RELEASETAG=SOMETAG zu der obigen Befehlszeile "make release" hinzufügen, z.B. würde RELEASETAG=RELENG_2_2 einen minutenaktuellen Schnappschuß von 2.2-STABLE erstellen.

Der gesamte Prozeß zur Erstellung von Installationsdisketten und Quell- und Binärarchiven ist durch verschiedene Targets in /usr/src/release/Makefile automatisiert. Die dortigen Informationen sollten für einen Einstieg ausreichen. Es sollte jedoch erwähnt werden, daß dies ein make world einschließt und daher sehr viel Zeit und Plattenplatz in Anspruch nimmt.

Das ist beabsichtigt. Wie der Name schon andeutet, erstellt make world alle Systembinaries von Grund auf neu. Sie können also sicher sein, am Ende eine saubere, konsistente Umgebung zu haben (das ist der Grund ist, warum es so lange dauert).

Falls die Umgebungsvariable DESTDIR während der Ausführung von make world oder make install definiert ist, werden die neu erstellten Binaries unter ${DESTDIR} in einem zum installierten identischen Verzeichnisbaum abgelegt. Einige zufällige Kombinationen von Änderungen von Shared Libraries und Neuerstellungen von Programmen können hierbei jedoch ein Scheitern von make world verursachen.

Die Adaptec 1542 SCSI Hostadapter erlauben dem Benutzer die Buszugriffsgeschwindigkeit per Software zu konfigurieren. Ältere Versionen des 1542-Treibers versuchten, die schnellstmögliche Geschwindigkeit herauszufinden und konfigurierten den Adapter entsprechend. Wir haben festgestellt, daß dies auf einigen Systemen nicht funktioniert, weshalb Sie nun die Kernelkonfigurationsoption TUNE_1542 definieren müssen, um es zu aktivieren. Die Benutzung auf Systemen, auf denen es funktioniert, könnte Ihre Platten schneller machen, aber auf den Systemen, auf denen es nicht funktioniert, könnten Ihre Daten beschädigt werden.

Ja, Sie können das tun, ohne den gesamten Quellbaum herunterzuladen, indem Sie die Einrichtung CTM benutzen.

Bei neueren BSD-basierten Systemen gibt es eine Option -b zu split, die das Splitten von Dateien an willkürlichen Bytegrenzen erlaubt.

Hier ist ein Beispiel aus /usr/src/Makefile.

    bin-tarball:
            (cd ${DISTDIR}; \
            tar cf - . \
            gzip --no-name -9 -c | \
            split -b 240640 - \
            ${RELEASEDIR}/tarballs/bindist/bin_tgz.)
             

Lesen Sie bitte den Handbucheintrag über das Einreichen vom Code.

Und Danke, daß Sie darüber Nachdenken!

Von: Frank Durda IV

Kurz gesagt gibt es nur wenige I/O-Ports über die PnP-Karten antworten, wenn der Host fragt, ob jemand da ist. Wenn die PnP-Erkennungsroutine startet, fragt sie, ob irgendwelche PnP-Karten vorhanden sind und alle PnP-Karten antworten mit ihrer Modellnummer auf demselben Port, von dem sie auch gelesen haben. Die Erkennungsroutine erhält also ein geodertes ``Ja'' auf diese Frage. Mindestens ein Bit wird bei dieser Antwort gesetzt sein. Die Erkennungsroutine ist dann in der Lage, dafür zu sorgen, daß Karten mit Modellnummern (zugeordnet von Microsoft/Intel) kleiner als X ``off-line'' gesetzt werden. Sie prüft dann, ob immer noch Karten da sind, die auf die Frage antworten. Falls die Antwort 0 war, sind keine Karten mit IDs größer X vorhanden. Nun prüft die Erkennungsroutine, ob Karten unterhalb X vorhanden sind. Dann setzt die Erkennungsroutine alle Karten größer als X-(limit/4) off-line und wiederholt die Frage. Wenn diese halbbinäre Suche nach IDs in Folge genügend oft wiederholt worden ist, wird die Erkennungsroutine schließlich alle in einem Rechner befindlichen PnP-Karten identifiziert haben und das mit einer Iterationszahl sehr viel kleiner als 2^64.

Die IDs bestehen aus zwei 32-Bit-Feldern (daher 2^64) + acht Bit Prüfsumme. Die ersten 32 Bit sind die Herstellerkennung. Es wurde zwar nicht bestätigt, aber es wird angenommen, daß unterschiedliche Kartentypen desselben Herstellers unterschiedliche 32-Bit Herstellerkennungen besitzen können. 32 Bit nur für eindeutige Hersteller zu benötigen, scheint etwas übertrieben.

Die niedrigen 32 Bit sind eine Seriennummer, Ethernetadresse - etwas, das die betreffende Karte einzigartig macht. Die Hersteller dürfen niemals eine zweite Karte mit denselben niedrigen 32 Bit herstellen, es sei denn, die höheren 32 Bit sind unterschiedlich. Sie können also mehrere Karten des selben Typs im Rechner haben und die gesamten 64 Bit bleiben stets eindeutig.

Die 32-Bit-Gruppen können niemals nur aus Nullen bestehen. Das erlaubt es, bei der binären Suche zu Beginn nur auf von Null verschiedene Bits zu achten.

Wenn das System alle vorhandenen Karten-IDs identifiziert hat, reaktiviert es jede Karte - eine nach der anderen (über dieselben I/O-Ports) und ermittelt, welche Ressourcen von der jeweiligen Karte benötigt werden, welche Wahlmöglichkeiten für Interrupts bestehen usw. Alle Karten werden abgefragt, um diese Informationen zusammenzustellen.

Diese Informationen werden dann mit Informationen aus allen ECU-Dateien auf der Festplatte oder mit im MLB-Bios verdrahteten Informationen verknüpft. Die ECU- und BIOS-PnP-Unterstützung für Hardware auf dem MLB ist für gewöhnlich künstlich und was die Peripheriegeräte tun ist nicht wirklich echtes PnP. Durch die Untersuchung der BIOS-Informationen und der ECU-Informationen können die Erkennungsroutinen jedoch die von PnP-Geräten benutzten Ressourcen so ändern, daß vermieden wird, daß bereits von anderen Geraeten benutzte Ressourcen verwendet werden.

Dann werden die PnP-Geräte nochmals besucht und ihre I/O, DMA, IRQ und Memory-Map-Adressen werden zugeordnet. Die Geräte werden an diesen Stellen sichtbar werden und dort bis zum nächsten Reboot verbleiben. Allerdings hindert Sie auch nichts daran, sie zu verschieben, wohin Sie wollen.

Im obigen Teil wurde sehr viel vereinfacht, aber die grundlegende Idee sollte klar geworden sein.

Microsoft hat einige der primären Druckerstatusports für PnP übernommen, da keine Karte diese Adressen für die entgegengesetzten I/O-Zyklen decodiert. Ich habe während der frühen Überprüfungsperiode des PnP-Vorschlags eine echte IBM Druckerkarte gefunden, die Schreibzugriffe auf dem Statusport decodiert hat, aber MS hat nur ``tough'' gesagt. Also schreiben sie auf den Druckerstatusport, um Adressen zu setzen, benutzen zusätzlich diese Adresse + 0x800 und einen dritten I/O-Port zum Lesen, der irgendwo zwischen 0x200 und 0x3ff liegen kann.

Verschiedene Gruppen haben ihr Interesse daran geäußert, an Multiarchitektur-Ports für FreeBSD zu arbeiten. Ziemlich erfolgreich waren die Anstrengungen für den Port FreeBSD/AXP (ALPHA), der unter ftp://ftp.de.FreeBSD.org/pub/FreeBSD/alpha erhältlich ist. Der ALPHA-Port läft nun auf einer steigenden Anzahl von ALPHA-Maschinen, unter ihnen die Modelle AlphaStation, AXPpci, PC164, Miata und Multia. Bitte schließen Sie sich der Mailingliste <freebsd-alpha@FreeBSD.org> an, falls Sie an Statusinformationen interessiert sind.

Außerdem wurde Interesse an einem Port von FreeBSD zur SPARC-Architektur ausgedrückt. Schließen Sie sich der Mailingliste<freebsd-sparc@FreeBSD.org> an, wenn Sie bei dem Projekt teilnehmen möchten. Die Neuzugänge auf der Liste der in Zukunft unterstützten Plattformen sind IA-64 und PowerPC, weitere Informationen erhalten Sie auf den Mailinglisten <freebsd-ia64@FreeBSD.org> und/oder <freebsd-ppc@FreeBSD.org>. Schließen Sie sich dieser Mailingliste <freebsd-platforms@FreeBSD.org> an, wenn Sie an grundsätzlichen Diskussionen über neue Architekturen interessiert sind.

Das hängt davon ab, ob Sie beabsichtigen, den Treiber frei verfügbar zu machen, oder nicht. Falls dem so ist, senden Sie uns bitte eine Kopie der Treiber-Sourcen und zusätzlich die entsprechenden Änderungen der Datei files.i386, ein Beispiel für einen Eintrag in der Konfigurationsdatei und den entsprechenden Code für MAKEDEV(8) um spezielle Geräte zu erstellen, die Ihr Gerät benutzt. Falls Sie nicht beabsichtigen, den Treiber frei verfügbar zu machen, oder es aufgrund von Lizenzbeschränkungen nicht können, dann ist die Hauptnummer 32 für zeichenorientierte und die Hauptnummer 8 für blockorientierte Geräte speziell für diesen Zweck reserviert. In jedem Fall würden wir uns freuen, in <freebsd-hackers@FreeBSD.org> etwas über Ihren neuen Treiber zu hören.

Als Antwort auf die Frage nach alternativen Layoutverfahren für Verzeichnisse ist das Schema, das derzeit benutzt wird, unverändert von dem, das ich 1983 geschrieben habe. Ich habe das Vorgehen für das originale Fast-Filesystem geschrieben und es niemals überarbeitet. Es funktioniert gut, wenn es darum geht, zu verhindern, daß Zylindergruppen volllaufen. Wie viele von Ihnen angemerkt haben, funktioniert es schlecht für find. Die meisten Dateisysteme werden von Archiven erstellt, die mit einer Tiefensuche (also ftw) erstellt wurden. Diese Verzeichnisse werden über die Zylindergruppen hinweg entfaltet und erzeugen denkbar ungünstigste Voraussetzungen für zukünftige Tiefensuchen. Falls man die Gesamtzahl der zu erstellenden Verzeichnisse wüsste, wäre die Lösung die, (gesamt / fs_ncg) pro Zylindergruppe zu erstellen, bevor fortgefahren wird. Offensichtlich müßte man eine Heuristik erstellen, um die Zahl zu schätzen. Sogar die Benutzung einer kleinen, fixen Zahl, z.B. 10, würde eine Verbesserung um Größenordnungen ausmachen. Um Wiederherstellungen von normalem Betrieb (wo der derzeitige Algorithmus vermutlich sinnvoller ist) zu unterscheiden, könnten Sie die Clusterung von bis zu 10 benutzen, wenn sie alle innerhalb eines 10-Sekunden-Fensters durchgeführt würden. Jedenfalls ist mein Schluss, daß dies ein fruchtbares Gebiet für Experimente ist.

Kirk McKusick, September 1998

[Dieser Abschnitt wurde von Dag-Erling C. Smørgrav <des@FreeBSD.org>, der einige Tippfehler korrigiert und die Kommentare in eckigen Klammern hinzugefügt hat, aus einer Mail von Bill Paul <wpaul@FreeBSD.org> in der Mailingliste freebsd-current entnommen.]

    From: Bill Paul <wpaul@skynet.ctr.columbia.edu>
    Subject: Re: the fs fun never stops
    To: ben@rosengart.com Date: Sun, 20 Sep 1998 15:22:50 -0400 (EDT)
    Cc: current@FreeBSD.org
             

[<ben@rosengart.com> sendete die folgende Panik-Meldung]

    > Fatal trap 12: page fault while in kernel mode
    > fault virtual address   = 0x40
    > fault code              = supervisor read, page not present
    > instruction pointer     = 0x8:0xf014a7e5
                                       ^^^^^^^^^^
    > stack pointer           = 0x10:0xf4ed6f24
    > frame pointer           = 0x10:0xf4ed6f28
    > code segment            = base 0x0, limit 0xfffff, type 0x1b
    >                         = DPL 0, pres 1, def32 1, gran 1
    > processor eflags        = interrupt enabled, resume, IOPL = 0
    > current process         = 80 (mount)
    > interrupt mask          =
    > trap number             = 12
    > panic: page fault
             

[Wenn] Sie eine Meldung wie diese sehen, reicht es nicht, sie einfach zu reproduzieren und sie einzusenden. Der Wert des Instruktionszeigers, den ich oben hervorgehoben habe, ist wichtig; leider ist er auch konfigurationsabhängig. Mit anderen Worten variieren die Werte abhängig von dem Kernel-Image, das Sie tatsächlich benutzen. Wenn Sie ein GENERIC Kernelimage von einem der Snapshots benutzen, dann ist es für jemand anderen möglich, die fehlerhafte Instruktion herauszufinden, aber wenn Sie einen angepaßten Kernel benutzen, können nur Sie uns sagen, wo der Fehler auftrat.

Was Sie tun sollten, ist folgendes:

Ich sehe ständig Leute, die Panik-Meldungen wie diese zeigen, aber ich sehe kaum jemanden, der sich die Zeit nimmt, den Instruktionszeiger einer Funktion aus der Symboltabelle des Kernel zuzuordnen.

Der beste Weg, den Grund für eine Panik herauszufinden, ist der, einen Crash-Dump festzuhalten und dann gdb(1) zu benutzen, um den Stack im Crash-Dump zurückzuverfolgen.

Jedenfalls ist die Methode, die ich normalerweise benutze, folgende:

Der make(1)-Prozeß wird zwei Kernel erstellt haben: kernel und kernel.debug. kernel wurde als /kernel installiert, während kernel.debug als Quelle für Debuggersymbole für gdb(1) benutzt werden kann.

Um sicherzustellen, daß ein Crash-Dump erhalten bleibt, müssen Sie /etc/rc.config editieren und dumpdev so setzen, daß es auf Ihre Swap-Partition zeigt. Das bewirkt, daß die rc(8)-Skripte den Befehl dumpon(8) benutzen, um Crash-Dumps zu ermöglichen. Sie können dumpon(8) auch manuell ausführen. Nach einer Panik kann der Crash-Dump mit savecore(8) wiederhergestellt werden; wenn dumpdev in /etc/rc.conf gesetzt ist, werden die rc(8)-Skripte savecore(8) automatisch ausführen und den Crash-Dump unter /var/crash ablegen.