Tag Archives: Debian

Running EAGLE 9.6 on Debian 10 (buster)

For some side project I wanted to look at the schematics of the Adafruit PowerBoost 500C, which happened to be made with Autodesk EAGLE.

Having run EAGLE on Debian 9 (stretch) for a while now without great hassle, I did not expect much difficulties, I was wrong. First I downloaded the tarball from their download site. Don’t worry, there’s still the “free” version for hobbyists, however it’s not Free Software, but precompiled binaries for amd64 architecture, better than nothing.

After extracting, I tried to start it like this and got the first error:

There’s no verbose or debug option. And according to the comments on the blog post “How to Install Autodesk EAGLE On Windows, Mac and Linux” the problem also affects other users. I vaguely remembered somewhere deep in the back of my head, I already had this problem some time ago on another machine, and tried something not obvious at all. My system locale is German, looked like this before:

As you can see, no English locale, so I added one. On Debian you do it like this. Result below:

This seems like a typical “works on my machine” problem from an US developer, huh? Next try starting eagle, you’ll see the locale problem is gone, the next error appears:

That’s the problem if you don’t build from source against the libraries of the system. In that case EAGLE ships a shared object libxcb-dri3.so.0, which itself is linked against the libxcb.so.1 from my host system, and those don’t play well together. I found a solution to that in a forum thread “Can’t run EAGLE on Debian 10 (testing)” and it is using the ld_preload trick:

This works. Hallelujah.

Performance Analysis on Embedded Linux with perf and hotspot

This is about profiling your applications on your embedded Linux target or let’s say finding the spots of high CPU usage, which is a common concern in practice. For an extensive overview see Linux Performance by Brendan Gregg. We will focus on viewing flame graphs with a tool called hotspot here, based on performance data recorded with perf. This proved to be helpful enough to solve most of the performance issues I had lately.

Installing the Tools

We have two sides here: the embedded Linux target and your Linux workstation host. For your computer you need to install hotspot. In Debian it is available from version 10 (buster). You can build from source of course, I did that with Debian 9 (stretch) a while ago. IIRC there are instructions for that upstream. Or you build it from the deb-src package from Debian unstable (sid) by following this BuildingTutorial.1

The embedded target part needs basically two parts. You have to set some options in the kernel config and you need the userland tool perf. For ptxdist here’s what I did:

  • Add -fno-omit-frame-pointer to global CFLAGS and CXXFLAGS

Note: I had to update my kernel from v4.9 to v4.14, otherwise I got build errors when building perf.

Configuring the Kernel

I won’t quote the whole kernel config here, but I have a diff on what I had to set to make perf record useful things. These options are probably important, at least I had those on in my debug sessions (others might also be needed):


Using it

For embedded use, I basically followed the instructions of upstream hotspot. You might however want to dive a little into the options of perf, because it is a very powerful tool. What I did to record on the target was basically this to get samples from my daemon application mydaemon for 30 seconds:

This can produce quite a lot of data, so use it with short times first to not fill your filesystem. Luckily I had enough space on the flash memory of the embedded target available. Then just follow what the hotspot README says: copy the file and your kernel symbols to your host and call hotspot with the right options to your sysroot. This was the call I used (from a subfolder of my ptxdist BSP, where I copied those files to):

Happy performance analysing!

  1. I did not test that with hotspot []

Getting CDash to work on Debian 9 (stretch) with lighttpd and MariaDB

After reading It’s Time To Do CMake Right and The Ultimate Guide to Modern CMake I stumbled about the slides of Effective CMake by Daniel Pfeifer. (I did not watch the related video C++Now 2017: Daniel Pfeifer “Effective CMake” though.)

What attracted my attention where the commands ctest_coverage() and ctest_memcheck() from the slide about CTest which comes with CMake and which I already use. In libcgi and some non free projects I create additional tests to be run with valgrind if that tool is found on the build host, but when using CTest/CDash I don’t need to do that and also get coverage tests on top, so I set up a local CDash server on my workstation, which was painful in multiple ways.

