Ich nutze das Plugin „Vicious“ für den Batteriestatus in Awesome. Eine beispielhafte Implementierung für das Battery-Widget findet man in der README, allerdings bei mir im Textmodus:

batwidget = wibox.widget.textbox()
vicious.register(batwidget, vicious.widgets.bat, "⚡: $2%/$3", 30, "BAT0")

Der 3. Parameter kann netterweise eine Funktion sein, sodass man einfach den Batteriestatus prüfen und entsprechend eine Meldung ausgeben kann:

vicious.register(batwidget, vicious.widgets.bat, function(widget, args) 
 if args[2] <= 15 then
 naughty.notify({
 title="BATTERY!!",
 text="Battery left: "..args[2].."%",
 bg="#ff0000",
 fg="#000",
 timeout=5,
 border_width=5,
 font="Arial 25" 
 })
 end
 return "⚡: "..args[2].."%/".. args[3]
 end, 30, "BAT0")

In meinem Fall wird die Meldung angezeigt, wenn weniger als 15% Akku verbleiben. Das sieht dann so aus (100% nur, da es ein Test ist):

Damit sollten sich die unbemerkten Abschaltungen meines Laptops in Zukunft drastisch reduzieren.

~ Sebastian

in diesem Blogpost möchte ich beschreiben wie man mit Hilfe einer udev-Regel und Systemd eine mit luks verschlüsselte SD-Karte automatisch mounten lassen kann.

Vorwort: SD-Karte verschlüsseln

Damit man die SD-Karte automatisch entschlüsseln lassen kann, bietet es sich an, diese mit einem Keyfile zu verschlüsseln. Dazu erstellt man zunächst ein Keyfile:

sudo dd bs=512 count=4 if=/dev/urandom of=/etc/sdkey iflag=fullblock

Damit nicht jeder diesen Schlüssel lesen kann, verpasst man ihm noch die korrekten Rechte und einen Änderungsschutz:

sudo chmown root:root /etc/sdkey
sudo chmod 500 /etc/sdkey
sudo chattr +i /etc/sdkey

Danach kann man auch schon mit cryptsetup die SD-Karte verschlüsseln:

sudo cryptsetup luksFormat /dev/mmcblk0p1 /etc/sdkey

• /dev/mmcblk0p1 ist die zu verschlüsselnde Partition auf der SD-Karte
• /etc/sdkey ist das Keyfile, dass zur Verschlüsselung genutzt wird

Zuletzt öffnet man die SD-Karte und erstellt ein Dateisystem:

sudo cryptsetup --key-file=/etc/sdkey luksOpen /dev/mmcblk0p1 sdcard
sudo mkfs.ext4 /dev/mapper/sdcard

Fertig.

Automatische Entschlüsselung und Einbindung

Zum automatischen Entschlüsseln und Mounten der SD-Karte müssen wir eine neue udev-Regel und ein passendes Systemd Unitfile schreiben.

Systemd Unitfile

Wir beginnen mit dem Systemd Unitfile, da dieses relativ straight forward ist. Man legt eine neue Datei an: ‚/etc/systemd/system/sdcardencrypt.service‘. Der Inhalt kann so aussehen:

[Unit]
Description=Automount encrypted sdcard

[Service]
Type=oneshot
ExecStart=/usr/bin/cryptsetup --key-file=/etc/sdkey luksOpen /dev/sdcard sdcard
ExecStart=/usr/bin/mount /dev/mapper/sdcard /sdcard

Möchte man in dem Unitfile mehere ‚ExecStart‘-Kommandos ausführen, so ist ‚Type=oneshot‘ zu setzen.

Das erste Kommando ist bereits von oben bekannt und öffnet den luks-Container. Neu ist hier, dass als Device ‚/dev/sdcard‘ statt ‚/dev/mmcblk0p1‘ angegeben wird. Das erklärt sich aber später mit unserer udev-Regel.

Der zweite Befehl mountet den luks-Container in ‚/sdcard‘. Der Mountpoint muss einmalig davor erstellt werden und/oder geändert werden.

Damit Systemd das neue Unitfile korrekt ausführt, müssen wir einen kurzen Reload durchführen:

sudo systemctl daemon-reload

Udev-Regel

Als nächstes machen wir uns an die udev-Regel, welche den Symlink zu ‚/dev/sdcard‘ erstellt und das unser Unitfile aufruft. Dazu erstellen wir eine Datei in ‚/etc/udev/rules.d/‘ mit dem Namen ’10-sdcard.rules‘ und folgendem Inhalt:

ACTION=="add", KERNEL=="mmcblk0p1", SUBSYSTEM=="block", ATTR{size}=="124702720", ATTR{start}=="32768", SYMLINK+="sdcard", ENV{SYSTEMD_WANTS}="sdcardencrypt.service"

Hier passieren mehrere Dinge:

• ACTION: Nur wenn das neue Gerät eingesteckt wird, soll die Regel ausgeführt werden
• KERNEL, SUBSYSTEM, ATTR: Verundete Kriterien; Nur wenn alle matchen, wird die Regel ausgeführt
• SYMLINK: Erzeuge ein Symlink von der gematchten Partition ‚/dev/mmcblk0p1‘ zu ‚/dev/sdcard‘
• ENV: Führe danach das ’sdcardencrypt.service‘ Unitfile aus.

Das einzige, was ihr an der Regel ändern müsst, sind die Werte hinter KERNEL, ATTR{size}, ATTR{start}. Da wir hier von einer SD-Karte reden, wird SUBSYSTEM wahrscheinlich den Wert beibehalten. Alle anderen Werte nutze ich, um meine verschlüsselte SD-Karte (eindeutig) zu identifizieren.

An die entsprechenden Attribute gelangt man die SD-Karte einsteckt und danach das folgende Kommando ausführt:

udevadm info -a -p (udevadm info -q path -n /dev/mmcblk0p1)

Dabei ersetzt man ‚/dev/mmcblk0p1‘ mit der entsprechenden Partition der SD-Karte. Die Ausgabe kann so ähnlich aussehen:

udevadm info -a -p (udevadm info -q path -n /dev/mmcblk0p1)

Udevadm info starts with the device specified by the devpath and then
walks up the chain of parent devices. It prints for every device
found, all possible attributes in the udev rules key format.
A rule to match, can be composed by the attributes of the device
and the attributes from one single parent device.

 looking at device '/devices/pci0000:00/0000:00:1c.0/0000:02:00.1/mmc_host/mmc0/mmc0:aaaa/block/mmcblk0/mmcblk0p1':
 KERNEL=="mmcblk0p1"
 SUBSYSTEM=="block"
 DRIVER==""
 ATTR{alignment_offset}=="0"
 ATTR{discard_alignment}=="8388608"
 ATTR{inflight}==" 0 0"
 ATTR{partition}=="1"
 ATTR{ro}=="0"
 ATTR{size}=="124702720"
 ATTR{start}=="32768"
 ATTR{stat}==" 38 0 1099 136 0 0 0 0 0 56 136"

 looking at parent device '/devices/pci0000:00/0000:00:1c.0/0000:02:00.1/mmc_host/mmc0/mmc0:aaaa/block/mmcblk0':
 KERNELS=="mmcblk0"
 SUBSYSTEMS=="block"
 DRIVERS==""
 ATTRS{alignment_offset}=="0"
 ATTRS{capability}=="10"
 ATTRS{discard_alignment}=="0"
 ATTRS{ext_range}=="8"
 ATTRS{force_ro}=="0"
 ATTRS{inflight}==" 0 0"
 ATTRS{range}=="8"
 ATTRS{removable}=="0"
 ATTRS{ro}=="0"
 ATTRS{size}=="124735488"
 ATTRS{stat}==" 52 0 2155 206 0 0 0 0 0 96 206"

 looking at parent device '/devices/pci0000:00/0000:00:1c.0/0000:02:00.1/mmc_host/mmc0/mmc0:aaaa':
 KERNELS=="mmc0:aaaa"
 SUBSYSTEMS=="mmc"
 DRIVERS=="mmcblk"
 ATTRS{cid}=="035344534c36344780295762d200f800"
 ATTRS{csd}=="400e00325b590001dbd37f800a404000"
 ATTRS{date}=="08/2015"
 ATTRS{erase_size}=="512"
 ATTRS{fwrev}=="0x0"
 ATTRS{hwrev}=="0x8"
 ATTRS{manfid}=="0x000003"
 ATTRS{name}=="SL64G"
 ATTRS{oemid}=="0x5344"
 ATTRS{preferred_erase_size}=="25165824"
 ATTRS{scr}=="0245800300000000"
 ATTRS{serial}=="0x295762d2"
 ATTRS{type}=="SD"

 looking at parent device '/devices/pci0000:00/0000:00:1c.0/0000:02:00.1/mmc_host/mmc0':
 KERNELS=="mmc0"
 SUBSYSTEMS=="mmc_host"
 DRIVERS==""

 looking at parent device '/devices/pci0000:00/0000:00:1c.0/0000:02:00.1':
 KERNELS=="0000:02:00.1"
 SUBSYSTEMS=="pci"
 DRIVERS=="sdhci-pci"
 ATTRS{broken_parity_status}=="0"
 ATTRS{class}=="0x080501"
 ATTRS{consistent_dma_mask_bits}=="32"
 ATTRS{d3cold_allowed}=="1"
 ATTRS{device}=="0x16bc"
 ATTRS{dma_mask_bits}=="64"
 ATTRS{driver_override}=="(null)"
 ATTRS{enable}=="1"
 ATTRS{irq}=="17"
 ATTRS{local_cpulist}=="0-3"
 ATTRS{local_cpus}=="0f"
 ATTRS{msi_bus}=="1"
 ATTRS{numa_node}=="-1"
 ATTRS{subsystem_device}=="0x0504"
 ATTRS{subsystem_vendor}=="0x1025"
 ATTRS{vendor}=="0x14e4"

 looking at parent device '/devices/pci0000:00/0000:00:1c.0':
 KERNELS=="0000:00:1c.0"
 SUBSYSTEMS=="pci"
 DRIVERS=="pcieport"
 ATTRS{broken_parity_status}=="0"
 ATTRS{class}=="0x060400"
 ATTRS{consistent_dma_mask_bits}=="32"
 ATTRS{d3cold_allowed}=="0"
 ATTRS{device}=="0x1c10"
 ATTRS{dma_mask_bits}=="32"
 ATTRS{driver_override}=="(null)"
 ATTRS{enable}=="1"
 ATTRS{irq}=="17"
 ATTRS{local_cpulist}=="0-3"
 ATTRS{local_cpus}=="0f"
 ATTRS{msi_bus}=="1"
 ATTRS{numa_node}=="-1"
 ATTRS{subsystem_device}=="0x0504"
 ATTRS{subsystem_vendor}=="0x1025"
 ATTRS{vendor}=="0x8086"

 looking at parent device '/devices/pci0000:00':
 KERNELS=="pci0000:00"
 SUBSYSTEMS==""
 DRIVERS==""

