VBox: shared clipboard in v6.1.4

In VirtualBox v6.1.4 funktioniert das shared Clipboard zwischen Linux-Host und Linux-Guests nicht (paste ist ausgegraut). Genaugenommen bereits seit VBoxGuestAdditions_6.1.3-135994.iso, zumindest habe ich das Fehlverhalten dort schon bemerkt gehabt, es aber für’s Erste mit dem zu der Zeit gerade neu installierten Host mit anderer Linux-Distribution in Verbindung gebracht. Ursächlich sind aber tatsächlich die GA. Seit 9 Tagen gibt es auch Bugreport und Diskussion(en), wie dem zu begegnen wäre.

Es sind auch wirklich nur die GA, d.h. man kann 6.1.2, die vorige Final, installieren, sicherlich auch ein 6.1.3er dev-build vor obiger Version, so man noch hat.

Seit nicht mal einer Stunde gibt es (endlich wieder) ein aktuelles trunk dev-snapshot (VBoxGuestAdditions_6.1.97-136310.iso), so eine typische Versionsnummer .97 dafür. Damit funktioniert Linux-Host <> Linux-Guest wieder einwandfrei. VirtualBox-6.1.97-136310-Linux_amd64.run muß man nicht installieren.

Lieber mögliche neue Bugs als sichere alte Bugs. ;-)

Update: Statt des Snapshots kann seit 2020-03-04 das jeweils aktuelle 6.1.5er Testbuild verwendet werden.

arch: initramfs-linux-fallback.img, errors during the build

Mit in arch aktiviertem testing wird derzeit mittels mkinitcpio initramfs-linux-fallback.img mit einer error-Msg gebaut:

~$ sudo mkinitcpio -p linux
==> Building image from preset: /etc/mkinitcpio.d/linux.preset: 'default'
  -> -k /boot/vmlinuz-linux -c /etc/mkinitcpio.conf -g /boot/initramfs-linux.img
==> Starting build: 5.5.5-arch1-1
  -> Running build hook: [base]
  -> Running build hook: [udev]
  -> Running build hook: [autodetect]
  -> Running build hook: [modconf]
  -> Running build hook: [block]
  -> Running build hook: [keyboard]
  -> Running build hook: [keymap]
  -> Running build hook: [resume]
  -> Running build hook: [filesystems]
  -> Running build hook: [fsck]
==> Generating module dependencies
==> Creating gzip-compressed initcpio image: /boot/initramfs-linux.img
==> Image generation successful
==> Building image from preset: /etc/mkinitcpio.d/linux.preset: 'fallback'
  -> -k /boot/vmlinuz-linux -c /etc/mkinitcpio.conf -g /boot/initramfs-linux-fallback.img -S autodetect
==> Starting build: 5.5.5-arch1-1
  -> Running build hook: [base]
  -> Running build hook: [udev]
  -> Running build hook: [modconf]
  -> Running build hook: [block]
==> WARNING: Possibly missing firmware for module: wd719x
==> WARNING: Possibly missing firmware for module: aic94xx
  -> Running build hook: [keyboard]
  -> Running build hook: [keymap]
  -> Running build hook: [resume]
  -> Running build hook: [filesystems]
  -> Running build hook: [fsck]
cp: cannot stat '(builtin)': No such file or directory
==> Generating module dependencies
==> Creating gzip-compressed initcpio image: /boot/initramfs-linux-fallback.img
==> WARNING: errors were encountered during the build. The image may not be complete.
~$

Warning, daß errors… ;) Wie man sieht, tatsächlich nur für fallback, nicht normal. Das Gleiche ergibt sich, wenn man für einen etwaigen Notfall linux-lts-image (das wäre 5.4, so weit sind andere Distributionen noch nicht mal) installiert hat. An der Kernel-Version liegt es also nicht.

Postings über die Jahre mit dieser Ausgabe sind durchwachsen. Einer meint, er habe den Komprimierer in “/etc/mkinitcpio.conf” geändert. Gut, kann man ja mal probieren – vielleicht gibt’s mit default gzip ja ein Problem – so am halboffenen Herzen, grin. Interessant ist’s allemal (xz dürfte die beste Komprimierungsrate haben, dafür dauert dann mkinitcpio deutlich länger, man braucht auch gar nicht komprimieren, wenn man cat setzt), löst aber das Problem nicht.

