GZB – Gero Zahns Blog – ger.oza.hn

Die folgenden Experimente bei der Installation eines Desktop-Linux beziehen sich auf einen Orbsmart AW-05 Mini-PC. Die dabei gewonnen Erfahrungen, vor allem in Hinblick auf 32-bittige EFI-Bootloader, dürften sich aber auch auf andere Mini-PCs ähnlicher Bauart übertragen lassen.

Den oben genannten Orbsmart AW-05 MiniPC besitze ich seit gut 4 Jahren. Dessen schmächtige Leistungsdaten lesen sich wie folgt:

• 2,16 GHz GHz 64-Bit Quad Core Atom Z3736F Bay Trail-T CPU
• UEFI-„BIOS“ von American Megatrends (AMI)
• 2 GB Arbeitsspeicher
• 32 GB NAND-SSD
• µSD-Steckplatz
• Davicom DM9601 100 Mbit-Ethernet
• Realtek RTL8723BS 2,4 GHz-WLAN
• 4x USB 2.0
• HDMI-Anschluss und gesonderter Kopfhörer-Ausgang
• Stromversorgung über ein Steckernetzteil mit 12V / 2A

Also alles in allem Schrott aus alten Flippern; im Februar 2020 wurde der Mini-PC gebraucht für 20-25 EUR gehandelt. In meinen Haushalt kam er nagelneu im Dezember 2015 in einem schwarzen Karton mit einem Aufkleber „Windows 10“, der über einem „Windows 8.1“-Schriftzug klebte. Korrekt: Auf der Maschine lief ein ursprünglich englischsprachiges, anschließend von mir händisch auf deutsche Sprache umgestelltes 32-bittiges Windows 10 Home, das trotz des engen SSD-Korsetts jedes Windows 10-Update bis einschließlich „1909“ (September 2019) mitgemacht hat. … Aber so richtig schön war das alles nicht, und das Windows 10 sprang regelmäßig beim Updaten „halb“ zurück auf englische Sprache – eher ein optisches Problem, aber trotzdem nervig.

Windows frisch installieren

Nachdem ich den Kasten nicht mehr wirklich viel nutzte und Zeit totzuschlagen hatte, kam ich auf die Idee, den Mini-PC neu aufzusetzen. (Merke: Kaffee ☕️, Hüte 🎩 und Computer 🖥 „setzt man auf“ – wobei diese Wortwahl bei einer Betriebssystem-Installation einen so genannten „Falschen Freund“ darstellt, fehlerhaft wörtlich übersetzt vom englischsprachigen „to set up“. Wie auch immer.)

Gesagt, getan: Ich entschied mich dazu, die SSD komplett zu löschen und das System frisch von Grund auf neu zu installieren. Natürlich verfügt der Mini-PC über eine digitale Windows 10-Lizenz, die sich mit Hilfe von Microsofts Aktivierungsservern auch nach einer „Tablua Rasa“-Installation ohne Eingabe des nicht im Detail bekannten Product Keys aktivieren lässt.

Wie also anfangen? Nun, im ersten Schritt habe ich auf einem anderen PC mit Hilfe von Microsofts ureigenem Windows 10 Media Creation Tool das aktuelle Windows 10 Home 1909 heruntergeladen und daraus einen bootfähigen USB-Stick generiert.

Auf Mini-PC-Seite stellte sich die Frage, wie man denn überhaupt ein alternatives Boot-Medium adressieren kann. Hier nun die relevanten Informationen, die man bei aktiviertem „Quiet Boot“ unter dem bildschirmfüllenden „Orbsmart“-Logo gar nicht zu lesen bekommt:

• Ins „BIOS“, d.h. ins Konfigurationsmenü der UEFI-Firmware, kommt man durch frühzeitigen Druck auf wahlweise Esc oder Entf.
• Freundlicherweise muss man keine Klimmzüge unternehmen: Secure Boot ist ab Werk deaktiviert, dem Booten von nicht-signierten Linux-Bootloadern steht also nichts im Wege.
• Hier aber der Pferdefuß: Die UEFI-Firmware lässt sich nicht auf einen BIOS-kompatiblen „Legacy-Boot“ umstellen; das ist schlichtweg nicht vorgesehen. Betriebssysteme können nur per EFI gebootet werden (mehr dazu weiter unten).
• Das Bootmenü erreicht man bei Bedarf nach frühzeitigem Druck auf F7.
• Im Falle des Falles muss für einen Not-Aus die Power-Taste stolze 10 Sekunden lang gedrückt gehalten werden.

