Archive for the 'FreeBSD' Category

OnlineTVRecorder-Decoder

Mittwoch, Mai 11th, 2011

Wer einen Account bei OnlineTVRecorder.com hat, wird feststellen, dass der Decoder bei weitem nicht fuer alle Betriebssysteme verfuegbar ist. Eine Datei herunterladen und direkt auf dem Server dekodieren ist also nicht ganz so einfach, wenn man ein FreeBSD hat. Wie unschoen das zunaechst auch erscheint, es gibt eine Moeglichkeit den Decoder trotzdem zu nutzen: den Linux-Kompatibilitaets-Layer.

Vorbereitungen

Installation

Statisches Binary

Nun, da das FreeBSD installiert ist, kann man das Linux-Binary des Decoders herunterladen. Den gibt es auf den Seiten des OTR im Linux-Bereich (Link zu den OTR-Downloadseiten). Dort gibt es diverse Linux-Versionen. Zunächst habe ich es mit der einfach statisch gelinkten Version ausprobiert. Das ging soweit auch, allerdings konnte er nie zum Server verbinden um die OTR-Datei zu dekodieren. Ich habe immer den selben Fehler erhalten, wie er auch im OTRForum zu finden war: „No Connection to Server“. Kein warum oder wieso… es geht schlicht nicht.

Statisch gelinktes Binary funktioniert also gar nicht.

Dynamisch gelinktes Ubuntu-Binary

Nächster Versuch erschien mir eigentlich unnötig, aber weil das ausprobieren ja schnell gemacht ist, habe ich dann doch noch das Ubuntu-Binary geladen und ausprobiert. Damit lief das Dekodieren der OTR-Datei problemlos. Wirklich installieren muss man den Decoder auch nicht. Es reicht das tar.bz2 auszupacken und die Datei otrdecoder auszufuehren (natuerlch mit den entsprechenden Parametern).

Welche der dort angebotenen Versionen funktionieren denn schlussendlich? Probiert habe ich insgesamt drei Versionen:

  1. Dekoder (Statisch gelinkt): funktioniert nicht
  2. Dekoder (Dynamisch gelinkt (Ubuntu Gutsy)): funktioniert
  3. EasyDecoder (Konsolenversion, 32bit – Ubuntu 8.04): funktioniert.

Die 64bit Varianten habe ich nicht weiter getestet, nachdem die 32bit Versionen liefen.

NetBSD5-Netzwerkinstallation

Montag, Juli 20th, 2009

So ab und an kommt es doch mal vor, dass ich mich von FreeBSD zu Open- oder NetBSD verirre. Dann stehe ich jedes mal vor der Frage: Verbrenne ich einen Rohling fuer die Installation oder installiere ich den Kram via Netzwerk? Meist entscheide ich mich dann fuer letzteres. Die Infrastruktur (TFTP- und DHCP-Server) ist sowieso vorhanden.

Gestern war wieder so ein Versuch ein NetBSD5 auf eine Kiste zu buegeln. Es war bei NetBSD mal so, dass es einen extra Installations-Kernel gab. Da brauchte man lediglich die pxeboot-Datei, die dem DHCP-Server hingeworfen wurde und eben diesen Installation-Kern. Mitlerweile hat sich aber eine Kleinigkeit geaendert, denn es wird nur noch der GENERIC-Kern und eine Ramdisk (miniroot.kmod) benoetigt um ins NetBSD-Setup zu gelangen. Um diese Veraenderung zu verstehen bzw. um herauszubekommen, wie es nun tatsaechlich geht, habe ich eine ganze Weile gebraucht. Das NetBSD-Handbuch schweigt sich darueber aus.

Schritt 1: TFTP-Server

Der Anfang dieser Installation ist wie gehabt. Man startet einen TFTP-Server, der die Dateien pxeboot_ia32.bin (fuer NetBSD5 zum Beispiel hier herunterladbar) und kern-GENERIC.tgz (Download hier) ausliefert. Darueber hinaus braucht man mitlerweile noch die entsprechende Ramdisk: miniroot.kmod (gibts hier zum herunterladen)
Unter FreeBSD wuerde das etwa so aussehen: Zunaechst werden die Dateien heruntergeladen und in /tftpboot abgelegt.