Am Besten nimmt man die Attribute von weiter oben. Es stellt allerdings auch kein Problem dar, wenn man Attribute nutzt, die weiter unten stehen, nur sind diese etwas genereller und könnten gegebenenfalls auf andere SD-Karten matchen. Allerdings darf man nur Attribute von einem ‚Parent‘ des Devices nutzen. Für bessere Robustheit könnte man noch zusätzliche folgende Attribute einführen:

• ATTRS{manfid}==“0x000003″
• ATTRS{name}==“SL64G“
• ATTRS{oemid}==“0x5344″
• ATTRS{serial}==“0x295762d2″
• ATTRS{type}==“SD“

Zuletzte sollte man noch die Regeln neu einlesen. Das klappt einfach mit einem:

sudo udevadm trigger

Fazit

Es braucht nicht viel Bastelei, um eine verschlüsselte SD-Karte automatisch einzubinden. Möglicherweise möchte man sich aber noch Gedanken darüber machen, dass der Mountpoint bzw. Luks-Container geschlossen wird, wenn die SD-Karte ausgehängt wird. Da ich das nicht häufig/wirklich benötige, ist dies dem interessierten Leser überlassen.

~ Sebastian

heute habe ich nach einer Möglichkeit gesucht, herauszufinden, welche Pakete welche Abhängigkeiten haben. Am Ende meiner Recherche wurden mir schöne bunte Graphen erzeugt. Dabei benötigt man dazu eigentlich nur zwei kleine Programme: Pactree und Graphviz.

Pactree

Pactree beschreibt sich selbst als „A simple dependency tree viewer.“ für Arch Linux. Man kann sich zum Beispiel ausgeben lassen, welche Abhängigkeiten das Paket „glibc“ hat:

> pactree glibc
glibc
├─linux-api-headers
├─tzdata
└─filesystem
 └─iana-etc

Die folgenden Switches werden wir gleich verwenden, um aus diesen Informationen schöne Grafiken zu bauen:

-c, --color          colorize output
-g, --graph          generate output for graphviz's dot

Die Abhängigkeiten von Oben ergeben folgende „dot“-Beschreibung:

> pactree -c -g glibc
digraph G { START [color=red, style=filled];
node [style=filled, color=green];
 "START" -> "glibc";
"glibc" -> "linux-api-headers" [color=chocolate4];
"glibc" -> "tzdata" [color=chocolate4];
"glibc" -> "filesystem" [color=chocolate4];
"filesystem" -> "iana-etc" [color=chocolate4];
}

Interessant kann auch die Verwendung des Switches „-r“ sein.

 -r, --reverse        list packages that depend on the named package

Graphviz

Graphviz ist eine kleine Toolsammlung, welche genutzt werden kann, um schöne Graphen zu erzeugen. Zum Beispiel aus dem o.g. Code.

Um die Umwandlung durchzuführen, führt man folgendes Kommando aus:

dot -Tgif deps.graph -o deps.gif

Wobei „deps.graph“ für den Eingabegraphen in dot-Notation und deps.gif für die Ausgabe im GIF-Format steht. Eine Liste mit weiteren Formaten gibt es natürlich auch. Man muss nur entsprechend „-Tgif“ durch „-TFORMAT“ ersetzen.

Die Aufrufe lassen sich natürlich verketten:

pactree -c -g glibc | dot -Tgif -o /tmp/glibc.gif

Das Ergebnis sieht dann so aus:

Oder etwas komplexer, wie z.B. für das „Gimp“-Programm.

~ Sebastian

als Arch-User hat man öfters (eigentlich nicht so oft)  mit Problemen zu kämpfen. Seit dem letzten Update von python-urwid läuft „wicd-curses“ nicht mehr. Da laut Arch-Wiki „wicd“ nicht mehr weiterentwickelt wird, hab ich mich an einem (erfolgreichen) Fix probiert.

Der Bug

Es handelt sich um folgende Fehlermeldung:

$> wicd-curses 
Traceback (most recent call last):
 File "/usr/share/wicd/curses/wicd-curses.py", line 1063, in <module>
 main()
 File "/usr/share/wicd/curses/wicd-curses.py", line 995, in main
 ui.run_wrapper(run)
 File "/usr/lib/python2.7/site-packages/urwid/display_common.py", line 757, in run_wrapper
 return fn()
 File "/usr/share/wicd/curses/wicd-curses.py", line 88, in wrapper
 return func(*args, **kargs)
 File "/usr/share/wicd/curses/wicd-curses.py", line 1003, in run
 app = appGUI()
 File "/usr/share/wicd/curses/wicd-curses.py", line 591, in __init__
 self.update_status()
 File "/usr/share/wicd/curses/wicd-curses.py", line 88, in wrapper
 return func(*args, **kargs)
 File "/usr/share/wicd/curses/wicd-curses.py", line 734, in update_status
 self.set_status):
 File "/usr/share/wicd/curses/wicd-curses.py", line 88, in wrapper
 return func(*args, **kargs)
 File "/usr/share/wicd/curses/wicd-curses.py", line 161, in check_for_wireless
 ('$C', ip))
 File "/usr/share/wicd/curses/wicd-curses.py", line 781, in set_status
 self.update_ui()
 File "/usr/share/wicd/curses/wicd-curses.py", line 88, in wrapper
 return func(*args, **kargs)
 File "/usr/share/wicd/curses/wicd-curses.py", line 930, in update_ui
 input_data = ui.get_input_nonblocking()
AttributeError: 'Screen' object has no attribute 'get_input_nonblocking'

Nach einem Blick in den Quellcode (Zeile 930) und etwas Backtracking der Funktionen/Variablen stößt man auf:

import urwid.raw_display
ui = urwid.raw_display.Screen()

Der Fix

Werfen wir doch mal einen Blick in die Dokumentation: http://urwid.org/reference/display_modules.html

Dort wird nur noch „get_input()“ für das raw_display genannt, so dass die Eingabe blockierend verarbeitet wird. Mein erster Gedanke war, einen Thread für die Eingabe zu schreiben, aber dann las ich diese Zeile:

If there is no input pending it will wait before returning an empty list. The wait time may be configured with the set_input_timeouts function.

Also habe ich einfach die dazu passende Zeile eingebaut:

ui.set_input_timeouts(max_wait=0, complete_wait=0)

Der Patch

