Eine Novena im Jahr 2026 - Teil 1

Eigentlich wollte ich nur Debian aktualisieren

Auf meinem Tisch steht ein Computer, der eigentlich aus einer anderen Zeit stammt.

Eine Kosagi Novena.

Und eigentlich wollte ich nur ein aktuelles Debian darauf installieren.

Das klang zunächst nach einem überschaubaren Projekt: SSD vorbereiten, Debian installieren, Bootkonfiguration anpassen und anschließend mit einem halbwegs aktuellen Linux-System weiterarbeiten.

Was daraus tatsächlich wurde, war etwas völlig anderes.

Denn ziemlich schnell stellte sich heraus, dass die entscheidende Frage nicht lautete:

Wie bekomme ich Debian 12 auf die Novena?

Sondern:

Wie viel von einer Novena lässt sich im Jahr 2026 eigentlich noch mit einem modernen Linux-System betreiben?

Diese Frage führte mich schließlich durch mehrere Kernelgenerationen, alte Device Trees, historische NixOS-Images, U-Boot, eine serielle Konsole und immer tiefer in die Hardware des Rechners hinein.

Aber der Reihe nach.

Ein Rechner, der verstanden werden wollte

Die Novena entstand Anfang der 2010er-Jahre als Projekt von Andrew „bunnie“ Huang und Sean „xobs“ Cross.

Die Idee dahinter unterschied sich deutlich von einem gewöhnlichen Notebook.

Novena sollte kein möglichst geschlossenes Produkt sein, bei dem Hardware und Software hinter einer möglichst glatten Oberfläche verschwinden. Im Gegenteil: Der Rechner war als offene Plattform gedacht, die man untersuchen, verändern und erweitern konnte.

Im Zentrum arbeitet ein Freescale i.MX6 Quad, also ein ARMv7-SoC mit vier Cortex-A9-Kernen. Dazu kommen unter anderem ein Xilinx-FPGA und zahlreiche offen dokumentierte Schnittstellen.

2014 finanzierten Huang und Cross das Projekt über Crowd Supply. Das ursprüngliche Finanzierungsziel lag bei 250.000 US-Dollar. Am Ende kamen 890.732 US-Dollar von 856 Unterstützern zusammen.

Es gab unterschiedliche Varianten – von der reinen Platine über eine Desktop-Ausführung bis hin zur Laptop-Version. Sogar eine aufwendig gefertigte „Heirloom“-Variante von Kurt Mottweiler wurde angeboten.

Doch wichtiger als das Gehäuse war die Philosophie dahinter.

Schaltpläne, Hardwareinformationen und große Teile der Software waren verfügbar. Debian gehörte zur ursprünglichen Softwarebasis. Wer wissen wollte, was der Rechner beim Einschalten tat, sollte grundsätzlich die Möglichkeit haben, genau das herauszufinden.

Mehr als zehn Jahre später sollte sich zeigen, wie wertvoll diese Entscheidung war.

Denn meine Novena ist heute zwar ein alter Rechner – aber keineswegs eine Blackbox.

Bild 1: Meine Kosagi Novena im geöffneten Zustand. Platine, SATA-SSD, Akku, Lautsprecher und Verkabelung liegen offen zugänglich im Gehäuse – genau diese Offenheit der Hardware sollte für das weitere Projekt noch entscheidend werden.

Das ist nicht nur eine gestalterische Besonderheit.

Für das, was ich mit dieser Maschine noch vorhatte, sollte sich genau dieses Konzept als ausgesprochen nützlich erweisen.

Der Ausgangspunkt: Debian – aber aus einer anderen Zeit

Auf der Novena lief ursprünglich ein altes Debian-System.

Auch der Kernel stammte noch aus der aktiven Entwicklungszeit des Rechners:

Linux novena 3.19.0-00485-gc5f2138
#858 SMP PREEMPT Tue Sep 15 13:41:23 SGT 2015
armv7l

Linux 3.19.

Für einen Rechner aus dieser Generation ist das zunächst nichts Überraschendes. Das System funktionierte, die Hardware wurde unterstützt und der Kernel enthielt die Anpassungen, die Novena benötigte.

Aber 2026 ist ein Kernel aus dem Jahr 2015 natürlich keine besonders attraktive Grundlage mehr für ein System, das tatsächlich weiter benutzt und untersucht werden soll.

