Wissen

Benutzer-Werkzeuge

Webseiten-Werkzeuge

Sie befinden sich hier: Start » freebsd
Zuletzt angesehen: • energie • superhelden-filme • deutschland • chemie • dies_und_das • esoterik • lebensmittel • freebsd
freebsd:freebsd

Dies ist eine alte Version des Dokuments!

Inhaltsverzeichnis

FreeBSD

> pw groupadd -n schlauberger
> pw useradd -n fritz -m -M 0700 -g schlauberger -s /usr/local/bin/bash

> pw userdel fritz -r
> pw group del schlauberger

> sysctl machdep.bootmethod
machdep.bootmethod: BIOS

FreeBSD Mall

  • http://www.chruetertee.ch/?q=freebsd - seit FreeBSD 9.0 wird sysinstall nicht mehr verwendet, aber es gibt einen Nachfolger ⇒ sysutils/bsdconfig
  • FreeBSD: Statusbericht von April bis Juni → (Fr, 29. Juli 2016, 11:33 Uhr) Das FreeBSD-Projekt hat den Statusbericht für das zweite Quartal 2016 vorgelegt. Ein Schwerpunkt war die Vorbereitung der Freigabe von FreeBSD 11.0. Die Arbeiten am Basissystem und den Anwendungen überwogen daher die Kernel-Änderungen bei weitem.