Vom vorbereiteten Windows 10-USB-Stick bootet der Kasten EFI-gestützt problemlos, wenn man im Bootmenü oder im Setup „UEFI: VendorCoProductCode 2.00“ als Boot-Medium wählt (vielleicht ist das aber auch nur die Hardware-ID des von mir verwendeten NoName-Fernost-USB-Sticks). Die anschließende Windows-Installation verläuft daraufhin bis auf weiteres unspektakulär.

Bis nämlich – ja, bis man das frisch installierte Windows erstmalig bootet. Problemlose Aktivierung gut und schön, aber im Bereich Chipsatz finden sich allerhand Ausrufezeichen im Gerätemanager, die Windows weder aus eigener Kraft noch online mithilfe des Windows Update-Servers so recht zu beheben weiß. Das führt dazu, dass sogar der µSD-Slot nicht erkannt wird.

Guter Rat ist teuer, genauer gesagt, gar nicht zu bekommen: Die Firma Orbsmart bietet auf ihrer Website keinerlei Support mehr für dem AW-05 an, und folglich gibt es leider keine Möglichkeit, einen entsprechenden Treiber-Satz herunterzuladen. … Da ich Schlaukopf das alte, marode Windows 10 zuvor natürlich nicht gesichert hatte, und da ich mir natürlich auch keine Notizen über die zuvor installierten Gerätetreiber gemacht hatte, stand ich an dieser Stelle in einer Sackgasse.

Erste misslungene Linux-Experimente mit UEFI

Nun, schlimmer konnte es ja kaum werden, also beschloss ich, Experimente mit verschiedenen Linux-Distributionen zu unternehmen, um zu sehen, wie sich moderne Desktop-Distros auf dieser schwachen Hardware schlagen würden.

Ich bin seit jeher ein großer Fan von Linux Mint, einem Ubuntu-Derivat. Also ging ich los und lud mir die aktuelle 32-bittige Mint-Version 19.3 „Tricia“ mit Cinnamon-Desktop herunter. Ich hatte ergooglet, dass man derlei ISO-Images am besten an einem Windows-PC mit Rufus auf einen USB-Stick kopiert, um von ihnen an einem Computer ohne DVD-Laufwerk zu booten..

Gesagt, getan: Den vorbereiteten Stick in den Mini-PC stecken, Einschalten, F7, und – nichts: Der Orbsmart mag nicht von diesem Stick booten, es gibt noch nicht einmal den o.a. „VendorCoProductCode“-Eintrag im Bootmenü. Huh …

Nach einigem Herumsuchen fand sich in Form einer FAQ-Seite meiner Lieblings-Computerzeitschrift c‘t des Rätsels Lösung: Derartige Mini-PCs, die mit 32-bittigem Windows ausgeliefert wurden, booten zwar via EFI, aber deren UEFI-Firmware ist oft nur 32-bittig ausgeführt. Im Gegensatz zu Microsofts eigener Windows 10-ISO sind die Bootloader der meisten Linux-Installations-ISOs aber rein 64-bittig implementiert und lassen sich folglich auf einem derartigen 32 Bit-EFI-PC schlichtweg nicht booten. — Merke: Es ist dabei vollkommen egal, ob der Orbsmart vom USB-Stick oder vom externen USB-DVD-Laufwerk gebootet werden soll: Das Brennen der DVDs kann man sich getrost sparen – ich habe es erfolglos ausprobiert.

… Nebenbei bemerkt: Dieses Problem teilen sich der Orbsmart und andere vergleichbare Mini-PCs mit einigen alten Apple Macintosh-Modellen – ein solcher Vertreter ist beispielsweise mein 14 Jahre altes MacBook 2,1 Late 2006: Auch dieses hat zwar eine 64-bittige Core2Duo-CPU, bootet aber nur mit 32-bittigem UEFI. — Für mehr Informationen zu diesem Thema darf der interessierte Leser gerne diesem Link folgen.

64-bittiges Fedora 31 via 32-bittigem EFI-Bootloader

Aus eben genanntem c’t-FAQ-Eintrag geht ebenfalls hervor, dass es einige wenige Ausnahmen von dieser Regel gibt – und zwar etwa 32-bittiges Debian und 64-bittiges Fedora. Anschließende Experimente bestätigten diese Aussage: Spielt man Debian 10 (32 Bit) mit Rufus auf einen USB-Stick, oder alternativ Fedora 31 (64 Bit) mit dem eigenen Fedora Media Writer, bootet der Orbsmart Mini-PC anstandslos davon, und die jeweilige Distribution lässt sich installieren.

