Nudge am 28.04.2013

Ubuntu: Update von 12.10 auf 13.04

in Linux | Tags: 13.04, Muon, Raring Ringtail, Ubuntu, Update, Upgrade

Seit dem ich von Debian Testing auf Ubuntu, genauer gesagt Kubuntu, wechselte, war für mich die Computerei mit Linux in etwas ruhigeres Fahrwasser geraten. Statt dem Rolling Release von Debian, bei dem täglich mit neuen Paketen rechnen konnte, tauchte bei Kubuntu die gleiche Menge an Updates eher pro Woche auf und enthielt in der Regel nur keine Bugfixes. Nun stand mit der Erscheinung von Ubuntu’s neuer Version 13.04 namens Raring Ringtail allerdings das erste größere System-Upgrade bevor. Hier mein kleiner Erfahrungsbericht zum Update.

Sicherheitshalber wartete ich ab, bis ich mein verborgtes USB-CDROM von einem Freund zurück erhielt. Das X1 Carbon hat als Ultrabook kein eingebautes Laufwerk, und ich wollte nicht in der Unbootbarkeit enden, sollte etwas schiefgehen. Da ich die volle Festplatte verschlüsselt habe, könnte das bereits bei fehlenden Modulen im Bootprozess passieren. Seelisch und moralisch stellte ich auch auf den Notfall ein, das System komplett neu installieren zu müssen. Was nicht ganz so schlimm ist, da ich mein Home per Git verwalte. Im Falle eines Falles oder einer Migration kann ich es schnell von meinem Server neu ziehen.

Zunächst installierte ich alle Aktualisierungen der vorhandenen Version 12.10. Damit purzelte auch eine neue Version von Muon herein. Muon ist der Updater von Ubuntu. Dieser meldete sich in der Systemleiste mit der freundlichen Ankündigung, dass eine neue Ubuntu-Version verfügbar ist. Und so begann ich nun mein Upgrade.

Ein Start von Muon brachte erst einmal nicht viel. Der KdeSudo-Dialog forderte mich auf, mein Passwort einzugeben. Nichts passierte. Root-Passwort? Falsch! Noch einmal, noch einmal. Ende. Was war hier passiert? Achso, ich bin nicht in /etc/sudoers eingetragen. Ich mag den Sudo-Mechanismus nicht. Der Grund hierfür liegt darin, dass mit einer einmal autorisierten Eingabe der Root-Zugriff quasi gecached ist und jeder weitere Call mit sudo xyz schlichtweg hart durchgeführt wird. Und das kann meines Erachtens auch von mich angreifenden Prozessen oder Personen schamlos ausgenutzt werden. Dann arbeite ich lieber direkt per su als Root und beende die Shell wieder, wenn ich fertig bin.

GUI – Can’t touch this

Gut, sudoers nachgetragen, Muon gestartet, Passwort eingegeben, und nichts passierte mal wieder. Nachdem ich es noch ein paar Mal probiert hatte, wechselte ich auf die Kommandozeile und schob das Update per

1
# do-release-upgrade
# do-release-upgrade

an. So eine Konsole ist doch was feines. Wenn grafische Prozesse abschmieren, kann man nur hoffen, sie hätten saubere Logs geschrieben. In einer Konsole schmiert ein Prozess ab und hinterlässt gegebenenfalls noch eine aufschlussreiche Bemerkung auf Standard-Output oder dem Fehler-Kanal. Beides bleibt sichtbar stehen, während GUIs einfach entgleiten.

Viel Platz in /tmp einzuplanen

Nun muckerte das Update herum, dass /tmp mit noexec eingehangen war. Richtig, aber ein weiteres Sicherheits- und Performance-Feature! Mein /tmp ist per tmpfs eingebunden (long live the SSD) und zwar noexec,nosuid. Diese Einstellungen sollte man auf jeden Fall für einen Server in Betracht ziehen. Zum Beispiel werden damit Session-Files nicht bei jedem Request von der Platte geholt, sondern performant aus dem RAM bedient. Ich konnte davon ausgehen, dass ein Distro-Wechsel alle neuen Pakete ziehen möchte, und das würde meine 512 MB fix für /tmp sprengen. Also nahm ich das tmpfs direkt raus und ließ beim nächsten Reload /tmp direkt auf der Root-Partition.

Ein neues do-release-upgrade lief nun an und ratterte diverseste Paketquellen durch. Und das ist auch gleich mein erster Kritikpunkt. Anstatt die konfigurierten Quellen aus /etc/apt/sources.list zu nehmen und die Distributionskennung umzustellen, erschienen hunderte Fehlermeldungen zu unbekannten oder unerreichbaren Quellen. Solche Zeilen starten bei apt-get immer erst mit “Fetch …” und werden später mit “Fehl …” oder “Ign …” abgetan. Ich kann mir vorstellen, dass Linux-Beginner hier einfach mal verzweifelt ausgestiegen wären. Am Ende dieses mich etwas irritierenden Vorgangs wurden mir rund 1400 Pakete als neu, ca. 30 als veraltet und 4 glaube ich als aktuell gemeldet. Da sollte man schon mal über 1 GB in /tmp freigaben. OK, na dann mal los.

Pakete aktualisieren, ersetzen und bereinigen