cd /tftpboot
fetch ftp://ftp.de.netbsd.org/pub/NetBSD/NetBSD-5.0/i386/installation/misc/pxeboot_ia32.bin
fetch ftp://ftp.de.netbsd.org/pub/NetBSD/NetBSD-5.0/i386/binary/sets/kern-GENERIC.tgz
fetch ftp://ftp.de.netbsd.org/pub/NetBSD/NetBSD-5.0/i386/installation/miniroot/miniroot.kmod

Nun muss noch der TFTP-Server in /etc/inetd.conf aktiviert werden. Dazu wird das Kommentarzeichen vor der Zeile

#tftp    dgram   udp     wait    root    /usr/libexec/tftpd      tftpd -l -s /tftpboot

entfernt. Danach kann man dann entweder ein inetd_enable=“YES“ in /etc/rc.conf unterbringen und mittels /etc/rc.d/inetd starten, oder aber man fuehrt einfach ein /etc/rc.d/inetd forcestart aus. Beides fuehrt auf jeden Fall dazu, dass der inetd gestartet wird.

Schritt 2: DHCP-Server

Einen laufenden DHCP-Server vorausgesetzt, sollte ein kleiner Eintrag reichen. Ich selber habe einen isc-dhcpd am laufen, den ich um folgende Zeile im Subnet-Bereich der dhcpd.conf ergaenzt habe:

filename "pxeboot_ia32.bin";

Danach noch den DHCP-Server neustarten (/usr/local/etc/rc.d/isc-dhcpd restart) und alles sollte soweit funktionieren.
Sicher koennte man auch der Einfachheit halber einen Eintrag fuer die entsprechende MAC-Adresse machen, aber ich hatte diese gerade nicht zur Hand, als ich den DHCP konfiguriert habe. Sie stand schlichtweg nicht auf dem Device drauf. Also habe ich einfach als globale Einstellung das pxeboot eingetragen. Da sollte man vielleicht noch dran denken das wieder zu deaktivieren. Ansonsten koennte es irgendwann mal komische Ueberraschungen geben, wenn ploetzlich einige Rechner versuchen ein NetBSD aus dem Netz zu booten. 🙂

Schritt 3: Rechner installieren

Nun fehlt eigentlich nur noch eine Sache, die da waere, den Zielrechner zu installieren. Dazu wird er ganz normal angeschlossen und gestartet. Sofern er pxeboot-faehig ist und dies auch aktiviert ist (das ist rechnerabhaengig), sollte der NetBSD-pxeboot kommen. Dort hat man 5 Sekunden lang Zeit die Leertaste zu druecken. Nachdem das erfolgt ist, braucht man eigentlich nur noch zwei Befehle:

load tftp:miniroot.kmod
boot tftp:kern-GENERIC.tgz

Falls man noch Einstellungen mittels userconf machen will, kann man hier noch ein -c anfuegen: boot tftp:kern-GENERIC.tgz -c.

Soweit so gut, sollte eigentlich funktionieren und den Rechner ins Setup booten lassen.

Perl 5.8.9-Fehler

Freitag, Januar 30th, 2009

Wieder mal einer dieser merkartigen Fehler: Ich habe ein frisches FreeBSD7.1 auf einem Xeon mit 1GB RAM und 2 SCSI-Platten im Software RAID-1 installiert. Ports-Tree geladen und wollte dann die eine oder andere Anwendung installieren: Ruby, portupgrade, Midnight Commander, … und spaetestens der Midnight Commander faengt an als Abhaengigkeit ein Perl haben zu wollen. Mitten drin brach das ganze aber mit folgendem Fehler ab:


==> Your Makefile has been rebuilt. <==
==> Please rerun the make command. <==
false
*** Error code 1