Der aufmerksame Leser wird sich nun fragen: „Moment mal, wenn doch das UEFI nur 32-bittig ausgeführt ist – kann man denn dann das o.a. 64-bittige Fedora installieren und ausführen?“ Erstaunlicherweise lautet die Antwort „ja“: Die verbaute Intel Atom-CPU ist 64-bittig, hat also keine Probleme mit 64 Bit-Betriebssystemen – sofern sie denn bitte per 32-bittigem EFI-Bootloader in den Speicher geholt werden. Fedora/64 installiert dann auf der Festplatte auch brav den dual 32-/64-bittigen GRUB-Bootloader, und anschließend ist alles gut.

32-bittiges Debian 10 „Buster“ mit Realtek-Treiber-Ladehemmung

Nun bin ich zu­ge­ge­be­ner­ma­ßen nicht der weltgrößte Fedora-Fan, und das installierte Fedora 31 „fühlte sich nicht so richtig gut an“ – das mag subjektiv sein, aber so war es halt. Umgekehrt mag ich Debian sehr (meist in der Raspbian-Ausprägung, aber das ist eine andere Geschichte, die an einem anderen Tag erzählt werden soll). Also verwarf ich die nun als grundsätzlich funktionstüchtig bekannte Fedora-Installation und bootete vom 32-bittigen Debian-Installations-USB-Stick, den man wahlweise mit Rufus oder auch mit Balena Etcher generieren kann.

Debian gibt sich aber aufgrund seiner Open Source-Philosophie ein bisschen divenhaft: Die Inbetriebnahme des WLAN-Interfaces scheitert daran, dass die für das Realtek RTL8723BS-WLAN-Device benötigte proprietäre „rtl8723bs“-Firmware nicht im Lieferumfang des Debian-Boot-ISO-Images enthalten ist.

Man muss also die benötigte Firmware in einem gesonderten Vorgang herunterladen und den ausgepackten Ordner „Firmware“ auf einen zweiten USB-Stick kopieren. … Pro-Tipp: Hat man den Boot-Stick mit Rufus generiert, ist dieser FAT-formatiert, ist folglich an PC oder Mac beschreibbar – und man kann die non-free Firmware aus dem heruntergaldenen ZIP-Archiv einfach mit in den im Hauptverzeichnis des Boot-Stick liegenden „Firmware“-Ordners legen. Debian findet den Treiber dann ohne die o.a. Meldung.

Aber: Den Kontakt zu meinem Feld-Wald-Wiesen-WLAN mit TP-Link-Access-Point mag der Debian-Installer dann immer noch nicht herstellen. Er sieht zwar zwar die SSID, lässt mich daraufhin das WPA2-Passwort eingeben – aber einen Connect gibt es trotzdem nicht.

Also Plan B: Flugs in der Hardware-Schublade gekramt und ein überzähliges WLAN-Dongle mit einem linux-bewährten Ralink RT5370-Chip angesteckt. Alte Lebensweisheit: Boot’s, tut’s. Denn damit lässt sich Debian dann problemlos installieren – und siehe da, nach dem ersten Bootvorgang des fertig installierten Systems funktioniert dann auch das Realtek-WLAN-Device mit der non-free Firmware, und man kann fortan auf das Ralink-USB-WLAN-Dongle verzichten. … Könnte mir das bitte mal jemand erklären?

Apropos „geht, geht nicht“: Ich würde mich ja gar nicht zu so einem frühen Zeitpunkt mit dem WLAN herumschlagen, wenn das im Orbsmart verbaute Davicom DM9601-Fast Ethernet-Device funktionieren würde. Aber das mag auch nicht so richtig mitspielen: Mal funktioniert es beim Boot der Live-CD, mal nicht. Sehr dubios, und nicht so richtig schön. — Details zu dieser LAN-Problematik finden sich weiter unten.

… All das ist mir dann doch ein wenig zu bodennah. Wie gesagt, ich mag zwar Debian, aber lieber als Server-Betriebssystem und nicht so sehr am Desktop. Bleibt die Frage: Wie bekomme ich denn bitte eine „ausgewachsene“ Linux-Distribution auf den Orbsmart?

YUMI UEFI to the rescue

An dieser Stelle wurde ich auf YUMI aufmerksam – „Your Universal Multiboot Installer“. Die etablierte BIOS-Version 2.0.6.9 (Stand: 11. Mai 2019) nützt im aktuellen EFI-Szenario zwar leider nichts. Hingegen die aktuelle 0.0.2.0 Beta-Version von „YUMI UEFI“ (selben Datums) dafür um so mehr: Sie verspricht, einen Multiboot-Stick auf EFI-Basis zu erstellen, den man mit verschiedensten ISOs bestücken kann.