After extracting the CDash archive and configuring lighttpd to server its PHP files the install.php came back with the following error message:

Specified key was too long; max key length is 767 bytes

It was not easy to find the cause. The web says this is fixed in MariaDB 10.2.x while my Debian stable still has 10.1.x … and I found only some workarounds on that problem for other projects than CDash. I could “solve” that by changing the database collation from utf8mb4_unicode_ci to utf8_unicode_ci in phpMyAdmin on the still empty database cdash before running install.php.

The more challenging problem was to actually submit results to the CDash server when calling CTest. The webserver always responded with HTTP Status Code 417. That was only partly fault of CDash, which seems to call curl with some strange (?) headers for submission. That turned out to trigger some (from my side) unexpected behavior in lighttpd, for which several tickets exist, I found #1017 eventually, which led me to the lighttpd 1.4.21 release info giving the hint I needed. I added this somewhere in my lighttpd config files:

In the end I have a local CDash instance now and could already submit some helpful coverage and memcheck results. Best thing: This way I can remove the error prone additional tests from my CMakeLists.txt and still run the tests with valgrind, even more flexible than ever.

HowTo: ownCloud mit lighttpd auf Debian Jessie

Der Fortschritt macht nicht halt und dass jemand™ sich jetzt ein Fairphone mit Android drauf gekauft hat, war eine willkommene Gelegenheit sich mal eine eigene ownCloud-Instanz aufzusetzen. Debian Jessie ist zwar derzeit noch »testing« aber schon ganz gut nutzbar und da es dort fertige Pakete für ownCloud 7 gibt und eine passende VM auf dem Server zu Haus bereits lief, fiel die Wahl darauf. Ein lighttpd mit PHP lief auch schon und der Rest war auch so schwer nicht.

Im derzeitigen Stand des Paktes muss man die Datenbank für ownCloud noch selbst anlegen. Ich hab das mit phpmyadmin gemacht, wo das Debian-Paket sich selbst schon einfach in lighttpd integriert. Die Zugangsdaten gibt man später beim Einrichtungswizard vom ownCloud an.

Im ownCloud Paket ist eine Möglichkeit dokumentiert, das Paket mit lighttdp zu nutzen, die automatische Integration wie bspw. bei phpmyadmin gibt es so nicht. Der falsch vorgeschlagene Pfad in der Doku, wurde von mir gemeldet und ich hab noch ein paar Dinge ergänzt:

Der untere Teil ist aus dem Vorschlag vom Paket übernommen, nur der alias-Pfad korrigiert. Der obere Teil ist für den direkten Zugriff über eine andere Subdomain statt über den hostname des Servers und einen Unterordner. An sich steht da aber das gleiche drin. Besonderes Augenmerk sei noch auf die redirects für die sogenannten well-known URLs nach RFC 5785 gelegt, die den Zugriff mit bestimmten Kalenderprogrammen deutlich vereinfachen.

Nachtrag: Dieses Mini-HowTo unterschlägt die Einrichtung von verschlüsseltem Zugriff über HTTPS. Ich habe das weggelassen, weil es a) an anderer Stelle gut beschrieben ist und b) ich hier noch einen nginx als Reverse Proxy vor dem lighty habe, der mit diesem HowTo rein gar nichts zu tun hat. ;-)

Auth required on KDE

Debian Wheezy, KDE und ab und zu funktioniert das Einspielen von Updates nicht oder das Mounten von Datenträgern. Manchmal hilft Reboot, manchmal nervt’s und manchmal schaut man warum. Also heute, eine NTFS-Partition auf einer eingebauten Platte, die nicht in /etc/fstab steht, über Dolphin einbinden. Normalerweise wird da nach dem Passwort gefragt und dann macht er das. Heute nicht, stattdessen:

An error occurred while accessing ‘DATEN’, the system responded: An unspecified error has occurred.: Authentication is required

