Auf meinen zwei betroffenen Rechnern verschaffen die im Antergos-Forum genannten Tipps wie das Unlinken von /usr/share/icons/default oder ein Downgrade der libxcursor leider keine allumfassende Besserung. Auch mit diesen Tipps stürzen eben Gummi, Firefox und mit Sicherheit noch andere Anwendungen gnadenlos ab. Als einzig wirklich brauchbarer Workaround hat sich bei mir das Setzen eines anderen Maus-Cursor-Themes als Adwaita erwiesen.

$ sudo pacman -S xcursor-vanilla-dmz
$ gsettings set org.gnome.desktop.interface cursor-theme Vanilla-DMZ
# Wieder Adwaita als Cursor-Theme setzen
$ gsettings set org.gnome.desktop.interface cursor-theme Adwaita

Mit den obigen Befehlen holt ihr euch das DMZ-Cursor-Set aus den Paketquellen von Arch Linux und aktiviert es über die Gsettings für euren User. Alternativ können ihr auch den grafischen dconf-editor starten und unter dem Pfad org.gnome.desktop.interface im Punkt cursor-theme das Vanilla-DMZ Theme eintragen. Das Cursor-Theme wird umgehend aktiv und die Abstürze gehören — zumindest bei mir — endgültig der Vergangenheit an.

In den Arch-Paketquellen und im Arch-User-Repository AUR gibt es neben dem hier genannten DMZ-Theme zahlreiche andere Cursor-Themes. Ein pacman -Ss xcursor oder pacaur -Ss xcursor spuckt euch zahlreiche mögliche Alternativen aus. Den für dconf benötigen Namen bekommt ihr über einen Blick in /usr/share/icons heraus. Beachtet bitte, dass ihr die Konfiguration für jeden User des Systems wiederholen müsst.

Wer sich zum Problem informieren möchte, der findet im Arch Bugtracker #40658, in mehreren Threads im Arch-Linux-Forum und auch auf Reddit zahlreiche Beiträge im Netz. Sollten bei euch unter Arch und seinen Derivaten wie Manjaro oder Antergos unerklärliche Abstürze auftreten, so prüft bitte kurz welche Version der libxcursor bei euch installiert ist.

$ pacman -Ss libxcursor
extra/libxcursor 1.1.14-2 [Installiert]
    X cursor management library
multilib/lib32-libxcursor 1.1.14-1 [Installiert]
    X cursor management library (32-bit)

In diesem Fall ist also problematische Version 1.1.14-2 der libxcursor installiert. Von dem Problem betroffen sind Anwendungen wie zum Beispiel Chromium und Leafpad — besonders unter der Gnome Shell. Der Chromium-Browser stürzt sofort beim Aufruf kommentarlos ab. Aus dem Terminal heraus aufgerufen, melden die betroffenen Anwendungen zumindest einen Speicherzugriffsfehler.

$ chromium
[781:781:0613/125554:ERROR:component_loader.cc(138)] Failed to parse extension manifest.
ATTENTION: default value of option force_s3tc_enable overridden by environment.
Speicherzugriffsfehler (Speicherabzug geschrieben)

Auf einem meiner Systeme hat es geholfen einen Symlink von /usr/share/icons/default zu lösen. Danach ließen sich Chromium und alle anderen streikenden Anwendungen sofort wieder starten. Den Symlink scheint es besonders auf Antergos-Systemen zu geben. Auf meinen „richtigen“ Arch Linuxen finde es den Symlink nicht und auch die Abstürze konnte ich nur auf meinen Antergos-Rechnern nachvollziehen.

$ sudo unlink /usr/share/icons/default

Sollte das Entfernen des Symlinks aus dem System nicht helfen, so kann man sich alternativ aus dem Pacman-Cache oder auch der Archlinux Rollback Machine die Version 1.1.14-1 der libxcursor holen und von Hand ins System einspielen. Mit den folgenden Befehlen ist das eigentlich recht schnell gemacht.

# Für 32-Bit Arch...
$ wget ftp://seblu.net/archlinux/arm/packages/l/libxcursor/libxcursor-1.1.14-1-i686.pkg.tar.xz

# Für 64-Bit Arch...
$ wget ftp://seblu.net/archlinux/arm/packages/l/libxcursor/libxcursor-1.1.14-1-x86_64.pkg.tar.xz

$ sudo pacman -U libxcursor*.tar.xz