In anderen Threads wird von nvidia oder VBox gesprochen. Hier nix nvidia, sondern nouveau. VBox ist freilich vor zwei Tagen in v6.1.4 erschienen (wie üblich habe ich sämtliche 6.1.3er Testbuilds installiert gehabt, ohne Trara). Schrittweise Testdeinstallation von virtualbox-host-modules-arch, des ExtensionPacks und VBox’ selbst…außer Spesen nix gewesen.

Um es nun ;) kurz zu machen, ursächlich ist kmod 27-1. Mit 26-3 läuft mkinitcpio sauber durch.

  1. Installation von kmod-26-3-x86_64.pkg.tar.xz aus dem PackageCache:
    1
    
    sudo pacman -U /var/cache/pacman/pkg/kmod-26-3-x86_64.pkg.tar.xz
  2. kmod in “/etc/pacman.conf” mit “IgnorePkg = kmod” auf hold setzen.
  3. initramfs*.img neu bauen:
    1
    
    sudo mkinitcpio -p linux

Wenn man sowas macht, muß man

  • auf Abhängigkeiten achten (andere Pakete, die ggf. mit gedowngradet werden müssen),
  • diese Änderung im Hinterkopf behalten, denn die stellt selbstverständlich keine Dauerlösung dar, sprich nach Bugfixing ist wieder der Paketeintrag von IgnorePkg zu nehmen.

Hat man den Paketzwischenspeicher bereits geleert gehabt, kann man sich kmod über archlinux.org/packages ziehen (solange es da in 26-3 noch liegt, grin).

Btw., es gibt zwar ein Helferlein namens downgrade, Installationen aus AUR sollte man allerdings auf persönlich wirklich unverzichtbares minimieren. Und so selten, wie derartiges in arch trotz Rolling Release Distribution und aktiviertem testing vorkommt…das ist QA!

Update: Ein zwischenzeitlich erfolgtes Update von mkinitcpio fixt obiges Problem. Ergo in “/etc/pacman.conf” die “IgnorePkg”-Zeile wieder mit “#” auskommentieren und mit pacman aktualisieren.

VBox: stuttering in yt

VMs in VBox eignen sich für wirklich vieles, aber nicht gerade für yt. In Firefox (und wohl auch Chromium) starten Videos nicht wirklich, es wird scheinbar ewig gebuffert. Man muß mehrfach stoppen und starten, bis es weiter geht…ein wenig.

(Nicht nur) in diesen Browsern gibt es unter Linux keine Hardware-Unterstützung durch die GPU, geplant ist bislang auch nichts (nicht mal im closed source Chrome). D.h., das Rendering hat die CPU in Software zu übernehmen. In nativen Linux-Installationen macht sich das nicht bis kaum bemerkbar, so man nicht gerade eine Schippe Sand als CPU hat. In VBox-VMs allerdings eben schon, zumal die GPU-Treiber VBoxSVGA und VMSVGA dahingehend auch nicht die stärksten sind.

In altägyptischen Flash-Zeiten hat es mal den Workaround gegeben, per Rechtsklick (oder auch kleiner Konfigurationsdatei) im Video HW-Unterstützung zu deaktivieren, also das, was eh nicht da ist. Flash, ohnehin nie für Videos gedacht, ist aber tot (und nein, solchen Dreck installieren wir auch nicht, User ohne Plan aus einem bestimmtem Forum), mithin auch diese Einstellmöglichkeit.

Das problematische OpenGL in Hardware ausknipsen hilft bei diesem Fehlerbild auch nicht. Auch nicht, den Original-Firefox zu verwenden statt des Kompilats der jeweiligen Linux-Distribution (in debian gibt es gerade mal ein Problem, was so umgehbar ist). Alles bereits ausprobiert.

In Fx’ “about:config” gibt es mehrere Probanden, die zu testen wären. Ohne die Ursache zu kennen, ist das aber eher ein trial & error. Defaults eines frischen Profils bringen auch nichts.

Nun hat das Ganze früher mal ohne zu stottern funktioniert. Da es für mich aber keine Priorität hat (ja, das gibt es, User ohne Plan aus einem bestimmtem Forum), bin ich dem bislang nicht nachgegangen.

Um zum Punkt zu kommen, yt streamt in VP8/VP9. Eine Hardware-Unterstützung gibt es dafür bisher kaum, wohl aber für H.264. Als Linux- und OSS-Verfechter würde man natürlich lieber ein freies Format verwenden, an der Stelle muß man abwägen.