„Just for the sh*ts and gigs“ habe ich YUMI UEFI angewiesen, alle bis hier testweise heruntergeladenen Linux-ISOs auf einen 32 GB fassenden Multi-Boot-Stick zu kopieren, darunter:

• 32-bittiges und 64-bittiges Debian 10 „Buster“
• 64-bittiges Fedora 31 (32-bittiges Fedora gibt es seit Oktober 2019 nicht mehr)
• 32-bittiges und 64-bittiges Mint 19.3 „Tricia“, jeweils mit Cinnamon und Mate

Ein kurzer Test ergibt: Das Multiboot-Menü auf GRUB2-Basis ist dual 32-/64-bittig ausgeführt – bootet also problemlos auch auf dem Orbsmart Mini-PC via 32-bittigem UEFI (und, nebenbei bemerkt, auch auf o.a. MacBook 2,1).

Nicht sein kann was nicht sein darf: Mint 19.3 (32 Bit) per EFI-Boot

Spannend dabei ist: 32-bittiges Linux Mint ist überhaupt nicht für das Booten via EFI ausgelegt, sondern kann per Dekret nur per BIOS gebootet werden: Dem ISO fehlt schlichtweg jegliche EFI-Unterstützung. Um so erstaunter war ich, dass YUMI UEFI es mit seinem dual 32-/64-bittigen EFI-Bootmenü schafft, das 32-bittige Mint-Live-System sehr wohl zu booten. Anschließend lässt sich die 32 GB große SSD des Orbsmart via GPT partitionieren, das System installieren, und schlussendlich problemlos via 32-bittigem UEFI booten.

Noch einmal fürs Protokoll: Mit YUMI UEFI ist es möglich, was die Macher von Linux Mint eigentlich gar nicht mehr vorgesehen haben – nämlich ein 32-bittiges Mint auf einem PC mit 32-bittigem UEFI zu installieren und anschließend davon zu booten: Mints GRUB ist scheinbar BIOS/EFI-32/EFI-64-multitalentiert und bootet nach der Installation anstandslos.

… Aber so erfreut ich anfänglich darüber war, um so besorgter wurde ich: Wenn Mint/32 so gar nicht gedacht ist, wer sagt mir denn, dass mir das System nicht mit dem nächsten oder übernächsten Update hintenüber kippt und nicht mehr booten mag?

Final Destination: Mint 19.3 (64 Bit) per 32 Bit-UEFI

Also habe ich auch das überaus passabel laufende Mint/32 wieder von der SSD gekegelt und stattdessen Mint/64 via YUMI UEFI auf den bootfähigen USB-Stick kopiert und anschließend per EFI-32 davon gebootet.

Eigentlich bootet das 64-bittige Mint-Live-ISO nur vom 64-bittigem EFI, dem ISO fehlt die EFI-32-Unterstützung. Aber auch dieses Live-System bootet YUMI UEFI problemlos via 32-bittigem EFI-Bootloader in den Speicher. Die anschließende Installation mitsamt GPT-Partitionierung funktioniert wie zuvor bei Mint/32 nunmehr bei Mint/64 wiederum erwartungsgemäß vollkommen problemlos, und auch das fertig installierte System bootet via dual 32-/64-bittigem GRUB2 problemlos per EFI-32.

… Meine aus der Windows-Perspektive genährte Sorge, dass ein 64-bittiges Linux einen deutlich höheren Speicherdruck haben könnte als ein 32-bittiges, und dass es sich auf einem PC mit lediglich 2 GB Arbeitsspeicher einfach nicht gut bedienen lassen würde, bestätigte sich nicht: Das 64-bittige Mint 19.3 „Tricia“ mit Cinnamon-Desktop fühlt sich auf dieser kleinen Gurke von einem PC den Umständen entsprechend überaus gut an – also genauso gut oder schlecht wie die 32-Bit-Variante. … OK, so lange man nicht gerade Chromium lädt. Das ist wirklich übel auf einer Maschine mit nur 2 GB Arbeitsspeicher.

Davicom DM9601-Netzwerktreiber-Probleme – und Lösung

Im Gegensatz zu Debian haben weder Fedora noch Linux Mint Probleme damit, die proprietäre WLAN-Firmware für den Realtek WLAN-Chip zu laden (s.o.) und den Orbsmart so schon direkt während der Installation ins 2,4 GHz-WLAN zu hieven.