Stop in /usr/ports/lang/perl5.8/work/perl-5.8.9/ext/DynaLoader.
make config failed, continuing anyway...
Makefile out-of-date with respect to Makefile.PL
Cleaning current config before rebuilding Makefile...
make -f Makefile.old clean > /dev/null 2>&1
../../miniperl "-I../../lib" "-I../../lib" Makefile.PL "INSTALLDIRS=perl" "INSTALLMAN3DIR=none" "PERL_CORE=1" "LIBPERL_A=libperl.so"
Writing Makefile for DynaLoader
==> Your Makefile has been rebuilt. <==
==> Please rerun the make command. <==
false
*** Error code 1

Stop in /usr/ports/lang/perl5.8/work/perl-5.8.9/ext/DynaLoader.
*** Error code 1

Stop in /usr/ports/lang/perl5.8/work/perl-5.8.9.
*** Error code 1

Stop in /usr/ports/lang/perl5.8.
*** Error code 1

Stop in /usr/ports/lang/perl5.8.

Das fand ich dann ein wenig bedenklich. Also fing ich an zu gruebeln, was das sein koennte. Der Versuch ein frisches FreeBSD-Grundsystem zu installieren, scheiterte daran, dass irgendwelche Dateien nicht kopiert werden konnten, weil sie angeblich nicht existierten. Warum aber lief dann bitte das buildworld durch? Neuinstallieren und nochmal probiert. Aenderte nichts, das Perl brach beim selben Fehler wieder ab. Ich weiss nicht mehr genau bei welchem Befehl es war, aber irgendwann gab mir ein Kommando mal zurueck, dass das Systemdatum nicht stimmte. Bah! Widerliches Zeug, also Systemdatum korrigiert und auf ein neues Perl kompiliert – siehe da: geht doch!

Achja, fast haette ich es vergessen, zwischenzeitlich versuchte ich dann auf dem mit dem falschen Systemdatum nochmal ein aelteres Perl (5.6 oder so). Das hatte einen anderen lustigen Effekt: es hing in irgendeine Endlosschleife und erzeugte immer neue Shell/make-Prozesse.

Was es nicht alles gibt und was ein falsches Systemdatum nicht alles anrichten kann. Genug davon für heute, ich geh schlafen.

FreeBSD8amd64 bei Strato

Freitag, Juli 25th, 2008