Mein erster Gedanke war deshalb ausgesprochen unspektakulär:

Installiere einfach ein aktuelleres Debian.

Als Ziel wählte ich Debian 12 Bookworm.

Das neue System sollte nicht die ursprüngliche Installation zerstören. Stattdessen wollte ich eine SATA-SSD verwenden und damit gleichzeitig einen neuen, klar getrennten Bootpfad schaffen.

In meiner Novena steckt dafür eine Transcend-SSD mit rund 256 GB.

Ich teilte sie in zwei Partitionen auf:

/dev/sda1   512 MiB   FAT   /boot
/dev/sda2   ~238 GiB  ext4  /

Das Root-Dateisystem erhielt später die PARTUUID:

338c080c-02

Auf der Bootpartition lagen unter anderem:

novena.dtb
novena.recovery.dtb
uEnv.txt
zimage
zImage.recovery

Der Bootloader bekam als Root-Dateisystem:

root=PARTUUID=338c080c-02

Das Debian-System selbst entstand mit debootstrap.

Bis hierhin sah alles nach einer relativ gewöhnlichen Installation auf etwas ungewöhnlicher Hardware aus.

Und tatsächlich:

Debian 12 startete von der SATA-SSD.

Damit hätte die Geschichte eigentlich zu Ende sein können.

Debian 12 läuft

Bild 2: Debian auf der Novena. Der moderne Userspace läuft, doch ein Blick auf die Kernelversion offenbart den entscheidenden Haken: Unter dem aktuellen Debian arbeitet noch immer der Novena-Kernel aus dem Jahr 2015.

Auf den ersten Blick sah das Ergebnis genau so aus, wie ich es mir vorgestellt hatte: ein aktuelles Debian auf der Novena.

Doch bei der Kontrolle des laufenden Systems fiel etwas auf, das aus dem vermeintlich abgeschlossenen Debian-Upgrade ein wesentlich größeres Projekt machen sollte.

Der Userspace war neu.

Der Kernel war es nicht.

Das neue Debian lief weiterhin mit:

Linux novena 3.19.0-00485-gc5f2138

Damit hatte ich zwar einen modernen Debian-Userspace auf der SATA-SSD, darunter arbeitete aber noch immer der alte Novena-Kernel von 2015.

Technisch war das durchaus interessant.

Es zeigte nämlich, dass sich ein aktuelles Debian nicht grundsätzlich an der alten Novena-Hardware störte. Ein großer Teil des Systems funktionierte problemlos.

Aber es war nicht das Ergebnis, das ich eigentlich haben wollte.

Ich wollte wissen, ob die Novena auch mit einem modernen Kernel vollständig funktionieren kann.

Und genau an dieser Stelle begann das eigentliche Projekt.

Warum nicht einfach den Debian-Kernel installieren?

Die naheliegende Antwort lautete zunächst:

Dann nimm eben den aktuellen Debian-Kernel für ARM.

So einfach war es allerdings nicht.

Bei den ersten Versuchen mit einem neueren Debian-Kernel – unter anderem aus der 6.1er-Reihe – wurde schnell deutlich, dass zwischen

„Linux unterstützt ARMv7“

und

„dieser Kernel bootet auf einer Novena vollständig“

ein erheblicher Unterschied besteht.

Plötzlich spielten Dinge eine Rolle, die beim funktionierenden alten System kaum sichtbar gewesen waren:

• Welche Treiber sind fest in den Kernel eingebaut?
• Welche liegen nur als Module vor?
• Wann steht das SATA-Gerät zur Verfügung?
• Kann der Kernel das ext4-Root-Dateisystem bereits beim Booten erreichen?
• Wird eine initrd benötigt?
• Ist sie im richtigen Format vorhanden?
• Stimmen Kernel, Device Tree und Bootparameter zusammen?
• Welche Hardwarebeschreibung erwartet der neue Kernel?

Ein falscher Parameter oder ein fehlender Treiber konnte bedeuten, dass der Kernel zwar startete, das Root-Dateisystem aber nie fand.

Oder dass der Bootvorgang an einer Stelle stehen blieb, an der ich zunächst überhaupt nicht erkennen konnte, warum.

Denn zu diesem Zeitpunkt fehlte mir noch etwas Entscheidendes.

