Am Anfang meines Studiums habe ich mir ein Asus Transformer Mini T102HA zugelegt. Das Gerät ist dem Microsoft Surface nachempfunden und besteht aus einem 10″ Tablet mit Windows 10 und einer ansteckbaren Tastatur inkl. Touchpad. Da derselbe Digitizer wie im Surface verbaut ist, habe ich mir statt des Asus-Stifts direkt den originalen Surface Pen dazugekauft. Der Plan war, das Gerät zum handschriftlichen Mitschreiben in den Vorlesungen zu nutzen.

Im Laufe des ersten Semesters mit dem Convertible musste ich dann allerdings feststellen, dass das nicht so wirklich gut klappte. Beim Mitschreiben auf dem Tablet musste ich immer wieder ganze Wörter löschen und neu schreiben, weil sie wegen der – im Vergleich zum Schreiben auf Papier – geringeren Präzision und dickeren Linienbreite unleserlich wurden. Dadurch dauerte das Mitschreiben einfach zu lange und lenkte mich zu sehr vom Vortrag ab. Da die Vorlesungsskripte meiner Professoren eh digital zur Verfügung gestellt wurden und sich das gelegentliche Anstreichen einzelner Passagen während der Vorlesungen als praktikabler herausstellte, stellte ich das Mitschreiben in den meisten Fächern zum Ende des Semesters ein und ersetzte das Convertible durch ein gebrauchtes ThinkPad T440. Für den seltenen Fall, dass mal etwas handschriftlich mitzuschreiben war, griff ich dann einfach zu Block und Füller, so dass ich zwar nicht ganz papierlos, aber dennoch recht papierarm arbeiten konnte.

Das Convertible verschwand also die meiste Zeit in einer Schublade. Zur Klausurvorbereitung holte ich es allerdings doch immer wieder heraus, da es sich als Tablet gut zum Durchsehen meiner Aufzeichnungen eignete. Von Zeit zu Zeit habe ich auch mal ein paar Comics darauf gelesen, weil der 10″-Bildschirm dafür genau die passende Größe hat. Allerdings waren die Comic-Apps unter Windows 10 nicht so gut wie die unter Android, weshalb ich dann doch immer öfter zu meinem Nexus 7 griff.

Mit der Zeit erwischte ich mich immer wieder bei dem Gedanken, dass das Gerät mit Android eigentlich cooler wäre als mit Windows 10. Es gibt nicht allzu viele gute Tablet-Apps im Windows 10 Store, weshalb ich häufig zu normalen Desktop-Apps greifen musste, die sich aber nicht gut per Touchscreen nutzen lassen. Irgendwann kam ich dann mal auf die Idee, Android x86 darauf auszuprobieren. Leider lief der Touchscreen nicht ordentlich und mit dem Wlan hatte ich auch Probleme. Der Ansatz war also eine Sackgasse.

Der Weg zu ChromeOS

In den letzten Monaten habe ich immer mal wieder etwas über Neuerungen bei ChromeOS in den Technik-News gelesen. Das Betriebssystem von Google war ursprünglich dafür entwickelt worden, ein möglichst leichtgewichtiges Betriebssystem als Unterbau für einen Web-zentrierten Desktop anzubieten. Das System basiert auf Gentoo, obendrauf sitzt eine leichte – ebenfalls von Google entwickelte – DE und alle Apps laufen direkt im Chrome-Browser. Ja, alle Apps. Auch das Terminal. Die einzigen Ausnahmen, die ich kenne, sind der Dateimanager und die Systemeinstellungen.

Von diesem “alles läuft in Chrome”-Ansatz hat sich ChromeOS inzwischen etwas entfernt. Seit ein paar Monaten kann man auch Android-Apps per Google Play Store installieren. Außerdem ist es inzwischen möglich, Linux-Programme auf ChromeOS zu installieren. Dazu kann man über eine Option in den Systemeinstellungen die Installation einer Ubuntu-VM starten, die dann auch in den Dateimanager eingebunden wird. Die in der VM installierten Desktop-Anwendungen kann man dann einfach über das Startmenü von ChromeOS starten. Die Kombination von Linux- und Android-Apps in einem Betriebssystem machte mich damals hellhörig, da man so unter anderem die Microsoft Office-Apps nutzen kann, ohne dafür auf Linux verzichten zu müssen.

