Auf einem PandaBoard (PB), dessen Betriebssystem ("Linaro 12.01") ich von einem 4 GByte-Image auf eine SDHC-Karte mit 16 GByte installiert hatte, stieß ich bereits kurz danach bei einem apt-get dist-upgrade, bei dem auch ein neuer Kernel mitsamt Header installiert werden musste, auf Probleme. Mangels Speicherplatz auf der SD-Karte wurde das Update fehlerhaft beendet. Ursache war, dass die "rootfs"-Partition des Linaro-Linux nur knapp über 3 GByte groß war und dort nicht mehr (nur temporär erforderlicher) Platz für das Update vorhanden war.

Abhilfe sollte ein Vergrößern der "rootfs"-Partition auf eine Größe von ca. 14 GByte per resizefs (hier in Form von GParted) bringen. Also die SD-Karte am Arbeits-PC angeschlossen und entsprechend bearbeitet. Die Karte wieder zurück in das PandaBoard, dieses gebootet und...

Nun, da ich auf meinem BeagleBoard-xM (BBxM) unter Angstrom-Linux ein USB-Modem installiert und die Voraussetzungen für das Übersetzen von C++-Programmen geschaffen hatte, konnte ich mein nächstes großes Ziel ins Auge fassen: Die Installation von HylaFAX+.

Damit sollte das BBxM in die Lage versetzt werden, in meinem Netzwerk als Faxserver für das Versenden und Empfangen von Faxen zu arbeiten. Da es kein fertiges Installations-Paket für HylaFAX(+) im Repository von Angstrom gab und wegen der fehlenden Binärkompatibilität der von HylaFax+ bereitgestellten Binaries musste ich dieses Paket selbst übersetzen und installieren.

Um Programme (C++, C usw.), die nur im Quellcode vorliegen und für die es keine Pakete im Software-Repository der entsprechenden Linux-Distribution gibt, lauf- bzw. funktionsfähig (ausführbar) übersetzen zu können, braucht man auf dem PC / System in aller Regel einen entsprechende Kompiler bzw. Compiler (und noch einiges mehr).

Auf einem BeagleBoard-xM (BBxM) wird dies noch dadurch erschwert, dass überwiegend empfohlen wird, Programme, die nur im Quellcode vorliegen, auf einem leistungsfähigen Computer zu übersetzen. Da das BBxM einen ARM-Prozessor, reguläre PCs in der Regel aber einen x86-kompatiblen Prozessor haben, sind die auf einem PC kompilierten Programme nicht einfach auf das BBxM übertragbar (nicht binärkompatibel). Deshalb wäre dafür die Schaffung einer sogenannten "cross-compile-Umgebung" erforderlich.

Für den gewünschten Einsatzzweck (Fax-Funktionalität) meines BeagleBoard-xM (BBxM) brauchte ich ein Modem. Es gibt Modems, die per serieller Schnittstelle (über die das BBxM ja verfügt) oder USB angeschlossen werden können. Die seriellen brauchen ein eigenes Netzteil und erhöhen den Verkabelungsaufwand, USB-Modems sind teilweise nicht für Linux geeignet, wenn ein Treiber, sprich der PC die Rechenarbeit erledigt (Win-Modem, ähnlich der Win-GDI-Drucker). Nach einer Internet-Recherche fiel meine Wahl auf ein USB-Modem "Trendnet TFM-561U", weil dieses ausweislich einiger Kaufrezensionen problemlos unter halbwegs aktuellen Linux-Versionen funktionieren soll. Zudem bewirbt der Hersteller (siehe o.a. Link) ebenfalls die Linux-Funktionalität.

Also bestellt, gewartet und geliefert ...

Das BeagleBoard-xM (BBxM) hat eine LAN- bzw. Ethernet-Schnittstelle bereits installiert. Das mit dem BBxM gelieferte Angstrom-Linux enthält den "networkmanager", der dafür sorgt, dass dieser Schnittstelle (bei angeschlossenem LAN-Kabel) von einem (soweit vorhanden) DHCP-Server bzw. -Dienst eine IP-Adresse zugewiesen wird. Nun ist es so, dass bei jedem Neustart des BBxM sich die MAC-Adresse der Ethernet-Schnittstelle ändert und die DHCP-Server dadurch dem BBxM eine neue (sprich: andere als vorher) IP-Adresse zuweisen. Besser und / oder komfortabler ist es, wenn das BBxM eine feste IP-Adresse des LANs zugewiesen bekommt, vor allem, wenn es ohne Monitor und Tastatur irgendwo im Netzwerk eingebunden ist.