Die aktuellen dedizierten PowerServer bei Strato sind ein relativ ansprechendes Angebot. Seit einiger Zeit habe ich ja einen – so langsam ist es aber mal dran, dass er ausgetauscht wird. Nun habe ich mir also einen neuen Server geholt. Dieser hat ein Software-RAID1, einen Opteron 146 und 1GB Ram. Dort habe ich dann versucht ein FreeBSD mittels Depenguinator 2 zu installieren – das war leider nicht moeglich. Also habe ich mir in Qemu ein 2GB AMD64-Image gebastelt. (siehe dazu auch: http://www.hcesperer.org/howtos/fbsd_alturo.html) (mehr …)

FBSD7amd64 bei Server4You

Dienstag, Juli 15th, 2008

Nachdem ich im letzten Artikel beschrieben habe, wie man den Depenguinator auf einem S4Y-Server einsetzt, fehlt nun nur noch die eigentliche FreeBSD-Installation.

Nachdem man das System depenguiniert hat, kann man sich mit ssh wieder auf die Kiste verbinden. Hierzu brauchen wir wieder das Keyfile, dass wir in der vorherigen Anleitung angelegt haben.

ssh -i id_rsa root@SERVER

(mehr …)

Depenguinator 2.0 auf S4Y-Server

Freitag, Juli 11th, 2008

Server4You ist wohl einer der Anbieter, die dedizierte Server fuer relativ wenig Geld unters Volk bringen. Leider hat man dort nur die Wahl zwischen Linux und ggf. einem Windows. Da das fuer mich eigentlich mitlerweile keine wirklich schoene Option mehr ist, habe ich mich mal eine Weile umgesehen. So einfach ist es nicht dort ein FreeBSD zu installieren, da das RescueSystem nicht einfach ist und Zugriff auf eine Konsole hat man bei S4Y auch nicht inklusive.

Es gibt jedoch eine Moeglichkeit um auch hier ein FreeBSD zu installieren. In frueheren Zeiten (FreeBSD5) konnte man das mit dem Depenguinator 1 erledigen – mit aktuellen FBSDs funktioniert das jedoch nicht mehr. Mitlerweile gibt es einen Nachfolger: Depenguinator 2.0. Mit ihm ist es moeglich ein FreeBSD so in eine RAM-Disk zu legen, dass man dies booten und dann mit der Installation weiter machen kann. 🙂

Zunaechst mal braucht man also einen dedizierten Server4You-Server (keinen VServer), weiterhin etwas FreeBSD-Know How und natuerlich Geduld und ein bisschen Frickelwillen. Die Anleitung unter http://www.daemonology.net/blog/2008-01-29-depenguinator-2.0.html hilft zwar schon viel weiter, aber so ganz hat es bei mir damit dann doch nicht funktioniert.

(mehr …)

Freebsd7amd64 & Linux-Sphere

Dienstag, Juli 8th, 2008

Wer sich nun erstmal fragt, was eine Sphere ist, hat damit eine berechtigte Frage gestellt. Ein Sphere-Server ist ein Spielserver fuer Ultima Online – ein MMORPG. Normalerweise ist Ultima Online ein Spiel fuer das bezahlt werden muesste. Es gibt jedoch einige Server, die ein freies Spielen ermoeglichen. Es gibt einige Freeshards (freie Server) – einer davon ist Alathair, auf dem mein Bruder spielt. Wir haben vor einiger Zeit einen Umzug des gesamten Webauftrittes und des Spielservers vollzogen – mitlerweile laeuft auch fast alles wieder. Leider sind wir dabei jedoch auch auf einige Unschoenheiten gestossen.

Auf einem meiner dedizierten Server laeuft ein Linux auf einem AMD Athlon X2, also was liegt naeher als dort auch die Linux-Sphere laufen zu lassen. Also alles raufkopiert und gestartet, jedoch war dann keine Verbindung auf den entsprechenden Port moeglich. Nach vielem herumprobieren stellte sich heraus, dass die Sphere nicht auf einem Linux/x86-64 laeuft, sondern nur auf Linux/x86. Beim naechsten Test gingen wir dann dazu ueber die FreeBSD-Version der Sphere zu probieren. Diese war fuer das Laufen auf einem FreeBSD7 vorgesehen, startete auf meinem zweiten dedizierten Server jedoch nicht. Nach alle dem haben wir es dann also auf einem Linux/x86 zum Laufen gebracht, alles jedoch sehr unschoen.

Nach einiger Zeit habe ich mir dann den Spass gemacht und auf meinem MacBook ein FreeBSD7amd64 installiert. Dort das linux-Kernelmodul geladen emulators/linux_base-f8 aus den Ports installiert. Als weitere Spielerei dann noch mit ezjail ein extra Jail konfiguriert (ein Jail ist quasi chroot auf Steroiden :)). Dadrin dann wieder die linux-base installiert und dadrin die Linux-Sphere gestartet. Siehe da, alles lief problemlos. Leider wirds nicht dazu kommen, dass die Sphere auf einem FreeBSD eingesetzt wird. Sie wird nun ihr Dasein auf einem Linux fristen. 🙂

Update 2008-07-08:

Nachdem nun schon eine Weile ins Land gegangen ist, haben wir die Beta-Sphere auf mein Macbook umgezogen. Zumindest ein Teil laeuft nun auf einem FBSD7amd64 im Jail – wenigstens etwas.

FreeBSD und Razer Copperhead

Freitag, April 18th, 2008

Vor ein paar Wochen war es noch so, dass eine Razer Copperhead (ich glaube auch bei Habu-Maeusen von M$ war es so) nicht unter FreeBSD betrieben werden konnte. Dies äusserte sich dahingehend, dass die Maus zwar als Device erkannt wurde – sie fing sogar an zu leuchten. Allerdings war es dann nicht mehr möglich mit ihr Eingaben zu tätigen. Als Antwort auf der Mailingliste bekam ich dann einen Patch, der dies gefixt hat.

Seit einem Update der letzten Tage funktioniert es allerdings auch wieder ohne irgendwelche Probleme. Jeder Copperhead-Benutzer kann nun also wieder froehlich ohne viel Bastelei durch die gegend mausen.