ChromeOS ist – wie auch Android – Open Source. Genauer müsste man sagen: ChromiumOS ist Open Source. ChromeOS sind Googles ChromiumOS-Builds mit integrierten Google-Services. Als ich zum ersten Mal von Android-Apps in ChromeOS las, sah ich mich zum ersten Mal nach einer Möglichkeit um, das Betriebssystem auf mein Convertible zu bekommen. Die beste Anlaufstelle schien da CloudReady zu sein. CloudReady ist eine um weitere Treiber und Funktionen ergänzte Variante von ChromiumOS, die von Neverware vertrieben wird. Neben einer kostenlosen Variante für Heimanwender werden auch kostenpflichtige Versionen für Unternehmen und Bildungseinrichtungen angeboten, mit denen dann auch eine Integration in GSuite möglich ist.

Leider wird zum Erstellen eines Installationsdatenträgers der CloudReady-Images (die als .bin-Dateien vorliegen) das Chromebook Recovery Utility benötigt – sagt zumindest die CloudReady Webseite. Alternativ bietet CloudReady ein Windows-Programm zum Erstellen eines USB-Installationssticks an. Da ich damals weder Zeit noch Lust hatte, mich mit einem von beiden zu beschäftigen, ruhten meine ChromeOS-Pläne vorerst. Erst vor ein paar Tagen fand ich dann heraus, dass man auch unter Linux einen Installationsstick erstellen kann, denn das Chromebook Recovery Utility nutzt einfach nur dd, um die .bin-Datei auf den Stick zu schreiben.

Vor ein paar Tagen habe ich dann endlich Zeit gefunden, mich weiter mit den Installationsmöglichkeiten für ChromiumOS auf meinem Asus Transformer Mini T102HA auseinanderzusetzen. Nach etwas Gegoogle stieß ich neben CloudReady auch noch auf die ChromiumOS-Builds von ArnoldTheBat. Der bietet auf seinem Blog Daily und Weekly Builds von ChromiumOS an. Zusätzlich bastelt er auch noch an Special Builds, die das normale ChromiumOS-Image um weitere Treiber und Funktionen erweitern. Er arbeitet dort unter anderem daran, die Runtime für die Android-Apps und den Play Store in seine Images zu integrieren, da diese nur Teil von ChromeOS, nicht aber von ChromiumOS sind. Zur Zeit funktionieren die Android-Apps aber leider noch nicht, da die Runtime mehr Platz benötigt, als in der Standard-Systempartition noch frei ist.

Der aktuelle Special Build war das erste ChromiumOS-Image, das ich ausprobiert habe. Glücklicherweise ließ es sich ganz einfach per Etcher auf einen USB-Stick schreiben. Allerdings ist das Image 9GB groß. Leider war zwar der passende Treiber für mein WLAN-Modul im Image enthalten, funktionierte aber nicht. Das WLAN ließ sich zwar anschalten, deaktivierte sich aber sofort wieder. Da ich mich zum Fortsetzen der Ersteinrichtung des Live-Systems auf dem USB-Stick – das übrigens Änderungen über einen Neustart hinweg speichert – mit meinem Google-Konto anmelden musste, habe ich kurzerhand einfach die Tethering-Funktion meines Nokia 8.1 im USB-Modus genutzt. Das funktionierte ohne Probleme und das per USB angeschlossene Netzwerk wird einfach als Ethernet in den Einstellungen angezeigt.

Abgesehen vom WLAN klappte hier schon erstaunlich viel. Der Touchscreen funktionierte sofort und eine Touch-Navigation im System war ohne Probleme möglich. Sogar der Digitizer und der Surface Pen wurden sauber erkannt und selbst die unterschiedlichen Druckstufen des Stifts funktionierten beim Probezeichnen korrekt. Die automatische Displayrotation funktionierte leider nicht, aber das ließ sich ohne Probleme per Tastenkombination (Strg + Shift + F3) auf der ebenfalls sauber erkannten Tastatur durch manuelles Drehen in 90°-Schritten lösen. Auch ohne Tastatur lässt sich die Rotation problemlos in den Systemeinstellungen ändern. Einem Betrieb als Tablet steht also auch nichts im Wege.

Da ein Convertible ohne WLAN ziemlich witzlos ist, probierte ich am nächsten Tag einmal CloudReady aus. Hier funktionierte die WLAN-Verbindung ohne Probleme. Allerdings fehlten hier die Vorbereitungen für die Android-Apps, wie sie bereits im vorher getesteten Special Build enthalten waren. Neverware hat anscheinend auch nicht vor, Android-Apps in CloudReady zu integrieren. Sie haben sogar den einzigen Konkurrenten, der die Android-Unterstützung bereits in seinen Images hatte, aufgekauft und die Entwicklung daran eingestellt. CloudReady war also eine Sackgasse.