Meilensteine

  • FreeBSD 1.0 (November 1993): die erste FreeBSD-Version;
  • FreeBSD 2.0 (1994-11-22): die erste FreeBSD-Version ohne AT&T-Unix-Code;
  • FreeBSD 3.0 (Oktober 1998): die erste FreeBSD-Version mit SMP-Unterstützung;
  • FreeBSD 3.1 (Februar 1999): die erste FreeBSD-Version mit USB-Unterstützung;
  • FreeBSD 4.0 (2000-03-14): die erste FreeBSD-Version mit IPv6-Unterstützung, es wurde für seine Stabilität gelobt und war bei den ISPs sehr beliebt;
  • FreeBSD 4.1 (2000-07-27): meine erste FreeBSD-Installation, mit der ich etwas anfangen konnte;
  • FreeBSD 4.5 (2002-01-29): meine erste FreeBSD-Version, die aus meiner Sicht absolut problemlos lief;
  • FreeBSD 5.0 (2003-01-14): erste FreeBSD-Version mit funktionierendem Power-Management und mit dynamischem /dev/-Verzeichnis, endlich ist Schluss mit dem lästigen MAKEDEV-Script;
  • FreeBSD 8.0 (2009-11-25): erste FreeBSD-Version in der ZFS funktioniert, da hab ich fast zwei Jahre drauf gewartet;
  • FreeBSD 9.0 (2012-01-12): erste FreeBSD-Version in der UFS den Trim-Befehl (für SSD's) unterstützt; und der Kernel erhielt Schnittstellen, um den Ressourcenverbrauch zu messen und zu begrenzen; seit FreeBSD 9.0 wird sysinstall nicht mehr verwendet, aber es gibt einen Nachfolger ⇒ portinstall sysutils/bsdconfig
  • FreeBSD 9.1 (2012-12-30): erste FreeBSD-Version in der USB 3.0 jetzt endlich richtig funktioniert; in Jails lassen sich jetzt die Dateisysteme devfs, nullfs und ZFS mounten, ohne das dies Prozesse außerhalb des Jails betrifft;
  • FreeBSD 9.2 (2013-09-30): erste FreeBSD-Version in der ZFS den Trim-Befehl (für SSD's) unterstützt; zudem wurde in dem Dateisystem eine lz4-Kompression implementiert;
  • FreeBSD 10.0 (2016-10-10): erste FreeBSD-Version in der ZFS mit der Installations-CD direkt als root-Dateisystem ausgewählt werden kann;
  • FreeBSD 10.3 (2016-04-04): durch Zufall habe ich erst jetzt bemerkt, dass in dieser FreeBSD-Version UTF-8 richtig funktioniert (in Version 8 war ich noch nicht zufrieden!);
  • FreeBSD 12.0 (2018-12-11): die Sicherheit der Jails hat einen dicken Sprung nach vorne gemacht - jetzt kann ich weder meinen TS3-Server noch meinen MiniDLNA-Server in der Jail betreiben (ich habe massive Probleme mit der Erreichbarkeit aus dem Netz), die müssen jetzt wieder auf dem nativen System laufen;
  • FreeBSD 13.0 (2021-04-13): die erste Version, die komplett ohne grundlegende GNU-Werkzeuge auskommt. Das hat über ein Jahrzehnt gedauert. Die Quellen bekommt man ab jetzt nicht mehr mit SVN sondern nur noch mit Git. Alle unterstützten Architekturen verwenden jetzt die LLVM/Clang-Toolchain. Der Kernel unterstützt jetzt das In-Kernel-Framing und die Verschlüsselung von TLS-Daten (Transport Layer Security) auf TCP-Sockets für TLS-Versionen 1.0 bis 1.3. Die 64-Bit-ARM-Architektur (arm64 / AArch64 / 64-bit ARMv8 ⇒ Raspberry Pi 4) wird für FreeBSD 13 in den Tier-1-Status und die 32-bit-x86-Architektur in den Tier-2-Status versetzt.
  • FreeBSD 14.0 (2023-11-20): die letzte Version mit vollständiger 32-Bit-Unterstützung; Standard-Shell geändert von csh auf sh; Home-Verzeichnisse geändert von /usr/home/<Benutzer> (mit SymLink) auf /home/<Benutzer> (ohne SymLink); der Ports-Tree wird nicht mehr per portsnap(8), sondern per git heruntergeladen

Ich hatte mit FreeBSD im Jahre 2000 angefangen (FreeBSD 4.1 bis FreeBSD 7.2) und habe es bis ins Jahr 2005 auf all meinen Rechnern (Server, Desktop, Laptop und in der Firma am Arbeitsplatz) eingesetzt. Zwischen 2005 und 2009 habe ich daneben auch noch NetBSD, OpenBSD, Solaris und OpenSolaris ausprobiert. Leider konnte mich aber keines dieser Systeme vollkommen überzeugen und so habe ich mich 2009 mit FreeBSD 8.0, für meinen Server, wieder voll und ganz für FreeBSD entschieden. Auf meinen anderen Rechnern (Desktop, Laptop und in der Firma am Arbeitsplatz) setze ich allerdings (seit 2005) weiterhin Linux ein, weil die grafische Oberfläche auf FreeBSD einerseit bei Updates mehr Handgriffe erfordert (es waren immer zusätzliche Nacharbeiten nötig) und andererseits auch nicht den vollen Funktionsumfang besitzt.

Auf Linux-Systemen ist die grafische Oberfläche dagegen sehr Wartungsarm.

Zuerst hat Fedora Gnome 3 und dann hat Ubuntu Unity (basiert auf Gnome 3) eingeführt, diese Oberflächen taugen für einen ordentlichen Desktop-Rechner (mit großem Bildschirm) garnichts.
Ich setze jetzt nur noch ein Ubuntu Server LTS mit (anfangs) nachträglich installierter Mate-Oberfläche und (später) Cinnamon-Oberfläche ein.

  1. Mate - ist besser auf schwachen Systemen, besonders bei Verwendung von Grafikkarten ohne ordentlicher 3D-Unterstützung; leider besitzt MATE aber in mind. einem meiner Lieblings-Apps einen gewalltigen MEM-Leak, der bereits seit 2010 existiert
  2. Cinnamon - hat eine deutlich besser integrierte Bluetooth-Unterstützung und keinen mir bekannten MEM-Leak

Mit Einführung von SNAP, wechsle ich (seit 2023 - hab vorher auch MINT ausprobiert) nach und nach auf Debian (Stable) mit Cinnamon-Oberfläche.

Ports online

Benutzer / User

Download

HTTPS

Am 2018-06-27 erschien das neue FreeBSD-11.2-RELEASE:

FTP

FTP-Pfad: 

.../releases/$(uname -m)/$(uname -p)/$(uname -r)

CSV

FreeBSD 9.0 Beta2: If you would like to use csup/cvsup mechanisms to access the source tree the branch tag to use is "." (head).

SVN (Subversion)

Port/PKG

den Port installieren: 

# portupgrade -NRO devel/subversion-freebsd

Update

kopiergeschützte DVD's

Um von seinen DVD's die "Daten" lesen zu können, oder einfach die absolut nervige Werbung vor dem Film zu entfernen, braucht man nur das folgende Programm zu installieren: 

# portinstall sysutils/vobcopy

Auch die Handhabung ist ganz einfach!

FreeBSD - Live-CD / USB-Stick

oder aus den Ports ⇒ sysutils/livecd

Hier gibt es Images mit Live-FS für CD (livefs) und USB-Stick (memstick):

FreeBSD und X11

nicht nur WindowManager sondern auch DesktopManager wie Gnome:

X11 mit FreeBSD 13.0

portsnap fetch extract update
portsnap fetch update
cd /usr/ports/ports-mgmt/portmaster/
make clean
make
make install clean
portmaster ports-mgmt/portupgrade

portsclean -CDL
portupgrade -arF

portmaster shells/bash
portmaster misc/mc
portmaster sysutils/screen
portmaster misc/gnu-watch 
portmaster x11/xorg
portmaster x11-wm/icewm
portmaster x11/cinnamon-desktop
portmaster x11/gdm
portmaster graphics/drm-kmod

portsclean -CDL
portupgrade -arF
> pkg info -oa | wc -l

> vi /boot/loader.conf
# in die erste Zeile:
kern.vty=vt

> sysctl kern.vty
kern.vty: vt

> vi /etc/rc.conf
gdm_enable="YES"
dbus_enable="YES"
hald_enable="YES"

> vi /etc/fstab
proc /proc procfs rw 0 0

> vi ~/.xinitrc
exec cinnamon-session

nützliche Programme (vor FreeBSD 13)

shells/bash
misc/mc
misc/gnu-watch
audio/cdparanoia
audio/faac
audio/vorbis-tools
devel/libchipcard
devel/subversion-freebsd
ftp/wget
mail/dovecot-sieve
misc/cpuid
misc/seq2
multimedia/gpac-mp4box
multimedia/lsdvd
multimedia/lxdvdrip
multimedia/mencoder
multimedia/mkvtoolnix
net/bmon
net/cvsup-without-gui
net/isc-dhcp42-server
net/samba35
net/vnc
security/doscan
security/nmap
sysutils/bsdsar
sysutils/cdrtools
sysutils/cpupowerd
sysutils/dmidecode
sysutils/dvd+rw-tools
sysutils/dvdbackup
sysutils/dvdisaster
sysutils/livecd
sysutils/pwgen2
sysutils/smartmontools
sysutils/udfclient
sysutils/usbutils
sysutils/vobcopy
www/squid
www/dokuwiki
www/apache22
graphics/php5-exif
emulators/virtualbox-ose
x11-servers/xorg-server
x11-wm/icewm
x11/xterm

/usr/local/etc/php/extensions.ini

Zu beachten ist hier, dass nach der Installation von "graphics/php5-exif" in der Datei "/usr/local/etc/php/extensions.ini" das Modul "exif.so" irgendwo nach bzw. unter dem Modul "mbstring.so" aufgelistet wird!

zum Beispiel so: 

extension=zlib.so
extension=openssl.so
extension=session.so
extension=mbstring.so
extension=xml.so
extension=gd.so
extension=exif.so

Auto-Login

In der "/etc/ttys" muss man im gewünschten "tty" statt "/usr/libexec/getty Pc", "/usr/libexec/getty autologin" eintragen. Dann muss in der Datei "/etc/gettytab", im Bereich "autologin|al.9600" statt "root" der gewünschte User eingetragen werden.

Fehlermeldungen

Fetching metadata signature for 12.0-RELEASE from update2.freebsd.org... failed.

Fehler: 

> freebsd-update fetch
...
Fetching metadata signature for 12.0-RELEASE from update2.freebsd.org... failed.
...

23.2.3.2. Aktualisierung der Pakete nach einem Upgrade auf eine Hauptversion 

> pkg-static upgrade -f

nachdem die API aktuallisiert wurde, funktioniert auch der normale Aufruf wieder: 

> freebsd-update fetch
src component not installed, skipped
Looking up update.FreeBSD.org mirrors... 3 mirrors found.
Fetching metadata signature for 12.0-RELEASE from update4.freebsd.org... done.
Fetching metadata index... done.
Inspecting system... done.
Preparing to download files... done.

/usr/local/lib/libpkg.so.4: Undefined symbol "openat"

Diese Fehlermeldung 

> pkg update
/usr/local/lib/libpkg.so.4: Undefined symbol "openat"

deutet darauf hin, dass es das Repository nicht mehr gibt. In diesem Fall muss man FreeBSD auf die neueste Version aktuallisieren.

Python headers not found

checking whether Python support is requested... checking whether /usr/local/bin/python2.6 version >= 2.5... yes
checking for /usr/local/bin/python2.6 version... 2.6
checking for /usr/local/bin/python2.6 platform... freebsd8
checking for /usr/local/bin/python2.6 script directory... ${prefix}/lib/python2.6/site-packages
checking for /usr/local/bin/python2.6 extension module directory... ${exec_prefix}/lib/python2.6/site-packages
checking for headers required to compile python extensions... not found
configure: error: Python headers not found
===>  Script "configure" failed unexpectedly.
Please run the gnomelogalyzer, available from
"http://www.freebsd.org/gnome/gnomelogalyzer.sh", which will diagnose the
problem and suggest a solution. If - and only if - the gnomelogalyzer cannot
solve the problem, report the build failure to the FreeBSD GNOME team at
gnome@FreeBSD.org, and attach (a)
"/usr/ports/devel/gobject-introspection/work/gobject-introspection-0.6.7/config.log",
(b) the output of the failed make command, and (c) the gnomelogalyzer output.
Also, it might be a good idea to provide an overview of all packages installed
on your system (i.e. an `ls /var/db/pkg`). Put your attachment up on any
website, copy-and-paste into http://freebsd-gnome.pastebin.com, or use
send-pr(1) with the attachment. Try to avoid sending any attachments to the
mailing list (gnome@FreeBSD.org), because attachments sent to FreeBSD mailing
lists are usually discarded by the mailing list software.
*** Error code 1

Stop in /usr/ports/devel/gobject-introspection.

Diesen Fehler kann man beheben, in dem die folgenden Befehlen Abgegeben werden: 

cd /usr/ports/lang/python26
make rmconfig
portupgrade -f --batch lang/python26

BUG (serielle Schnittstelle): "Silo overflow"

Joseph Jacobson wrote:
>
> Just got this error, doing a 'make fetch' over ppp, while running mpg123.
> Kernel config can be provided if needed.
>
> sio0: 1 more silo overflow (total 1)
> sio0: 1 more silo overflow (total 2)
> sio0: 1 more silo overflow (total 3)
> sio0: 1 more silo overflow (total 4)
> sio0: 1 more silo overflow (total 5)
> sio0: 1 more silo overflow (total 6)

This is a frequently reported problem.  It is, for the most part,
harmless.  You will find an abundance of history by searching the mail
archives.  Apparently some recent changes involving 'fast' interrupt
handling will cause FreeBSD to neglect a serial port for a bit too long,
and incoming data isn't read from the device before it is lost.

The following patch seems to help.  It lowers the fifo threshold a bit
causing more frequent reads from the device.  It also increases
interrupt frequency which, to some, seems rather tragic.  I've never
felt any pain as a result of 'too many' interrupts from a serial port,
but I like not getting the silo overflows.  This hack isn't Right(tm),
but it does work.

--- sio.c.orig  Wed Aug 16 09:29:34 2000
+++ sio.c       Fri Sep  1 14:53:47 2000
@@ -2345,7 +2345,7 @@
                 * latencies are larger.
                 */
                com->fifo_image = t->c_ospeed <= 4800
-                                 ? FIFO_ENABLE : FIFO_ENABLE | FIFO_RX_HIGH;
+                                 ? FIFO_ENABLE : FIFO_ENABLE | FIFO_RX_MEDH;
 #ifdef COM_ESP
                /*
                 * The Hayes ESP card needs the fifo DMA mode bit set

No promises about whether this patch will apply to your version of
src/sys/isa/sio.c.  I usually just change the one line by hand.

###############################################################################
#
In FreeBSD 4.7 RELEASE,
in dem dieses Problem auch besteht, sieht der entsprechende Teil wie folgt aus:

   2466         if (com->hasfifo && divisor != 0) {
   2467                 /*
   2468                  * Use a fifo trigger level low enough so that the inpu
t
   2469                  * latency from the fifo is less than about 16 msec and
   2470                  * the total latency is less than about 30 msec.  These
   2471                  * latencies are reasonable for humans.  Serial comms
   2472                  * protocols shouldn't expect anything better since mod
em
   2473                  * latencies are larger.
   2474                  *
   2475                  * Interrupts can be held up for long periods of time
   2476                  * due to inefficiencies in other parts of the kernel,
   2477                  * certain video cards, etc.  Setting the FIFO trigger
   2478                  * point to MEDH instead of HIGH gives us 694uS of slop
   2479                  * (8 character times) instead of 173uS (2 character ti
mes)
   2480                  * @ 115200 bps.
   2481                  */
   2482                 com->fifo_image = t->c_ospeed <= 4800
   2483                                   ? FIFO_ENABLE : FIFO_ENABLE | FIFO_RX
_MEDH;
   2484 #ifdef COM_ESP
   2485                 /*
   2486                  * The Hayes ESP card needs the fifo DMA mode bit set
   2487                  * in compatibility mode.  If not, it will interrupt
   2488                  * for each character received.
   2489                  */
   2490                 if (com->esp)
   2491                         com->fifo_image |= FIFO_DMA_MODE;
   2492 #endif
   2493                 sio_setreg(com, com_fifo, com->fifo_image);
   2494         }

Beachten Sie, das hier der relevante Teil mehr als 130 Zeilen tiefer liegt als
in dem oben genannten Patch!
Obwohl die trigger point schon von "FIFO_RX_HIGH" auf "FIFO_RX_MEDH" gesetzt is
t
(wie duch den Petch "empfohlen") habe ich das Problem immer noch.
###############################################################################
#

Das Problem wird auch in der man-Page genannt. Die Puffer sind schon wieder leer
bevor sie ausgelesen wurden. Das Problem tritt meistens (aber nicht nur) auf,
wenn die Geschwindigkeit der seriallen Schnittstelle (oder des seriallen
Geraetes) zu hoch eingestellt wurde.

Auf einigen Internetseiten wird beschrieben wie man das Problem durch abschalten
des IRQ-sharings beheben kann. Dabei ist nur zu beachten, das der entsprechende
IRQ dann von keinem anderen Geraet mehr verwendet werden kann!

###############################################################################
#

LOESUNG in meinem Fall:
=======================

Das Problem trat mit einem "ASUS-P5A + K6-2-400" und FreeBSD 4.4 noch nicht auf,
nach dem Update auf FreeBSD 4.7 hatte ich den Fehler "silo overflow".
Dieser lies sich nur durch den Austausch der genannten Hardwarekomponennten
gegen "ABIT-PB6 + P2-Celeron-366" beheben! Seltsam, aber so war es...

ZFS + Marvell-Controller

Die HDDs werden im RAID-1 mit ZFS betrieben. Leider zeigen sich im Log diese Fehler: 

> less /var/log/messages
Aug  2 06:06:00 freebsd12 kernel: ahcich5: Timeout on slot 27 port 0
Aug  2 06:06:00 freebsd12 kernel: ahcich5: is 00000000 cs 00000000 ss 00000000 rs 08000000 tfd 50 serr 00000000 cmd 00711b17
Aug  2 06:07:02 freebsd12 kernel: ahcich3: Timeout on slot 3 port 0
Aug  2 06:07:02 freebsd12 kernel: ahcich3: is 00000000 cs 00000000 ss 00000000 rs 00000008 tfd 50 serr 00000000 cmd 00710317
Aug  2 06:08:23 freebsd12 kernel: ahcich3: Timeout on slot 13 port 0
Aug  2 06:08:23 freebsd12 kernel: ahcich3: is 00000000 cs 00000000 ss 00000000 rs 00002000 tfd 50 serr 00000000 cmd 00710d17
Aug  2 07:08:23 freebsd12 kernel: ahcich3: Timeout on slot 14 port 0
Aug  2 07:08:23 freebsd12 kernel: ahcich3: is 00000000 cs 00000000 ss 00000000 rs 00004000 tfd 50 serr 00000000 cmd 00710e17
Aug  2 07:09:23 freebsd12 kernel: ahcich5: Timeout on slot 20 port 0
Aug  2 07:09:23 freebsd12 kernel: ahcich5: is 00000000 cs 00000000 ss 00000000 rs 00100000 tfd 50 serr 00000000 cmd 00711417

Diese Fehler werden auch in der Ausgabe von dmesg angezeigt.

Es treten also an ahcich3 und ahcich5 Wartezeitüberschreitungen auf.

Wenn seit dem letzten Boot-Vorgang noch nicht zuviele Kernel-Meldungen vom System geschickt wurden, dann kann man in der Ausgabe von dmesg sehen, welcher SATA-Controller die problembehafteten Anschlüsse besitzt: 

> dmesg
ahci1: <Marvell 88SE9215 AHCI SATA controller> port 0xbf00-0xbf07,0xbe00-0xbe03,0xbd00-0xbd07,0xbc00-0xbc03,0xbb00-0xbb1f mem 0xfd9ff000-0xfd9ff7ff irq 19 at device 0.0 on pci4
ahci1: AHCI v1.00 with 4 6Gbps ports, Port Multiplier supported with FBS
ahcich2: <AHCI channel> at channel 0 on ahci1
ahcich3: <AHCI channel> at channel 1 on ahci1
ahcich4: <AHCI channel> at channel 2 on ahci1
ahcich5: <AHCI channel> at channel 3 on ahci1

…hier ist auch zu lesen, dass es der 4-Port-Controller ist (with 4 6Gbps ports).

zur Kontrolle können wir uns auch die komplette Hardware-Bestückung unseres Systems anschauen (hier nur das Ende der Ausgabe): 

> pciconf -lv
...
ahci0@pci0:3:0:0:       class=0x010601 card=0x10601b21 chip=0x06121b21 rev=0x01 hdr=0x00
    vendor     = 'ASMedia Technology Inc.'
    device     = 'ASM1062 Serial ATA Controller'
    class      = mass storage
    subclass   = SATA
ahci1@pci0:4:0:0:       class=0x010601 card=0x92151b4b chip=0x92151b4b rev=0x11 hdr=0x00
    vendor     = 'Marvell Technology Group Ltd.'
    class      = mass storage
    subclass   = SATA
re0@pci0:5:0:0: class=0x020000 card=0xe0001458 chip=0x816810ec rev=0x03 hdr=0x00
    vendor     = 'Realtek Semiconductor Co., Ltd.'
    device     = 'RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller'
    class      = network
    subclass   = ethernet
none0@pci0:6:14:0:      class=0x0c0010 card=0x10001458 chip=0x8024104c rev=0x00 hdr=0x00
    vendor     = 'Texas Instruments'
    device     = 'TSB43AB23 IEEE-1394a-2000 Controller (PHY/Link)'
    class      = serial bus
    subclass   = FireWire
ahci3@pci0:7:0:0:       class=0x010601 card=0xb0001458 chip=0x2363197b rev=0x02 hdr=0x00
    vendor     = 'JMicron Technology Corp.'
    device     = 'JMB363 SATA/IDE Controller'
    class      = mass storage
    subclass   = SATA
atapci0@pci0:7:0:1:     class=0x010185 card=0xb0001458 chip=0x2363197b rev=0x02 hdr=0x00
    vendor     = 'JMicron Technology Corp.'
    device     = 'JMB363 SATA/IDE Controller'
    class      = mass storage
    subclass   = ATA

so kann man sehen, welche HDD an den problematischen Anschlüssen stecken: 

> fgrep ' kernel: ' /var/log/messages | fgrep ' at ahcich3 '
Jul 31 17:35:34 freebsd12 kernel: ada2 at ahcich3 bus 0 scbus3 target 0 lun 0

> fgrep ' kernel: ' /var/log/messages | fgrep ' at ahcich5 '
Jul 31 17:35:34 freebsd12 kernel: ada4 at ahcich5 bus 0 scbus5 target 0 lun 0

In einem Forum habe ich gelesen, dass ZFS mit Controllern Probleme hat, die einen Marvell-Chip-Satz besitzen. Nachdem ich diesen SATA-Controller mit Marvell-Chipsatz aus dem System entfernt hatte, war das Problem behoben.

acpi error ae_not_found while resolving a named reference package

Dieser Fehler tritt oft mit Mainboards von Gigabyte auf. Die Ursache sind Bugs im BIOS bezüglich der ACPI-Steuerung. Gelöst werden kann das Problem ggf. durch ein BIOS-Update.

/home/http/wiki/data/attic/freebsd/freebsd.1716832978.txt · Zuletzt geändert: von manfred