Razer Copperhead unter FreeBSD

Mittwoch, Januar 23rd, 2008

Seit einiger Zeit funktionierte meine schoene Razer Copperhead nicht mehr unter FreeBSD – ein Update des damaligen 7-Current machte es zunichte. Ich wollte jedoch nicht ewig auf dem alten Code sitzen bleiben (um meine Maus mit einer alten Version der ums.c weiter zu nutzen) und schrieb es mal an die usb-Mailingliste. Leider bekam ich dort lange keine Antwort. Vor ein paar Wochen ging jedoch ein Patch ueber die Liste. Dieser war zwar fuer FreeBSD-7, funktioniert jedoch auch auf meinem FBSD-8 ganz hervorragend (an dieser Stelle danke an Jase Thew fuer den Patch). Es ist jedoch im Moment nicht der Fall, dass dieser Diff uebernommen wird – warum weiss ich nicht. Damit jedoch andere Leute, die dieses Problem ebenfalls haben, davon profitieren koennen, stelle ich den Diff hier online. Interessant waere noch, ob dieser Patch auch mit Microsoft-Maeusen funktioniert, da auf der Liste einige Mails umgingen, dass auch die Maeuse aus der Kooperation von Microsoft und Razer seit dem Update eher nicht mehr funktionierten.

Problembeschreibung: Die Razer Copperhead besteht aus einer Mauskomponente und einer Tastaturkomponente, mit der die programmierbaren Tasten realisiert werden. FreeBSD erkennt diese Maus nur noch als Tastatur – dementsprechend ist eine Maussteuerung nicht mehr moeglich.

Problemloesung: Einspielen des Diffs: files/2008/01/copperhead.diff.

FreeBSD und ATI M24 1T FireGL

Donnerstag, Januar 17th, 2008

Ich habe am Wochenende mein ThinkPad von ZFS wieder auf UFS + SoftUpdates + Background-fsck umgestellt. Der Grund dafuer war der Geschwindigkeits- und Stabilitaetsvorteil. Es kam bei mir unter einigen komischen Konstellationen gerne mal zu einer Kernelpanik, trotz der Tuning-Settings. ZFS ist nun mal urspruenglich fuer 64bit Systeme (mit ausreichend RAM) entwickelt worden, mein ThinkPadist aber leider noch ein Pentium-M und noch kein Core2.

Soweit so gut, die Neuinstallation war schnell erledigt. Auch das bauen der notwendigen Ports ging fix. Ich habe mir vorher eine Sicherung aller Settings gemacht und dann spaeter alles nur noch zurueckkopiert. Aber was war das? Ich habe mir wohl eine sehr unguenstige Zeit ausgesucht um eine Neuinstallation zu machen … ich hatte Grafikfehler im X. Also nochmal alles runter und statt des FreeBSD-Current (8) ein FreeBSD-7 RC installiert. Aber auch hier die selben Grafikfehler. Aber wieder nur im X und mit dem ATI-Treiber – mit VESA funktionierte alles wunderbar und nach einiger Zeit konnte ich dann von VESA auf ATI ohne Probleme umestellen.

Was hatte ich verkehrt gemacht? Ich weiss es bis heute nicht, aber ich habe auf der FreeBSD-X11-Mailingliste einige Tage zuvor aehnliche Probleme gesehen. Und habe heute gesehen, dass es dafuer eine relativ einfache Loesung gibt. Ein Options-Eintrag in der xorg.conf-Section fuer die Grafikkarte half:

Section „Device“

Option „CPPIOMode“ „yes“
Identifier „Card0“
Driver „ati“
VendorName „ATI Technologies Inc“
BoardName „M24GL [Mobility FireGL V3200]“
BusID „PCI:1:0:0“

EndSection

Wie man sieht, einfach die Zeile Option „CPPIOMode“ „yes“ ergaenzen und die Sache laeuft. Da das Thinkad noch immer mit einem FreeBSD7 lief, habe ich eben mal wieder ein Update auf -Current gemacht und noch laeuft alles wunderfein, mal sehen wie lange. 🙂