Ohne serielle Konsole bleibt vieles unsichtbar

Zu Beginn meiner Versuche hatte ich keinen brauchbaren Zugriff auf die serielle Konsole der Novena.

Das machte die Fehlersuche erheblich schwieriger.

Wenn der Bildschirm schwarz blieb, konnte das praktisch alles bedeuten:

• U-Boot hatte den Kernel nicht geladen.
• Der Kernel war gestartet und sofort abgestürzt.
• Der Device Tree war falsch.
• Das Root-Dateisystem wurde nicht gefunden.
• Das Display war lediglich noch nicht initialisiert.
• Das System lief vielleicht sogar weiter, ohne dass etwas zu sehen war.

Ein schwarzer Bildschirm ist kein besonders aussagekräftiges Diagnosewerkzeug.

Damit wurde klar, dass ich die Novena nicht einfach wie einen gewöhnlichen PC behandeln konnte.

Ich musste verstehen, wie sie bootet.

Und dafür musste ich weiter zurückgehen.

Ein Hinweis aus der Vergangenheit: Linux 5.7

Bei der Suche nach früheren Arbeiten an moderneren Novena-Systemen stieß ich auf etwas sehr Interessantes.

Es existierte bereits ein deutlich neuerer Kernel für die Novena:

Linux 5.7.0-rc2

Er stammte aus früheren Arbeiten rund um NixOS und Novena.

Noch wichtiger:

Ein historisches NixOS-System mit diesem Kernel hatte nachweislich vollständig bis zum Login gebootet.

Das änderte die Fragestellung.

Bis dahin hätte man vermuten können, dass die Novena praktisch an ihrem alten Linux-3.19-Kernel hängt, weil dort spezielle Hardwareunterstützung vorhanden ist, die später verloren ging.

Linux 5.7 zeigte jedoch:

Das konnte nicht die ganze Erklärung sein.

Die Hardware war grundsätzlich mit einem wesentlich moderneren Kernel betreibbar.

Also musste es möglich sein herauszufinden, welche Unterschiede zwischen den funktionierenden und den nicht funktionierenden Systemen entscheidend waren.

Aus einem Installationsproblem wurde langsam ein Vergleichsproblem.

Ich hatte jetzt mindestens zwei interessante Referenzpunkte:

Linux 3.19   → bekannt funktionierendes Debian-System
Linux 5.7    → bekannt funktionierendes NixOS-System

Und daneben standen die Versuche mit wesentlich neueren Kerneln.

Damit begann eine Spurensuche durch mehrere Generationen der Novena-Software.

Die serielle Konsole verändert alles

Später bekam ich schließlich Zugriff auf die serielle Konsole.

Das war einer der wichtigsten Wendepunkte des gesamten Projekts.

Plötzlich bestand ein fehlgeschlagener Boot nicht mehr aus:

Bildschirm bleibt schwarz

sondern aus einer nachvollziehbaren Abfolge:

U-Boot
↓
Kernel laden
↓
Device Tree laden
↓
Bootparameter
↓
Starting kernel ...
↓
Kernelmeldungen
↓
Treiberinitialisierung
↓
Root-Dateisystem
↓
Userspace

Damit ließ sich erstmals sauber unterscheiden, wo ein Fehler tatsächlich entstand.

Und auch die vorhandenen Bootwege der Novena wurden klarer.

Heute kann ich für meine Maschine drei wichtige Fälle unterscheiden:

externe SD-Karte eingesetzt
        ↓
Testsystem auf externer SD

keine externe SD-Karte
        ↓
System auf SATA-SSD

User-Taste beim Einschalten
        ↓
interner MMC-/Recovery-Pfad

Gerade für experimentelle Kernel ist diese Trennung ausgesprochen praktisch.

Ein Testsystem kann auf einer externen SD-Karte liegen, während das bekannte funktionierende System auf der SATA-SSD erhalten bleibt.

Damit wurde die Novena zu einer wesentlich angenehmeren Experimentierplattform.

Vom alten Rechner zur untersuchbaren Plattform

Damit veränderte sich auch meine Sicht auf die Novena.

Ich hatte nicht mehr einfach einen alten Rechner vor mir, auf dem ein neueres Betriebssystem installiert werden sollte.