Danach solltet ihr bei Updates allerdings die Augen ein wenig offen behalten und diese entweder bis zu einer richtigen Lösung des Problems aussetzen, oder aber ihr sagt Pacman doch bitte das anstehende Update der libxcursor zu ignorieren.

$ sudo pacman -Syu --ignore libxcursor
:: Synchronising package databases...
 core is up to date
 extra is up to date
 community                          2.2 MiB  3.32M/s 00:01 [###############################] 100%
:: Starting full system upgrade...
warning: libxcursor: ignoring package upgrade (1.1.14-1 => 1.1.14-2)

Das Problem lässt sich leider aus meiner Erfahrung heraus nicht grafisch lösen. In Nautilus fehlt bei Ordnern im Kontextmenü der Reiter „Öffnen mit“, in dem man die Zuordnung wie bei Dateien üblich korrigieren könnte. Weiß man man aber machen muss, ist die Lösung allerdings nicht sonderlich aufwändig, man muss sie nur in den Tiefen des Internets finden. In meinem Fall führte ein kurzer Beitrag auf bbs.archlinux.org zum Ziel, der auch gleich die Lösung des Problems beinhaltet. Die Ursache des Problems liegt in einem Bug, bei dem durch die Installation von Anjuta (oder auch anderer Apps) der Mime-Eintrag für Verzeichnisse verbogen wird, es gilt also diesen zu korrigieren.

$ xdg-mime query default inode/directory
anjuta.desktop

$ xdg-mime default nautilus.desktop inode/directory

$ xdg-mime query default inode/directory
nautilus.desktop

Die Befehle zeigen die verbogene Zuordnung von Ordnern an und korrigiere diesen gleich wieder. Unmittelbar nach dem Ausführen des zweiten Kommandos öffnen sich Ordner wieder mit Nautilus. Beachtet aber bitte, dass die Zuordnung nun nur für euren aktuellen Benutzer stimmt, bei anderen Usern des Systems öffnet sich nach wie vor Anjuta. Ihr müsst den zweiten Befehl daher für alle Benutzer des Systems ausführen, eine globale Lösung gibt es meines Wissens aktuell nicht.

//EDIT: Im AUR findet man mit gnome-defaults-list ein Paket, dass die Dateizuordnungen global für alle Benutzer des Systems korrigiert. Das ist für Mehrbenutzersysteme wahrscheinlich einfacher, als jedem User den Befehl zu vermitteln.

Dort werden eine ganze Reihe von Workarounds geschildert. Am besten wird es wohl sein Flash nicht aus den Paketquellen, sondern von Adobe selber zu installieren. Dies behebt meinen Informationen nach das Problem. Ich kann bestätigen, dass der Workaround auf einem 64-bit System funktioniert. Auf mein Notebook – mit einem 32-bit Karmic – trat das Problem jedoch erst gar nicht auf, daher kann ich nur das wiedergeben, was andere sagen…

32-bit

Auf einem 32-bit Ubuntu kann man aus das von Adobe unter get.adobe.com zur Verfügung gestellte .deb-Paket zurückgreifen. Ihr solltet also das über die Paketquellen installierte Flash deinstallieren…

$ sudo apt-get remove --purge flashplugin-nonfree flashplugin-installer

…dann das .deb-Paket von Adobe herunterladen und es über einen Doppelklick auf das Paket installieren. Nach einem Neustart des Browsers sollte Flash nun problemlos funktionieren.

64-bit

Kleiner Disclaimer hinterher: Firefox erweist sich mit dem 64-bit Flash-Plugin als sehr instabil. Der Browser stürzt bei zahlreichen Seitenaufrufen mit einem segmentation fault ab. Lösche ich das Plugin, so läuft Firefox wieder problemlos. In verschieden Foren berichten User, dass das Plugin gut laufen würde, von daher will ich nicht ganz vom 64-bit Flash Plugin abraten, sondern nur empfehlen bei Problemen, doch wieder das 32-bit Plugin inkl. nspluginwrapper über die Paketverwaltung zu installieren.

Adobe stellt aktuell noch keine offizielle Flash-Version für ein 64-bit Linux zur Verfügung. Allerdings gibt es schon seit geraumer Zeit eine öffentliche Beta-Version, die ebenfalls das „Klick-Problem“ behebt. Über…

$ sudo apt-get remove --purge flashplugin-nonfree flashplugin-installer nspluginwrapper
$ wget http://download.macromedia.com/pub/labs/flashplayer10/libflashplayer-10.0.32.18.linux-x86_64.so.tar.gz
$ tar xf libflashplayer-10.0.32.18.linux-x86_64.so.tar.gz

… deinstalliert Ihr das über die Paketverwaltung installierte Flash, ladetet die Beta-Version herunter und entpackt das Archiv. Im letzten Schritt…

$ sudo cp libflashplayer.so /usr/lib/firefox-addons/plugins/

… kopiert Ihr das Plugin ins System. Wieder müsst Ihr den Browser neu starten, erst dann wird das „neue“ Flash-Plugin benutzt. Das Klick-Problem sollte damit behoben sein. [UPDATE 14.11.2009: Auf launchpad.net ist nun endlich ein Weg aufgetaucht, der das Problem auf einem 64-bit System behebt, ohne dass man auf das – zumindest bei mir sehr problematische – 64-bit Plugin zurückgreifen müsste. Dazu verschiebt man die Datei /usr/lib/nspluginwrapper/i386/linux/npviewer.bin…

$ sudo mv /usr/lib/nspluginwrapper/i386/linux/npviewer.bin /usr/lib/nspluginwrapper/i386/linux/npviewer.bin.real

…und ersetzt die Datei mit einer neuen…

$ sudo gedit /usr/lib/nspluginwrapper/i386/linux/npviewer.bin

…in die man den folgenden Inhalt einfügt.

#!/bin/sh
GDK_NATIVE_WINDOWS=true /usr/lib/nspluginwrapper/i386/linux/npviewer.bin.real "$@"

Anschließend muss man das neue Skript noch ausführbar machen…

$ sudo chmod 755 /usr/lib/nspluginwrapper/i386/linux/npviewer.bin

…Danach sollte Flash nun auch mit „Klicks“ klappen.]

Beide Anwendungen kennen eine Vollbildfunktion. Es muss wohl auch an der Kombination Nvidia/Compiz liegen, denn das Geflacker habe ich nur bei meiner MSI Nvidia GeForce 9400GT, an einem anderen Rechner mit einer älteren Grafikkarte von ATI, tritt das Geflacker nicht auf. Durch Zufall bin ich nun endlich über den passenden Bug und den entsprechenden Workaround gestolpert, der das Problem löst.

Schuld daran ist eine Option von Compiz, die von Haus aus aktiv ist. Der Workaround verbirgt sich hinter der Option Umleitung von Vollbildfenstern aufheben, die man im CompizConfig Einstellungs-Manager unter System | Einstellungen | CompizConfig Einstellungs-Manager | Allgemeine Optionen findet. Sollte man den CompizConfig Einstellungs-Manager nicht installiert haben, so kann man ihn über…

$ sudo apt-get install compizconfig-settings-manager

…nachinstallieren. Sobald die Option deaktiviert ist, gibt es kein Geflacker mehr im Vollbildmodus. Negative Auswirkungen konnte ich bislang noch nicht ausmachen.

Wer sich vor dem Konfigurationswahnsinn des CompizConfig Einstellungs-Manager fürchtet, der kann auf die Installation des Programmes verzichten. Die Option lässt sich auch direkt über die gconf-Datenbank setzen. Der Befehl

$ gconftool-2 --set /apps/compiz/general/screen0/options/unredirect_fullscreen_windows --type bool 0

sollte das Geflacker beseitigen und

$ gconftool-2 --set /apps/compiz/general/screen0/options/unredirect_fullscreen_windows --type bool 1

die Option Umleitung von Vollbildfenstern aufheben wieder aktivieren. Der Workaround sollte für alle Grafiktreiber wirksam sein. Bei mir hat er das Geflacker bei einer Nvidia- und einer Intel-Grafikkarte bereinigt.

Die virtuelle Maschine wird daraufhin neu gestartet und man landet wieder vor der sehr aussagekräftigen Fehlermeldung:

Error:
Installation Failed: D:\ENGLISH\WINXP\PRO_WITH_SP2\I386\asms. Error Message:
The parameter is incorrect

Fatal Error:
One of the components that Windows needs to continue setup could not be installed

The parameter is incorrect

Trotz längerer Recherche, bin ich eher durch Zufall über die Lösung gestolpert. Das Problem lässt sich in den Einstellungen der virtuellen Maschine lösen. Hier ist als Standard die „Legacy Emulation“ aktiviert. Deaktiviert man diese, so bootet die die VM ordentlich und Windows lässt sich installieren.