Beim Benutzen von CloudReady ist mir aufgefallen, dass weder Tonausgabe noch -eingabe funktionierten. Auch bei allen danach getesteten Images funktioniert die Audio-Ein-/Ausgabe nicht und erst nach viel Bastelei habe ich eine Möglichkeit gefunden, Sound für meinen chtrt5645 Soundchip zu aktivieren. Leider gibt es dazu nicht viel im Internet zu finden. Es liegt an einer fehlenden ALSA-State-Datei, die man sich erst aus einem aktuellen Android x86-Image besorgen muss. Dann muss man die (normalerweise schreibgeschützte) Root-Partition schreibbar neu mounten und mit alsactl restore die Einstellungen für die Soundkarte aus der ALSA-State-Datei wiederherstellen. Da alsactl unter /usr/sbin liegt, kann man es auch nur finden, wenn man bereits sudo benutzt. Ich dachte erst, es ist gar nicht installiert.

In CloudReady habe ich dann mal die Integration von Linux-Apps ausprobiert. Dazu musste ich diese erst in den Systemeinstellungen aktivieren. ChromiumOS läd dann eine Ubuntu-VM herunter und legt darin ein Benutzerverzeichnis für den aktuellen Benutzer an. Das Benutzerverzeichnis wird dann automatisch in den Dateimanager eingebunden, damit man lokale Dateien einfach in die VM kopieren kann. Im Startmenü wird außerdem ein App-Ordner für die Linux-Apps angelegt. Damit man auch Zugriff auf eine Konsole in der VM hat, wird dort direkt eine Verknüpfung zum Terminal angelegt. Im Gegensatz zum regulären Terminal von ChromiumOS läuft das Ubuntu-Terminal als App in einem eigenen Fenster und nicht im Browser.

Als erste Linux-App habe ich Firefox ESR per APT installiert. Die App ließ sich starten, wurde korrekt dargestellt und die Verknüpfung im Startmenü hatte auch das richtige Icon. Danach habe ich noch testweise IntelliJ Idea installiert. Da IntelliJ nur als Tar-Datei angeboten wird, musste ich das Archiv manuel entpacken, die IntelliJ-Binary starten und in der Ersteinrichtung eine Desktop-Verknüpfung erstellen lassen, um die App ins Startmenü zu integrieren. Dabei sind mir zwei Dinge aufgefallen: Erstens haben Apps anscheinend nur dann das richtige Icon im Startmenü, wenn sie über APT installiert werden. Zweitens werden die unterschiedlichen Java-Fenster von IntelliJ durch ChromiumOS nicht gruppiert, sondern einzeln in der App-Leiste angezeigt. Später habe ich dann noch ausprobiert, ob sich auch Flatpaks installieren lassen. Zwar musste ich dafür erst manuell Flatpak per APT installieren, konnte danach aber ohne Probleme den GNOME Taschenrechner per Flathub installieren. Leider wurde auch hier das Icon nicht korrekt angezeigt.

Da der WLAN-Treiber von CloudReady im Gegensatz zu dem aus dem Special Build funktionierte, machte ich mir kurzerhand eine lokale Kopie der Root-Partition des USB-Sticks. Im Anschluss daran flashte ich erneut den Special Build auf den Stick und suchte mir den Pfad zum Ordner des WLAN-Treibers heraus. Nachdem ich den Ordner auf dem USB-Stick gegen den aus der Sicherungskopie von CloudReady ersetzt hatte (jeweils /lib/firmware/ath10k/QCA9733), konnte ich den Special Build nun auch mit meinem WLAN-Chip nutzen.

Als nächstes installierte ich den Inhalt des USB-Sticks auf die Festplatte (bzw. eMMC), damit ich schon mal etwas mit dem System herumspielen konnte. Beim Herumspielen ist mir aufgefallen, dass weder der Powerbutton noch die Lautstärkewippe erkannt werden. In CloudReady funktionieren beide. Nach ein wenig Recherche fand ich heraus, dass die für die Buttons benötigten Treiber wohl Teil des Kernels sind. Leider blieben alle meine Versuche, den Kernel aus CloudReady in den Special Build zu integrieren, erfolglos. Ich kann den neuen Kernel per Legacy Boot nutzen, aber per EFI will er partout nicht funktionieren. Anscheinend nutzt ChromiumOS bei Verwendung von EFI noch eine spezielle ChromeOS Kernel-Partition zusätzlich zum Kernel in der EFI-Partition. Leider lässt sich diese spezielle Partition in Linux nicht einfach mounten und da das Convertible kein Legacy Boot unterstützt (Wieso eigentlich nicht? Scheint mir dumm.) kann ich den neuen Kernel dort nicht nutzen. Nach etwas mehr Recherche scheint es so, dass die Kernel-Partition aus einem signierten Image erstellt werden muss, weshalb auch ein Kopieren dieser Partition aus dem CloudReady-Image auf Grund unterschiedlicher Kernel-Partitionsgrößen im normalen ChromiumOS und in CloudReady nicht funktioniert.

