Category Archives: Linux

Fedora 28 und der OpenXenManager

Posted on by

Ja, daß Aftermatch von Fedora 28 geht in Runde 3 und die hats in sich. Jeder der OpenXenManager benutzt hat um seine XenServer zu versorgen, der sollte jetzt ganz genau weiterlesen. If you found this article about OXM, all relevant informations will be available in english too, the rest will be infos about the situation.

Fedoras Zukunft mit Python 2

Wir haben ein Problem. Eigentlich haben wir mehrere, aber eins nach dem Anderen. Der Entwickler des OpenXenManagers hat leider keine Zeit mehr für das Projekt. Das wäre an sich nicht soooo dramatisch, da es bis auf eine Kleinigkeit ganz gut funktioniert. Jetzt ist das Teil in Python 2 geschrieben. Das ist das Problem!

In Fedora 28 wurde die GTK-VNC Bindung für Python gekappt. Das Paket gibt es nicht mehr bei Fedora, weil GTK-VNC 0.8 kein Python 2 mehr können will, zumindest nicht so. Es gibt also eine neue API. Da kommt Problem 1 wieder ins Spiel: OXM müßte umgebaut werden, was aber nicht passiert, weil Daniel Lintott keine Zeit mehr hat. Deadlock!

In Fedora 30 wird Python 2 komplett entfernt. Wer also noch auf Python 2 setzt, ist dann raus.

Lösung – Solution

Bis Ihr einen Ersatz für den OXM habt, könnt Ihr das hier machen:

enter as root into a bash / als root in Bash eingeben:

rpm -i –force –nodeps http://dl.fedoraproject.org/pub/fedora/linux/releases/27/Everything/x86_64/os/Packages/g/gtk-vnc-python-0.7.1-3.fc27.x86_64.rpm

after this, OXM will start again / danach startet der OXM wieder

BUT / ABER

Your problem is not fixed yet, as Python 2 will be erased from Fedora 30. You need a new OXM, and there is no Opensource Version insight. https://xen-orchestra.com may be an alternative for Linux, but it’s commercial.

Wie oben schon angedeutet, mit Fedora 30 verschwindet Python 2 ganz. Bis dahin braucht Ihr Ersatz. https://xen-orchestra.com/ wurde da empfohlen, aber das ist kommerziell.

A skilled Python Dev could take over OXM for good and add the missing python gtk support again. If you know one, let him/her know.

Wer zufällig einen Python Entwickler kennt, könnte dem ja mal einen Tip geben. Da mir Python so gar nicht gefällt, kann ichs leider nicht machen.

Stimmt.. was war Runde 2? 🙂

Runde zwei war, das die Wetter-Anwendung aufgrund des libmozjs-38 Bugs nicht mehr startet, sondern einen core-dump produziert. Das muß man auch erstmal schaffen 🙂

Fedora 28 und das Upgradeaftermatch

Posted on by

„Hey, Fedora 27 ist Geschichte, freu Dich auf Fedora 28, User!“ Ich habe ihn nicht gehört, aber der MCP hat das bestimmt vorhin beim Upgrade gesagt oder gedacht. Leider hat es nicht funktioniert.

Keine Friends in Sicht…

Ja, heute war es soweit: das obligatorische Sechsmonatsupgrade auf Fedora 28 war dran. Auf dem Laptop läuft es seit letzter Woche, also sollte das ja jetzt kein Problem werden. Flugs den Desktop stoppen, in eine Root-Shell und DNF mit Arbeitsanweisung versorgen. Gesagt, getan. 15 Minuten später waren alle 3800 Pakete geladen und bereit. Zwei unwichtige Downgrades und 3 unwesentliche Altpaketentfernungen waren abgesegnet. Schritt 1/7550 kam in Sicht und …. hey… (nanü? Was ist mit der Absatzüberschrift los?)… ging 🙂