Wie ich in meinem ersten Beitrag zum BeagleBoard-xM (BBxM) schrieb, ist es besser, von dem lauffähigen Angstrom-System, welches dem BBxM auf einer bootfähigen micro-SDHC-Karte beiliegt, eine Kopie anzufertigen. Anschließend kann man mit dieser Kopie seine weiteren "Gehversuche" machen und hat das Original immer noch als Reserve bzw. Backup, wenn mal gar nichts mehr geht.

Das BeagleBoard-xM (nachfolgend einfach BBxM genannt) ist ein ARM-Prozessor basierendes kleines PC-System, was sich besonders durch seinen niedrigen Stromverbrauch auszeichnet. Durch seinen RAM-Speicher, die Taktrate des Prozessors und die Vielfalt der Schnittstellen eignet es sich meines Erachtens für eine Vielzahl von kleinen bis mittleren Aufgaben in vielen Umgebungen (Messen, Steuern, Regeln, Überwachen usw.).

Auf einem neu installierten OpenSUSE 11.4 System mit Firefox (FF) 4.0.1 stellte ich - im direkten Vergleich zu einem baugleichen PC mit OpenSUSE 11.0 und FireFox 3.6.10 - einen sehr langsamen Seitenaufbau fest. In der Statuszeile waren die Anzeigen der Namensabfragen (DNS) und andere Statusmeldungen immer sekundenlang sichtbar.

Die Protokollierung sollte

Dieser Eintrag beschreibt meine Versuche, ein Arduino UNO (mit USB-Schnittstelle) unter OpenSuse 11.1 32-Bit in Betrieb zu nehmen, da ich mit diesem Arduino-Board unter Kubuntu 10.04 32-Bit LTS ab dem 2. Tag des Experimentierens immer größere Probleme hatte.

Vor dem Anschluss des UNO-Boards erst mal in einer Konsole


tail -f /var/log/messages


eingegeben, um zu sehen, ob es auch richtig erkannt wird.

Aus (zunächst) Spieltrieb und Neugierde heraus habe ich mir ein Arduino UNO Board mit einigem Zubehör (Sensoren usw.) gekauft...

Hier der Anfang meiner Erfahrungsberichte:

Arduino Uno angeschlossen (nachdem ich mir aus den Arduino-Repos das entsprechende Paket installiert hatte) und vorher in einem Konsolen-Fenster ein


#$: tail -f /var/log/messages


abgesetzt.
Die Ausgabe in der Konsole:

Nach einem Update von Drupal 5 auf Version 6 habe ich neue Storys erstellt bzw. vorhandene geändert. Relativ zeitnah stellt ich fest, dass genau diese Storys (und nur diese) von Besuchern nicht mehr gelesen werden konnten. Als angemeldeter Administrator bestanden dagegen keinerlei Probleme alle Artikel zu lesen. An sich also ein Rechteproblem ...

Hinweise im W3 gab es überwiegend nur zu einem Problem, dass der Site-Admin zwar alles, die Gäste aber gar keinen Artikel lesen konnten.

Meine mittels Drupal (Version 5.3) gestaltete Seite sollte auf eine neue Hardware umziehen (beim gleichen Provider). Zudem sollte (später!) auch die Drupal-Version auf den aktuellen Stand (Version 6.19) gebracht werden (dazu wird es in Kürze hier einen eigenen Beitrag geben. Nur soviel vorab: Es ist gelungen).

Im W3 gab es verschiedene Anleitungen zu diesem Umzugs-Szenario (Update blieb erst Mal außen vor), u.a. gelegentlich der Hinweis, dass dies auch 1:1 - also per "einfachem" kopieren - ging. Das weckte mein Interesse, ob dies tatsächlich "so einfach" sein konnte (vorweg: War es nicht, aber passieren konnte nicht viel, da meine bisherige Web-Präsenz ja nicht damit abgeschaltet wurde). Deshalb habe ich es zunächst auf die 1:1-Methode versucht bzw. gemacht.

Ausgehend von dieser Anleitung (englisch) für Debian 5 (Lenny) habe ich auf einem neuen Root-Server mit Ubuntu 10.04 LTS einen Mail-Server aufgesetzt. Dabei stieß ich zunächst auf nur geringfügige Unterschiede zwischen den beiden Linux-Derivaten bzw. -Distributionen.

Vorweg genommenes Fazit: Am Ende hatte ich einen funktionierenden Mail-Server mit Spam-Erkennung (Markierung) und Virenschutz für verschiedene Domains und mehrere Mail-Konten.

Nachfolgend einige Probleme, die ich bei der Installation (zu lösen) hatte:

Unter Windows gibt es einige grafische Programme, mit denen man Auswertungen seiner Fotografier-Gewohnheiten an Hand der in den Fotos eingebetteten EXIF-Informationen erstellen kann. Fragen wie