Noch zwei weitere kleine Änderungen waren nötig. Am Ende kommt dann folgender Patch raus:

--- /usr/share/wicd/curses/wicd-curses.py	2013-08-20 15:09:54.000000000 -0400
+++ /tmp/wicd.py	2014-12-05 23:32:05.303349880 -0500
@@ -927,9 +927,11 @@
         if not ui._started:
             return False
 
-        input_data = ui.get_input_nonblocking()
+        # input_data = ui.get_input_nonblocking()
+        ui.set_input_timeouts(max_wait=0)
+        input_data = ui.get_input()
         # Resolve any "alarms" in the waiting
-        self.handle_keys(input_data[1])
+        self.handle_keys(input_data) # [1]
 
         # Update the screen
         canvas = self.frame.render( (self.size),True )

Diesen speichert man sich als Datei unter „/tmp/wicd.patch“ und führt danach folgendes Kommando aus:

sudo patch /usr/share/wicd/curses/wicd-curses.py < /tmp/wicd.patch

Danach sollte „wicd-curses“ wieder laufen.

Die Mankos

Dadurch, dass das Einlesen der Tastendrücke nicht mehr wirklich im Hintergrund läuft, kam es bei der Nutzung der „ESC“-Taste zu Problemen. Diese wurde erst nach einem weiteren Tastendruck (z.B. Pfeil-runter) verarbeitet. Aber nunja, besser als ein kaputtes wicd-curses ist es allemal :)

~ Sebastian

/usr/lib/libgdk-3.so.0: undefined symbol: cairo_surface_set_device_scale

Wie immer, lässt sich das Problem leicht beheben.

Die libgdk wird u.a. vom Paket namens „cairo“ bereitgestellt. Nach ein wenig googlen, stieß ich auf die vorteilhaften Hinweise, ich solle meine Pakete aktualisieren.

Es stellte sich heraus, dass ich das Paket „cairo-ubuntu“ aus dem AUR nutzte. Dieses ist jedoch als „orphaned“ markiert und lässt den o.g. Fehler entstehen.

Um das Problem zu beheben, braucht man nur das Paket „cairo“ zu installiere, um „cairo-ubuntu“ damit zu ersetzen. Auf die Konfliktmeldung kann einfach mit „j“ geantwortet werden.

sudo pacman -S cairo

Problem gelöst ;)

~ Sebastian

Ich gehe in dieser Anleitung davon aus, dass VirtualBox installiert ist.

Vorbereitung

Als Erstes steckt man einfach den entsprechenden USB-Stick rein und kann dann z.B. mit dem Befehl dmesg schauen wie es heißt, bei mir heißt der Stick zum Beispiel sdc (oft heißt er auch sdb), also kommt am Ende von der dmeseg-Ausgabe etwa sowas raus:

 [sdc] Attached SCSI removable disk 
 

Jetzt kann man den USB-Stick seinem Benutzer zuweisen.

sudo chown  [dein Benutzername] /dev/sdc

Jetzt kann man den USB-Stick zu einem Virtual Disk Image (.vmdk) machen

$ VBoxManage internalcommands createrawvmdk -filename /tmp/test-usb.vmdk -rawdisk /dev/sdc

RAW host disk access VMDK file /tmp/test-usb.vmdk created successfully.
#die .vdi für den USB-Stick liegt jetzt in /tmp

Jetzt hat man alles Vorbereitet und kann die VM erstellen.

Die VM erstellen

Die VM kann man am einfachsten mit rum klicken erstellen.

Man öffnet den Virtual Box Manager und erstellt eine neue Maschine:

Auf Neu klicken

Danach macht man optimaler Weise Einstellungen, über das erwartete System, bei den anderen Optionen kann man die Standardeinstellungen übernehmen. Als Festplatte muss man dann natürlich sein in den vorigen Schritten erstelltes .vmdk im /tmp auswählen. Dann nur noch erstellen und es solte funktionieren.

Das richtige Logo auswählen, bei mir Arch

Egal, weiterklicken

/tmp/test-usb,vmdk auswählen

Freuen, es funktioniert

Die Problemlösung

In der /etc/systemd/logind.conf findet man die Option „HandleLidSwitch“. Setzt man diese auf „ignore“, so bleibt der Laptop nach dem Zuklappen des Bildschirms an.

> cat /etc/systemd/logind.conf | grep '^[^#]'
[Login]
HandleLidSwitch=ignore