7550 Schritte später, wartet mein Cursor, meine Root-Shell und mein neues Fedora auf mich, also „reboot“ getippt, beide Daumen zerquetscht und gewartet. Bios .. Grub \o/ … die seit Jahren vertraute Meldung, daß die Kernel-Module vom Systemd nicht geladen werden konnten…( Anm.d.R „auch diesmal“ wieder nicht 🙁 ) .. Fedora Bootlogo… wird weiß… Login! … DESKTOP! … P.R.O.G.R.A.M.M.E !.! … was ist das denn?

„Wollen Sie die Default Ordner rename to die lokal gewählte Sprache…“

Was zum Geier… wie kommt Cinnamon darauf, daß ich bei einem Deutschen Desktop englische Verzeichnisnamen haben können wollte? Könnten die Spracheinstellungen defekt sein? Nachguck.. Nö. Deutsch/Deutsch. Sieht ok aus. „Da hat bestimmt Gnome beim Update was zerlegt.“ war der Gedanke, also ins Gnome gewechselt… was ein schwerer Fehler war, den GNOME ist nicht mehr .. DAS hat es tatsächlich beim Upgrade zerlegt, denn die Gnome-Shell kommt nicht an den Start. Die Programme schon, aber ohne Windowmanager nützt das nicht viel 😀 … Hmm.. Programme melden sich aber in Deutsch, das ja komisch.

Mit STRG+ALT+F3 ab in die Root-Shell, anmelden …. was ist das denn? „setlocale: Konnte LC_TIME nicht setzen“ (War natürlich auf english, aber zum besseren Verständnis wird es hier eingedeutscht). Wie kann das denn sein?

Kurz mal die Umgebungsvariablen checken:

# strings /proc/self/environ 
...
LANG=de_DE.UTF-8
...
_=/usr/bin/strings


# locale
LANG=de_DE.UTF-8
LC_CTYPE="de_DE.UTF-8"
LC_NUMERIC="de_DE.UTF-8"
LC_TIME="de_DE.UTF-8"
LC_COLLATE="de_DE.UTF-8"
LC_MONETARY="de_DE.UTF-8"
LC_MESSAGES="de_DE.UTF-8"
LC_PAPER="de_DE.UTF-8"
LC_NAME="de_DE.UTF-8"
LC_ADDRESS="de_DE.UTF-8"
LC_TELEPHONE="de_DE.UTF-8"
LC_MEASUREMENT="de_DE.UTF-8"
LC_IDENTIFICATION="de_DE.UTF-8"
LC_ALL=

Alles ok, Deutsch ist eingestellt. Übersetzungen gingen ja in den Programmen, aber tatsächlich war die Zeit in English mit 12H+AM/PM .. schauen wir doch mal mit strace auf welche Locale will das Programm eigentlich zugreifen: also „strace -f locale de_DE.UTF-8“ eingegeben und es würde gern diese Datei benutzen „/usr/lib/locale/de_DE.utf8/LC_TIME“ … ist ja merkwürdig, die ist gar nicht vorhanden…. hey! den ganzen Ordnerbaum gibt es gar nicht! HIER FEHLT DEUTSCH!

Und so behebt man das

Die Sachelage ist klar: Keine Deutsche Locale vorhanden, also nachinstallieren. Da wir den Pfad kennen, fragen wir dnf wer das bereitstellen könnte:

# dnf provides „/usr/lib/locale/de_DE.utf8/LC_TIME“
…
glibc-langpack-de-2.27-32.fc28.x86_64 : Locale data for de
….

also installieren wir das und rebooten kurz ( damit auch die Bootprozesse in Deutsch melden können, wenn Sie das wünschen):

# dnf install glibc-langpack-de

und da merkt man dann, daß das kein Witz war, weil der jetzt „j“ nicht mehr als „ja“ => „yes“ erkennt .. muß man also wirklich „y“ drücken 🙂

Nach dem Reboot war es dann in Ordnung. Warum der den Language-pack nicht installiert hat, werden wir nicht erfahren. Um GNOME werde ich mich wohl mit „rm -rf .config/gnome-session“ kümmern müssen.

Update Tag 2:

Die WetterApp geht nicht. Libmozjs crasht beim Start extrem hart, incl. Coredump. Autsch. Mal sehen was von den HinterbänklerApps noch so nicht geht.

QPhotorec und das Danach

Posted on by

Ja, jetzt ist es passiert. Ich habe aus Versehen ein paar Bilder gelöscht. Zum Glück hatte ich von früher bereits QPhotoRec auf dem Rechner, so daß ich gleich loslegen konnte.

Die Konstellation

Auf einer reinen Datenplatte waren PNG Bilder, die aber keine PNGs sondern JPEGs waren (danke Tello Devs, Ihr seid echte CodeMonkeys wie Sie im Buche Tannenbaum stehen 🙁 ). Die sollten zwecks verscripteter Umbenennung ( falls das mal wer braucht: for i in *.png;do mv $i ${i%png}jpg; done ) und Voransicht auf eine SSD verschoben werden und dann, nach der anschliessenden Bearbeitung, wieder auf die Datenplatte zurück. So der Plan.

Jetzt was wirklich passierte. Die Bilder wurden auf die SSD verschoben, aber nicht aus Listenansicht des Verzeichnisses, sondern aus der Nemo eigenen Suchergebnisliste (von PNGs). Beim Verschieben ist das Programm ganz clever und findet dann die gesuchten Bilder lustigerweise gleich wieder, weswegen ich dachte, ich hätte COPY statt MOVE benutzt. Da das in Nemo nur eine SHIFT-Taste weit auseinander liegt, sahs ich einem Irrtum auf .. und weg waren die Bilder auf der Zielpartition und der Quelle. Kann passieren.

Da es eine Datenpartition war, bestand keine Gefahr das die gelöschten Bilder überschrieben werden, also kam QPhotoRec zum Einsatz. 3,8 Milliarden Blöcke später lagen 181.685 PNG und 3.106 JPG Bilder auf der Zischenlagerplatte ( nie auf die zu rettende Partition zurücksichern! Wichtig !)  verteilt auf 370+ Ordner! und natürlich 99,9% Schrott. Für Euch noch wichtig, QPhotoRec kann man auf bestimmte Dateientypen einschränken, sonst wäre da noch sehr viel mehr gekommen 😉

Wie man den Datenwust jetzt optimal ignoriert

180k Dateien.. von Hand durchsehen? Wohl kaum. Daher zwei Wege das zu Beschleunigen:

1. „file“ auf eine Datei gleichen Typs anwenden:

1539788463675.jpg: JPEG image data, JFIF standard 1.01, aspect ratio, density 1×1, segment length 16, Exif Standard: [TIFF image data, little-endian, direntries=4, manufacturer=RYZE, model=RZ001, software=v01.04.35.01], baseline, precision 8, 2592×1936, frames 3

Da die Bilder der Drohne in meinem Fall alle die gleiche Auflösung haben, kann man jetzt einfach so suchen:

file recup_dir.?/* | grep 2592×1936
file recup_dir.??/* | grep 2592×1936
file recup_dir.1??/* | grep 2592×1936
file recup_dir.2??/* | grep 2592×1936
file recup_dir.3??/* | grep 2592×1936

Wenn in einem Verzeichnis ein Bild der Drohnenauflösung zu finden ist, würde es angezeigt werden.

2. „find recup_dir.* -size +200k -exec gnome-open {} \;“

Der Befehl sucht nach Dateien > 200kb und zeigt die mit gnome-open an. Ok, ist nur ein Befehl mit einigen Annahmen, aber jeder Menge Treffer, die man selbst durchsehen muß. Es schränkt aber das zu durchsuchende Material auf ein paar Treffer ein. Kommt natürlich darauf an, was QPhotoRec so alles gefunden hat.

Ich habe meine Bilder wieder und Ihr ein paar Ideen, wie man nach dem Recovery effizient an die Sache rangeht. Kleine Anmerkung: Nemo hat einen Papierkorb, wäre nicht passiert, wenn man den benutzt hätte 🙂