Bleibt aber noch das oben bereits angedeutete Mysterium des Davicom Ethernet-Interfaces, das nichtdeterministisch mal funktionieren mag und mal wieder nicht: Mal stellt es direkt den Kontakt her und holt sich seinen Netzwerkzugang vom DHCP-Server – mal geht absolut gar nichts, auch nicht mit statischer IP-Konfiguration – und das, obwohl die Link-LED des Netzwerkports in beiden Fällen leuchtet.

Ich habe daraufhin den Orbsmart gefühlt dutzende Male gebootet – und wann immer ich ins LAN kam, habe ich mir mit den üblichen Linux-Diagnosewerkzeugen die Hardware-Konfiguration und das geladene Treiber-Kernel-Modul genau angesehen – und natürlich im Gegensatz dazu auch dann, wenn ich eben nicht ins LAN kam.

Mein sich einstellendes Bauchgefühl trog mich nicht: Das intern per USB angebundene Davicom DM9601-Ethernet-Modul wird aufgrund seiner Hardware-ID sowohl als „dm9601“ (was korrekt klingt) als auch als „cdc_ether“ erkannt – einem USB-basierenden Ethernet-Standard. Dummerweise werden daraufhin beide zugehörigen Kernelmodule werden geladen, und aus unerfindlichen Gründen bekommt dann mal der eine, mal der andere Treiber die Oberhand.

Es scheint so zu sein, dass wann immer zuerst das „cdc_ether“-Kernelmodul und anschließend das „dm9601“-Kernelmodul geladen wird, das LAN funktionsuntüchtig ist – so sieht das dann aus:

Ist umgekehrt zuerst das „dm9601“-Modul geladen und erst danach das „cdc_ether“-Modul, so funktioniert das LAN – so sieht das dann aus:

Man beachte in den beiden Screenshots die unterschiedliche Zeilenreihenfolge in der linken Spalte.

Ich habe daraufhin beherzt in die insmod-Blacklist unter /etc/modprobe.d/blacklist.conf eingegriffen und am unteren Ende die Zeile „blacklist dm9601“ hinzugefügt, um den Kernel beim Booten davon abzuhalten, ebendieses Modul zu laden.

Und siehe da: Wenn der „dm9601“-Treiber nicht quer schießt, kommt der „cdc_ether“-Treiber zum Zug, und das LAN funktioniert reproduzierbar jedes Mal.

tl;dr – das Wichtigste in Kürze

• Wer den Orbsmart AW-05 frisch mit Windows 10 installiert, steht im Regen, weil die integrierte Hardware mangels Treiber-Satz nur unzureichend unterstützt wird.
• Mit Esc oder Entf gelangt man ins UEFI-„BIOS“-Setup. SecureBoot ist bereits deaktiviert, die Bootreihenfolge lässt sich ändern, aber ein Legacy-Boot per BIOS-kompatiblem Bootloader lässt sich nicht aktivieren. Mit F7 gelangt man ins UEFI-Bootmenü.
• Das UEFI kann nur 32-bittige EFI-Bootloader ausführen, was viele Linux-Live-ISOs von Haus aus nicht unterstützen und sich dann folglich nicht booten lassen.
• Dem lässt sich begegnen, indem man den Boot-Stick mit YUMI UEFI generiert, der auch via EFI-32 bootet und anschließend verschiedenste 32- oder 64-bittige Linux-Live-ISOs booten und dann auch installieren kann – typischerweise auch dann, wenn diese gar nicht für den 32-bittigen UEFI-Boot gedacht sind.
• Die 64-bittige Atom-CPU des Orbsmart AW-05 unterstützt 64-bittige Betriebssysteme, sofern sich diese per 32-bittigem EFI booten lassen, was per GRUB2 meist kein Problem ist.
• Das Realtek RTL8723BS-WLAN-Interface benötigt bei Debian eine nicht-freie proprietäre „rtl8723bs“-Firmware, die mit bei der Installation zur Verfügung stehen muss – und doch funktioniert das WLAN erst nach, aber noch nicht während der Installation sauber. Andere Distributionen wie Fedora oder Mint unterstützen dies problemlos direkt ohne gesonderten Download.
• Das Davicom DM9601-Fast Ethernet-Interface wird doppelt erkannt und funktioniert dann mit dem eigentlich passenden „dm9601“-Treibers nicht. Wirksam hilft hier das Blacklisten des „dm9601“-Kernelmoduls, anschließend arbeitet es zuverlässig mit dem „cdc_ether“-Treiber.

Share