Allein Codecs installiert zu haben, genügt nicht. Dem Browser muß gesagt werden, daß er H.264 verwenden, d.h. von yt anfordern soll. Gibt’s sicherlich auch eine Möglichkeit unter “about:config”, denn etwas anderes wird das Fx-Add-on h264ify auch nicht verändern. Als Quickfix mag es genügen – und es funktioniert einwandfrei.

Btw., wenn man ein Add-on zum Ändern des User Agents installiert hat, kann man auch eine brauchbare Kombination aus OS und Browser ermitteln, dann wird H.264/mp4 gestreamt und man braucht nichts extra.

endeavouros release

Nachdem der monatliche Build endeavouros 2019-11-19 zurückgezogen worden ist (natürlich 5 min nachdem ich die 1.6 GiB gezogen gehabt habe, 8-)), kurz genannte Probleme habe ich freilich nicht verifizieren können und hätte das Image durchaus verwendet, ist gestern Nachmittag der Snapshot 2019-12-03 als Final veröffentlicht worden.

VBox-(upstream-)Probleme (VMSVGA, vboxsf) bestehen fort, sind jedoch nicht dringlich, da umgehbar.

Project Leader Bryan Poerwoatmodjo (Bryanpwo) schreibt zwar, “this interim release is just to address the Kalu problem”, aber es ist weit mehr als nur das einfach zu deinstallierende kalu (dessen Abhängigkeiten beißen sich mit denen von pacman, verhindern daher Aktualisierungen, und wird zudem nicht weiterentwickelt), werden doch Grundkomponenten Kernel, Mesa, Systemd und weiteres aktualisiert.

Wer neu installiert, will ja nicht gerade das Oktober-Image oder gar das August-Image (der Vorschlag ist gestern in einem Thread bei einem Wayland-Problem eines Users gefallen…bei einer Rolling Release Distribution) verwenden, um hernach quasi alles updaten, sprich neu ziehen, zu müssen.

User mit bereits laufendem System interessiert’s (erstmal) nicht, nur wenn man das aktuelle Image als Sicherheit im Werkzeugkasten haben will.

Btw., Bryanpwo (NL). Dieser ist äußerst rührig. Bspw. habe ich ihm vorgestern kurz geschrieben, daß Links im Light-Theme des Forums farblich nur schwer als solche erkennbar sind (das hat man auch gemerkt, wenn User irritiert nachgefragt haben, wo sie denn klicken sollen). Quasi in derselben Minute hat er die Linkfarbe geändert. Spitzenmäßig.

·

2020-05-09: endeavouros 2020.05.08 (endeavouros-2020.05.08-x86_64.iso.torrent).
2020-04-11: endeavouros 2020.04.11 (endeavouros-2020.04.11-x86_64.iso.torrent).
2019-12-24: endeavouros 2019.12.22 ist freigegeben worden.

VBox 6.0.13 laeuft mit Kernel 5.3 im Host

Vor zwei Tagen ist Kernel 5.3 erschienen, die ersten Distributionen beginnen, ihn auszuliefern. Klar, keine verstaubten á la Long Term Sleeping, sondern die, die stets vorn dran sind, so arch bzw. arch-basierte wie endeavouros.

Mit VirtualBox hat man bis gestern auch keine 5.3rc nutzen können. Mit Testbuild VirtualBox-6.0.13-133347-Linux_amd64.run (GA 6.0.13-133316, EP 6.0.13-133347) wird nun ordentlich gebaut, VMs starten und laufen. Tests mit endeavouros und siduction als Hosts.

Btw., VBox 6.1.0b1 ist erschienen (dev-snapshots auf der testbuilds-site sind bereits höher, mehr bleeding edge geht dann aber nicht). Wie ich vor 4 Wochen schon geschrieben habe, VBoxVGA ist nun entfernt worden, es ist also auf VBoxSVGA oder, dort, wo es nicht crashed, VMSVGA zu wechseln.

endeavouros, das Image

endeavouros logo
Spielt man mit Links, kann man mit ein wenig Phantasie endeavouros bereits ziehen, auch wenn auf der Website noch nicht offiziell verkündet. Ich bin fair und verrate ihn nicht. :-p

Jedoch weise ich auf bekannte Probleme der Installation hin. Diese hat es auch bei der dritten Vorabversion gegeben (neben kleineren Geschichten). Gerade was die Partitionierung oder (von mir sowieso abgelehntes) Dualboot angehen, sollte man bedacht vorgehen.

