Flight Simulator 2020 Top oder Flop? Review [Kommentar]

Nach dem Hype um den Flight Simulator 2020, den man in den letzten Tagen auf diversen Internetseiten gefunden hat, musste man meinen man verpasst das Spiel (pardon Simulation, ach was im Store nennt Microsoft es selbst Spiel, somit bleibe ich dabei) des Jahrhunderts, wenn man ihn nicht hat.

Gerade in Zeiten von Corona, wo das Reisen doch arg eingeschränkt ist oder man es den Unbelehrbaren überlässt die Infektionszahlen wieder deutlich nach oben zu treiben, reizt es natürlich sehr sich virtuell durch die Welt zu bewegen. Da ich zusätzlich auch noch Urlaub habe konnte auch ich mich nicht beherrschen.

Flight Simulator 2020 - High Sierras

Flight Simulator 2020 – High Sierras

Normalerweise kaufe ich keine Vollpreisspiele mehr, sondern warte ein paar Jahre bis sie deutlich günstiger und mit Patches versehen sind. So ändern sich die Zeiten. Beim FS 2020 hat die Neugierde aber gesiegt.

Der Weg ein langer zum FS 2020 es ist hätte Joda wohl gesagt

War es das Wert? Bedingt.

Flight Simulator 2020 - High Sierras

Flight Simulator 2020 – High Sierras

Zuerst mal ist die Größe des Spiels beachtlich. Für die Installation werden ca. 130GB benötigt (bitte auf SSD, sonst hat man graue Haare, bevor das Spiel geladen wurde). Ich hatte die DVD Version bestellt, wo man erst mal zum Disc Jockey wird. Ganze 10 DVDs bekommt man in dem Paket.

Problem eins: Im Notebook hatte ich kein DVD Laufwerk, optische Laufwerke hat man ja heute kaum noch. Also erst mal 10 DVDs zu Images verarbeiten, dann die Images vom einen Rechner auf den anderen Kopieren und dann noch installieren. Da ist man schnell mal drei Stunden älter.

Flight Simulator 2020 - Mount Whitney Bereich

Flight Simulator 2020 – Mount Whitney Bereich

Wenn man dann die Installation beendet hat, steht man erst mal etwas ratlos da. Denn installiert danach ist kein funktionsfähiges Programm, sondern nur die Weltdaten. Zusätzlich muss man noch die App auf dem Microsoft App Store installieren, also muss man zwangsweise erst mal eine Registrierung bei Microsoft durchführen. Danach wird dann zwangsweise noch ein XBox whatever Konto erstellt und dann darf man theoretisch downloaden.

Nicht so auf meinem Notebook. Dort kam nur die Meldung, dass aktuell ein Problem bei Microsoft vorliegt und ich es später versuchen soll. Ich dachte mir schon, dass das nichts temporäres ist und das die Fehlermeldung irreführend ist. Man kennt ja Microsoft so langsam…

Flight Simulator 2020 - Mount Whitney Bereich

Flight Simulator 2020 – Mount Whitney Bereich

Die Lösung war die Installation der neusten Windows Version (auf dem Notebook war 1909 installiert, also locker neu genug lt. FS Voraussetzungsliste). Das  Installieren der aktuellen Windows Version ging natürlich auch nicht problemlos. Erst mal gab es zwei Fehlversuche beim Upgrade bis es gelungen ist (für alle die es interessiert ich habe danach sämtliche alte Hardware im abgesicherten Modus entfernt und die Systemdatein per Kommando reparieren lassen), das waren glaube ich in Summe noch mal rund 5 Stunden und juchu danach ließ sich die App sogar installieren (ca. 1GB).

Flight Simulator 2020 - Mount Whitney

Flight Simulator 2020 – Mount Whitney

Anschließend stehen natürlich direkt mal 16GB Patches bereit (und das direkt in Version 1 – in einem Jahr darf man dann wahrscheinlich gleich 100GB neu laden).

Ihr merkt also schon – eine gute Internetverbindung ist Pflicht, auch aus anderen Gründen, wie man später noch erkennt.

Der erste Sturzflug

Zuerst habe ich für eine schnelle Proberunde versucht mit Maus und Tastatur zu spielen. OMG. Mehr gibt es dazu nicht zu sagen. In einem Review stand, dass sich das Spiel mit Maus und Tastatur recht gut spielt. Das kann ich so nicht bestätigen. Das kann nur Wunschdenken gewesen sein. Ich bin nicht mal von der Landebahn weggekommen, da hatte ich den Flieger schon versenkt.

FS 2020 - Angebliche Schutzhütte auf Mount Whitney

FS 2020 – Angebliche Schutzhütte auf Mount Whitney (da steht eine aber die sieht etwas anders aus)

Flight Simulator 2020 - Mount Whitney

Flight Simulator 2020 – Mount Whitney

Zu Vergleichszwecken die Realität, die leider von Fotos auch nur unzureichend eingefangen wird (alles was oben grün ist sind blanker Fels und auch deutlich steiler als oben dargestellt und mit viel mehr Konturen):

Mount Whitney

Mount Whitney (der linke Teil von den beiden Seen entspricht dem oberen)

Mount Whitney

Mount Whitney

Mount Whitney

Mount Whitney

Also habe ich den Thrustmaster HOTAS entstaubt und angeschlossen und siehe da, easy going. Fliegen kann so einfach sein. Den Thrustmaster hatte ich eigentlich mal für Star Citzen gekauft. Das ein paar Jahre später den FS 2020 damit spiele noch bevor Star Citizen erscheint war auch nicht geplant. Die 4 Buttons und 4 Mehrwegeschalter (4-8 Wege je Schalter) bekommt man übrigens selbst mit einem Kleinflugzeug problemlos belegt.

Flight Simulator 2020 - Yosemite Valley?

Flight Simulator 2020 – Yosemite Valley?

Nach längerem Suchen bin ich dann doch noch fündig geworden (die Dronencam war die Lösung – die Dronencam erlaubt Bewegungen unabhängig vom Flugzeug und mit beliebiger Geschwindigkeit):

FS 2020 - Half Dome Rückseite

FS 2020 – Half Dome Rückseite

Half Dome Rückseite Original

Half Dome Rückseite Original

FS 2020 - Yosemite Valley

FS 2020 – Yosemite Valley

Original Yosemite Valley

Original Yosemite Valley

FS 2020 - Weichspülen von Bergen

FS 2020 – Weichspülen von Bergen

Yosemite Valley Original

Yosemite Valley Original

Ok, dann ab in die Flugschule und mit dem HOTAS (Hands on Throttle and Stick, wobei ich nur den Stick habe) spielen sich alle Flugmanöver sehr einfach, Start, Landen, Navigieren, alles kein Ding. Lediglich Seitenruderpedale wären noch hilfreich aber mit dem Thrustmaster und der Target Software bekommt man die Achse auch recht gut über Tasten abgebildet.

Ab in die Sierras

Nachdem ich die Flugschule durch hatte war ich heiß wieder in die High Serras zu kommen. Nach meinem PCT Besuch werde ich von den Sierras wohl nie wieder los kommen.

Flight Simulator 2020 - Epcot von oben mit 3D Modellen (nicht zu Tief gehen, dann sieht es klasse aus)

Flight Simulator 2020 – Epcot von oben mit 3D Modellen (nicht zu Tief gehen, dann sieht es klasse aus)

Nach dem Start in Lone Pine bin ich zuerst beeindruckt, sogar auf dem “Flughafen” irgendwo im nirgendwo sind Gebäude vorhanden, sogar mit Satellitenschüsseln auf dem 3D Modell. Der Anflug auf die Sierras lässt erste Ernüchterung aufkommen. Vom Fotorealismus, den einige Reviewer hinaus beschwören ist selbst in der Ultra Stufe rein gar nichts zu sehen.

Flight Simulator 2020 - Gelandet in Epcot - eher hässlich

Flight Simulator 2020 – Gelandet in Epcot – eher hässlich

Die ersten 3 Anläufe in die High Sierras zu fliegen sind an der Wahl des Flugzeugs gescheitert. 14500 Fuß sind offenbar eine Hausnummer. Schon beeindruckend, was der menschliche Körper so alles leisten kann, wenn nicht mal Flugzeuge für mehrere hundert tausend Dollar oder sogar im Millionenbereich dort ankommen.

Auch wenn die Flugzeuge eine Reiseflughöhe von bis zu 20.000 Fuß hatten sind sie alle kläglich gescheitert. Es wird also nicht nur bei Autos das Blaue vom Himmel versprochen. Klar, wenn man den Copiloten rausschmeißt, den Tank leer macht und die richtigen Windverhältnisse hat, dann kommt man ggf. auf die Höhe. Ggf. hätte ich auch das Gemisch noch anders einstellen können, die Idee ist mir aber erst später gekommen (dazu verliert die Flugschule natürlich auch kein Wort, genauso wie zum Autopiloten usw.).

Flight Simulator 2020 - Hollywood Studios - Toy Story fehlt, Star Wars fehlt, der Disney Hut ist noch vorhanden - Veraltet

Flight Simulator 2020 – Hollywood Studios – Toy Story fehlt, Star Wars fehlt, der Disney Hut ist noch vorhanden – veraltet um mindestens 3 Jahre

Mein Ziel war der Mount Whitney (der höchste Berg von den USA abseits von Alaska), den ich letzte Jahr erklettert hatte (zumindest fast bist oben, ein paar hundert Fuß fehlten noch, bevor mich die Übelkeit befiel – Höhenkrankheit, überanstrengt oder ggf. was anderes).

Ich habe mich übrigens direkt noch mal geärgert als ich nun im FS gesehen habe wo ich abgebrochen habe. Ich war vielleicht noch 500m vom Gipfel weg. 🙁 Vor Ort war das leider keineswegs so gut ersichtlich. Derartige Analysen gehen mit dem FS 2020 übrigens super. Mehr dazu auch im Grand Canyon.

Mit dem 4. Flugzeug (reichlich overpowered aber noch ohne Turbine) ging es dann endlich zum Whitney – auch das war recht ernüchternd. Auch wenn man zumindest den Zig Zag Weg hinauf erkennt, ist von der Schönheit der Landschaft rein gar nichts zu sehen.