Vor dem Download wurde ich darauf hingewiesen, dass das Update mehrere Stunden dauern könnte. Der Updater ist übrigens immer freundlich und fragt an mehreren Stellen nach, ob man wirklich weiter verfahren möchte. Ein kleiner Blick auf die Uhr (“damn, dann komme ich heute gar nicht mehr ran…”), eine kurze Bestätigung (“Na gut
…”) und schon rasten wie bei einem “üblichen” apt-get dist-upgrade gewohnt die Paketnamen durch den Äther. Wenige Minuten später (danke an dieser Stelle an 32fach-DSL von Kabel DE, die mich heute nicht er-Drossel-ten) war alles Erforderliche im apt-Cache gelandet.

Das Update fuhr wie gewohnt mit der Paket-Ersetzung aktiv fort, und hier tauchten weitere kleine Mängel auf: Nach einigen Paketen werden Trigger für die Anpassung von Menüs, udev, ureadahead, initramfs und install-info ausgelöst. Was bei einem täglichen Update ein-zweimal okay ist, wird hier viel zu oft durchlaufen. Außerdem wurden vielfach die gleichen Locales neu generiert. Ich weiß nicht, ob das Not tut, aber ich denke, das könnte man noch verbessern. Leider hatte ich gerade vor dem Upgrade Latex neu installiert, sodass auch die texmf-Dateien immer wieder neu generiert wurden.

Danach ging es an die Entfernung der veralteten Pakete. Hierzu gehörte auch libllvm3. Da ich die Festplatte verschlüsselt habe, war ich etwas unsicher. Im irrigen Glauben, dass llvm irgendetwas mit lvm, der flexiblen Partitionserwaltung zu tun hat, hielt ich dies für eine heikle Änderung. Eine kurze Recherche ergab aber: Das Paket heißt “low-level virtual machine” und hat mit Dateisystemen gar nichts am Hut. Merkwürdigerweise erschienen nach der Entfernung eine Handvoll leak file descriptors, eine unschöne Sache. Die könnte gegebenenfalls aber auch ganz unabhängig vom Update passiert sein.

Ubuntu staubt hier natürlich ein paar generelle Debian-Lorbeeren ab. Das schöne und flexible deb-Paketformat und das on-the-fly austauschen sogar von laufender Software sind Dinge, die ich nicht mehr missen möchte. Was ich mir noch wünschen würde wäre eine Alternative zu Delta-RPMs in Deb, um viel Netzwerk-Traffic sparen zu können.

Endlich: der Neustart in 13.04 Raring

Schick präsentierte sich der ecryptfs-Dialog zum Booten der Platte in dunkleren Farbtönen als das bisherige undefinierbare blaugrau. Und der Rechner bootet. Das ist schon einmal sehr gut, meine Sorgen waren vermutlich ungerechtfertigt. Nach wenigen Sekunden – das ist bei einer SSD wirklich schön – grüßte mich lightdm mit einem neuen, aber etwas 80er wirkenden vollblauen Farbverlauf. Schnell anmelden, das möchte man nicht wirklich lange sehen!

Und ebenso schick präsentiert sich KDE 4.10 mit schwarzer (oder transparenter?) Fensterleiste. Da ich einen schwarzen Hintergrund bevorzuge, reduziert sich der Bildschirm so wirklich auf das minimal Notwendige:

In KDE selbst ist mir kaum was als Änderung aufgefallen, einzig die etwas dicken, einfarbigen Dialog-Ränder scheinen neu zu sein. Schattenverläufe halte ich eigentlich weiterhin für eleganter, aber vielleicht gibt es einen Trend zum Flächigen (Windows 8)? LibreOffice in Version 4.0 startete wirklich flott, aber ich habe noch keins der neuen Features angetestet.

Zuletzt noch eine sehr schöne Sache: Beim Update wird angeboten, alte, nicht mehr benötigte Kernel zu entfernen. Außerdem erkannte wohl Muon, dass mein Kernel eine lowlatency-Ausgabe ist und installierte daher auch einen solchen neu. So meldete uname nun ein zeitgemäßes 3.8.0-19-lowlatency. Sehr schön.

Fazit

Ich habe Euch heute meine Erfahrungen eines Upgrades von Ubuntu 12.10 auf 13.04 Raring Ringtail beschrieben. Zwar ging es hier um die Kubuntu-Ausgabe mit KDE als grafischer Oberfläche (Window Manager), aber die durchzuführenden Schritte, Probleme und Anforderungen dürften auch für alle Ubuntu-Derivate gelten.

Also: Ich würde es wieder tun. Meine vorher bestehenden Zweifel über ein Release-Wechsel waren unbegründet. Die Maintainer und Entwickler im Hause Canonical wissen anscheinend sehr genau, was sie machen. Ich glaube, für ein versioniertes Betriebssystem solch ein gut funktionierendes Update anzubieten, ist schon fast einmalig und verdient an dieser Stelle meinen vollen Respekt.

Auf der anderen Seite überlegt Ubuntu ja gerade, auf ein Rolling Release zu wechseln…^^

 


Das mark ich mir: Alltagz Mr Wong Yigg Del.icio.us Yahoo MyWeb Blinklist Google folkd
 

Leave a Reply

Your email address will not be published. Required fields are marked *