Genaugenommen ist das Ganze mit den Problemen noch kein Final Release, aber sei’s drum! Von einer Verschlüsselung derzeit noch abgesehen (ursächlich diese Calamares-Version, upstream zu beheben) ist alles umgehbar.

Tip von mir noch zu einer Installation in einer VBox-VM: Sowohl CSM/MBR als auch UEFI/GPT sollten möglich sein, jedoch sollte als virtuelle GPU VBoxSVGA, nicht VMSVGA (der VMware-Treiber) gewählt werden. Bei letzterer bleibt das Booten einfach stehen.

Nachtrag: So, jetzt ist endeavouros offiziell freigegeben.

Btw., auf Nachfrage Interessierter nach einem Torrent meint Bryanpwo, Project Leader, “Later this week (…).”. Dabei wäre es gerade direkt nach Freigabe, also jetzt, besonders sinnvoll. Man merkt, wie der Server (Strato…) in die Knie geht.

Eine knappe halbe Stunde danach ;) hat das Team weitere Links auf github bereitgestellt, auch zu endeavouros-2019.07.15-x86_64.torrent. Prima.

antergos’ Reinkarnation: endeavouros

EndeavourOS

Der Name

Der Name der neuen arch-basierten Distribution birgt verdammt viel Potential einer Falschschreibung, insbesondere die englische Schreibung statt der amerikanischen (wie schon beim namentlichen Space Shuttle, auf das sich die Protagonisten beziehen). Dazu das Anfangs-“e” und/oder “os” versal oder nicht. Auch, wenn ich gemeinhin die jeweiligen Eigenschreibweisen verwende, werde ich nicht schreiend durchgängig großschreiben, sondern wie bei anderen Linux-Distributionen gezieltes Understatement, also endeavouros (und auch so gesprochen).

Nein, Namen sind nicht Schall und Rauch, im Gegenteil mit Logo/Schriftzug Aushängeschild. Freilich bekommen sie erst durch den Inhalt Bedeutung. Nun, gegenüber antergos (abgeleitet vom galicischen Wort für Ahnen) erscheint mir die Hernahme eines bestehenden und bedeutungsbesetzten Wortes nicht einfallsreich (beim Logo hat es auch einen besseren Vorschlag gegeben).

Der Inhalt

Aber konzentrieren wir uns auf eben den Inhalt. archlinux ist eine Rolling Release Distribution, d.h., es gibt keine Release Dates wie bei den meisten Linux-Distributionen (bspw. letztes Wochenende debian 10 buster, stable, wie langweilig), sondern laufende Aktualisierung. Das funktioniert sogar sehr gut (siduction versucht das auch, aber debian sid, auf dem es basiert, hat per se permanenten Entwicklungsstatus, ist keine RRD für Produktivsysteme, da knirscht es zuweilen bei Transitions gewaltig). Jedoch ist arch keine Distribution für nach-Jahren-noch-nicht-weiter-Ubuntu-User. Das zeigt schon der nerdige Registrierungsvorgang auf archlinux.org (es ist die Ausgabe einer Shell-Befehlszeile zu copypasten).

Nichtsdestotrotz muß man ja nicht alles unnötig erschweren (wobei…Ubuntu hätte es in den letzten Jahren gutgetan…verspielt). So hat vor etlichen Jahren bereits ein Script Dritter die Basisinstallation zeitgemäß angepackt. Das an sich würde auch heute genügen, es muß keine extra Distribution geben. Hat es aber mit cinnarch, das später zu antergos umbenannt worden ist, da Cinnamon nicht mehr das default DE gewesen ist. Die nicht mal Handvoll Macher haben 7 Jahre durchgehalten. Das ist in diesem Metier beachtlich.

Antergos ist sehr nah an archlinux (gewesen), hat nichts zurückgehalten oder verändert wie Manjaro (das bringt diesem immer wieder Kritik ein), nur wenige zusätzliche Pakete in einem extra Repository angeboten und dazu einen anständigen Installer geliefert (auch, wenn cnchi bisweilen Probleme gehabt hat).

Das hat nun auch den Vorteil, daß man aus einem antergos leicht ein arch zaubern kann (antergos-Repo, das eh abgeschaltet werden wird, ‘raus, daraus installierte Pakete und deren Abhängigkeiten deinstallieren, wenn für nötig erachtet, entsprechendes aus einem AUR ähnlich einem PPA wieder installieren). Ja, strikte arch-User werden auch das anders sehen, von wegen nur arch-User wüßten, was sie installiert haben…haha, dem steht aber so manches trübe Posting entgegen.