Nachdem das WLAN lief, konnte ich mich nach einer Lösung für die fehlende Android-Unterstützung umsehen. Nach ein wenig Suchen fand ich nicht nur für dieses Problem eine Lösung.

ChromeOS dank Project Croissant

Auf der Suche nach einer Möglichkeit zum Nachrüsten der Android-Runtime stieß ich mehr als einmal auf den Name Chromefy. Eine kurze Recherche erbrachte dann ein sehr erfreuliches Ergebnis: Chromefy (inzwischen umbenannt in Project Croissant) ist ein Open Source Project zur Installation von ChromeOS auf nicht offiziell unterstützten Geräten. Dazu wird ein ChromiumOS-Image um diverse Dateien aus einem offiziellen ChromeOS Recovery Image erweitert, so dass nicht nur die Android-Runtime nachinstalliert wird, sondern auch der Google Assistant und die Option, ein Android-Smartphone mit dem System zu verknüpfen.

Project Croissant bietet mehrere Wege an, ChromeOS auf einem nicht offiziell unterstützten Gerät zu installieren:

• Erweiterung eines ChromiumOS-Images um alle benötigten Dateien per Skript. Das resultierende Image kann dann normal auf einen USB-Stick oder den internen Speicher geflasht werden.
• Erweiterung einer bestehenden ChromiumOS-Installation um alle benötigten Dateien per Skript
• Manuelle Erweiterung einer bestehenden ChromiumOS-Installation um die benötigten Dateien anhand einer Anleitung

Ich habe erst versucht, meine bestehende Installation auf dem zweiten Weg zu erweitern. Danach bootete die Installation aber leider nicht mehr. Daher habe ich mich dann für den ersten Weg entschieden. Dieser bietet auch den Vorteil, dass man den USB-Stick (oder internen Speicher) jederzeit neu flashen kann, falls man sich die Installation zerschießt.

Zum Erstellen des neuen Images braucht man neben einem ChromiumOS-Image noch ein ChromeOS-Recovery-Image der selben Architektur (Ich habe ein Image für das Pixel Slate verwendet.) und eine zusätzliche Tar-Datei von Project Croissant. Das ChromiumOS-Image muss entweder ein normaler ChromiumOS-Build oder einer von ArnoldTheBat sein. Die Images von CloudReady funktionieren – zumindest zur Zeit – nicht mit Project Croissant, da CloudReady ein anderes Partitionsschema als das normale ChromiumOS verwendet. Daher konnte ich leider keinen Nutzen aus der Tatsache ziehen, dass die Buttons in CloudReady funktionieren.

Das Erstellen des Images per Skript dauert nicht sehr lange. Die benötigten Dateien werden dabei einfach direkt in das ChromiumOS-Image hineinkopiert, weshalb man sich vorher eine Kopie davon anlegen sollte, falls man das reine ChromiumOS-Image noch benötigt. Danach kann das Image einfach mit Etcher auf einen USB-Stick oder eine MicroSD-Karte geschrieben werden.

Beim per Project Croissant erstellten Image musste ich leider feststellen, dass der integrierte Installer das System nicht sauber auf den internen Speicher des Convertibles schreibt. Das System bootet nicht. Ein manuelles Kopieren per dd war aber kein Problem. Danach muss lediglich die letzte Partition des internen Speichers auf den verbleibenden Platz ausgeweitet werden, damit auch aller verfügbarer Platz für die Benutzerdaten genutzt werden kann. Für das Kopieren und das Vergrößern der Partition habe ich von einem Ubuntu 18.04 USB-Stick gebootet und das ChromeOS-Image vorher auf eine MicroSD-Karte geschrieben, da das Convertible neben einem MicroSD-Kartenslot nur über einen USB-Anschluss verfügt. Auch hier musste ich wieder manuell den WLAN-Treiber auf der Karte austauschen.

