Dev.Fedorado

Note to myself, but maybe you found this article via search engine... 🙂

Symptome: You are trying to post-process a Canon CR3 RAW image file with Darktable, but it doesn't show any CR3 files.

Reason: Darktable uses LibRaw for reading CR3 files, which in turn uses exiv2. New file formats are not compiled into Fedora's exiv2 though, presumably for licensing or patent reasons (see this bug report, tl;dr).

Solution: Uninstall Fedora's Darktable version (either via dnf remove darktable or flatpak uninstall darktable), and install the flathub version via flatpak install darktable.

If you used the dnf version, you can copy the ~/.config/darktable directory to ~/.var/app/org.darktable.Darktable/darktable to keep your Darktable configuration.

Tagebücher und private Fotos, persönliche E-Mails, Bankverbindungen und Kreditkartennummern, Passwörter… Oft sind wir uns gar nicht bewusst, was für persönliche und geheime Informationen unsere Festplatten gespeichert haben. Nehmen wir uns nur mal als Beispiel das Cookie, durch das wir uns nicht mehr im Onlineshop anzumelden brauchen, oder all die Passwörter, die der Passwort-Manager des Browsers bequemerweise für uns gespeichert hat.

So gibt es immer wieder Aufsehen erregende Berichte über Computer oder Festplatten mit höchst vertraulichem Inhalt, welche gebraucht verkauft wurden, ohne vorher ausreichend gelöscht worden zu sein. Ein anderes, etwas amüsanteres Beispiel stammt von dem Käufer eines gebrauchten Notebooks, welches sich als defekt herausstellte. Da der Verkäufer nicht bereit war, das Geld zurückzugeben, veröffentlichte der Betrogene aus Rache allerlei private und delikate Details, die er auf der Festplatte des Notebooks vorfand.

Trotzdem kann es vorkommen, dass man Festplatten in fremde Hände gibt, weil man sie verkaufen, zurückgeben oder entsorgen möchte. Wie löscht man dann alle vertraulichen Daten sicher und zuverlässig?

Ein paar wichtige Worte vorweg!

Dieser Artikel bezieht sich auf Linux-Systeme und richtet sich hauptsächlich an Privatpersonen. Nicht etwa, weil ihre Daten weniger schützenswert wären, sondern weil der Gesetzgeber bei gewerblich genutzten Festplatten mit personenbezogenen Daten eine fachgerechte und dokumentierte Löschung der Daten erwartet.

In diesem Artikel beschreibe ich außerdem, wie Daten sicher und zuverlässig gelöscht werden. Mit nur einer Fehleingabe können in Sekundenschnelle auch Daten vernichtet werden, die eigentlich nicht gelöscht werden sollten. Man sollte deshalb genau darauf achten, ob das Festplatten-Device wirklich das gewünschte ist, und sich das Kommando lieber einmal mehr anschauen, bevor man die Eingabetaste drückt. Wichtige Daten, die nicht gelöscht werden sollen, sollten stets auf einem aktuellen Backup gesichert sein.

Im folgenden Text wird die zu löschende Festplatte beispielhaft unter /dev/sdX angesprochen. Man sollte mit hdparm -I /dev/sdX vorab prüfen, ob es sich tatsächlich um das zu löschende Festplattenmodell handelt.

Es gibt schon viele Artikel, wie man SSD-Festplatten richtig in Linux einbindet. Aber entweder sind sie veraltet, unvollständig oder recht lange. Also, hier eine tl;dr-Fassung – SSD mit Fedora, kurz und schmerzlos.

Trimming

Wenn die SSD trimming kann (was mittlerweile bei ziemlich allen SSDs auf dem Markt der Fall ist), sollte es natürlich auch verwendet werden. Dadurch ermöglicht man wear levelling, gibt also der SSD die Möglichkeit, den Verschleiß der Speicherzellen zu verteilen.

Seit Fedora 33 ist Trimming bereits standardmäßig aktiviert. Hier braucht man sich keine weiteren Gedanken mehr zu machen.

Bei älteren Fedora-Versionen muss man den Trim-Timer einmalig manuell aktivieren:

sudo systemctl enable fstrim.timer

Die Dateisysteme werden dann wöchentlich gesäubert.

Das Trimming kann mit dem Kommando fstrim auch jederzeit von Hand erfolgen:

sudo fstrim -v /
sudo fstrim -v /home

Swappiness

SSDs können beliebig oft und schnell gelesen werden, verschleißen aber bei Schreibzugriffen. Swapping auf eine SSD-Partition ist zwar möglich, aber der Lebensdauer nicht sehr zuträglich. Folgende Zeilen in der /etc/sysctl.conf reduzieren das Auslagern auf die Swap-Partition auf ein Minimum.

vm.swappiness=1
vm.vfs_cache_pressure=50

Bei den günstigen Preisen selbst für üppige RAM-Ausstattung wäre es bei Desktop-Rechnern eine Überlegung wert, ob man eine Swap-Partition überhaupt noch benötigt. Nachträglich kann sie durch Auskommentieren der entsprechenden Zeile in der /etc/fstab deaktiviert werden.

Kompakt, schnell und leise ist eine Herausforderung beim Selbstbau eines PCs. Meistens bekommt man nur zwei dieser Eigenschaften auf Kosten der dritten. Ich habe mich trotzdem an einen Versuch gewagt.