Bei Mount Whitney lässt sich aufgrund des Sees und des Aufstiegsweges aber recht leicht erkennen, das ich an der richtigen Position ist. Es gibt bei Mount Whitney zwar auch kein gutes Modell der Schutzhütte auf dem Gipfel (da steht ein Haus aber mit Satellitenschüssel – das entspricht nicht ganz der Wahrheit), aber immerhin lässt sich die Position recht gut bestimmen. Das Konzept setzt sich überall fort wo keine manuellen eingriffe erfolgen, wenn ich das richtig sehe. Wer zum Beispiel das eigene Haus sucht wird feststellen, dass der Grundriss zwar dem Original entspricht aber die komplette Textur, Fenster, Türen, Treppen sind frei erfunden. Das dürfte für 99% der Gebäude im FS 2020 zutreffen. Gebäude wie zum Beispiel in Disney und Vegas sind manuell Designt, wenn sie realistisch aussehen. Bei Disney trifft das aber auch nur auf markante Strukturen zu (beispielsweise der World Show Case – mal mit mehr oder weniger Sorgfalt – oder die Epcot Weltkugel, nicht aber die Mainstreet.

Flight Simulator 2020 - Epcot Testtrack und ein Teil vom World Showcase

Flight Simulator 2020 – Epcot Testtrack und ein Teil vom World Showcase und Mexiko (das Gebäude unten – schon witzig, wenn man mal im Park war und wie beeindruckend das von vorne aussieht und wie simpel die Halle dahinter von oben aussieht), dahinter Norwegen und China

Bei Mount Whitney sind die Farben teilweise falsch und die Berge arg weichgespült (abgerundet). Somit wirkt die Darstellung nicht wirklich echt. Wegen der teilweise falschen Texturfarben stellt sich die Frage, ob wirklich alles auf Satellitenaufnahmen basiert, oder zum Teil generiert ist.

Die Höheninformationen scheinen nur in den Eckdaten zu passen. D.h. ich gehe davon aus, dass die Informationen eher Höhenlinien einer Karte entnommen wurden und nicht die realen Konturen abbilden.

Am eigenen Haus (das zu finden hat mich ganze 5 Minuten gekostet, da wir einen kleinen Flugplatz im Ort haben) lässt sich auch gut nachvollziehen, dass eben nicht überall Satellitenaufnahmen benutzt werden, wie ich schon in den Sierras vermutet habe. Ganze Wege neben Gebäuden sind um unser Haus einfach Grünflächen (das sind keine offiziellen Wege), Bäume stehen überall ums Haus, obwohl kein einziger da steht.

D.h. die komplette Textur ist um unser Haus generiert und hat nichts mit Satellitenaufnahmen zu tun (oder die generierten Grasflächen / Bäume / Sträucher überblenden in dem Fall einfach die Satellitenaufnahme). Auch der Baum und Strauchbewuchs ist generiert. Die hässlichen Bäume und Sträucher (siehe Epcot oder Florida Keys), die wie Felsen aussehen, findet man dort, wo sie nicht generiert wurden. Dort ist dann die Basis scheinbar eine Satellitenaufnahme.

Das Haus ist abseits der Grundrisses frei erfunden, das gilt auch für alle umstehenden.

Somit mussten die Entwickler sich offenbar zwischen Pest und Cholera entscheiden. Satellitenaufnahme = gibt die reale Umgebung wieder aber eben nur von oben. Diese Variante bildet zum Beispiel auch nicht offizielle Wege ab. Die Zweite Variante “manuelles Eingreifen” erfordert Aufwand (z.B. Vegas, wo sogar die Werbung wie zum Beispiel Beatles Musical usw. passt) oder eben Variante 3 “generierte Welt” was zwar zu schönen Bäumen, Sträuchern, Grasbewuchs führt und wenig Speicherplatz belegt, aber eben nur in den Grundrissen der Realität entspricht.

Letzte Variante kommt sowohl um Mount Whitney, dem Grand Canyon als auch in Yosemite zum Einsatz. Wie die Wanderwege dort aufgezeigt werden ist mir noch nicht ganz klar, aber ich vermute die sind auch generiert und basierend nicht auf Satellitenaufnahmen. Auch Wanderwege sind ja auf Karten verzeichnet. Auf Bergen wiederum sehen die Farbpatches teilweise nach Satellitenaufnahmen aus, die dann aber teilweise fälschlicherweise mit Rasentexturen oder Bäumen / Sträuchern angereichert werden, wo in der Realität keine sind.

Somit wechselt der FS 2020 ständig zwischen sehr hohem Realitätsgrad und vollständiger Fiktion.

Flight Simulator 2020 - Epcot Wold Showcase - Komische Bäume, oder?

Flight Simulator 2020 – Epcot Wold Showcase – Komische Bäume, oder? Typisches Beispiel für aus einer Satellitenaufnahme entstandene 3 Baum Modelle

Weiter nach Yosemite Valley. Im ersten Anlauf war ich mir nicht sicher, ob ich es gefunden habe bzw ob ich richtig bin. Mangels Koordinaten ist das nicht immer so einfach. In dem Kontext hilft die Satellitenkamera deutlich um Ziele zu finden. Im zweiten Anlauf konnte ich dann Half Dome, Visitor Center, Campigplatz vor dem Halfdome usw. bestimmen.

Flight Simulator 2020 - Epcot World Showcase

Flight Simulator 2020 – Epcot World Showcase (Japan, Marokko)

Navigation?

Abseits von drei vorgegeben Karten und vorgegeben Zielen kann man die Navigation quasi vergessen. Man kann nur sehr kompliziert Koordinaten eingeben (z.B. von Google ermitteln und dann im Suchfeld eingeben – nähe Mount Everest z.B. 27°58’57.0″N 86°54’59.0″E – da der FS aber gerne abstürzt, wenn man raustabt sollte man die Koordinaten vorher im Zwischenspeicher haben) und Landmarks wie Mt. Whitney oder Yosemite Valley gibt es schlicht nicht als Text oder Marker auf der Karte.

Somit muss man entweder mit vom Spiel vorgegeben Zielen navigieren oder auf Sicht (Straßen, Flüsse, Seen, Berge). Letzteres (Seen) habe ich sowohl für die Identifikation von Yosemite als auch Mount Whitney genutzt.

Flight Simulator 2020 - Magic Kingdom von oben ohne 3D Modelle

Flight Simulator 2020 – Magic Kingdom von oben ohne 3D Modelle

Man kann lediglich von (zugegebenermaßen) vielen vorgegeben Punkten zu vorgegebenen anderen Punkten fliegen (also A / B). Mehr geht nicht. Der ist erstaunlich wenig für einen Simulator. Zumal es sicher kein großer Aufwand gewesen wäre Koordinaten zu erlauben oder Punkte auf der Karte anzuklicken und Zwischenwegpunkte zu setzen. Somit wirkt der Flight Simulator 2020 recht schnell hingeschustert.

Grafikhype trifft auf Realität

Nachdem Yosemite und Mt. Whitney eher enttäuschend waren, kann ich schon mal ein Fazit ziehen: Dort wo es keine 3D Modelle gibt sollte man deutlich Abstand vom Boden halten. Sonst sieht die Grafik nicht gut aus. Das sorgt auch dafür, dass die weichgespülten Berge weit weniger auffallen.

Flight Simulator 2020 - Magic Kingdom von oben mit 3D Modellen

Flight Simulator 2020 – Magic Kingdom von oben mit 3D Modellen

Naturexpeditionen streiche ich also komplett von der Feature Liste des FS 2020.

Somit lag als nächstes ein Besuch in Disney World Florida nahe. Die Parks kenne ich gut und wenn es irgendwo 3D Objekte gibt, dann wohl in den meistbesuchten Freizeitparks der Welt, oder?

Für die 3D Objekte benötigt es übrigens die oben bereits erwähnte gute Internetverbindung. Ohne Internetstreaming kann man zwar um die ganze Welt fliegen! aber abseits von landschaftlichen Erhebungen ist die Welt flach. Gebäude sind nur eine Textur auf dem Boden.

Flight Simulator 2020 - Magic Kingdom

Flight Simulator 2020 – Magic Kingdom

Erst das Streaming versieht die Welt mit 3D Objekten. Der erste Flug über Epcot – durchaus beeindruckend. Zu nah ran gehen sollte man aber nicht. Selbst mit 3D Objekten empfiehlt sich eine Mindesthöhe von 1000 Fuß. Ansonsten wird es unschön. Das ist übrigens auch bei der Grafikeinstellung Ultra so, die sorgt zwar für schöneres Wasser und bessere Beleuchtung aber am Boden wird dadurch nichts besser. Die Qualität der Satellitenaufnahmen ist aber der größte Schwachpunkt in Bezug auf Tiefflug.

Flight Simulator 2020 - Magic Kingdom Main Street. Da schüttelt es einen, oder?

Flight Simulator 2020 – Magic Kingdom Main Street. Da schüttelt es einen, oder?

In Magic Kingdom hat die Internetverbindung zwischendurch nicht für die 3D Modelle gereicht und dann zeigt der FS 2020 sich von seiner richtig hässlichen Seite. Ich wusste, dass ich mich über Magic Kingdom befinde aber wirklich erkennen kann man es ohne 3D Modelle kaum.

Florida Keys

Im nächsten Schritt habe ich dann doch noch mal an anderer Stelle versucht, ob der FS 2020 Landschaft nicht doch kann und bin noch mal enttäuscht worden. Der Flug über die Florida Keys sollte eigentlich wunderschön sein. Abseits von matschigen Texturen und etwas Strandflair hielt sich die Schönheit aber in Grenzen. Die Anzahl der Fehler in dieser Region ist aber wirklich beeindruckend.

Flight Simulator 2020 - Florida Keys Der alte Highway versinkt im Meer (links neben dem neuen Highway)

Flight Simulator 2020 – Florida Keys Der alte Highway versinkt im Meer (links neben dem neuen Highway)

Der alte Highway an den Florida Keys wurde übrigens vollständig entfernt. Das Problem was die Entwickler hatten, war das Wasseraufnahmen vom Satelliten statisch sind und das bescheiden aussieht. Somit müssen sie Satellitenwasser durch Simulationswasser ersetzen. Dieser Ersetzung fällt eben allem zum Opfer was nicht Land ist. Den alten Highway sieht man nun immer wieder ins Wasser gehen und aus dem Wasser kommen aber als Straße existiert er nicht.

An einigen Stellen wurde das Wasser auch nicht ersetzt. Dort bekommt man dann statische Bote mit statischen Schaumkronen im Wasser zu sehen. Insgesamt war die Reise entlang der Keys eher ernüchternd (ganz im Gegensatz zum realen Erlebnis). Was ich allerdings auf dem Weg erfahren habe, dass es unterdessen Kreuzfahrtschiffanleger in Key West gibt, die es bei meinem letzten Besuch noch nicht gab.

Wasserfälle kann das Spiel übrigens überhaupt nicht darstellen. Die Niagara Fälle sehen einfach potthässlich aus. Zum Glück bin ich nicht selbst hin geflogen, sondern habe mir ein Video angesehen.

Flight Simulator 2020 - Florida Keys Generiert vs. Satellit

Flight Simulator 2020 – Florida Keys Generiert vs. Satellit

Da wären wir übrigens beim Punkt Aktualität. Wie auch bei Google sind die Satellitenaufnahmen teilweise mehrere Jahre alt. Wenn man Disney überfliegt bekommt man also einen mehrere Jahre alten Stand geboten. Sehr schön kann man das an den Hollywood Studios erkennen. Den Disney Hut im Park gibt es nicht mehr. Den Star Wars Bereich und auch den Toy Story Bereich gibt es im FS 2020 nicht. Beides ist aber schon seit mehreren Jahren im Bau oder beendet (Toy Story Land wurde 2018 eröffnet, die Aufnahmen sind also mindestens von 2017 oder älter).

Grand Canyon

In wenig bewaldeten Regionen lassen sich sogar Wanderwege bestimmen. Ich habe mir am Grand Canyon den Weg vom South Kaibab Trailhead zurück zum Bright Angel Trailhead angesehen auch da habe ich mich geärgert, dass ich letztes Jahr am Tip Off Point gestoppt habe. Es waren zwar 40°C und ich hatte nur noch begrenzt Wasser aber der Aufstieg war dann viel einfacher als befürchtet (ja, es war die vernünftige Entscheidung aber das ist ja nicht immer die beste).

FS 2020 - Grand Canyon Fotospotcheck

FS 2020 – Grand Canyon Fotospotcheck

Ich hätte ich mindestens zum Colorado runter gehen sollen oder im Optimalfall den zweiten Weg zum Bright Angel Trailhead wieder hoch. Wenn ich das richtig sehe, wäre ich wohl auch an das Wasser im Colorado ran gekommen und hätte auffüllen können (siehe Screenshot oben). Man muss allerdings vorsichtig sein, was im Flight Simulator wie flaches Terrain aussieht kann extrem felsig sein (Stichwort Weichspülen von Bergen). Das passiert selbst an Bergen wie dem Everest, die abseits ihrer Höhe aus der Nähe alle so gerundet aussehen, als wenn es sanfte Hügel wären. Davon sollte man sich nicht täuschen lassen.

FS 2020 - Grand Canyon Fotospotcheck

FS 2020 – Grand Canyon Fotospotcheck

Solche Dinge kann man sich mit dem FS 2020 super anschauen, vor allem in wenig bewaldeten Regionen. Es ist sogar möglich im Grand Canyon zu schauen welche Fotospots  gut sind (die Details und Schönheit der Landschaft kommt zwar nicht rüber aber zumindest was man von einem Ort in etwa sehen kann).

FS 2020 - Grand Canyon Wanderwegcheck Bright Angel Trail

FS 2020 – Grand Canyon Wanderwegcheck Bright Angel Trail

Im Grand Canyon klappt das hervorragend und hat mir gezeigt, dass ich da irgendwann noch mal hin muss. 😉 Dann mit zwei Tagen Zeit, dann geht es ganz gemütlich runter und wieder hoch. Das geht auch in einem Tag aber ist dann schon etwas anstrengender und man muss recht früh los.

FS 2020 - Grand Canyon Fotospotcheck - nicht so schlecht, oder? Kann man mal hinwandern

FS 2020 – Grand Canyon Fotospotcheck – nicht so schlecht, oder? Kann man mal hinwandern

Ich habe von Yosemite ein paar Beispiele von realem Foto und Screenshot in FS 2020 angefügt. Zumindest die Perspektive kann man damit ziemlich genau nachstellen.

Tops und Flops

Flight Simulator 2020 - Christo Statue von hinten - totaler fail - von vorne sieht sie übrigens top aus!

Flight Simulator 2020 – Christo Statue von hinten – totaler fail – von vorne sieht sie übrigens top aus! – Die Treppen oben sind alle frei schwebend in der Luft

Flight Simulator 2020 - New York die Freiheitsstatue top

Flight Simulator 2020 – New York die Freiheitsstatue top

Flight Simulator 2020 - New York Central Railroad of New Jersey Terminal eher flop (Ellis Island sieht übrigens noch schlimmer aus)

Flight Simulator 2020 – New York Central Railroad of New Jersey Terminal eher flop (Ellis Island sieht übrigens noch schlimmer aus)

Flight Simulator 2020 - New York One World Trade Center eher flop

Flight Simulator 2020 – New York One World Trade Center eher flop (die Form passt, die Textur ist schlecht)

Flight Simulator 2020 - New York Brooklyn Bridge eher top

Flight Simulator 2020 – New York Brooklyn Bridge eher top

Flight Simulator 2020 - New York New York Queensboro Bridge das spottet jeder Beschreibung fail

Flight Simulator 2020 – New York Queensboro Bridge das spottet jeder Beschreibung fail

Flight Simulator 2020 - New York das soll der Flugzeugträger sein. Ok, muss man wissen - flop

Flight Simulator 2020 – New York das soll der Flugzeugträger sein. Ok, muss man wissen – flop

Flight Simulator 2020 - Washington - Urks sieht das scheiße aus. Das soll der Obelisk in Washinton sein. Unten sieht man den echten Schatten aus der Satellitenaufnahme und das Hochhaus was drauf geworden ist - fail++

Flight Simulator 2020 – Washington – Urks sieht das gruselig aus. Das soll der Obelisk in Washington sein. Unten sieht man den echten Schatten aus der Satellitenaufnahme, das echte Objekt  und das Hochhaus was daraus geworden ist mit eigenem Schatten. Das passiert bei automatisch generierten Objekten – fail++

Flight Simulator 2020 - Washington - fail

Flight Simulator 2020 – Washington – fail

Flight Simulator 2020 - Washington Lincoln Memorial - top

Flight Simulator 2020 – Washington Lincoln Memorial – top

Flight Simulator 2020 - Washington Lincoln Memorial - top

Flight Simulator 2020 – Washington Lincoln Memorial – top

Flight Simulator 2020 - Washington White House - fail++

Flight Simulator 2020 – Washington White House – fail++

Flight Simulator 2020 - Sydney Opera House - Wow!

Flight Simulator 2020 – Sydney Opera House – Wow!

Flight Simulator 2020 - Sydney Harbour Bridge - Ernsthaft? Mega fail

Flight Simulator 2020 – Sydney Harbour Bridge – Ernsthaft? Mega fail

Flight Simulator 2020 - San Francisco Golden Gate - top

Flight Simulator 2020 – San Francisco Golden Gate – top

Flight Simulator 2020 - Sydney Lobard Street - eher top

Flight Simulator 2020 – Sydney Lobard Street – eher top

Flight Simulator 2020 - Istanbul - Hups, ist da wer nicht fotogen?

Flight Simulator 2020 – Istanbul – Hups, ist da wer nicht fotogen?

Flight Simulator 2020 - Istanbul Hagia Sophia - top

Flight Simulator 2020 – Istanbul Hagia Sophia – top

Flight Simulator 2020 - Sultan Ahmed Moschee - top

Flight Simulator 2020 – Sultan Ahmed Moschee – top

Flight Simulator 2020 - Kairo Pyramiden - top

Flight Simulator 2020 – Kairo Pyramiden – top zumindest optisch, da ich noch nicht dort war kann ich die Übereinstimmung mit der Realität nicht bewerten

Herausforderungen und Spielmodi

Was kann man denn im FS eigentlich machen? Nicht viel und doch alles lautet die Antwort. Nicht viel, weil es abseits der Flugschule (die übrigens rein das Fliegen betrachtet und nichts anderes. Keine Kommunikation, kein Auftanken, kein Navigieren auf dem Flugplatz) nur recht wenig Auswahl gibt.

Auch die diversen Möglichkeiten der Funktionen eines größeren Flugzeugs werden nicht erklärt. Wer also einen Airbus besteigt wird plötzlich mit massenhaft Funktionen konfrontiert, von denen er in der Flugschule im Kleinflugzeug nie etwas gehört hat. Auch Themen wie Treibstoffmix oder andere Einstellungen werden überhaupt nicht behandelt? Ein Nachtflug vergesst es. Ihr werdet schon selbst rausfinden was zu beachten ist.

Flight Simulator 2020 - Key West Versunkene Schiffe und Gebäude

Flight Simulator 2020 – Key West Versunkene Schiffe und Gebäude

Es gibt 3 vorgegeben Flüge durch die Landschaft (oben hatten ich bereits festgestellt, dass die Landschaftsflüge eher durchwachsen aussehen).

Ansonsten gibt es einige Landeherausforderungen auf einigen herausfordernden Flughäfen. Das hat man recht schnell abgearbeitet und ansonsten gibt es nur noch den Freiflugmodus, bei dem man sich um die ganze Welt bewegen kann. Es sind weltweit auch sehr sehr kleine Flugfelder vorhanden. Man kann im wahrsten Sinne irgendwo im nirgendwo starten.

Flight Simulator 2020 - Florida Keys

Flight Simulator 2020 – Florida Keys

Das eigentliche Potenzial das der FS zeigt ist die ganze Welt auf verhältnismäßig hohem Detaillevel zu simulieren (man stelle sich mal die ganze Welt mit Modellen wie dem Sydney Opera House oder dem Licoln Memorial vor).

An vielen Stellen wie z.B. bei Disney hat man Lust zu landen und mehr ins Detail zu gehen (wobei der FS dann gänzlich versagt, wenn die Modelle nicht manuell erzeugt wurden, gut dafür ist er auch nicht gemacht). Das wäre aber wirklich spannend. Wenn man sich in einem detaillierten Weltmodell bewegen kann und zwar egal ob mit Flugzeug, Auto, Zug oder wie auch immer.

Wie man sieht ist die Grundlage da, bis das aber wirklich auf “fotorealistischem” Niveau geht werden wohl noch einige Jahre (Jahrzehnte) ins Land gehen. Oder man muss Fotorealismus mit einem Mindestabstand von mehreren tausend Fuß definieren.

In so einem Weltmodell könnte man dann aber problemlos alle Arten von Simulationen abbilden. Vom Flight Simulator, über Truck, Train, Landwirtschafts- und sonstige Simulationen.

Die Technik

Die Engine ist schlicht nicht optimiert. Sie ist weder für Low Level Apis ausgelegt (nur DX11 statt 12 – DX11 ist 11 Jahre alt!) und auch ansonsten in jeder Hinsicht eher mau. Es werden maximal 6 Kerne unterstützt und die CPU stellt schnell das Limit dar in Auflösungen bis Full HD oder teilweise auch bis 2560 je nach Grafikkarte, obwohl die Kerne nicht mal voll ausgelastet sind. Erst bei hohen Auflösungen im Prinzip ab 4K läuft man mit modernen Grafikkarten ins CPU Limit. Das liegt allerdings daran, dass das die Engine nicht optimiert ist.

Es ist teilweise lustig wie andere Reviews das rechtfertigen. “Es wird die ganze Welt simuliert, da darf es doch etwas dauern / langsamer sein” So ein Quatsch. Jeder Simulator stellt nur den Bereich da, der gerade sichtbar ist und das auch noch in deutlich schlechterer Qualität, desto größer die Entfernung ist. Ob die ganze Welt oder nur eine kleine Region simuliert wird ist vollkommen irrelevant.

Viel relavanter ist zum Beispiel wie viele 3D Modelle z.B. in New York gleichzeitig sichtbar sind.

Die technische Umsetzung ist somit eher schwach und klar kann man das mit mehr Power richten. Man kann auch versuchen mit platten Reifen Auto zu fahren, mit viel PS geht viel. Mit der teuersten und am meisten Strom schluckenden Grafikkarte wird sogar der FS flott.

Der schnöde Mammon

Wo die Preisgestaltung hingeht zeigt Microsoft recht eindeutig. Es gibt bereits jetzt einige Downloadcontents, die alle maßlos überteuert sind. Ein Upgrade von der Standardversion auf die größeren Versionen? In etwa 100% teurer, als wenn man sie direkt erwirbt. Im Prinzip kann man das Spiel auch gleich neu kaufen, viel teurer ist es nicht. Ein weiteres Flugzeug 30€ oder ein Flughafen 20€ und mehr. Wohlgemerkt wir reden hier von EINEM Flughafen / Flugzeug.

Flight Simulator 2020 - Landen in Key West? Besser nicht. Haus und Baum sind unterhalb der Straße platziert

Flight Simulator 2020 – Landen in Key West? Besser nicht. Haus und Baum sind unterhalb der Straße platziert.

In Zukunft wird man also vermutlich von mittelmäßigem Content zu Unsummen von Geld überschwemmt werden. Das ist aus meiner Sicht besonders ein Thema weil die enthaltenen Flugmodi abseits des Freiflugs von einem vorgesehenen Punkt A zu einem vorgesehen Punkt B sehr überschaubar sind.

Das Werkzeug für Fotografen?

Ich prophezeie, dass der Flight Simulator 2020 ein unverzichtbares Werkzeug für Fotografen wird (vielleicht ein Geheimtip). Man kann schnell mal an die entlegensten Orte, an Fotospots reisen und schauen was man aus einer bestimmten Perspektive sieht (sogar mit simuliertem Sonnenstand zu einem bestimmten Tag / Uhrzeit). Ich glaube es gibt nichts was das bisher auch nur ansatzweise so bequem erledigt. Das ersetzt natürlich keineswegs das fotografische Auge aber man erkennt auch, dass sich manche Fotospots einfach viel eher anbieten als andere.

Ob nun Skylines, Luftaufnahmen oder an irgendwelchen Fotospots im Grand Canyon oder Yosemite. Man kann ruck zuck sehen was man aus der Perspektive in etwa sehen kann. Ggf. im weg stehende Bäume usw kann man natürlich nicht berücksichtigen aber Berge und andere Prägnante Objekte passen erstaunlich genau.

Lediglich die Navigation ist in dem Kontext wieder ein Problem. Manchmal dürfte es erst gelingen einen bestimmte Stelle zu finden, wenn man schon vor Ort war. Das ist natürlich ziemlich sinnlos. Oder man muss die Koordinaten direkt von z.B. Google kopieren.

Fazit:

Der FS 2020 sorgt für einige wow Erlebnisse. Die Möglichkeit sich weltweit an jeden Ort zu bewegen ist auf dem Detaillevel ziemlich beeindruckend (ich glaube Abseits von Google Earth ist das soweit ich weiß der erste Weltsimulator mit ansatzweise passablem Detaillevel). Anderseits stößt man sehr schnell an die Grenzen, wenn man zu sehr in das Detail geht.

Von kaputten Bäumen, die wir Felsen aussehen, versunkenen Häusern, fliegenden Autos, Baumkronen auf Straßenniveau ist alles dabei. Danach braucht man auch nicht suchen. Das springt einen überall an. Auch Landen ist an Orten mit 3D Objekten an vielen Stellen zum Scheitern verurteilt. Man bleibt an allem möglichen hängen. Das sind keine Einzelfälle. Die Ganze Region der Florida Keys / Key West kämpft mit falschen Höheninformationen (man sollte meinen, wenn sich alles fast auf Meereslevel befindet kann das nicht so schwer sein, aber weit gefehlt, oft stehen Gebäude im Wasser, sind Schiffe versunken oder von Bäumen ragt nur die Krone aus der Straße). Gut, evtl. hat man hier die Klimaerwärmung bereits berücksichtigt. 😉

Auch der Simulationsteil enttäuscht mich partiell. Dabei geht es nicht um die Simulation der Flieger (die kann ich eh nicht beurteilen). Die Flugzeugtypen fliegen sich deutlich unterschiedlich und man bekommt zumindest das Gefühl, dass einiges an Arbeit investiert wurde. Schlimmer finde ich, dass man offenbar nicht mal einen eigenen Kurs setzen kann. Man kann auch nicht extern einen Kurs erstellen und einlesen soweit ich das bisher beurteilen kann.

Ursprünglich hatte ich mal den Ansatz den Pacific Crest Trail (PCT) zu erfliegen aber da der FS 2020 Natur nicht wirklich schön darstellt und offenbar in Naturregionen oft einfach generierte Grafik genutzt wird, statt Satellitenbilder, macht das wenig Sinn, zumal man den Kurs eh nicht eingeben kann.

Flight Simulator 2020 - Airbus. Der Fliegt sich wie ein Panzer

Flight Simulator 2020 – Airbus. Der Fliegt sich wie ein Panzer

Punkten kann der FS 2020 besonders in bewohnten Gegenden mit vielen Häusern. Ein Flug über Disney, New York oder San Francisco. Da liegt die Stärke des FS 2020. Ein Flug über Landschaft kann je nach Wetter auch so seine Momente haben, wenn man jemals vor Ort war wird man davon aber eher enttäuscht sein. Die Schönheit der Landschaft kann der FS 2020 aufgrund der zermatschten Satellitenaufnahmen und teilweise generierten Welt  nicht ansatzweise wiedergeben, von Fotorealismus ist er meilenweit entfernt. Das fängt schon ganz simpel damit an, dass teilweise nicht mal die Texturfarben stimmen und die Struktur auch nicht detailliert ist. Berge sehen z.B. in den Sierras aus wie Hügel und haben weiche Konturen, das ist auch an anderen Stellen so.

Wenn man in großen Höhen fliegt, sieht es durchaus aus wie in einem echten Flugzeug, weil dann die Details keine große Rolle mehr spielen.

Der Hype um das Spiel eh Simulation ist aus meiner Sicht keineswegs berechtigt. Das Problem ist eher, dass es seit langem quasi keine Konkurrenz mehr in dem Genre gibt. Trotzdem ist der FS 2020 wohl der aktuell beste Flugsimulator und wird es mangels Konkurrenz wohl auch lange bleiben.

Um die Eingangsfrage aufzugreifen. Für mich ist der FS weder top noch flop aber er vergibt deutlich Potenzial. Dabei meine ich nicht mal die grafische Darstellung, die noch deutlich Luft nach oben hätte (DX11, ernsthaft in 2020?), sondern eher die nicht vorhandenen Navigationsmöglichkeiten mit GPS Koordinaten oder ganz simpel zum Anklicken auf der Karte, fehlenden Landmarkenbezeichnungen und sehr wenige Flugmodi.

Stand heute würde das Spiel aus meiner Sicht nur als Early Access durchgehen. Soweit ich das beurteilen kann wird sich Microsoft aber jeden weiteren Inhalt mit exorbitant hohen Preisen finanzieren lassen.

Ist das Spiel 65€ oder noch mehr wert? Meiner Meinung nach nein. Ich würde eher sagen 30€. Die ganzen Zusatzinhalte sind eh der reinste Wucher. Wenn sie den ganzen Sierra Nevada Bereich mal als DLC anbieten mit passender Textur und echten Konturen, dann schau ich es mir mal an. Aktuell passt teilweise nicht mal die Farbe. Dort ist nichts grün, das sind Steine und die Formen passen auch nur grob.

Ich bin übrigens gespannt, ob die Darstellung sich im Winter ändert, oder ob es dann bei der hochsommerlichen Darstellung der Sierras bleibt (ich vermute, dass letzteres der Fall ist, man kann aber manuell Schnee aktivieren. Der wird dann einfach über die Landschaft gelegt – dabei ist es egal, ob man gerade am Grand Canyon in der Wüste oder in den Sierras ist).

Odroid H2+ Performance [Kommentar]

Nachdem ich schon einen Beitrag zum Thema Raspberry Pi (ARM) vs. VPS Server gepostet hatte, habe ich nun auch noch den Odroid H2+ gekauft. Somit bieten sich ein paar ergänzende Benchmarks an.

Um das Ergebnis vorweg zu nehmen der Odroid H2+ ist rund doppelt so schnell.

Die Benchmarks:

Odroid H2+ Geekbench 5

Sysbench CPU Odroid H2+

Sysbench CPU

Sysbench Memory Odroid H2+

Sysbench Memory

Sysbench IO Sequential write (BTRFS mit Kompression, Luks Verschlüsselung, NVMe) Odroid H2+

Sysbench IO Sequential write (BTRFS mit Kompression, Luks Verschlüsselung, NVMe)

SQL / PHP Performance Odroid H2+

SQL / PHP Performance

Backup mit Komprimierung mit einer konventionellen Festplatte als Ziel Odroid H2+

Backup mit Komprimierung mit einer konventionellen Festplatte als Ziel

Sysbench IO lineares lesen mit Luks Verschlüsselung und BTRFS Komprimierung Odroid H2+

Sysbench lineares lesen

Sysbench IO Random Read / Write Luks BTRFS Komprimierung Odroid H2+

Sysbench Random Read / Write mit Luks verschlüsselung und BTRFS Komprimierung

Cryptbench Odroid H2+

Cryptbench

Fazit:

Durch die x86 Kompatibilität lässt sich problemlos jede Software im Linux Bereich nutzen und sogar Windows 10 läuft problemlos. Der Speicher kann nach eigenen Wünschen angepasst werden (bis 32GB) und somit können sogar virtuelle Maschinen genutzt werden.

2 SATA Festplatten können direkt verwendet werden und mit 2×2,5 Gbit Netzwerk ist die Grundlage für ein NAS vorhanden.

Die CPU bietet im Gegensatz zum PI Hardwarebeschleunigte Verschlüsselung.

Es gibt ein UEFI BIOS und somit kann auch Linux oder andere Betriebssysteme ohne Spezualbootloader installiert werden.

Für mich ist der Odroid H2+ der bessere Raspberry Pi. Der Odroid H2+ ist zwar deutlich Teurer aber eben auch deutlich flexibler. Der Idle Verbrauch ist aber nicht deutlich höher.

Das hängt aber wirklich vom Anwendungsfall ab. Der Pi leistet für seinen Preis durchaus erstaunliches.

Wenn ihr mit dem Raspberry Pi oder einem VPS vergleichen wollt, könnt ihr das hier machen. Der VPS ist etwas flotter aber viel ist es nicht.

 

DIY NAS ein Network attached Storage im Eigenbau [Kommentar]

Vorüberlegungen

Dieses Jahr wird wohl als das DIY Jahr in die Geschichte eingehen. So viel Zeit für Projekte (@Corona) hatte ich noch nie.

Bisher habe mich immer von der NAS Thematik abgesehen. Das hatte verschiedene Gründe. Bei mir ist der primäre Einsatzzweck das Backup mehrerer Rechner.

Festplatten sind heute oft deutlich schneller als 1 Gbit Netze (das theoretische Maximum liegt bei einem Gbit Netz bei 125 MB/s, praktisch sind es oft eher 90 MB/s, eine Moderne Festplatte schafft heute ca. 250 MB/s). Somit war die per USB 3.0 angebundene Festplatte immer die deutlich flottere Alternative und zudem deutlich günstiger als ein NAS.

Weiterhin benötigt ein NAS ständig Strom, erzeugt Wärme und Geräusche. Festplatten können einen gerade im Wohnbereich auf Dauer nerven, wenn sie mit kleinen Lüftern kombiniert werden und rund um die Uhr laufen. Beides ist in NAS oft der Fall.

Seit längerer Zeit stehen bereits 10 Gbit Netze zur Verfügung aber die Kosten sind immens, wenn man mehrere Rechner vernetzen will. Ein Switch kostet je nach Portanzahl gerne mal mehrere hundert Euro und braucht aktive Belüftung und oft 30 oder 40 Watt Strom. Zusätzlich erzeugen diese Switches Lärm. Diese Variante war für mich absolut unattraktiv.

Es gibt zwar auch optische Switches (SFP+) für 10 Gbit im Bereich von 120€ aber dafür sind mir keine USB Adapter als Gegenstück bekannt. Somit braucht man zusätzliche Transceiver z.B. für Odroid H2+ und z.B. ein evtl. vorhandenes Notebook und somit treibt man den Preis schnell wieder deutlich in die Höhe.

Update 04.10.2021 Mittlerweile bekommt man 5 Port RJ45 10GBit Switches für 275€ mit bis zu 10 Jahren Garantie und ohne Lüfter.

Update Ende

Update 30.09.2022 Mittlerweile gibt es einen SFP+ Thunderbolt Adapter von QNAP, der als Gegenstück für eine 10 GBit Netzwerkkarte mit SFP+ Anschluss dienen kann. Auch Switches mit 4x SFP+ und diversen 1GBit Ports oder auch andere Konstellationen sind im bezahlbaren Rahmen von unter <275€ und mit passiver Kühlung verfügbar.

Update Ende

Seit einer Weile stehen nun 2,5 Gbit Netze bzw. Geräte für 2,5 Gbit zu günstigeren Preisen zur Verfügung. Je Rechner kann man für einen USB Adapter ca. 40€ veranschlagen. Seit wenigen Tagen steht auch der erste bezahlbare Switch für ca. 115€ zur Verfügung (QNAP QSW-1105-5T 5 Port).

Da ich mit dem Raspberry Pi bereits experimentiert hatte und bereits feststand, dass ich einen Minirechner für Linux, Spielereien und Backup nutzen möchte, war der Schritt zum Eigenbau-NAS ziemlich klein.

Warum ein NAS?

Ein NAS hat den Vorteil, dass man von x Stellen darauf zugreifen kann. Statt lokal USB Platten anzustöpseln (für den Hauptrechner, für den Zweitrechner, für das Notebook, für den SAT Receiver, usw.) hat man nur noch eine zentrale Datensammlung die im gesamten Heimnetz verfügbar ist.

Theoretisch benötigt man somit weniger Festplatten und lokale Datensilos. Dazu kommt, dass man mit dem Dateisystem freie Hand hat. Während man bei Windows auf NTFS beschränkt ist und beim SAT Receiver ggf. auf Spezialformate (siehe Technisat), hat man in der Linux Welt die freie Auswahl und kann moderne Systeme mit Copy on Write und Komprimierung nutzen.

Weiterhin braucht man nicht überlegen wo die Daten liegen, wenn man ein zentrales NAS für die Ablage nutzt (Festplatte A, Festplatte B oder doch irgendwo anders?). Heute ist es in der Regel so, dass die meisten Geräte eh per LAN verkabelt sind, somit ist der Schritt die Datenablage auch per Netzwerk anzubinden konsequent.

Was kostet ein DIY NAS?

Die Hardware:

  • Odroid H2+ (ca. 140€ – nicht mehr erhältlich / Odroid H3 ca. 205€)
  • RAM 32GB Ripjaws 2400 (ca. 100€, 8-16GB reichen auch, wenn  man nicht virtualisieren will und ZFS als Dateisystem ausschließt)
  • NVMe SSD WD SN550 (70€ 0,5TB bis 120€ 1TB) – Update 31.12.2021 mittlerweile ersetzt durch SATA SSD 2TB (ca. 180€)
  • Festplatten je nach Bedarf (in meinem Fall alte WD 4TB und neue Seagate Exos X14 mit 12TB für ca 300€) – Update 31.12.2021 mittlerweile wurden die beiden vorgenannten Festplatten ersetzt durch 2x 18TB Segate Exos (aktuell ca. 600€ für die beiden HDDs)
  • Gehäuse Kolink Satellite (ca. 40€)
  • Netzteil, Kabel, Schalter (40€)
  • 3D Druck Boardhalter und Mini-ITX-Blende (ca. 25€)
  • Noctua Lüfter 120mm 5V – NF-F12 5V (20€) – Update 31.12.2021 Nach Update mit 2 modernen Festplatten habe ich zusätzlich vorne einen zweiten Lüfter verbaut. Die Lüfter laufen beide mit Minimaldrehzahl von 300 RPM und nur, wenn die Festplatten aktiv sind, oder der Odroid H2+ / H3 eine gewisse Mindesttemperatur überschreitet (somit 40€)
  • Sharkoon HDD Vibe Fixer (15€)
  • Bereits vorhanden (zwei weitere Rahmen wie Sharkoon, Metallbleche, Schrauben und Befestigungsmaterial)

Abzüglich der Festplatte rund 500€

Dafür bekommt ihr:

  • Ein Dateisystem eurer Wahl btrfs / ZFS / ext4
  • 32GB für virtuelle Maschinen oder viel Platz für Zwischenpuffern von Daten (der Odroid ist für Textverarbeitung, Tabellenkalkulation, im Internet surfen, Mails als vollwertiger Desktop Ersatz nutzbar). Selbst Windows 10 lässt sich problemlos installieren (das habe ich selbst bisher nicht gemacht aber Videos dazu gesehen).
  • 2×2,5 Gbit Schnittstellen (einschließlich Link Aggregation was einem aber mangels passenden Switches eher wenig nützt)
  • Maximale Flexibilität (beliebige Software, 10 Gbit Erweiterung über NVMe Karte oder über NVMe Karte 6 SATA Anschlüsse)
  • Die NVMe SSD könnt ihr auch gegen eine Karte tauschen, mit der weitere SATA Festplatten angesteuert werden können. Dann ist eher der direkte Vergleich mit einem fertig NAS gegeben oder ihr könnt alternativ Port Multiplier nutzen, um aus den 2 SATA Anschlüssen z.B. 4 zu machen.

Und ein NAS von der Stange?

Am ehesten vergleichbar ist aktuell der QNAP TS-453D-4G. Der bietet 4 Bays (also doppelt so viel wie der Odroid H2+ Anschlüsse hat, 2×2,5 Gbit, 4GB Ram statt 32GB, keine 1TB SSD für das Betriebssystem) ein vorgegebenes Betriebssystem und ausschließlich ext4 als Dateisystem.

Die Kosten liegen bei rund 600€. Wenn man die SSD und den RAM in dem Beispiel oben raus rechnet (das entspricht dann dem QNAP), gut 300€ mehr als der Selbstbau aber dafür mit Anschlussmöglichkeiten für zwei weitere Laufwerke.

Der Adapter für 4 weitere Laufwerke über den NVMe Anschluss kostet rund 40€ und dann braucht man für das Betriebssystem ggf. einen 64GB eMMC Baustein statt der NVMe SSD oder man nutzt eine SATA SSD. D.h. für 75 – 100€ (on Top auf die 300) hat man quasi die gleiche Ausstattung wie der QNAP, liegt also 200€ günstiger mit deutlich mehr Flexibilität.

Wie sieht das DIY NAS aus?

Odroid H2+ von unten

Mein erster 3D Druck Auftrag (ich habe mich für die günstigste Variante entschieden, wie man an der Druckqualität erkennt). Das Material ist aber hinreichend stabil, wenn auch kein optisches Highlight. Odroid H2+ von unten mit Boardhalter und WD SN550 1TB NVMe SSD für das Betriebssystem und zwei mal 16GB RAM

Odroid H2+ von oben

Odroid H2+ von oben mit Powertaster und Board als 3D Druck

Odroid H2+ im Gehäuse verbaut

Odroid H2+ in eingebautem Zustand im Mini-ITX Gehäuse. Sagen wir es sieht semiprofessionell aus. Das Loch für den Schalter nach dem 3D Druck einzubringen war keine gute Idee, dafür ist das Material nicht stabil genug gewesen, da der 3D Druck nicht massiv war (das hängt vom Material ab und wie hoch die Füllung ist). Somit ist etwas ausgebrochen aber mit Etwas Ponal lies sich das beheben. 🙂

Seitenansicht Gehäuse Kühlung, Odroid H2+ Festplattenbefestigung

Seitenansicht. Links Odroid H2+ auf 3D Druck Halter befestigt an den Mini-ITX Befestigungsbohrungen. Rechts Sharkoon Vibe Fixer, auf dem ich mit den Blechen noch zwei weitere HDD Halter befestige. Die starren Füße am Vibe Fixer habe ich später noch durch Gummipuffer getauscht. Am Lüfter befindet sich ein Blech um einen Teil der Luft auf den Odroid H2+ zu lenken. Der Hauptteil der bewegten Luft geht Richtung HDDs.

Gehäuse von oben ohne Festplatte

Gehäuse von oben ohne Festplatte

Von oben - die oberste Festplatte von dem potenziellen 3er Stapel

Von oben – die oberste Festplatte von dem potenziellen 3er Stapel

Gehäuse von seitlich oben mit Odroid H2+ und Festplattenhalterung

Fast finaler Ansatz des Aufbaus: Geändert habe ich die Befestigungsrahmen der Festplatten. Oben nutze ich noch zwei Rahmen ohne die Gummiringe als Befestigung. Die Platten sind unten mit Gummischeiben unter den Festplatten verschraubt. Das hat zu viele Vibrationen erzeugt. Somit habe ich die Rahmen durch andere mit Gummiringen zur Aufhängung der Festplatten ersetzt.

Finaler Aufbau mit beiden Festplatten frei hängend und Gummipuffern unten drunter.

Finaler Aufbau mit beiden Festplatten frei hängend und Gummipuffern unten drunter.

Geschlossenes Koling Satellite Gehäuse von oben

Geschlossenes Gehäuse von oben

Geschlossenes Koling Satellite Gehäuse von vorne

Geschlossenes Gehäuse von vorne

Die Temperaturen:

Die Seagate ist heliumgefüllt und somit effizienter als die alte Western Digital Festplatte. Die Seagate bewegt sich beim Temperaturbereich zwischen 35 – 40°C je nach Last. Die WD bei ca. 5°C mehr (Zimmertemperatur ca. 25°C und 800 RPM Lüfterdrehzahl).

Der Odroid H2+ liegt bei ca. 30°C an den drei Boardsensoren im Leerlauf. Die CPU Sensoren bei 45°. Der Lüfter ist dabei angenehm leise. Bei Datenübertragung gehen die Kerne auf 65°C hoch und sind somit noch weit vom kritischen Bereich von 95°C entfernt.

Das kann man von den Festplatten in Kombination mit dem Gehäuse leider nicht sagen. Obwohl die Platten maximal entkoppelt sind, ist das Blech so dünn, dass es durch das Geräusch der Festplatten angeregt wird und dieses eher verstärkt. Das kann einem bei geringer Entfernung gerade bei der alten WD auf den Senkel gehen.

Da ich die Festplatten aber nach 10 Minuten in den Standby schicke ist es nicht so dramatisch.

Update 30.09.2020: Ich habe später das komplette Gehäuse noch mit selbstklebenden Bitumenmatten ausgekleidet, die Schwingungen minimieren.

Der Stromverbrauch:

Im Idle mit Samba, Apache, Nginx, Mysql, Firewall, DHCP, Bind, Webmin, Webadm, Slapd, Openotp, Elasticsearch, Memcached, PHP, Redis, Proftp, TS3 Server, Opendkim, Postfix, Dovecot, Openvpn, SSH-Server.

    • WD, Seagate, Odroid H2+, Ubuntu 20.04, USB Stick, MicroSD Card Reader, 1Gbit USB Netzwerkadapter, NVMe SSD, 4 Port USB 3.0 Hub, Lüfter – 21 Watt
    • WD, Odroid H2+, Ubuntu 20.04, USB Stick, MicroSD Card Reader, 1Gbit USB Netzwerkadapter, NVMe SSD, 4 Port USB 3.0 Hub, Lüfter – 18 Watt
    • Seagate, Odroid H2+, Ubuntu 20.04, USB Stick, MicroSD Card Reader, 1Gbit USB Netzwerkadapter, NVMe SSD, 4 Port USB 3.0 Hub, Lüfter – 12 Watt
    • Odroid H2+, Ubuntu 20.04, USB Stick, SD Card Reader, 1Gbit USB Netzwerkadapter, NVMe SSD, 4 Port USB 3.0 Hub, Lüfter – 9 Watt
    • Odroid H2+, Lüfter, NVMe SSD, Ubuntu 20.04 ca. 6-7 Watt
    • 4 Port USB 3.0 Hub, USB Stick, MicroSD Card Reader ca. 1 Watt
    • 1 GBit USB Adapter ca. 1 Watt
    • WD ca. 9 Watt (Idle) – lt. Datenblatt 8,1 Watt
    • Seagate ca. 3 Watt (Idle) – lt. Datenblatt 5 Watt (nach 2 Minuten ca. 3 Watt mit Idle_B, das habe ich gemessen)

An dem Beispiel sieht man wie viel Strom alte Festplatten benötigen. Die Seagate hat interne Sparmechanismen, die gegriffen haben und ohne externe Tools bereits den Stromverbrauch senken.

Die Performanz:

  • Lokale SSD in Windows PC über Netzwerk auf NVMe SSD mit Windows Explorer (Luks, Btrfs, ZSD1 Komprimierung) in der Spitze ca. 220MB/s, Einbrüche auf 70 MB/s, im Durchschnitt ca 175 MB/s (das Limit ist in dem Fall dank schlechter Parallelisierung der Btrfs Komprimierung der Prozessor des Odroid, die Verschlüsselung sollte dank Hardwareunterstützung keine Rolle für die Performanz spielen)
  • NVMe SSD (Luks, Btrfs, ZSD1 Komprimierung) auf lokale SSD auf dem Windows PC mit dem Windows Explorer in der Spitze bis 290 MB/s, im Schnitt ca. 200 MB/s (wo das Limit in dem Fall liegt ist mir nicht klar, der Odroid Prozessor ist nicht ausgelastet mit der Dekomprimierung, in der Vergangenheit habe ich aber bereits beobachtet, dass der Windows Explorer limitiert)
  • Die iperf3 Messungen waren für mich überhaupt nicht nachvollziehbar. Der i225V schafft in Senderichtung zum Odroid ca. 2,4 Gbit, die Realtek Chips kämpfen mit bescheidenen Treibern. Je nach Version (habe ich 2,15 Gbit) geschafft und das waren nicht die aktuellen Treiber von Realtek, sondern die automatisch von Windows installierten Treiber. In der Gegenrichtung Odroid nach PC liegt das von mir erreichte Maximum bei ca. 1,5 Gbit (unabhängig davon ob Realtek oder Intel auf dem PC die Gegenstelle gebildet haben). Sehr dubios. Update 18.08.2021 – Nun sind die Treiber für die Realtek Chips im Ubuntu Kernel enthalten, bei einer aktuellen Messung Realtek zu Realtek komme ich in beide Richtungen in etwa auf 2,25 Gbit gemessen mit iperf – also nicht die 3er Version und default Einstellungen – bei iperf3 ergibt sich noch immer das ungleiche Bild, dass ich oben beschrieben habe) Update Ende

