Seit zwei Tagen ist das erste Service-Update von Ubuntu 18.04 verfügbar. Geändert hat sich (außer den üblichen Updates) nichts. Wenn Sie Ubuntu 18.04 installiert haben und alle Updates durchgeführt haben, dann zeigt /etc/os-release jetzt Version 18.04.1.
cat /etc/os-release
NAME="Ubuntu"
VERSION="18.04.1 LTS (Bionic Beaver)"
...
Der springende Punkt dieses Minor-Updates besteht darin, dass bei dieser Gelegenheit auch neue Installations-Images erstellt wurden. Das erspart einerseits riesige Updates unmittelbar nach der Installation und gibt Canonical andererseits die Möglichkeit, Probleme im Installer zu beheben. Bei den gewöhnlichen Desktop-Images (Installationsprogramm »Ubiquity«) gibt es hier keine sichtbaren Änderungen, ebensowenig im von Debian übernommenen traditionellen Server-Installationsprogramm (Download-Seite).
Große Änderungen hat es dagegen beim relativ neuen Server-Installationsprogrammm (»Subiquity«) gegeben (Download-Seite) — und davon handelt dieser Beitrag.
Subiquity 18.04: Elegante Server-Installation ohne LVM und RAID
In Version 18.04 wurde Subiquity vielfach gelobt, weil das text-basierte Installationsprogramm wesentlich komfortabler zu bedienen ist ist der bisherige ‚Alternate-Installer‘. Server-Administratoren wurden mit Subiquity aber trotzdem nicht glücklich: LVM und RAID wurden nicht unterstützt, vorhandene Dateisysteme auf der Festplatte konnten nicht weitergenutzt werden etc. Subiquity war einer LTS-Version wahrlich unwürdig.
Subiquity 18.04.1: Neuer Versuch, immer noch nicht viel besser
Mit dem Release 18.04.1 wollte Canonical es besser machen. LVM und RAID (Level 0, 1, 5, 6, 10) werden nun offiziell unterstützt. Die Navigation durch die Partitionierungsmenüs ist einfacher als beim Alternate-Installer, aber zufriedenstellend funktioniert der Installer leider weiterhin nicht.
Für meine Tests habe ich eine virtuelle Maschine mit zwei Festplatten eingerichtet. Mein Ziel war eine RAID-1-Konfiguration mit LVM, also das, was ich auf meinen realen Servern üblicherweise verwende: Die beiden Festplatten werden zu einem RAID-1-Verbund kombiniert (Mirroring), darin wird ein LVM-System eingerichtet, und in diesem die Logical Volumes für Swap, / (Root) und /boot.
Im ersten Versuch habe ich das Setup so gewählt:
- in beiden Festplatten eine möglichst große Partition einrichten
- diese Partitionen zu RAID-1 verbinden
- darin LVM aufsetzen
- darin Logical Volumes für /boot, Swap und / einrichten
Obwohl die Menüführung unkompliziert ist, dauert es ein paar Minuten, um alle Einstellungen durchzuführen. Zum Schluss meckert Subiquity aber, dass die /boot-Partition direkt auf einer Festplatte sein müsse.
Gut, es ist üblich, dass /boot außerhalb von LVM ist, auch wenn GRUB durchaus damit zurecht kommen würde. Also zweiter Versuch:
- in den beiden Festplatten je zwei Partitionen einrichten, eine kleine und eine große
- die beiden kleinen Partitionen zum RAID-Verbund 1 verbinden
- RAID-Verbund 1 direkt für /boot nutzen
- die beiden großen Partitionen zum RAID-Verbund 2 verbinden
- im RAID-Verbund 2 LVM einrichten
- dort Logical Volumes für Swap und / einrichten
Subiquity ist immer noch nicht zu frieden. /boot muss direkt auf einer Festplatte liegen, auch RAID ist verboten. Das ist eine absurde Anforderung. Wenn die falsche der beiden Festplatten kaputt geht (also die ohne /boot-Partition), dann verliere ich zwar dank RAID für das restliche System keine Daten, booten kann ich aber auch nicht mehr.
Mangels besserer Alternativen dritter Anlauf:
- auf der ersten Festplatte zwei Partitionen einrichten:
- 1 GByte mit ext4 für /boot
- der Rest für RAID
- auf der zweiten Festplatte eine Partition für RAID
- /boot-Dateisystem direkt auf der ersten Festplatte einrichten
- die großen Partitionen beider Festplatten mit RAID-1 verbinden
- den RAID-Verbund für LVM nutzen
- im LVM Logical Volumes für Swap und /
Diese Konfiguration akzeptiert Subiquity. Während ich dem Rechner einen Hostnamen geben und meinen Account einrichten darf, beginnt Subiquity mit den Installationsarbeiten — nur um diese wenig später mit einer sehr unspezifischen Fehlermeldung an error has occurred zu beenden (siehe die Screenshots unten).
An dieser Stelle habe ich aufgegeben. (Genau genommen habe ich die dritte Konfiguration noch einmal exakt gleich durchgeführt, um eventuelle Fehler meinerseits auszuschließen — gleiches Resultat.)
Screenshots
Fazit
Wenn Sie Ubuntu in eine neue virtuelle Maschine (eine Disk, weder LVM noch RAID) installieren möchten, ist Subiquity OK. Für alle anderen Fälle — »echte« Server-Installationen also — müssen Sie den Alternate Installer verwenden. Achten Sie schon beim Download darauf! Den Alternate-Installer finden Sie hier.
Vielen Dank für den Blog-Eintrag!
Mich wundert es sehr, dass Ubuntu den Alternate Installer so versteckt „nebenbei“ anbietet. Gerade bei bestehenden Server-Installationen bzw. Upgrades ist es doch so wichtig, dass hier eine vernünftige ISO zum Einsatz kommt.
Frage: Welchen Vorteil soll der neue Subiquity Installer denn dann überhaupt bieten??
komfortablere Bedienung, etwas schneller (weil die Installation parallel zu den letzten Einstellungen durchgeführt wird)
an sich spricht nichts gegen Subiquity, aber das Programm ist halt überhaupt noch nicht ausgereift