Das Ergebnis ist:

• Gehäuse und Mainboard: Das ASRock DeskMini A300 ist ein Barebone, das kaum größer ist als ein ATX-Netzteil. Trotzdem hat es genug Platz für einen Prozessor mit AM4-Sockel und einer Verlustleistung von bis zu 65 Watt. Dazu passen zwei 2,5-Zoll-Festplatten und zwei M.2-SSDs hinein. WLAN gibt es optional dazu. Versorgt wird das Gerät mit einem externen 300W-Notebook-Netzteil.
• Kühlung: Ich verzichtete auf den beigelegten Kühlkörper und baute ein Noctua NH-L9a-AM4 ein. Die Lüfter- und Kühlkörper-Lösung ist wie für dieses Gehäuse gemacht. Der Lüfter ist enorm leise. Selbst unter Last ist nur ein leises Rauschen zu hören, das überhaupt nicht stört.
• CPU: Hier setzte ich auf einen AMD Ryzen 5 2400G, welcher sich bereits in meinem PC unter Linux bewährt hat. Mit 65 Watt TDP passt er in das Gehäuse und bietet mehr aus ausreichend Leistung für Office-Anwendungen, Video-Streaming und einfache Games.
• RAM: 8 GB DDR4-2400 SO-DIMM als Kit mit 2x 4 GB. Für den gedachten Anwendungszweck reicht das. Bei einer Bestückung beider Slots mit Dual Rank-Modulen ist bei 2400 MHz Schluss, so dass der Kauf höher getakteter Speicherriegel nur Geld verschwendet hätte.
• SSD: Als Festspeicher wurde eine vorhandene 2,5-Zoll SATA-SSD weiter verwendet.

Das System ließ sich zügig zusammenbauen. Problematisch war lediglich die Montage des Noctua-Kühlers. Dafür muss die vorhandene Halterung samt Bodenplatte entfernt werden. Anschließend wird Wärmeleitpaste auf die CPU aufgetragen, der Kühler daraufgelegt und von unten auf die beigelegte Bodenplatte geschraubt. Es erfordert schon ein wenig Geschick, den Kühlkörper dabei so wenig wie möglich zu bewegen, um die Wärmeleitpaste nicht zu verschmieren. SATA-Festplatten werden mit einem Spezialkabel mit dem Mainboard verbunden. Auch hier war es ein wenig Fummelei, den Spezialstecker auf das Mainboard zu stecken.

Bei einem ersten Test bootete ein Fedora 29-Livesystem auf der Maschine. Nachdem ich aber das BIOS auf die aktuelle Version 3.40 aktualisiert hatte, verweigerte das Livesystem selbst im Kompatibilitätsmodus den Dienst. Erst Fedora 30 (welches derzeit noch im Beta-Stadium ist) bootete problemlos und ließ sich ebenso leicht installieren.

Das System arbeitet unter Fedora 30 einwandfrei und stabil, selbst mit zwei angeschlossenen Monitoren. Beeindruckt hat mich vor allem der ruhige, nahezu lautlose Betrieb, der trotz dieser kompakten Abmessungen möglich ist. Darüber hinaus lässt sich ein solches System für einen verhältnismäßig günstigen Preis zusammenbauen. Es eignet sich bestens als kompakter Schreibtischrechner oder anspruchsvoller HTPC.

In dem Fedorablog, den ich ganz früher mal geschrieben hatte, hatte ich ein regelmäßig wiederkehrendes Thema: Die Installation von Google Earth. Lange Zeit war das echte Handarbeit, obwohl Google ein RPM-Paket bereitstellte.

Seitdem sind viele Jahre vergangen. Mittlerweile stellt Google die ehemals kostenpflichtige Pro-Version von Google Earth zum kostenlosen Download für Linux zur Verfügung. Und auch die Installation ist glücklicherweise kein Problem mehr. Es reicht schon, das RPM-Paket zu installieren:

sudo dnf install google-earth-pro-stable-current.x86_64.rpm

Auf deutschen und österreichischen Systemen¹ muss anschließend noch eine kleine manuelle Änderung vorgenommen werden. Der Grund dafür ist, dass die Google-Server bei der Ortssuche Geokoordinaten mit Dezimalpunkt ausliefern, das System aber das bei uns übliche Dezimalkomma erwartet und die Zahlen deshalb nicht verarbeiten kann. Die virtuelle Erdkugel dreht sich dann immer mitten auf den Atlantik statt auf die gewünschte Markierung.

Eine einfache Lösung ist, die Datei /opt/google/earth/pro/googleearth mit einem Texteditor zu bearbeiten (Root-Rechte erforderlich) und in der letzten Zeile der Datei ein LC_NUMERIC=us_US.UTF-8 einzufügen:

LD_LIBRARY_PATH=.:$LD_LIBRARY_PATH LC_NUMERIC=us_US.UTF-8 ./googleearth-bin "$@"

Danach sollte Google Earth Pro problemlos und stabil laufen.

¹) Nach meinen Recherchen verwendet ein Linux mit schweizerdeutscher Einstellung den Dezimalpunkt. Die Anpassung ist dann nicht nötig, schadet aber auch nicht.