Anmerkung: Ich rate davon ab über den QNAP QSW-1105-5T 5 Port sowohl Internet als auch den NAS Verkehr laufen zu lassen. Wenn man die Leitung zum NAS auslastet sind die Latenzen enorm. Stattdessen sollte man dafür einen separaten Adapter nutzen (1 Gbit per USB reicht vollkommen). Einige PCs bieten heute auch schon zwei Netzwerkschnittstellen an, dann ist kein Zusatzadapter erforderlich.

Ich habe übrigens auch BTRFS ohne Komprimierung getestet. NTFS war extrem lahm (liegt vermutlich am Linux Treiber), FAT32 und ext4 waren bei den Tests auch nicht schneller als BTRFS mit Komprimierung.

Der praktische Nutzen:

Der Nutzen muss sich final noch erweisen. Unter Linux ist er definitiv gegeben weil man dort immer ohne Probleme auf das NAS zugreifen kann. Bei True Image wird das NAS nicht automatisch gefunden. Bevor man im Notfall lange rumbastelt und das irgendwie Treiber integriert, nimmt man schnell mal wieder die USB Platte und schwups schon war das NAS für die Katz.

Dazu kommt, dass die Qualität bei Acronis True Image leider von Version zu Version und von Upgrade zu Upgrade sehr stark schwankend ist. Für Rescuemedien müssen Treiber für die jeweiligen Netzwerkchips hinzufügt werden. Selbst die 2020er Version findet weder den Intel 225V (2,5 Gbit), noch den 219V (1 Gbit), noch den Realtek 8156 (2,5 Gbit). Selbst wenn die Netzwerkchips per Treiber gefunden sind, muss man manuelle Schritte durchführen, damit das NAS erkannt wird. Die Performanz ist bei den Rescuemedien generell schlecht und reizt nicht mal ein Gbit LAN aus, was die Performanzgewinne partiell wieder aushebelt.