Interessant könnten auch diese Einstellungen sein:

HandlePowerKey=ignore
HandleSuspendKey=ignore
HandleHibernateKey=ignore

Damit verhindert man das (versehentliche) Ausschalten des Laptops bei einem Druck auf den Ausschalter.

Informationen über weitere nützliche Optionen kann man in den Man-Pages bekommen:

man logind.conf

Viele Grüße,
~ Sebastian

> java 
/usr/bin/java: Zeile 2: /usr/lib/jvm/default/bin/java: Zu viele Ebenen aus symbolischen Links
/usr/bin/java: Zeile 2: exec: /usr/lib/jvm/default/bin/java: Kann nicht ausführen: Zu viele Ebenen aus symbolischen Links

Der Fix ist schnell angewandt.

/usr/bin/java ist zunächst nur ein Link:

> file /usr/bin/java
/usr/bin/java: symbolic link to `/usr/lib/java-common-wrapper'

Die verlinkte Datei ist ein Shell-Script:

> file /usr/lib/java-common-wrapper 
/usr/lib/java-common-wrapper: Bourne-Again shell script, ASCII text executable
> cat /usr/lib/java-common-wrapper 
#!/bin/bash
exec "${JAVA_HOME:-/usr/lib/jvm/default}/bin/${0##*/}" "$@"

Ein Blick auf  /usr/lib/jvm/default bringt die Erkenntnis, dass der symbolische Link kaputt ist:

> file /usr/lib/jvm/default 
/usr/lib/jvm/default: broken symbolic link to `default'

Diesen Link müssen wir reparieren und auf das „java-7-openjdk“-Verzeichnis zeigen lassen:

sudo mv default default.bak
sudo ln -s java-7-openjdk default

Jetzt passen die symbolischen Links wieder und man kann „java“ ausführen.

~ Sebastian

gestern war ich an einem Ort an dem es Internet nur per Kabel gab. Mit meinem Laptop hab ich dann fix einen WLAN Hotspot aufgemacht, sodass die mobilen Endgeräte ebenfalls mit der täglichen Dosis Internet versorgt werden konnten.

Die Voraussetzung

Man benötigt einen AP-fähigen WLAN-Adapter. Ich hatte das Glück das mein integrierter WLAN-Adapter die Eigenschaft erfüllt. Ansonsten kann ein günstiger USB-WLAN-Stick helfen. Ein Device kann als Access Point genutzt werden, wenn es die Features „AP“ bzw. „AP/VLAN“ beherrscht:

$> iw list | grep AP
 Device supports AP-side u-APSD.
 * AP
 * AP/VLAN

Den Acess Point erstellen

Normalerweise müsste man hostapd / dnsmasq usw. von Hand konfigurieren. Allerdings gibt es im AUR ein Paket namens „create_ap“, welches uns die ganze Arbeit abnimmt.

$> yaourt create_ap
1 aur/create_ap git~20140817-1 [installed] (20)
 A shell script to create a NATed/Bridged Software Access Point(aka WiFi)

Nach der Installation muss man das Script nur noch mit Rootrechten ausführen:

sudo create_ap wlan0 eth0 MyWifi 1234567890

Nun wird wlan0 zu einem Access Point umgewandelt. Der Hotspot nennt sich „MyWifi“ und hat das recht langweilige Passwort „1234567890“. Der Traffic wird dann übers „eth0“ weitergeleitet.

~ Sebastian

Das verfehlt natürlich zu 100% den Zweck des Maximierens. Das kann man sich ungefähr so vorstellen:

Java unvollständig maximiertes Fenster

Die Lösung des Problems

Nach ein wenig Googlen stieß ich auf eine Lösungsbeschreibung im Arch-Wiki, die in etwa so lautete: Java kommt auf den Namen des Window-Managers (Awesome) nicht klar, sodass man Java mit einem kleinem Tool einen anderen Namen in die Umgebungsvariable legen muss.

Dazu muss man sich das Programm „wmname“ installieren:

sudo pacman -S wmname

Danach führt man wmname mit dem gewünschten Fake-Wert als Parameter aus. Bei mir hat der folgende Aufruf geholfen:

wmname LG3D

Führt man nun die Java-Applikation aus derselben Konsole aus, so funktioniert alles einwandfrei :)

Optimal maximiertes Java Fenster

Fazit

Wie immer gibt es für alles eine kleine oder manchmal auch eine größere Lösung :)

~Sebastian