Rumsuchen im Netz ist da nicht ganz leicht, aber folgendes ließ sich rausfinden. Es gibt ein Programm namens udisks mit dem man die selbe Fehlermeldung provozieren kann und das auch ansonsten interessante Dinge ausgibt. Und es gibt ein Programm pkexec welches Teil von polkit ist und wenn man es so aufruft, kann man testen, ob da alles stümmt:

Stimmte hier nicht, aber das brachte mich dahin, dass anscheinend ein Programm names polkit-kde-authentication-agent-1 laufen muss. Das lief hier nicht. Ob das abgestürzt war, oder nicht gestartet wurde, und warum, hab ich nicht mehr rausgefunden, aber das Ding einfach nochmal starten, behob mein Problem:

Sachdienliche Hinweise nehme ich gern entgegen.

HowTo: gitolite auf Debian Wheezy

Das Netz ist natürlich voll von HowTos zum Thema gitolite, in diesem hier nutze ich aber nicht die bleeding edge Version von upstream sondern das Debian-Paket. Eine gewisse Hilfe für’s Verständnis und bei der Installation war die Dokumentation für gitolite 2.x, denn in Wheezy ist Version 2.3 verpackt.


Geht los mit Installation des Pakets gitolite. Wenn der bei der Installation dpkg nichts konfiguriert haben will, dann gibt man danach nochmal ein:

Dort wird dann ein SSH public key abgefragt für den Admin-Nutzer. In meinem Fall hab ich hier für die Testinstallation auf dem selben Rechner den folgenden Pfad angegeben, ansonsten kopiert man seinen public key ins Eingabefeld:

Damit liegt jetzt hier unterhalb von /var/lib/gitolite1 folgendes:

Da mein public key bereits hinterlegt ist, kann ich direkt zum nächsten Schritt übergehen und das Admin-Repo clonen, welches bei der Installation angelegt wurde:

Wie man sieht, hatte ich den dedizierten Nutzer gitolite genannt, für Produktionsumgebung ist vielleicht git eine bessere Wahl.

Ganz wichtig: beim Ändern der Config muss man stets drauf achten, dass man sich nicht selbst aussperrt. Für das Repository gitolite-admin muss man Schreibrechte für irgendeinen Key behalten, auf den man auch Zugriff hat und der unterhalb von keydir im Repo liegt, sonst hat man keine Möglichkeit mehr ohne große Schmerzen diese Rechte wiederzuerlangen.


Als nächstes habe ich die Datei /var/lib/gitolite/.gitolite.rc angepasst. Berücksichtigt sind hier bereits, dass ich sowohl git-daemon als auch gitweb einsetzen und die Repos auf einen anderen Rechner spiegeln will. D.h. ich habe folgende Einträge geändert:

Der letzten Zeile ist erhöhte Beachtung zu schenken. Die bereits angelegten Repositories gitolite-admin und testing aus /var/lib/gitolite/repositories müssen nämlich in den geänderten Pfad verschoben werden.2 Damit der Zugriff über gitweb funktioniert, habe ich den Nutzer www-data der Gruppe git hinzugefügt und die Rechte des Repository-Verzeichnisses gelockert:3

Die eigentliche Konfiguration erfolgt dann wie bei gitolite üblich über das admin-Repository nachdem man es geklont hat:

Wie man das im Einzelnen macht, kann man in der Doku zu gitolite v2 nachlesen. Das ist nicht Debian-spezifisch.

gitweb mit lighttpd

Für einen schnellen Überblick mit dem Webbrowser ist das Paket gitweb installiert. Als Webserver kann vermutlich irgendein Webserver dienen. Für lighttpd habe ich eine Datei /etc/lighttpd/conf-available/80-gitweb.conf angelegt und mit den für diesen Browser üblichen Mechanismen aktiviert. Der Inhalt sieht so aus:4

Es ist außerdem das Modul 10-cgi.conf zu aktivieren:

In der /etc/gitweb.conf sind auch noch Anpassungen zu tätigen. Hier meine geänderten Zeilen:

Urspünglich war jetzt hier noch eine Beschreibung zum Mirroring, ich verschiebe das auf später und tu es in einen separaten Artikel … O:-)

  1. auch den Pfad kann man beim dpkg-reconfigure angeben. []
  2. Dieser Schritt kann natürlich entfallen, wenn man die Repositories im Standard-Pfad belässt. []
  3. Die Rechte der bei der Installation angelegten Repositories sind allerdings immernoch so restriktiv, dass sie nicht über gitweb angezeigt werden können. Bei <code>gitolite-admin</code> will man das sowieso nicht und statt <code>testing</code> legt man sich vielleicht ein weiteres Testrepository an, um zu sehen, ob das mit den Rechten beim neu anlegen richtig klappt. []
  4. Siehe auch gitweb im ArchWiki. []

Debian GNU/kFreeBSD in Xen HVM DomU mit Verschlüsselung und ZFS

Ich will Backup und ich will ZFS, da brauch ich glaube ich in beiden Fällen nicht drauf eingehen warum. Auf dem Server läuft ein Debian Wheezy (amd64) und mit Xen werden diverse virtuelle Maschinen ausgeführt. Für’s Backup sind vier Platten vorgesehen und da soll ZFS drauf und die Daten sollen verschlüsselt werden.

Wie ich jetzt darauf gekommen bin das ganze mit Debian GNU/kFreeBSD zu realisieren, sei mal nicht in Frage gestellt, ist jetzt so und es gibt eine VM, die mittels Hardware-Virtualisierung der CPU installiert wurde, hatte ich ja hier schon erwähnt wie. Probleme mit der I/O-Performance hab ich dank der passenden Mailingliste auch beheben können.

Bevor wir jetzt ZFS installieren, soll noch Crypto drunter. Das könnte man auch anders schichten, aber so rum scheint empfohlen zu sein. Ebenfalls empfohlen ist es Crypto nicht auf die nackte Platte zu tun (auch wenn das ginge) sondern die Platten noch zu partitionieren. Bei BSD scheint da mittlerweile GPT der Standard zu sein und das passende Tool bei FreeBSD wäre gpart. Beim Debian GNU/kFreeBSD haben wir aber Debian Userland und da gibt’s dieses Tool nicht. Partitioniere ich also mit gdisk, dachte ich mir, aber das ist dann auch wieder nicht so einfach, weil gdisk sich beschwert, dass /dev/da0 ein character device sei. Ist es auch, scheint bei BSD so zu sein, bedeutet aber, dass ich die Platten nicht in der VM partitionieren kann, sondern das bereits im Wirt tun muss. Mit gdisk war das kein Problem und als Partitionstyp hab ich mal FreeBSD ZFS benutzt aka 0xA504.

Nächster Schritt: Verschlüsselung. Da benutzt man bei FreeBSD das Tool geli und das ist dann wieder Kernel Space genug, dass es auch verfügbar ist. Befehle hier:

Und dann:

Beim Initialisieren kann man auch noch Keydateien angeben und alle möglichen Optionen setzen. Details dazu hat das FreeBSD-Handbuch. Analog wird mit den anderen Platten verfahren und es stehen einem dann die aufgeschlossenen Devices zur Verfügung, für die erste verschlüsselte Partition der ersten Platte hier /dev/da0p1.eli welches dann gleich einem zpool hinzugefügt wird.

Den zpool namens tank erzeugte ich dann so:

Das entspricht de facto einem RAID-6 und ist auch bereits unter /storage gemountet. Für den nächsten Systemstart fehlt also nur noch ein Skript, was mir die Crypto-Devices aufmacht. Bei Debian GNU/kFreeBSD kann man da mal in /etc/default/geom schauen. Das darauf liegende ZFS wird dann automatisch gefunden und eingebunden.

Alles weitere ist dann Anwendung von ZFS, das wäre thematisch aber was für einen anderen Artikel. ;-)