Vor mir lag eine Plattform, deren Bootloader, Kernel, Device Tree und Hardware zusammenspielen mussten – und bei der ein Fehler in einer dieser Schichten den gesamten Start verhindern konnte.

Bild 3: Die Novena von der Seite. Schon die Konstruktion unterscheidet sich deutlich von einem gewöhnlichen Notebook: Display, Rechnerplatine, Massenspeicher und weitere Komponenten bleiben zugänglich. Die Maschine ist nicht nur zum Benutzen, sondern auch zum Verstehen und Verändern gebaut.

Genau an diesem Punkt begann sich eine Eigenschaft auszuzahlen, wegen der Novena ursprünglich überhaupt entwickelt worden war:

Die Maschine lässt sich untersuchen.

Es existieren Schaltpläne.

Es existieren alte Kernelquellen.

Es existieren Device Trees.

Es existieren historische Patches.

Es existieren U-Boot-Quellen.

Und es existieren Spuren früherer Entwickler, die viele der gleichen Hardwarekomponenten bereits zum Laufen gebracht hatten.

Ein Rechner, dessen kommerzieller Lebenszyklus längst beendet ist, kann dadurch technisch erstaunlich lebendig bleiben.

Ausprobieren reicht nicht mehr

Mit zunehmender Zahl der Kernel- und Bootversuche entstand allerdings ein neues Problem.

Wenn man nur lange genug verschiedene Kernel, Device Trees, Bootparameter und Images ausprobiert, verliert man irgendwann den Überblick.

War dieser Kernel schon getestet?

Mit welchem Device Tree?

War das die Version mit initrd?

Kam der Fehler vor oder nach Starting kernel ...?

War das Image tatsächlich auf der Novena getestet worden oder nur erfolgreich gebaut?

Genau an diesem Punkt änderte sich auch meine Arbeitsweise.

Tests sollten von nun an möglichst nach demselben Muster ablaufen:

Beobachtung
    ↓
Hypothese
    ↓
kleinstmögliche Änderung
    ↓
Build
    ↓
Test auf der realen Novena
    ↓
Log / Messung
    ↓
Dokumentation

Das klingt selbstverständlich.

In einem Projekt, das sich über Wochen und viele Builds erstreckt, ist diese Trennung aber entscheidend.

Ein erfolgreich kompilierter Kernel ist noch kein funktionierender Kernel.

Ein bootfähiges Image ist noch kein getestetes Image.

Und eine plausible Erklärung ist noch keine nachgewiesene Ursache.

Diese Unterscheidung sollte später noch sehr wichtig werden.

Warum plötzlich NixOS interessant wurde

NixOS war zunächst gar nicht mein eigentliches Ziel.

Ich wollte Debian aktualisieren.

Doch durch den funktionierenden Linux-5.7-Stand tauchte NixOS immer wieder in der Geschichte auf.

Und irgendwann wurde eine Eigenschaft davon für das Projekt besonders interessant:

Reproduzierbarkeit.

Wenn ich einen funktionierenden Zustand erreiche, möchte ich später nachvollziehen können:

• welcher Kernel verwendet wurde,
• welche Kernelkonfiguration aktiv war,
• welcher Device Tree benutzt wurde,
• welche Patches angewendet wurden,
• welche Bootdateien zum Image gehörten,
• und wie sich exakt dieser Zustand erneut bauen lässt.

Damit entstand langsam eine zweite Zielsetzung.

Nicht nur:

Einen modernen Kernel auf meiner Novena zum Laufen bringen.

Sondern:

Ein reproduzierbares System bauen, das sich auch auf einer anderen Novena verwenden lässt.

Die Idee eines universellen Novena-Images war geboren.

Aber bevor es so weit kommen konnte, musste erst einmal geklärt werden, was die verschiedenen Kernelgenerationen eigentlich voneinander unterschied.

Mensch, Maschine und Analysewerkzeug

Bei der späteren Untersuchung kam noch ein weiteres Werkzeug hinzu: ChatGPT.

Nicht als Ersatz für die Tests auf der Hardware.

Die entscheidenden Ergebnisse entstehen weiterhin auf der echten Novena.

Sie bootet – oder sie bootet nicht.

Ein I²C-Transfer funktioniert – oder er schlägt fehl.

Ein Display zeigt ein Bild – oder es bleibt dunkel.