Ende und Neuanfang

2019-05-21 haben die Maintainer nun bekanntgegeben gehabt, antergos einzustellen (es ist schon etwas im Busch gewesen, da der monatliche Snapshot ausgeblieben ist). Nach nur sehr kurzer Zeit haben sich jedoch dafür neue Leute aus der bislang zweiten Reihe gefunden, die Distribution unter neuem Namen leicht verändert fortzuführen (z.B. mit calamares statt hauseigenem cnchi). Seitdem gibt es gefühlt soviel Traffic im noch bestehenden antergos-Forum und vor allem im seit 2019-07-02 freigeschaltetem neuem endeavouros-Forum (mit endlich brauchbarer Foren-Software statt dieses miesen WP-Plugins) wie in den letzten Jahren nicht.

Dabei gibt es auch Träumereien mancher, was alles ‘rein sollte (welch ein Unsinn – schlank und so original wie möglich), die meisten antergos-User freuen sich einfach, daß es mit frischem Wind weitergeht. Man sollte freilich wirklich nicht vergessen, daß es derzeit nur 3 Enthusiasten sind. Da man jedoch noch näher an arch bleiben will, als es antergos eh schon gewesen ist, sollte die Sache machbar sein. Und Nischendistribution her oder hin, man könnte jederzeit auf archlinux switchen.

Es sind 3 öffentliche Dev-Versionen erschienen. Für heute, 2019-07-15, ist die Final der sog. offline-Version angekündigt. Gut, das ist ein festes Datum, aber es muß ja mal anfangen. ;-)

VirtualBox: Kernel 5.0 nun auch im Guest

VirtualBox 6.0.4 kommt mit Kernel 5.0.x zurecht – aber nur im Host. In einer Linux-VM bislang nur ohne GuestAdditions, auch nicht mit 6.0.5er Testbuilds oder auch 6.0.97er Development Snapshots – bis heute.

Endlich (und wir sind schon bei Kernel 5.0.4, 5.1 liegt bereits als rc2 vor) werden mit VBoxGuestAdditions_6.0.5-129577.iso die Module gebaut (Nachtrag: mittlerweile sind höhere Testbuilds erschienen). Es können damit aktuelle Kernels in Virtual Machines bzw. auch entsprechend aktuelle Linux-Distributionen (antergos, siduction) in VMs genutzt oder getestet werden (selbst LDisco ist seit kurzer Zeit nach ewigem Stillstand auf aktuellen Kernel gewechselt – mit 5.1 wird das allerdings bis zum Release nichts mehr).

Die GA allein sollten zwar genügen, ich setze freilich seit langem insgesamt aktuelle Testbuilds von VBox, GA und EP ein (so nicht gerade mal ein Release aktueller sein sollte…für einen kurzen Zeitraum).

Update 2019-04-16: VBox 6.0.6 ist erschienen.

SystemRescueCd mit archlinux-Unterbau

SystemRescueCd Menu

Live-Systeme wie SystemRescueCd sollten in keinem IT-Werkzeugkasten fehlen. Mit der heute erschienenen v6.0.0 (Update) wechselt SysRescCd die Basis von bisher Gentoo auf archlinux. Ein Schritt, den ich persönlich begrüße, obgleich ich die Gründe zwar nicht kenne, jedoch hauptsächlich begrenzte Manpower vermute.

Das könnte übersehen, wer gewohnt startx oder ein Tool wie z.B. testdisk ausführt.

Read more “SystemRescueCd mit archlinux-Unterbau”

VitualBox: Installation ueber .run

Altägyptisch oder bleeding edge. Aktuelles Beispiel: In siduction wird anders als in sid Kernel 4.20 installiert (towo ist da glücklicherweise agil). Wer VirtualBox aus den debian-Repositories nutzt, bekommt bislang nur 5.2.22, das jedoch inkompatibel zu Kernel 4.20 ist.

VBox 6.0.0 ist kompatibel zu Kernel 4.20. Man kann zwar das VBox-Repo einbinden, daraus aber nur für debian stable und oldstable installieren, was im Normalfall unter sid(uction) wegen Dependencies fehlschlägt. Für Ubuntu gebaute Pakete in debian installieren ist auch nicht die gescheiteste Idee (auch wenn die für Bionic momentan laufen sollen).