Mit dem nun installierten ChromeOS konnte ich schon Einiges anfangen. WLAN funktionierte, Android- und Linux-Apps ließen sich nutzen, Touchscreen und Surface Pen funktionierten wie gewollt. Leider funktionierte die Soundausgabe noch nicht, aber auch dafür habe ich noch eine Lösung gefunden. Mit der aus Android x86 beschafften State-Datei konnte ich den Sound zum Laufen bringen. Dazu musste ich die von alsactl benötigte Datei /var/lib/alsa/asound.state erst manuell erstellen und dann die Einstellungen aus der State-Datei wiederherstellen. Mit speaker-test konnte ich dann auf der Kommandozeile prüfen, ob die Soundausgabe auch wirklich funktioniert. Ein kräftiges Rauschen aus den Lautsprechern bestätigte den Erfolg des Unterfangens.

Allerdings gab es auch hier einen Haken: Nach einem Neustart war der Sound wieder weg. Also musste ich es irgendwie hinbekommen, das Wiederherstellen der ALSA-Einstellungen zu automatisieren und an den Systemstart zu koppeln. Mein Mittel der Wahl wäre hier normalerweise Cron (für einmalige, von selbst endende Aufgaben), da es sehr einfach zu nutzen ist oder alternativ Systemd (für Dienste). Leider sind beide in ChromeOS nicht verfügbar. Zum Starten der Dienste nutzt ChromeOS stattdessen anscheinend Upstart, das weniger bequem zu nutzen ist als Cron oder Systemd. Um das Audioproblem zu beheben musste ich ein Bash-Skript erstellen, das das Wiederherstellen der ALSA-Einstellungen übernimmt. Um sicherzustellen, dass der ALSA-Dienst zum Zeitpunkt des Wiederherstellens schon läuft, schläft das Skript davor noch ein paar Sekunden. Damit das Skript automatisch ausgeführt wird, musste ich außerdem eine Konfigurationsdatei in /etc/init anlegen. Da ich mit diesem Init-System vorher noch nicht gearbeitet hatte, musste ich mich in die mindestens benötigten Felder der Konfigurationsdatei auch erst noch einlesen. Zum Starten des Bugfixes reichten am Ende die Felder “description”, “start on” und “exec”, also Beschreibung, Startzeitpunkt und der Pfad zur auszuführenden Datei.

Fazit

Nachdem das Audio-Problem dann endlich behoben war, funktionierte alles für mich wirklich Wesentliche. Ich kann Android-Apps nutzen, im Internet surfen, Comics lesen und Videos gucken. Viel mehr erwarte ich von dem Gerät nicht. Dass ich den Surface Pen darauf nutzen kann, ist ein nettes Extra. Leider gibt es immer noch Einiges, das nicht funktioniert, aber darüber kann ich vorerst hinwegsehen.

Zum Abschluss möchte ich noch einmal zusammenfassen, was – zur Zeit – noch nicht funktioniert:

• Der Powerbutton funktioniert nicht. Daher muss ich das Gerät immer entsperrt lassen, wenn ich es nicht komplett herunterfahren möchte. Da das recht nervig ist, werde dieses Problem wohl im Github-Repo von ArnoldTheBats Special Builds melden und hoffen, dass es zeitnah behoben werden kann.
• Die Lautstärkebuttons funktionieren ebenfalls nicht. Das ist für mich kein Problem, da ich die Lautstärke auch einfach im Systemmenü verstellen kann. Aber auch dieses Problem werde ich wohl melden.
• Der Sensor für die automatische Displayrotation wird nicht erkannt. Unter Ubuntu funktioniert die automatische Rotation, unter ChromeOS leider nicht. Auch für dieses Problem habe ich einen Workaround: Die Rotation kann in den Systemeinstellungen verstellt werden und bleibt über einen Neustart hinweg erhalten. Wie die beiden anderen Probleme werde ich dieses wohl melden.
• Die Webcam wird nicht erkannt. Die ist mir allerdings zur Zeit egal und mit den 3 anderen Problemen habe ich erst mal genug zu tun.
• Die Helligkeit lässt sich nicht verstellen. Das stört mich allerdings nicht weiter, da das Display hell genug ist.
• Die Soundeingabe klappt im Gegensatz zur Ausgabe nicht. Vielleicht will ich die irgendwann mal zusammen mit der Webcam nutzen, aber zur Zeit ist sie mir nicht wichtig.

Insgesamt bin ich mit dem Ergebnis recht zufrieden und gespannt darauf, was sich da noch verbessern lässt. Ich kann jedem Nerd empfehlen, sich ChromeOS einmal anzusehen. Es ist definitiv ein sehr interessantes Linux-Betriebssystem mit einzigartigen Konzepten und Fähigkeiten.