Update 04.10.2021: Die Performanz ist wohl nicht alleine ein Problem von True Image (auch aber eben nicht nur). Der Odroid hat pro Kern eine überschaubare Rechenleistung. Samba nutzt in der Regel (Ausnahme: Stichwort RSS fähige Netzwerkadapter) nur einen Kern (Details siehe hier). Die Samba Versionen kleiner 4.12 sind zudem noch langsamer als die aktuelleren Versionen (Wechsel der Verschlüsselungstechnik). True Image läuft per FTP Anbindung an den Odroid deutlich schneller. Dann allerdings nur FTP (non secure), also nur für das interne Netz geeignet. Diesbezüglich ist Acronis ziemlich vorsintflutlich unterwegs. Mit FTP bekomme ich ca. 1,8 GBit hin mit den 2,5 Gbit Adaptern und meiner Festplatte. Mit einem 2,5 GBit Adapter und Samba 4.13 gehen mit Glück etwas mehr als ein GBit mit True Image. Mit einem 10GBit Netz erreiche ich rund 2,5 Gbit netto. Sehr seltsam das Ganze. Acronis ist daran aber offenbar auch nicht unschuldig, denn mit einem Filetransfer über den Windows Explorer auch mit Samba erreicht man locker die Maximalgeschwindigkeit einer Sata SSD. eigentlich sollte man meinen das Acronis identische Werte erreicht.

Ich habe mittlerweile auch eine große Blu Ray / UHD Sammlung auf das NAS überspielt. Das NAS hält somit über 300 Filme und gut 700 Serienfolgen vorrätig.

Update Ende

Zusammenfassung:

Abseits von einer manuellen Ubuntu Installation mit allen Einzelkomponenten kann man für den NAS Einsatzzweck auch Fertiglösungen wie z.B. Freenas nutzen, verliert damit aber wieder einen Teil der Flexibilität.