Dann sollte man so flexibel sein und die .run-Files nutzen, statt wie ein User im siduction-Forum zu jammern, er wolle nur installieren, was “über apt oder dpkg” geht, und deshalb bei der letzten 4.19 bleiben (von der Paketverwaltung abgesehen, was er meint und womit er natürlich Recht hat, erntet er meinerseits dennoch Unverständnis, man fährt doch keine bleeding-edge-RRD, um ausgerechnet beim Kernel stehenzubleiben bzw. zurückzugehen). Fremdpakete aus Sicht der Distribution sind es so und so, aber in diesem Fall bzw. aus Sicht VBox’ sind sie das Original.

Das Ganze ist auch nicht schwieriger, mehr noch, man kann das so unter diversen Distributionen durchführen, bspw. unter siduction und antergos die jeweils selben .run-Files (braucht sie also auch nur 1x ziehen) und bis auf sudo vs. root-Terminal gleich. Zudem kann man Testbuilds nutzen, die ihrerseits ggf. Fixes ggü. dem letzten Release enthalten. Der einzige Nachteil ist lediglich, daß man sich selbst um neue Versionen kümmern muß (und das Interesse für derlei setze ich bei Usern, die bewußt brandaktuelle Distributionen fahren, voraus).

Ich selbst nutze seit längerem VirtualBox*.run unter (bis vor einiger Zeit noch Lubuntu,) siduction, antergos (die gemischte Groß-/Kleinschreibung für solche Namen ist übrigens kein ständiger Fehler meinerseits, falls das jemand annimmt, sondern jeweilige Eigenschreibweise). Insbesondere durch die nicht aufhörenden Probleme mit dem Lubuntu-Host seit Kernel 4.15 (nur dort, nicht in siduction und antergos, reproduzierbare Freezes unterschiedlicher VMs und das Suchen nach den Ursachen) haben mich das jeweils aktuelle Testbuild installieren lassen, mittlerweile mache ich das standardmäßig (nur nicht, wenn das Release gerade mal neuer ist) und fahre damit sehr gut. Natürlich weiß ich, was das bedeutet und kann damit umgehen.

.

Installation VirtualBox 6.1.8 über .run

  1. Ein ggf. installiertes Extension Pack deinstallieren:
    1
    
    sudo VBoxManage extpack uninstall "Oracle VM VirtualBox Extension Pack"
  2. Eine ggf. installierte VBox-deb-Version deinstallieren:
    1
    2
    
    killall -9 virtualbox 
    sudo apt-get purge virtualbox*
  3. Zum Kompilieren der Kernel-Module nötige Pakete installieren:
    1
    
    sudo apt-get install build-essential dkms linux-headers-$(uname -r)
  4. VirtualBox*.run ziehen:
    1
    2
    
    cd ~/Downloads/
    wget https://download.virtualbox.org/virtualbox/6.1.8/VirtualBox-6.1.8-137981-Linux_amd64.run
  5. Aktuelle VBox-Version installieren:
    1
    
    sudo sh Virt*
  6. Weiter geht es in meinem Tutorial VirtualBox: Repository in Ubuntu hinzufügen mit Punkt 8, “Entsprechende Version des Extension Packs ziehen”.

Soll ein so installiertes VBox wieder deinstalliert werden, sollte zuerst wie oben geschrieben das Extension Pack deinstalliert werden, danach VBox selbst (das EP bliebe anderenfalls erhalten, aber nicht nutzbar):

1
sudo sh Virt* uninstall

.

Update 2020-05-14: Aktualisiert auf v6.1.8.
Update 2020-04-09: Aktualisiert auf v6.1.6.
Update 2020-02-20: Aktualisiert auf v6.1.4.
Update 2020-01-15: Aktualisiert auf v6.1.2.
Update 2019-12-11: Aktualisiert auf v6.1.0.
Update 2019-10-15: Aktualisiert auf v6.0.14.
Update 2019-09-03: Aktualisiert auf v6.0.12.
Update 2019-07-16: Aktualisiert auf v6.0.10.
Update 2019-05-14: Aktualisiert auf v6.0.8.
Update 2019-04-16: Aktualisiert auf v6.0.6.
Update 2019-01-28: Aktualisiert auf v6.0.4.
Update 2019-01-15: Aktualisiert auf v6.0.2.