Auf dem neuen Rechner im Büro ist (natürlich) Debian installiert, mit KDE, so wie auf allen meinen Rechnern. Flotte Kiste und ich hab mir nichts weiter dabei gedacht, dass nach dem Einloggen kein Splash Screen erschien, schnell halt die Mühle. Durch einen Zufall bin ich aber heute nochmal bei den Einstellungen der Splash-Screens gelandet und stellte fest, dass »Default« zwar funktionierte, das von mir bevorzugte »joy« des aktuellen Debian-Release Wheezy jedoch nicht. Warum? Gar nicht so leicht rauszufinden, aber was aufgerufen wird, ist wohl sowas wie das hier:

Huch, was ist da denn das Problem? Mein Monitor läuft in keiner der Auflösungen, wo im Paket desktop-base Bilder mitgeliefert werden, also mal mit strace geschaut, was er da öffnen will:

Hmm, da hat wohl wer umgerechnet und abgelegt, und …

Na sowas?! Also kurzerhand die leere Datei gelöscht und schon geht das! :-)

Wireshark als normaler Nutzer ausführen

Mit jedem neuen Rechner und damit jeder neuen Installation kommen jedesmal die gleichen Probleme auf einen zu. Aktuell hab ich hier im Büro eine neue Maschine mit Debian Wheezy und ich will Wireshark als normaler Nutzer ausführen. Laut /usr/share/doc/wireshark/README.Debian muss dumpcap installiert sein und richtig eingerichtet und man muss selbst der Gruppe wireshark angehören. Das genannte Tool ist Teil des Pakets wireshark-common und das lässt sich wie folgt umkonfigurieren:

Es öffnet sich ein Menü, man stellt das gewünschte ein. Nutzer zur passenden Gruppe hinzufügen mit Debian-Mitteln sieht dann so aus:

Ausloggen und neu wieder einloggen, damit die Gruppenberechtigungen wirksam werden und dann tut das.

Problemchen mit approx beheben

In Zeiten vieler Rechner und dennoch langsamer Internetverbindungen1 kann ein Paketproxy ein wahrer Segen sein. Updates und Pakete für Debian und auf Debian basierenden Betriebssystem werden dann im lokalen Netz zwischengespeichert und es muss nicht jeder einzelne Rechner immer alles von einem Debian-Spiegel aus dem Netz holen. Ich setze dazu approx ein. D.h. ich betreibe keinen eigenen Mirror, sondern halte nur die nötigen Pakete lokal nochmal vor. Ein spezialisierter Proxy wie approx, der über die Struktur des Paketservers bescheid weiß, kann hier meiner Meinung nach bessere Dienste leisten, als ein generischer Proxy.

Während die Idee an sich gut ist, gibt es im Detail ein paar Problemchen. Sowohl approx vermurkst sich manchmal seine Daten als auch clientseitig das apt auf dem Rechner. Auf beiden Seiten kann man das wieder bereinigen und ich zeige kurz wie.


Ein häufiges Problem, das ich bei approx festgestellt habe, sind 0 Byte große Dateien. Sind solche unter /var/cache/approx solche vorhanden, kommt es auf Clientseite zu allerlei komischen Fehlern, heute hatte ich da beispielsweise HTTP 404 für Dateien, die auf dem Mirror vorhanden sind. Auf dem Server, wo approx läuft, habe ich dann zwei Sachen ausgeführt:


Die Probleme hier entstehen vermutlich ähnlich wie serverseitig durch unterbrochene Updatevorgänge, nutzer- oder netzwerkseitig, egal, es ist halt was kaputt. Es gibt natürlich aptitude clean und dergleichen und manchmal scheint das aber nicht zu helfen. Zuletzt behalf ich mir dann damit:

So sind Updates jetzt wieder möglich. Ich weiß zwar nicht, was genau und warum das ab und zu kracht, aber so kann man’s wenigstens in einen funktionierenden Zustand zurücksetzen.

  1. Breitbandausbau am Arsch! []