Der Odroid H2+ ist über den NVMe Slot recht flexibel. Es lässt sich auch 5Gbit (USB) oder 10Gbit (NVMe) Ethernet nachrüsten. In letzterem Fall allerdings nur mit 2 SATA HDDs oder mit Port Multipliern (wobei Port Multiplier nur für 2 HDD pro Port Sinn machen, wenn parallele Zugriffe erfolgen – ansonsten verliert man zu viel Performanz – d.h. mit Port Multipliern kommt man auf insgesamt 4 HDDs). Das sollte für die meisten Setups ausreichend sein.

Für mich ist der Odroid H2+ aktuell das beste NAS, sofern man maximal 2-4 HDDs dauerhaft betreiben möchte. Darüber hinaus ist ein professionelles NAS je nach Anwendungsfall ggf. besser geeignet.

Update 04.10.2021: Ich habe mittlerweile einen SATA Port Replikator im Odroid H2+ getestet. Bis 4 Laufwerke sollte es bei Festplatten keinen Performanzverlust geben (also 2 an jedem Port). Allerdings wird das von der Stromversorgung wohl ziemlich grenzwertig sein je nach HDDs und Anlaufstrom der Festplatten. Man kann zwar ein etwas größeres Netzteil nutzen (bis ca. 80 – 100 Watt) aber es gibt es Limits für den Odroid H2+ bei der Stromversorgung pro Port und somit auch insgesamt. Ich habe neben den beiden HDDs eine SSD angeschlossen (2xHDD an einem Port mit Port Multiplier, SSD an dem anderen – das läuft problemlos). Die M2 SSD ist nun rausgeflogen und dafür ist eine 10GBit Netzwerkkarte rein gekommen, die über einen M2 > PCIe 4x Adapter mit Kabel von ADT-Link angeschlossen ist. Die Wärmeentwicklung bei den Karten von Asus / TP-Link mit dem AQC 107 ist zwar nicht gering aber passiv kühlbar und der Odroid H2+ kann die Karte locker versorgen.

10GBit Karte mit AQC107 von Asus am Odroid (der Stromadapter wird benötigt, fehlt aber im Foto noch)

10GBit Karte mit AQC107 von Asus am Odroid (der Stromadapter wird benötigt, fehlt aber im Foto noch)

Auf dem Kopf, das NAS ist umgedreht, die SSD befindet sich an einem regulären 2,5" Einbauplatz des Gehäuses

Auf dem Kopf, das NAS ist umgedreht, die SSD befindet sich an einem regulären 2,5″ Einbauplatz des Gehäuses

Und noch mal auf dem Kopf, der Port Multiplier befindet sich oberhalb der zwei Festplatten

Und noch mal auf dem Kopf, der Port Multiplier befindet sich oberhalb der zwei Festplatten

Port Multiplier von oben, rechts daneben die SSD

Port Multiplier von oben links, rechts daneben die 2TB SSD

Update Ende

Update 30.09.2022: Ich bin mittlerweile auf SFP+ Netzwerkkarten mit dem AQC100S umgestiegen, weil dieser deutlich weniger Strom verbraucht. Die oben gezeigte Asus Karte benötigt ca. 6-7 Watt und wird verhältnismäßig warm. Der AQC100S benötigt weniger als ein Watt. D.h. selbst mit DAC Kupfer oder AOC Lichtleiterkabel kann man pro Port grob 1 Watt rechnen. Dementsprechend bleibt auch der Kühler viel kälter, obwohl er viel kleiner ist.

Nach meinen Tests funktionieren folgende PCIe Karten mit dem Odroid H2+:

  • Zyxel XGN100F / Trendnet TEG-10GECSFP (Version v2.0R) – beide SFP+ und mit dem AQC100S (Stromverbrauch ca. 1 Watt)
  • Asus XG-C100C – RJ45 (Stromverbrauch ca. 6 Watt)

Nicht funktioniert hat bei mir die Delock 89100, obwohl sie auch auf dem AQC100S basiert.

Update Ende

Als einzigen Fehler beim Kauf meiner Komponenten würde ich ggf. das Gehäuse einstufen. Allerdings stellt sich die Frage, ob man dann nicht in ganz anderen Preisregionen landet, wenn man ein Gehäuse mit dickerem Blech oder gar Dämmung möchte. Ich habe zumindest nichts besseres entdeckt was kompakt und günstig ist. Bessere Gehäuse kosten dann eher das doppelte (z.B. Fractal Design Node 304 – und die Standardkabel für den Odroid könnten dann zu den Festplatten bereits etwas kurz sein) und sind auch größer. Wer allerdings auf meine Bastelei zur Festplattenbefestigung von oben verzichten möchte, kann die Festplatten in dem genannten Gehäuse direkt befestigen.

Um das Gehäuse wirklich beurteilen zu können, muss man das aber in der Realität begutachten und nicht nur anhand von Fotos im Netz.

Ich habe im Nachgang noch etwas Dämmmaterial in mein Gehäuse eingebracht und die klappernden Staubfilter entfernt, die eh so große Löcher hatten, dass sie quasi wirkungslos sind.

Fazit:

Ob man ein NAS “braucht” ist individuell sehr unterschiedlich. Das selbstbau NAS ist deutlich flexibler als die Lösung von der Stange aber eben auch um einiges aufwendiger.

Ich finde den Odroid H2+ absolut klasse, aber nicht unbedingt primär als NAS. Sehr viel mehr als Minicomputer für Windows, Linux oder als Server, wofür die meisten NAS nur sehr bedingt geeignet sind. Der NAS Part ist für mich eher ein mitgenommenes Abfallprodukt, dass ich gerne dazu nehme.

Update: Im Nachgang zum Test sind auch einige kleine Barebones / NICs z.B. mit Tigerlake CPUs erschienen, die ggf. deutlich mehr Rechenpower liefern und auch 2,5 GBit Adapter zur Verfügung stellen. Preislich dürfte man in vergleichbaren Regionen landen. Die Kühlung bei derartigen Geräten ist aber oft sehr laut, da sehr kleine Lüfter verwendet werden. Zusätzlich benötigt man dann noch ein externes Gehäuse z.B. mit USB 3.0 Anbindung für die Festplatten.

Raspberry Pi 4b als Webserver für einen WordPress Blog [Kommentar]

Nachdem ich bei ersten Performancetests festgestellt habe, dass sich der Pi im Vergleich zu einem VPServer recht gut schlägt. Bzgl. der Einrichtung mit dem btrfs Dateisystem in einem verschlüsselten Luks Device habe ich auch einen Beitrag geschrieben aber wie sieht es mit den praktischen Nutzungsmöglichkeiten aus?

Der erste Ansatz war einen vorhanden VPServer vollständig zu kopieren. Das funktioniert aber aufgrund der unterschiedlichen Architektur (Arm / x86) nicht. Da ich auf dem VPServer Ubuntu 20.04 LTS nutze und das auch auf dem Pi verfügbar ist, lag eine Neuinstallation mit Ubuntu 20.04 nahe.

Ich will in dem Artikel nicht auf den Installationsprozess eingehen. Ubuntu installiert sich mit dem bereitgestellten Image quasi von allein und danach verhält sich das Pi Ubuntu weitgehend wie ein normales Ubuntu.

Ein Unterschied ist das Cloudinit, was die IP Adresse zum Beispiel per DHCP bezieht und wo abweichend vom Ubuntu Standard (netplan) die IP vergeben wird und auch geregelt wird, dass zum Beispiel der Root Zugriff per SSH nicht erlaubt ist. Wer an den Ubuntu Standardstellen danach sucht wird nicht fündig.

Abseits davon funktioniert aber fast alles was ich benutze und das ist einiges. Es gibt einzelne Binaries oder Pakete, die nicht für die Arm Architektur vorliegen.

Was geht?

Ich habe im folgenden Text zwei Screenshots der Diensteüberwachung in Webmin eingefügt. Eine Variante ist der VPS und die andere der Pi. Wie ihr erkennt fehlen zwei Prozesse. Webadm und Teamspeak. Es geht also eine ganze Menge. Fail2Ban funktioniert auch, der ist nur gerade deaktiviert.

Neben den aufgeführten Prozessen / Programmen ist z.B. Nextcloud (private Cloud), WordPress (Blog), Roundcube (Webmail), PHP Admin (grafische Datenbankadministration) auf dem Server. Bei WordPress funktioniert nach bisherigen Tests alles. Ich konnte bisher keine Probleme finden.

Raspberry Pi 4 Dienste:

VPS x86 Dienste:

Was geht nicht?

Folgende Anwendungen habe ich für Arm nicht gefunden:

  • Webadm / Rcdevs – Open Otp 2-Factor Authentification – kann man ersetzen durch das Google Gegenstück. Webadm ist vielfältiger und bietet deutlich mehr Optionen, dafür ist das Google Gegenstück viel schneller eingerichtet und reicht in der Regel aus. Mittlerweile habe ich mit dem Google Authentificator sogar XRDP zum Laufen bekommen (dort hat man nur ein Feld für beide Faktoren – somit muss die Software damit umgehen können, dass man beides PW und Token in ein Feld eingibt).
  • Teamspeak
  • Google Pagespeed Plugin
  • Collabora Office (eine von zwei Varianten der Online Bearbeitung ermöglicht). Only Office (das ist einfacher in Nextcloud zu integrieren) ist aber verfügbar
  • Geekbench
  • Elasticsearch (das ist für die Suche in Nextcloud erforderlich) lässt sich nicht automatisch installieren. Es gibt aber Guides mit denen es funktioniert.

Abseits von Teamspeak (wenn man einen entsprechenden Server betreiben will) ist das alles verschmerzbar bzw. keine große Einschränkung. O.g. Anwendungen lassen sich zwar ggf. über Virtualisierung verwenden aber da der Pi limitierte Ressourcen hat, macht das aus meiner Sicht wenig Sinn.

Update 03.07.2020:

Eine Alternative zum Raspberry Pi ist der Odroid H2(+). Der beruht auf x86 Architektur und somit muss man nichts neu installiert werden, wenn man schon einen entsprechenden Server hat.

Der Odroid hat mehr als doppelt so viel Rechenpower als der Pi 4b und der Preisunterschied hält sich je nach Setup in grenzen. Beispielsweise kann man direkt eine M2 NVMe SSD nutzen und kann somit das externe USB Gehäuse einsparen. Mittlerweile würde ich also zum Odorid greifen statt zum Pi.

Weiterhin laufen alle Programme uneingeschränkt.

Empfehlungen:

Für einen kleinen Webserver braucht man nicht viel Geld ausgeben. Der Pi liegt bei 60€ in der 4GB Variante. Die sollte es für den Zweck schon sein.

Eine microSD liegt je nach Größe im Bereich von 10 bis 25€ je (32GB z.B. 10€ und 128GB z.B. 25€). Man sollte darauf achten, dass die Schreibrate so hoch liegt, dass sie den Pi nicht ausbremst. Ich verwende zum Beispiel die Sandisk Pro Extreme. Die spezifische Marke ist egal.

Man sollte aber trotzdem auf ein Markenprodukt achten, da die microSD nicht für dauerhaftes Schreiben (Logging) ausgelegt sind, dass aber bei Linux fast immer irgendwo passiert, besonders wenn man viele Anwendungen nutzt. Somit bleibt die Hoffnung, dass die Markenprodukte länger halten. Beim Dauerbetrieb muss man lt. einem Benutzerbericht ca. nach zwei Jahren mit dem Ableben rechnen. Dann ist es gut, wenn man dann eine (halbwegs aktuelle) Kopie hat.

Aus dem Grund schadet auch nicht einen USB microSD Kartenleser zu kaufen (ca. 10€ – der aktuell verfügbare Mobile Mate wird unter Ubuntu erkannt) und eine zweite Karte als Backup. Das Backup kann man automatisieren (zum Beispiel tägliche Kopie auf die zweite SD mit Rsync bei der nur Änderungen synchronisiert werden – wenn man die microSD klont (Befehl dd) muss man aber vorsichtig sein, weil direkt danach die UUIDs identisch sind. Das kann zu unerwünschtem Chaos führen). Wenn man wiederum die UUID ändert, kann es sein, dass man auch eine neue initramfs erstellen muss.