Diese Beobachtungen kann kein Sprachmodell ersetzen.

Hilfreich wurde die KI dagegen an anderen Stellen:

• lange Bootlogs vergleichen,
• Unterschiede zwischen Kernelständen strukturieren,
• Hypothesen aus Beobachtungen ableiten,
• Tests so formulieren, dass sie eine konkrete Hypothese widerlegen können,
• Quellcode aus verschiedenen Kernelgenerationen gegenüberstellen,
• Build- und Testschritte dokumentieren,
• und darauf achten, dass aus einer Vermutung nicht versehentlich eine vermeintliche Tatsache wird.

Die Rollen sind damit ziemlich klar verteilt:

Die reale Novena entscheidet, was tatsächlich funktioniert.

Die Analysewerkzeuge helfen dabei herauszufinden, warum.

Aus einem Debian-Upgrade wird ein Forschungsprojekt

Rückblickend war die erste erfolgreiche Debian-12-Installation auf der SATA-SSD deshalb weniger das Ende eines Projekts als dessen eigentlicher Anfang.

Sie bewies:

aktueller Debian-Userspace
+
alte Novena-Hardware
=
grundsätzlich funktionsfähig

Aber sie warf gleichzeitig die wichtigere Frage auf:

aktuelle Novena-Hardware
+
moderner Linux-Kernel
=
?

Linux 3.19 funktionierte.

Linux 5.7 hatte funktioniert.

Neuere Kernel waren grundsätzlich verfügbar.

Also musste irgendwo zwischen diesen Versionen nachvollziehbar sein, welche Teile der Novena-Unterstützung vorhanden waren, welche verändert wurden und welche möglicherweise nie im Mainline-Kernel gelandet waren.

Aus

„Ich installiere Debian 12“

war damit endgültig

„Ich rekonstruiere die Linux-Unterstützung einer offenen ARM-Plattform über mehr als zehn Jahre Kernelentwicklung“

geworden.

Und genau dort beginnt der nächste Teil.

Wie es weitergeht

Im zweiten Teil geht es um die drei Kernelgenerationen, die für die weitere Untersuchung entscheidend wurden:

Linux 3.19
    ↓
die alte funktionierende Novena-Referenz

Linux 5.7
    ↓
der Beweis, dass ein wesentlich modernerer Kernel funktioniert

Linux 6.x
    ↓
der Weg zu einer heutigen, reproduzierbaren Novena

Dabei geht es nicht nur darum, ob ein Kernel startet.

Wir schauen uns an, warum manche Versuche scheiterten, welche Rolle initrd, Root-Dateisystem, Device Tree und Bootparameter spielten und warum die serielle Konsole die Untersuchung grundlegend veränderte.

Und vor allem:

Was braucht eine Novena im Jahr 2026, um mit einem modernen Linux-Kernel vollständig zu funktionieren?

Weiter in Teil 2: Drei Kernelgenerationen – Auf der Suche nach der modernen Novena

Quellen und weiterführende Links

Titelbild: https://www.bunniestudios.com/blog/2014/make-article-on-novena/

Novena und ihre Entstehung

• Andrew „bunnie“ Huang – Beiträge zu Novena und Open Hardware:
  https://www.bunniestudios.com/blog/tag/novena/

• Andrew „bunnie“ Huang – Crowdfunding the Novena Open Laptop (2014):
  https://www.bunniestudios.com/blog/2014/crowdfunding-the-novena-open-laptop/

• Andrew „bunnie“ Huang – Novena Update (2014):
  https://www.bunniestudios.com/blog/2014/novena-update/

• Kosagi Wiki – Novena Main Page:
  https://www.kosagi.com/w/index.php?title=Novena_Main_Page

• Crowd Supply – Novena Open Laptop:
  https://www.crowdsupply.com/sutajio-kosagi/novena

Projektinterne Quellen

Die technischen Aussagen zu den eigenen Boot- und Kerneltests beruhen auf den während des Projekts gesicherten seriellen Bootlogs, Kernelständen, Device Trees, Images, Git-Ständen und der fortlaufenden Projektdokumentation.

Dazu gehören insbesondere die Dokumentation der Kerneltests, der Bootpfade und des reproduzierbaren Novena-Images sowie die erhaltenen historischen NixOS-/Novena-Artefakte.