Somit gibt es zwei Varianten unter Linux:

  • Klonen der microSD (nach dem klonen und vor dem nächsten Reboot entfernen und dann in gewissen
  • Rsync, davor kann initial geklont werden (dd), danach die UUID / PARUID anpassen und die initramfs aktualisieren. Anschießend täglich oder wöchentlich per rsync aktualisieren (nur das Delta).

Im besten Fall tauscht man dann beim Ableben einfach die microSD Karte und schon geht es weiter.

Wenn man nicht gerade Nextcloud mit vielen Daten auf den Pi verfrachten möchte kommt man mit der 32GB Karte aus.

Zusätzlich ist ein Netzteil (ca. 10€) und ein HDMI (<10€) Kabel fällig.

Ergo ist man bei:

1×60 + 2*10 (2 SD Karten) + 10 (Netzteil) + 10 (HDMI Strippe) = 100€

Die benötigte Software ist frei zugänglich.

Bei einem Dauerbetrieb als Webserver wäre eine SSD als externer Datenträger optimal. Mit Adapter ist man dann aber schnell bei 75€ oder mehr zusätzlich und die Einrichtung ist nicht ganz so einfach wie das simple Installieren des Images. Wirklich kompliziert ist die Variante aber auch nicht.

Beim Betrieb @Home ist in der Regel ein NAT Router mit optionaler Portfreigabe im Einsatz (z.B. Fritzbox). Wichtig ist, dass man die Ports nur auf den Pi leitet. Noch besser ist eine DMZ Zone (ich habe aktuell zwei Router – Speedport Hybrid und Fritzbox, somit hat man dazwischen automatisch eine DMZ), wenn beide im NAT Modus laufen.

Update 03.07.2020

Wenn man den Odorid als Vergleich nimmt, sind die Anschaffungskosten mit etwas über 100€ deutlich höher. Dafür entfallen die 60€ für das externe NVMe Gehäuse.

Fazit:

Aus meiner Sicht eignet sich der Pi 4 als vollwertiger Webserver. Wenn man sich auf die benötigten Dienste reduziert lässt sich die Performanz weiter optimieren (elasticsearch ist zum Beispiel ziemlich ressourcenhungrig und eine MySQL Datenbank ist auch nicht ohne).

Mit einem ausreichend schnellen Internetanschluss (besonders im Upload) ist es möglich einen Webserver mit minimalen Kosten zu Hause zu betreiben. Im Gegensatz zu “echten” Servern macht der Pi keinen Krach und heizt wenig. Etwas Linux Vorerfahrung schadet aber nicht, um halbwegs flott zu Erfolgen zu kommen. Andersrum ist der Pi eine super Experimentierbasis um sich in das Thema einzuarbeiten.

Update 03.07.2020

Nachtrag: Im Praxisbetrieb mit einer recht großen WordPress Seite und vielen Plugins ist der Pi, trotz der recht guten Daten gerade beim initialen Seitenaufbau (also dem Abarbeiten des PHP Codes) ziemlich langsam. Für einen WordPress Server würde ich also mehr Rechenpower empfehlen, wenn man nicht gerade ohne Plugins arbeitet.

Eine 50GB Nextcloud Installation läuft aber gut (einschließlich Indexierung und Suche). Man muss also den jeweiligen Anwendungsfall anschauen.

Für mich ist das so aber vollkommen ok, weil ich damit keinen VPS ersetzen wollte, sondern nur die Funktionalität des VPS weitgehend auf dem Pi haben wollte zwecks Tests und Backup.

Raspberry Pi mit Ubuntu 20.04 LTS, Btrfs und Luks Verschlüsselung des Root Dateisystems + Remote Login [Kommentar]

Worum geht es?

Aktuell ist der Blog recht Linux- und wenig buchlastig. Ggf. muss ich das doch irgendwann mal trennen.

Der Post hat zwei Komponenten. Erstens den Raspberry Pi mit Ubuntu 20.04 und Btrfs betreiben. Das ist eher noch in der Kategorie einfach anzusiedeln. Einen allgemeinen Beitrag zum Thema Btrfs und Backups hatte ich bereits hier veröffentlicht.

Der zweite Teil betrifft die Verschlüsselung des Root Laufwerks mit Ubuntu 20.04 und  dem Pi. Der Teil ist aus meiner Sicht schon nicht mehr für Fortgeschrittene, sondern eher für Profis.

Btrfs (Dateisystem) und Luks (Verschlüsselung) sind vollkommen unabhängig, man sollte aber nicht den Fehler begehen und erst Btrfs einrichten und dann davon ausgehen, dass man im nachhinein einfach die Verschlüsselung aktiviert. Das Motto bei Linux Verschlüsselung ist da eher Grüne Wiese und von vorne.

Aber der Reihe nach – warum Verschlüsselung?

Wenn man einen Rechner zu Hause stehen hat, denken viele ich habe nichts zu verbergen und warum verschlüsseln. Es braucht es aus meiner Sicht keine Geheimdienstszenarien um gute Gründe für Verschlüsselung von Daten zu finden.

Beispielszenario: Ein Einbrecher nimmt den ganzen Technikkram mit, er ist selbst kein IT Profi aber irgendwo verkaufen geht immer. Die Datenträger oder Computer werden also weiterverkauft. Jemand mit IT Kenntnissen bekommt die Datenträger in die Hände und je nachdem was man so alles auf dem Rechner hat (Emails, Rechnungen, Chatverläufe, Pincodes, Sexfotos, …) usw. kann das höchst spannend und ggf. schädlich werden, auch für Leute die vermeintlich nichts zu verbergen haben.

Es reicht ja schon, wenn die Person lustig bei Amazon bestellt, auf die Rechnung des Opfers.

Andere Szenarien lassen sich beliebig generieren. Die unachtsam entsorgte SSD Karte / Festplatte, die vermeintlich nicht mehr ging usw.

Da ich zuerst Btrfs aufgesetzt hatte und alle meine Mails (über einen Zeitrum von 15 Jahren und Rechnungen, Versicherungsunterlagen, …) auf dem Pi sind, fand ich die Idee der Verschlüsselung recht angeraten, zumal ich das bei allen Windows Rechnern auch so handhabe. Der Pi hätte ansonsten die Verschlüsselung auf dem Windows Rechnern und Backups quasi ad absurdum geführt und wäre das schwächste Glied in der Kette gewesen.

Verschlüsselung bei Linux

Vorab möchte ich zu dem Verschlüsselungsthema anmerken, dass ich zum ersten Mal im Linux Kontext den Eindruck hatte, dass Dinge extrem schlecht ineinander greifen und unnötig kompliziert sind. Ich bin mit der Erwartungshaltung eines Windows Bitlocker Nutzers an das Thema herangegangen.

Wie funktioniert es bei Bitlocker? Im Prinzip drückt man in Windows auf den Button mit Bitlocker verschlüsseln, bekommt einen Key zur Wiederherstellung den man irgendwo speichern kann und zusätzlich kann man auch einen eigenen verkürzten Key vergeben. Die Verschlüsselung lässt sich auf ein bestehendes Laufwerk anwenden und auch wieder rückgängig machen. Anschließend kann man in Bitlocker mit der regulären Windows Anmeldung alle Laufwerke entsperren.

Die Einrichtung ist für Anfänger geeignet. So muss es auch sein, wenn man Themen wie Verschlüsselung voran bringen will.

Wer mit dieser Erwartungshaltung in Linux startet fällt ganz Böse auf die Nase. Es gibt bei Linux verschiedene Verschlüsselungsvarianten aber der Tenor ist im Prinzip, die einzig sinnvolle ist eine Vollverschlüsselung. Gerade bei einem Server findet sich irgendwo doch mal ein Passwort, dass in einer Datei eingetragen wurde und das einem ggf. Zugriff auf andere Bereiche ermöglicht.

Es gibt Varianten, die nicht mehr unterstützt werden oder sehr langsam sind aber mein Fazit nach etwas Recherche ist zum aktuellen Zeitpunkt, dass Luks / Luks2 die am meisten verbreitete und unterstützte Variante ist, die auch weiterentwickelt wird.

Erwartungshaltung – und tschüss!

Was geht und was geht nicht bei Linux?

  • Entschlüsseln mit der Standardanmeldung (wie in Windows) – das geht soweit ich das bisher herausgefunden habe über pam_mount aber nicht für ROOT Laufwerke. Das Konzept ist, dass man das Anmeldepasswort und das Entschlüsselungspasswort des Laufwerks analog vergibt. Über eine entsprechende Konfiguration kann dann das Laufwerk durch die Anmeldung entsperren.
  • Entschlüsseln mehrerer Laufwerke gleichzeitig? Fehlanzeige. Zumindest nicht automatisch. Es gibt verschiedene mehr oder weniger schlechte Ansätze.
    • Mit einem Key aus einer Datei ein oder mehrere Laufwerke entsperren – das ist nicht gut, weil der Key zumindest zwangsweise ins die initramfs muss und das dazu führt, dass man ihn auslesen kann (zumindest bei Ubuntu auf dem Pi, weil boot nicht verschlüsselt ist. Theoretisch gillt das nur für Root Laufwerke aber bei mir hat es selbst dann nicht ohne Fehlermeldung bei der initramfs Erstellung funktioniert, wenn es sich nicht um ein root laufwerk handelt)
    • Abgeleitete Keys (derived keys) – die Variante leitet aus dem Key des Root Laufwerks weitere ab, das ist auch nachteilig, weil man an nichts mehr dran kommt, wenn der Root Key beschädigt wird. Richtig zum Laufen bekommen habe ich diese Variante auch nicht. Beim Start wurde trotzdem ein Key abgefragt.
    • Man nutzt überall denselben Key. Mit einem Zusatzprogramm (separates Paket)! kann man den dann laufwerksübergreifend nutzen. Dafür sind aber einige Voraussetzungen zu beachten. Das ist aber auch meiner Sicht die beste schlechte Variante.
  • Nativer Kernel Support? Nö, man muss sich initramfs Images bauen, damit man es ans Laufen bekommt. Das ist ziemliche Bastelei und fehleranfällig. Alles was man an Programmen benötigt muss in das Image und zumindest bei meinen bisherigen Versuchen war es so, dass sogar das Root Laufwerk in der Ramdisk verdrahtet wird. D.h. das Image läuft bereits bei einem Laufwerkswechsel nicht mehr. Wenn man was falsch macht, schaut man nach dem nächsten Boot ggf. in die Röhre.
  • Vergrößern und Verkleinern von Partitionen mit Verschlüsselung. Theoretisch soll das funktionieren. Das ging bei mir mit Gparted nicht (das liegt wohl daran, dass cryptsetup ein PW verlangt und Gparted keine Eingabe vorsieht). Die Btrfs Partition in Luks wurde verkleinert. Der Luks Teil nicht. Ich habe das auch manuell nicht hinbekommen die Partition zu verkleinern bzw. wie ich später raus gefunden habe, vergrößert Luks ganz automatisch bei der nächsten Anmeldung auf das Maximum.
  • Das Verschieben von Luks Partitionen funktioniert mit Gparted, der KDE Partition Manager hat dabei die Partition geschrottet. Von dem kann ich also nur abraten.
  • Nachträgliches Umwandeln von vorhandenen Partitionen in verschlüsselte Partitionen oder andersrum. Nö, geht nicht.
  • Der Einzige Vorteil ist aus meiner Sicht, dass man aufgrund der Trennung von Anmeldung und Entsperrung der Laufwerke zwei unterschiedliche Kennwörter nutzen kann.

Besonderheit Ubuntu 20.04 LTS mit Raspberry Pi

Ubuntu 20.04 ist recht neu und der Raspberry Pi 4b auch noch verhältnismäßig. Dazu kommt, dass die meisten Raspberry Pi Benutzer Raspian oder Arch benutzen (zumindest findet man dazu in der Regel Guides). Mein Ansatz an der Stelle war, da ich auf meinem x86 Server auch Ubuntu nutze, wollte ich beim Pi nichts anderes. Ob das wirklich die beste Idee war sei dahingestellt, weil man auf Ubuntu 20.04 + Pi 4 viel Pionierarbeit macht und nie so genau weiß in wie weit die Guides für andere Linux Derivate sich übertragen lassen.

Wenn es um Umbuntu geht, dann ist in der Regel auch die Rede von Grub, der wiederum mit dem Pi nicht funktioniert. Insofern muss man versuchen bei jedem Guide die Versatzstücke zu finden, die für die Kombination Pi + Ubuntu 20.04 passen bzw. übertragbar sind.

Das fällt anfangs enorm schwer, wenn man noch kein (tieferes) Verständnis der Materie hat.

Ich finde es allerdings schon etwas arm (wie doppeldeutig), dass es im Standard kein simples Bootmenü gibt (per Text reicht ja), mit dem man verschiedene Konfigurationen auswählen kann (Eintrag 1 cmdfile1.txt, Eintrag 2 cmdfile2.txt usw.) und ggf. die dazu passende initramfs.

Btrfs

Ich geben den Teil etwas verkürzt wieder. Unter anderem auch deshalb, weil ich die Konfiguration jetzt nicht mehr habe uns somit nicht alles 1:1 darstellen kann.

Es gibt recht viele Guides zu btrfs. Ich denke es ist an der Stelle hilfreich einfach einige Screenshots zu sehen bei denen man erkennt was in den Konfigurationsdateien steht bzw. passend dazu was die IDs der Laufwerke sind. Genau das sparen die meisten Guides leider aus. Es ist eine ziemlich blöde Idee mit /dev/sdax zu arbeiten, weil das Anstecken einer externen Platte dazu führen kann, das die Bezeichnungen nicht mehr passen. Keine Ahnung warum viele Guides das so handhaben.

Die Hauptvorteile von Btrfs sind, dass es komprimiert (on the fly) und vor allem die Snapshotfunktionalität im Kombination mit Copy on write. D.h. es werden ggf. mit Zusatztools (snapper) automatisch Snapshots in bestimmten  Zeitabständen oder nach Aktionen (Boot, apt install) vorgehalten. Diese lassen sich vollständig oder auch beliebige Dateien daraus zurückspielen.

Die Komprimierung bringt bereits Vorteile, richtig gut wird es dann aber in Kombination mit den Snapshots. Ohne Snapshots sieht man, dass lediglich die Komprimierung greift. Durch die Snapshots steigt das Verhältnis und das Referenced Total liegt mit grob 20 Scnapshots bei 900GB. Soll heißen, wenn ich mit der Häufigkeit Snapshots erstellen würde, wie Snapper das macht, dann würde ich ein 900GB ext4 Volume benötigen. Das gleiche auf 200GB unterzubringen ist schon praktisch. Man bekommt also sehr viel mehr Komfort und Sicherheit fast ohne Kosten.

Der wesentliche Unterschied zur Konfiguration mit Luks ist, dass man statt mit den Mappern direkt mit den UUIDs arbeitet. Sonst ist alles gleich.

Beispiel aus der fstab:

LABEL=writable       /sd  ext4    defaults        0        0
LABEL=system-boot       /boot/firmware  vfat    defaults        0       1
UUID=cbb8245c-32ae-4800-9730-b17f9479b00d /btrfs           btrfs   defaults,ssd,compress=zstd:1        0       0
UUID=cbb8245c-32ae-4800-9730-b17f9479b00d /           btrfs   defaults,ssd,compress=zstd:1,subvolid=258,subvol=/ROOT        0       0
UUID=cbb8245c-32ae-4800-9730-b17f9479b00d /.snapshots           btrfs   defaults,ssd,compress=zstd:1,subvolid=260,subvol=/snapshots/ROOT_snaps   0 0
UUID=cbb8245c-32ae-4800-9730-b17f9479b00d /btrfs/sync1/.snapshots           btrfs   defaults,ssd,compress=zstd:1,subvolid=552,subvol=/snapshots/sync1_snaps   0 0
UUID=cbb8245c-32ae-4800-9730-b17f9479b00d /btrfs/sync2/.snapshots           btrfs   defaults,ssd,compress=zstd:1,subvolid=553,subvol=/snapshots/sync2_snaps   0 0
UUID=863579b2-5411-4f2f-bba4-f675a21f6fd4 none       swap   sw         0     0

SSD darf natürlich nur an sein, wenn es sich um eine SSD handelt. Die Subvolume ID sollte bei euch identisch sein,wenn ihr ROOT oder wie auch immer ihr es nennt als erstes anlegt.

Die crypttab wird nicht benutzt und die cmdline.txt sieht entsprechend so aus:

net.ifnames=0 dwc_otg.lpm_enable=0 console=serial0,115200 console=tty1 root=UUID=cbb8245c-32ae-4800-9730-b17f9479b00d rootflags=subvol=ROOT rootfstype=btrfs elevator=deadline fsck.repair=no rootwait fixrtc

Leider habe ich keinen Screenshot der blkid gemacht. Die oben sichtbare ID entspricht der ID, die links angezeigt wird und nicht der ID des Subvolumes, die rechts gezeigt wird (die heißt auch nicht UUID, sondern UUID_SUB).

Luks (Verschlüsselung) mit Btrfs (Komprimierung / Snapshots)

Ich hatte es bereits oben geschrieben: Alles neu macht der Mai. Es macht keinen Sinn erst btrfs aufzusetzen und dann Luks, sondern nur andersrum, wenn man beides nutzen möchte.

Wie sieht das Minimalsetup aus:

Luks
—Btrfs
——Subvol 1
———Subvol 3
——Subvol 2
——Subvol 4

Luks beinhaltet also Btrfs (es können natürlich auch andere Dateisysteme genutzt werden). Das heißt die Partition wird zuerst mit Luks vorbereitet, sobald das erfolgt ist, kann man die Partition mit Btrfs formatieren und anschließend Volumes anlegen.

Im Gegensatz zu einem reinen Btrfs Setup, bei dem man nur mit der /etc/fstab arbeitet, kommt bei dem Luks Setup noch die /etc/crypttab hinzu, die etwas biestig ist. Man kann da gerne schon mal etwas Zeit verplempern, wenn man zum Beispiel oben eine Kommentarzeile hat (das war bei mir im Standard so), und dann Folgeeinträge schlicht ignoriert werden.

Performance:

Das Raspberry Pi hat keine Hardwareunterstützung für Verschlüsselung. Das kennt man von anderen Prozessoren heute nicht mehr. Um die zu erwartende Leistung abzuschätzen kann man zwei Benchmarks nutzen:

Variante 1: Standard

Anmerkung: Pi auf 1650 / 600 mit einem kompletten Webserver Apache, Nginx, Elasticsearch mit MysqlDB, Postfix, Dovecot usw. im Hintergrund

Falls cyptsetup nicht installiert ist, müsst ihr das Paket installieren (ich bin mir gerade nicht ganz sicher, ob es im Standard drauf war aber ich meine schon)

cryptsetup benchmark
# Tests are approximate using memory only (no storage IO).
PBKDF2-sha1       437636 iterations per second for 256-bit key
PBKDF2-sha256     696265 iterations per second for 256-bit key
PBKDF2-sha512     550144 iterations per second for 256-bit key
PBKDF2-ripemd160  358120 iterations per second for 256-bit key
PBKDF2-whirlpool  136249 iterations per second for 256-bit key
argon2i       4 iterations, 273064 memory, 4 parallel threads (CPUs) for 256-bit key (requested 2000 ms time)
argon2id      4 iterations, 260490 memory, 4 parallel threads (CPUs) for 256-bit key (requested 2000 ms time)
#     Algorithm |       Key |      Encryption |      Decryption
        aes-cbc        128b        24.8 MiB/s        83.6 MiB/s
    serpent-cbc        128b        37.8 MiB/s        39.4 MiB/s
    twofish-cbc        128b        61.2 MiB/s        62.1 MiB/s
        aes-cbc        256b        19.0 MiB/s        63.6 MiB/s
    serpent-cbc        256b        39.3 MiB/s        39.6 MiB/s
    twofish-cbc        256b        62.7 MiB/s        62.6 MiB/s
        aes-xts        256b        91.3 MiB/s        80.5 MiB/s
    serpent-xts        256b        39.6 MiB/s        40.0 MiB/s
    twofish-xts        256b        64.5 MiB/s        65.6 MiB/s
        aes-xts        512b        71.1 MiB/s        62.3 MiB/s
    serpent-xts        512b        40.9 MiB/s        39.3 MiB/s
    twofish-xts        512b        66.0 MiB/s        64.1 MiB/s

Variante 2: Das ist ein Cipher von Google, der speziell für Prozessoren mit geringer Leistung entwickelt wurde. Eigentlich wird der von Google nur bei Übertragungsraten von 50 MB/s empfohlen. So ganz traut man der  Sicherheit wohl nicht.

[root@pi ~]# cryptsetup benchmark -c xchacha12,aes-adiantum
# Tests are approximate using memory only (no storage IO).
#            Algorithm |       Key |      Encryption |      Decryption
xchacha12,aes-adiantum        256b       170.5 MiB/s       179.7 MiB/s

Ohne Verschlüsselung und Komprimierung wären lesend theoretisch um die 380MB/s möglich. Praktisch muss der Pi die aber auch erst mal verarbeiten. Fakt ist: Schneller wird der Pi nicht durch Verschlüsselung und Komprimierung (zumindest nicht bei einer SSD – bei einer micro SD kann sich durch die deutlich geringeren Datenraten die Komprimierung sogar positiv auswirken).

Gnome-disks Raw Performance

Mit Verschlüsselung und Komprimierung und BTRFS Dateisystem wird es schon weniger aber die Werte sind trotzdem gut:

Gnome-Disks Bench mit Btrfs zstd:1 Komprimierung und Luks Verschlüsselung

Sysbench mit Btrfs schreibend  (ZSTD:1 Komprimierung ohne Luks – zu dem Zeitpunkt lief auf dem Pi auch im Hintergrund noch etwas weniger als beim folgenden Test mit Luks):

Sysbench io mit Btrfs ZSTD:1 Komprimierung

Sysbench mit Btrfs schreibend (ZSTD:1 Komprimierung und Luks):

sysbench --test=fileio --file-test-mode=seqwr run
WARNING: the --test option is deprecated. You can pass a script name or path on the command line without any options.
sysbench 1.0.18 (using system LuaJIT 2.1.0-beta3)

Running the test with following options:
Number of threads: 1
Initializing random number generator from current time


Extra file open flags: (none)
128 files, 16MiB each
2GiB total file size
Block size 16KiB
Periodic FSYNC enabled, calling fsync() each 100 requests.
Calling fsync() at the end of test, Enabled.
Using synchronous I/O mode
Doing sequential write (creation) test
Initializing worker threads...

Threads started!


File operations:
    reads/s:                      0.00
    writes/s:                     7730.45
    fsyncs/s:                     9902.57

Throughput:
Throughput:
    read, MiB/s:                  0.00
    written, MiB/s:               120.79

General statistics:
    total time:                          10.0090s
    total number of events:              176420

Latency (ms):
         min:                                    0.00
         avg:                                    0.06
         max:                                   25.59
         95th percentile:                        0.04
         sum:                                 9886.92

Threads fairness:
    events (avg/stddev):           176420.0000/0.00
    execution time (avg/stddev):   9.8869/0.00

Das entspricht ca. 15% Einbruch.

Selbst wenn man das mit einem x86 VPServer vergleicht, der 15€ im Monat kostet kommt der Pi sehr gut weg und gewinnt in dieser Disziplin ziemlich locker.

Ans Werk:

Zuerst: Macht ein Backup oder auch zwei. Ich bin so gerade um einen Vollcrash drum rum gekommen, das letzte Werk der microSD war das überspielen der Daten auf die SSD. Zum Glück hatte ich noch ein Image auf dem Windows PC und das Überspielen hat noch funktioniert. Das Image war auf einem älteren Stand.

Die Partitionen selbst sind ggf. vorhanden oder können mit Gparted erstellt werden. Dafür in die grafische Oberfläche Wechseln (z.B. Ubuntu Desktop, x2go, xrdp) was auch immer ihr nutzt. Ich verwende bei einem Remotezugang in der Regel x2go. Bei xrdp hatte ich teilweise probleme grafische Tools per Remotezugang zu starten und die volle Desktopumbebung auf dem Pi schluckt noch mal mehr Ressourcen und ist auch unpraktisch, weil ich alle Unterlagen auf meinem Windows Rechner habe.

sudo gparted

Anschließend eine Partitionsgröße vorgeben und als Dateisystem keins auswählen. Wenn die Partition vorhanden ist das Dateisystem ggf. löschen. Wenn ihr auch eine Swappartition erstellen wollt ist jetzt der richtige Zeitpunkt. Später Luks Partitionen zu verändern kann ziemlich ekelig sein. Auch die Swap Partition muss verschlüsselt werden, da sich dort alle Daten befinden können, die man bearbeitet hat.

Achtung: Da der PI 4 bald von externen Medien booten können wird, sollte man am Beginn des Mediums 256MB frei lassen für einen Bootbereich (also nicht so wie ich im folgenden Screenshot!).

Gparted

Zuerst aushängen, dann formatieren als ohne Formatierung (Luks mit Btrfs ist in Gparted leider nicht verfügbar, also per Kommandozeile). Auf obigem Screenshot ist schon alles fertig.

Theoretisch kann man auch ohne separate Partition mit Swap arbeiten aber bei btrfs finden sich diverse (vermutlich alles veraltete) Informationen, dass es ggf. Probleme damit geben kann. Da ich aber auch keinen Vorteil darin sehe die Swap Datei in der Root Konfiguration zu haben und auch btrfs keine Vorteile dafür bringt, habe ich eine separate Partition mit 6GB erstellt um später ggf. auch Hibernation nutzen zu können.

Vorbereiten Partition mit Luks:

sudo cryptsetup luksFormat --type=luks2 -c xchacha12,aes-adiantum-plain64 -s 256 -h sha512 --use-urandom /dev/sda1

sda1 ggf. anpassen. Ich habe ein externes Laufwerk genommen, man kann das natürlich auch mit der SSD Karte machen. Faktisch braucht man aber eh ein externes Laufwerk oder ein bootbaren USB Stick um das Setup aufzusetzen, da man natürlich nicht das laufende Rootlaufwerk im Betrieb neu aufsetzten kann und man vermutlich auch die Daten überspielen möchte.

ACHTUNG: Der folgende Schritt löscht den Inhalt der Partition vollständig. Ihr werdet vorher gewarnt. Wenn ihr die Warnung übergeht, sind die Daten weg, wenn ihr vorher bereits das Dateisystem gelöscht habt, hat sich das aber eh schon erledigt.

Den Schritt muss man mit YES bestätigen und anschließend muss man das PW vergeben.

sudo cryptsetup luksOpen /dev/sda1 cryptrootssd

Öffnen des Luks Devices. Anschließend kommt die Passwortabfrage. Den Bezeichner cryptrootssd könnt ihr beliebig vergeben. Der wird aber im folgenden immer wieder benötigt.

Nun könnte man weitere Keyfiles oder Passwörter zum Luks Header hinzufügen, wenn Bedarf vorhanden ist.

Erstellung des Btrfs Dateisystems innerhalb des geöffneten Luks devices.

sudo mkfs.btrfs -L btrfs /dev/mapper/cryptrootssd

Hier seht ihr einen entscheidenden Unterschied zur bisherigen Handhabung Btrfs ohne Luks. Ab jetzt wird ausschließlich mit Mapper devices und dem soeben vergebenen Namen gearbeitet. L ist das Label (das ist Optional aber ich fand es relativ praktisch für die spätere Adressierbarkeit – wie das Label heißt ist auch wieder euch überlassen).

Es wird ein Verzeichnis für einen Mountpunkt erstellt.

Mkdir /btrfs

Einhängen der btrfs Partition unter btrfs.

sudo mount -o compress=zstd:1 /dev/mapper/cryptrootssd /btrfs
Volumes erstellen

Die Volumes sind im Wesentlichen für Snapshots relevant, weil sie sich später einzeln zurücksetzen lassen. Wie detailliert man das macht ist jedem selber überlassen. Theoretisch kann man für jedes Verzeichnis ein Volume erstellen, sinnvoll ist das aber meiner Meinung nach nicht. Ggf. macht jeweils ein Volume für /var/ /etc/ /home/ Sinn.

Das ist letztendlich eine Geschmacksfrage. Ein definitiv konsistenter Snapshot entspricht dem gesamten Root Laufwerk.

Das Verzeichnis /etc/ (alle Konfigurationen) lässt ich ggf. konsistent separat zurückspielen, wenn keine Programme dazu gekommen sind oder entfernt wurden. /var/ beinhaltet oft Logs, Mysql Datenbanken, Webseiten und /home/ ist zumindest dafür gedacht Benutzerdaten abzulegen.

Ich habe mich für folgendes  Setup entschieden:

btrfs (label und Einhägepunkt)
—ROOT
—sync1 (Backup von einem Server Root)
—sync2 (Backup von zweitem Server Root)
—snapshots
——ROOT_snaps
——sync1_snaps
——sync2_snaps

Ob man die Snapshots direkt nutzt oder nicht ist erst mal nicht relevant. Mit dem Layout sind sie aber zumindest vorbereitet.

Volumes anlegen

sudo btrfs subvolume create /btrfs/ROOT
sudo btrfs subvolume create /btrfs/sync1
sudo btrfs subvolume create /btrfs/sync2
sudo btrfs subvolume create /btrfs/snapshots
sudo btrfs subvolume create /btrfs/snapshots/ROOT_snaps
sudo btrfs subvolume create /btrfs/snapshots/sync1_snaps
sudo btrfs subvolume create /btrfs/snapshots/sync2_snaps

Und das Ergebnis bewundern:

sudo btrfs subvolume list -p /btrfs/
ID 256 gen 15306 parent 5 top level 5 path ROOT
ID 258 gen 15286 parent 5 top level 5 path sync1
ID 259 gen 15287 parent 5 top level 5 path sync2
ID 260 gen 14645 parent 5 top level 5 path snapshots
ID 261 gen 15290 parent 260 top level 260 path snapshots/ROOT_snaps
ID 262 gen 15290 parent 260 top level 260 path snapshots/sync1_snaps
ID 263 gen 15290 parent 260 top level 260 path snapshots/sync2_snaps

Wichtig dabei sind vor allem die IDs vorne. Die benötigt man in der /etc/fstab

Nun fehlt noch die Swap Partition.

sda2 ggf. wieder anpassen. Der Prozess ist der gleiche wie oben.

sudo cryptsetup luksFormat --type=luks2 -c xchacha12,aes-adiantum-plain64 -s 256 -h sha512 --use-urandom /dev/sda2

Öffnen

sudo cryptsetup luksOpen /dev/sda2 swap

Und als Typ Swap einrichten.

mkswap /dev/mapper/swap

Nun könnt ihr per rsync alle Datein von dem vorhandenen root Datenträger auf das root btrfs Subvolume kopieren.

Zwischenstand:

Die Vorbereitungen sind durch, nun geht es ans Eingemachte. Wie sieht blkid aus?

blkid
/dev/mapper/cryptrootssd: LABEL="btrfs" UUID="282cba41-e894-4938-9b66-76b75dfb7f6d" UUID_SUB="ca8842b1-7159-45c1-b686-fc3bcadb5631" TYPE="btrfs"
/dev/mapper/swap: UUID="c1f33a48-6a76-4fc9-9b39-b8298a7a7ca6" TYPE="swap"
/dev/mapper/cryptrootsd: LABEL="writable" UUID="cace300f-31e8-498c-8134-b6ba9dac5d12" UUID_SUB="4e539ec9-271e-4f8b-9a96-7b78035ce67a" TYPE="btrfs"
/dev/mmcblk0p1: LABEL_FATBOOT="system-boot" LABEL="system-boot" UUID="0468-A52F" TYPE="vfat" PARTUUID="87c6153d-01"
/dev/mmcblk0p2: UUID="71f6f452-8efe-4d0f-8a65-01bd18237e6d" TYPE="crypto_LUKS" PARTUUID="87c6153d-02"
/dev/sda1: UUID="87455e48-dae8-4e8d-8683-acc6ad6e8225" TYPE="crypto_LUKS" PARTUUID="99329026-01"
/dev/sda2: UUID="8459a5c7-9b08-4e4e-b76c-f0cdb5caf4e9" TYPE="crypto_LUKS" PARTUUID="99329026-02"

 

  • /dev/mmcblk0p1 = Boot Partition der microSD (250MB – ich würde eher 500 empfehlen um ggf. mehr Sicherheit für initramfs Images zu haben)
  • /dev/mmcblk0p2 = verschlüsselte Root microSD (Kopie von der SSD mit abweichender /etc/fstab und /etc/crypttab – ca. 128GB)
  • /dev/sda1 = Entspricht Luks 1 – Root Btrfs
  • /dev/sda2 = Entspricht Luks 2 – Swap
  • /dev/mapper/cryptrootssd = btrfs auf / in /dev/sda1
  • /dev/mapper/cryptrootsd = btrfs auf / in /dev/mmcblk0p2
  • /dev/mapper/swap = swap auf / in /dev/sda2

Bei euch sieht das zu dem Zeitpunkt natürlich anders aus, weil ihr maximal die SSD oder ein externes Laufwerk verschlüsselt habt und somit ggf. ein Mappereintrag weniger vorhanden ist.

Wie sieht die passende /etc/fstab dazu aus?

LABEL=system-boot /boot/firmware/ vfat defaults 0 1
/dev/mapper/cryptrootssd / btrfs defaults,ssd,compress=zstd:1,subvolid=256,subvol=/ROOT 0 0
/dev/mapper/cryptrootssd /btrfs btrfs defaults,ssd,compress=zstd:1 0 0
/dev/mapper/cryptrootssd /.snapshots btrfs defaults,ssd,compress=zstd:1,subvolid=261,subvol=/snapshots/ROOT_snaps 0 0
/dev/mapper/cryptrootssd /btrfs/sync1/.snapshots btrfs defaults,ssd,compress=zstd:1,subvolid=262,subvol=/snapshots/sync1_snaps 0 0
/dev/mapper/cryptrootssd /btrfs/sync2/.snapshots btrfs defaults,ssd,compress=zstd:1,subvolid=263,subvol=/snapshots/sync2_snaps 0 0
/dev/mapper/cryptrootsd /sd btrfs defaults,ssd,compress=zstd:1 0 0
/dev/mapper/swap none swap sw 0 0

Der Reihe nach:

  • Ganz oben das Boot Firmware Verzeichnis, dass unter Boot eingehängt wird und die Startdateien beinhaltet.
  • Dann kommt das Root Verzeichnis
  • Der nächste Eintrag hängt den kompletten btrfs Baum in das Verzeichnis btrfs ein. Das ist ziemlich praktisch, auch wenn man später ggf. mit chroot arbeiten muss / möchte, um die initramfs zu erstellen.
  • .snapshots wird als Volume unter Root angelegt. Da sich damit dann aber auch die Snapshots selbst unterhalb des Volumes Root, gibt es die Empfehlung die Snapshots woanders unterzubringen. Dafür habe ich also ein separates Volume angelegt. Damit Snapper damit arbeiten kann, muss es aber z.B. unter ROOT eingebunden werden, wenn man für ROOT snapshots erstellen möchte.
  • Sync 1 Snapshots (analog vorheriger Punkt)
  • Sync 2 Snapshots (analog vorherige beide Punkte)
  • SD Laufwerk unter SD (gleiches Konzept wie bei Btrfs der ganze Baum wird eingehängt auch hier Vorteilhaft für chroot / initramfs
  • Swap Partition

Und passend dazu die /etc/crypttab

cryptrootssd UUID=87455e48-dae8-4e8d-8683-acc6ad6e8225 key1 luks,initramfs,keyscript=decrypt_keyctl
swap UUID=8459a5c7-9b08-4e4e-b76c-f0cdb5caf4e9 key1 luks,initramfs,keyscript=decrypt_keyctl
cryptrootsd UUID=71f6f452-8efe-4d0f-8a65-01bd18237e6d key1 luks,initramfs,keyscript=decrypt_keyctl
# <target name> <source device> <key file> <options>

Achtung: Als bei mir der Kommentar in der ersten Zeile stand wurden Folgeeinträge nicht erkannt. Das merkt ihr spätestens beim erstellen der initramfs

Wichtig hier die UUIDs nicht /dev/sda1 verwenden,weil letzteres nicht eindeutig ist. Die UUIDs sind die von den Luks Devices und nicht die von den Mappern. key1 ist ein Platzhalter der dafür sorgt, dass alle Laufwerke mit einem Key entschlüsselt werden können (also letztlich einer Eingabe – wenn man das nicht macht darf man beim Start 3x das Passwort eingeben – Remotelogin geht dann überhaupt nicht!). Dafür ist auch der initramfs und der keyscript Eintrag notwendig.

Die Vorbereitung ist durch. Nun fehlt noch die Initramfs. Das decrypt_key script ist nicht Ubuntu Standard, sondern muss nachinstalliert werden.

sudo apt install keyutils

Weiterhin lässt sich das Entschlüsseln nur vornehmen, wenn man direkten Zugriff auf das Pi hat (Keyboard, Bildschirm). Wenn man das auch Remote machen möchte, muss man zusätzlich Dropbear installieren.

sudo apt install dropbear

Jetzt steht noch ein wenig Konfigurationsarbeit an. Dropbear kann auf einem anderen Port laufen als der Standard SSH Login. Der Vorteil ist, dass man dann keine Sicherheitswarnungen bekommt. Faktisch war ich aber schlicht zu faul einen separaten Port in der Firewall zu öffnen und immer dran zu denken welcher Port denn nun wohl der Loginport ist. Ich bin also bei Port 22 geblieben.

Ich greife von Putty (Windows) auf das Pi zu. Somit habe ich den key mit dem Puttygen erstellt. Dafür einfach mit dem Puttygen einen Key erzeugen, den privaten Teil speichern und anschließend den öffentlichen Teil über die Zwischenablage auf den Server bringen. Der öffentliche Teil muss unter /etc/dropbear-initramfs/authorized_keys abgelegt werden.

Das Schema ist z.B. Typ, Key, Bezeichnung – also ssh-rsa key123ganzviele blabla

In der /etc/dropbear-initramfs/config

DROPBEAR_OPTIONS="-p 22"

Ich vermute das ist Standard aber schaden kann es ja nicht.

Ansonsten noch in etc/default/dropbear

NO_START=1 auf NO_START=0

Da ihr in der Regel den Dropbear nicht als SSH Zugang nach dem Boot verwenden möchtet, könnt ihr den Start des Dienstes deaktivieren:

sudo systemctl disable dropbear

Nun noch die Konfiguration der initramfs und schon kann es los gehen.

/etc/initramfs-tools/initramfs.conf

BUSYBOX=y
CRYPTSETUP=y
DROPBEAR=y
DECRYPT_KEYCTL=y

Ich weiß nicht, ob das alles nötig ist (speziell bei dem letzten Eintrag habe ich Zweifel, ob der korrekt ist bzw. die Initramfs Erstellung erkennt eigentlich auch von alleine was benötigt wird aber doppelt hält besser.

/etc/initramfs-tools/modules

btrfs
cryptsetup
decrypt_keyctl
busybox

Doppelt hält besser sagte ich ja schon. 😉

Nun geht es an das eigentliche Erstellen der initramfs. Bei dem ersten Laufwerk habe ich es ohne chroot gemacht. Das hat in dem Fall auch funktioniert. Beim Boot wurde das Laufwerk nicht automatisch entschlüsselt. Ich konnte aber die entsprechenden Befehle sudo cryptsetup luksOpen /dev/sda1 cryptrootssd und den Mount (siehe oben) manuell einfügen. Anschließend habe ich per exit die Busybox verlassen und konnte ganz normal ins Betriebssystem booten und dort eine initramfs erstellen.

Beim zweiten Laufwerk ist mir das nicht gelungen. Dort musste ich explizit über Chroot die initramfs erstellen, da offensichtlich das Laufwerk in der initramfs verdrahted wird. Die Guides, die ich gelesen habe hörten sich alle eher so an, als wenn das nicht der Fall ist. Zumindest sollte der Pi die cryprootssd entsperren, obwohl ich alle Configdateien vorher auf die microSD um gestellt hatte

Bevor nun neu gebootet werden kann muss noch die cmdline.txt angepasst werden (vorher Kopie erstellen):

net.ifnames=0 dwc_otg.lpm_enable=0 console=serial0,115200 console=tty1 root=/dev/mapper/cryptrootssd rootflags=subvol=ROOT rootfstype=btrfs elevator=deadline fsck.repair=no rootwait fixrtc cryptdevice=UUID=87455e48-dae8-4e8d-8683-acc6ad6e8225:cryptrootssd

Auch dieser Eintrag bezieht sich auf die Luks ID. Wenn man wie im meinen Fall zwischen zwei Laufwerken wechselt benötigt man also zwei cmdline.txt Files und zwei initramfs (initrd.img). Einen komfortableren Weg habe ich noch nicht gefunden. Sobald der Pi 4 echten Boot von USB beherrscht kann man die SD von dem USB Laufwerk trennen und das Rumgehampel entfällt.

Das hebt auch die Wechselwirkungen im Kontext initramfs auf.

Weiterhin muss man den Raspi noch davon überzeugen die Initramfs zu nutzen. Dazu unter boot/firmware die Datei config.txt um folgenden Text ergänzen:

initramfs initrd.img followkernel

Nun noch die initramfs erstellen. Die alte initramfs wird als bakup erzeugt. Falls also irgendwas schief geht, funktioniert die noch. Wenn ihr also mit eurem ursprünglichen Bootvolume starten wollt, müsst ihr das Backup zurück kopieren. Wenn ihr mehrfach die Initramfs erstellt (siehe unten), dann macht vorher eine Sicherheitskopie, sonst hilft das Backup auch nichts mehr.

Chroot Umgebung vervollständigen:

mount /dev/mmcblk0p1 /btrfs/boot/firmware

(ggf vorher mit mkdir Verzeichnis anlegen, wenn nicht vorhanden)

mount -t proc none /btrfs/ROOT/proc
mount -t sysfs none /btrfs/ROOT/sys

Mit Root Nutzer (sicherheitshalber):

chroot /btrfs/ROOT/

Und jetzt noch eine Runde beten:

update-initramfs -u -k all

Bei der Erstellung der initramfs sollte man tunlichst darauf achten, ob Fehler ausgeworfen werden. Der einzige Fehler, den ich ignoriert habe war, dass das Root Volume nicht erkannt wurde (Sicherheitshalber hatte ich beim ersten Boot alle anderen Volumes in fstab / crypttab auskommentiert. Trotzdem kam die Meldung, obwohl nur noch ein Volume vorhanden war und das offensichtlich Root war). Wenn ich das richtig sehe, dann prüft cryptsetup nicht gegen das chroot Dateisystem, sondern gegen das System mit dem gebootet wurde. Dementsprechend können auch mehr Fehler auftreten.

Bei einem Folgeversuch habe ich dann nichts mehr auskommentiert. Geändert hat sich sowohl am Ergebnis als auch an der Fehlermeldung nichts. Das Root Volume sollte in der crypttab an erster Stelle stehen. Theoretisch ist es ja ganz leicht zu erkennen welches das Bootvolume ist – so viele Einträge, die auf / mounten gibt es in der fstab ja nun nicht. Zusätzlich steht auch in der cmdline.txt eindeutig drin wo die Reise hingeht.

Wenn man also keine Fehler sehen will muss man ggf. im Boot etc Ordner die fstab / crypttab temporär anpassen. Ich würde davon aber abraten. Wenn euch das Raspi dann abschmiert, müsst ihr in der initramfs die Werte mit cat zurückstellen. Das macht keinen Spaß.

Wenn der Raspi nicht Bootet könnt ihr entweder warten bis die initramfs auftaucht und dann versuchen das Problem zu korrigieren oder ihr steckt die microSD Karte in einen beliebigen Lauffähigen Rechner und kopiert die alte initrd.img.bak und euer cmdline.txt.bak (oder wie auch immer ihr es genannt habt) zurück. Dann startet der Pi wieder von microSD.

Wie sieht die Anmeldung aus:
Am System:

Entsperrung direkt am System

Das Timing ist etwas blöd. Oben sieht man Caching Passphrase for cryptrootssd, dann pfuscht Dropbear mit seinen Netzwerkmeldungen dazwischen. Das zweite Caching passphrase for cryptrootssd sieht man zuerst nicht. Ein simpler Druck auf die Spacetaste oder eine beliebiege andere Taste löst das Problem aber. Danach kann man das Kennwort eingeben und der Boot erfolgt. Die weiteren Laufwerke werden freigeschaltet (Achtung, die erste gedrückte Taste wird schon als erstes Zeichen im Kennwort ausgelegt).

Über Putty

Dropbear

Wie oben nur in dem Fall die microSD als Bootmedium

Putty Key für Dropbear

Der Bereich Auth ist für die Keyübergabe des private Key relevant.

Putty Root Login mit Key

Eingabe der Passphrase über Putty und Dropbear SSH

Anmerkungen:

Ich habe sowohl mit abgeleiteten Schlüsseln als auch mit Schlüsseln in Datein experimentiert. Beides ist aus meiner Sicht nicht sinnvoll.

In einigen Konfigurationen wird für Dropbear eine feste IP vergeben. Das hat bei mir im Kontext des Cloudsetup in Ubuntu 20.04 dazu geführt, dass die Netzwerkverbindungen nicht mehr korrekt funktionierten, obwohl die Einstellungen sich nach meinem Verständnis nur auf die Startumgebung auswirken sollten. Faktisch konnten Namen aufgelöst werden zu IPs. Direkte Verbindungen zu Ips gingen aber nicht. Das hatte sich so noch nie und ergibt für mich auch keinen Sinn.

Teilweise werden in Guides externen Scripts abgelegt (hooks). Die sind nach meinen bisherigen Tests nicht erforderlich.

Spaß ist anders.

Wenn ihr das nicht nur für einen externen Datenträger wie zum Beispiel eine SSD machen wollt ist das Prozedere weitestgehend identisch. Lediglich die /etc/crypttab und die /etc/fstab unterscheiden sich. Um zwischen beiden Systemen zu wechseln müsst ihr die cmdline.txt und die initrd.img tauschen. Der Einzige Bereich wo sich die beiden Systeme unterscheiden ist die Bootpartition und dort speziell in denen beiden Datein. Bei Kernelupdates muss man entsprechend daran denken zwei neue initramds zu erstellen.

Sobald das Pi sauber von einem externen Medium bootet, kann man das ggf. etwas besser trennen. Allerdings weiß ich auch nicht was für Effekte entstehen, wenn der init auf einem älteren Kernel erfolgt als der Rest.

Der Effekt würde zum Beispiel entstehen, wenn man standardmäßig mit der SSD bootet und dort ein Kernelupdate durchführt (apt update / apt upgrade). Die initrd.img wird durch das Update auf den neusten Stand gebracht. Die zweite initrd.img für den microSD Boot aber nicht. Wenn man nun noch per rsync das Root Dateisysetem von der SSD auf die microSD synchronisiert, dann hat man bzgl. der initrd.img für die SD einen Schiefstand im Vergleich zu dem restlichen System.

Das käme wohl auf einen Versuch an, könnte aber ziemlich unschön Enden. Also besser beide Images erneuern bei einem Kernelwechsel oder ein Komplettimage der micro SD erstellen und dann testen.

Der Dropbear Remotezugang hat übrigens auch Vorteile, wenn ihr nicht wirklich “remote” seid. Erstens ist es ziemlich blöd, wenn man auf der Console ohne Nano und co arbeiten muss, dann auch noch Texte zu kopieren. Wenn sich über SSH anmeldet hat man eine Maus und copy & paste, wenn man zum Beispiel Putty nutzt.

Zweitens benötigt man dann auch immer eine angeschlossene Tastatur / einen Bildschirm.

Fazit:

Luks mit Btrfs und so einfach! Die Windows Benutzer, die sowas mit ein paar einfachen Klicks machen sind doch nur verweichlicht oder einfach vernünftiger?

Auf jeden Fall fehlt in dem Linux Luks Kontext ganz viel Liebe. Für mich ist es unverständlich, dass solche essentiellen Dinge nicht out of the Box gehen. Die Remoteöffnung ok das ist sicher ein spezieller Anwendungsfall aber Anmelden mit gleichzeitigem Freischalten von einem oder mehreren Laufwerken gehört in den Kernel und zwar ohne rumgehampel mit zusätzlichen Tools oder initramfs und zwar auch und gerade für das root Dateisystem.

Mit allen Schritten hat mich die ganze Aktion mehrere Tage gekostet und das Lesen von grob 20 Guides und versuchen darin die Versatzstücke und Zusammenhänge zu finden. Jeder hat in seinen Guides (ich sicher auch) Schritte, die nicht erforderlich sind, nicht zu Ubuntu passen oder veraltet sind. Daraus halbwegs sinnvolle Zusammenhänge zu erkennen ist nicht so einfach.

Da ich den Guide aus dem Gedächtnis zusammen geschrieben habe, gebe ich keine Garantie auf Vollständigkeit, habe aber hoffentlich alles erwischt was relevant ist und die diversen Sackgassen ausgelassen.

Ich habe jetzt folgendes Setup:

  • SSD 1TB (BTRFS, Bootpartition vorbereitet, aktuell ungenutzt), Datenpartition Verschlüsselt mit Backups von 2 Servern, Swap verschlüsselt)
  • microSD 128GB (BTRFS, Bootpartition geteilt, Datenparition verschlüsselt und enthält keine Backups) – wird regelmäßig per rsync aktualisiert, ist also nahe an dem Stand der SSD)
  • microSD2 128GB (wie die vorherige SD per DD als 1:1 Image angelegt. Anschließend UUID, PARTUUID geändert, dev mapper von cryptrootsd auf cryptrootsd2 geändert (fstab,cmdline.txt,crypttab). Keine Aktualisierung per rsync. Liegt neben dem Pi als Notfallboot, falls ich mir die erste microSD beschädige und ich per default auf microSD Boot konfiguriert, kann aber leicht auf SSD umgestellt werden.
  • Raspian (16GB microSD reicht vollig) unverschlüsselt für Firmwareupgrades

D.h. ca. 50€ für microSDs aber das Geld ist gut angelegt. Der Zeitbedarf einer evtl. Neuinstallation + Konfiguration ist sehr viel größer.

Update: 20.05.2020

Es gibt jetzt ganz frisch die ersten Beta Versionen für direkten Boot von einem USB Gerät. An dem Guide ändert das wenig. Lediglich der fstab Mount für die Firmware ändert sich von der microSD auf das entsprechende Device. Man benötigt aber die aktuell Firmware (die lässt sich nur über ein Raspian Image installieren) und dann die neuen startelf dateien. Wie und wann die nach Ubuntu kommen ist noch offen. Das kann man sich vermutlich auch manuell zusammen basteln aber ggf. macht es durchaus Sinn noch etwas zu warten.

1 2 3 4 5 6 11