dist-upgrade-Verfettung

[hikaru]

Hallo,

ich muss mal was beichten. Entgegen guter Debianusertradition mache ich Releasewechsel für gewöhnlich nicht über ein dist-upgrade sondern über eine Neuinstallation. Rein pragmatisch hatte das den Grund, dass sich das bisher durch starke Änderungen in meinen Nutzungsgewohnheiten zwischen zwei Releases oder in Debian selbst meist gelohnt hat. Ein weiterer Grund, der jetzt mehr in den Vordergrund tritt ist, dass ein per dist-upgrade erzeugtes neues Release deutlich mehr für mich nutzlose Pakete (und damit Speicherplatzanforderungen) hat als eine Neuinstallation.

Dazu habe ich gestern mal einen Test gemacht. Ich habe in Virtualbox zwei virtuelle Maschinen erstellt, jeweils eine Xfce-Standardinstallation mit Netzwerkunterstützung von der amd64-CD1 für Wheezy (7.8) und von Jessie (8.1). Anschließend habe ich ein dist-upgrade der Wheezy-VM auf Jessie gemacht und den Speicherplatz verglichen. Die per dist-upgrade angehobene Maschine brauchte gut 600MB mehr Speicherplatz als die Jessie-Neuinstallation. Ich finde das bei rund 3GB Gesamtvolumen ziemlich krass und es würde mich mal interessieren, wie andere dieser Problematik begegnen, falls sie es überhaupt tun.


Im Detail:
Vergleich der Ausgaben von df für ein frisch installiertes Xfce/amd64:
Wheezy:

Code: Alles auswählen

Dateisystem    1K-Blöcke Benutzt Verfügbar Verw% Eingehängt auf
rootfs           9848352 3093776   6254304   34% /

Jessie:

Code: Alles auswählen

Dateisystem    1K-Blöcke Benutzt Verfügbar Verw% Eingehängt auf
/dev/sda1        9717280 2817688   6382936   31% /

Schon hier belegt Wheezy fast 300MB mehr als Jessie, Vergleiche zwischen verschiedenen Releases finde ich aber nicht sonderlich interessant.

Die dazugehörigen Paketlisten (dpkg -l):
Wheezy: 38663
Jessie: 38664

Nach einem dist-upgrade der Wheezy-Maschine, anschließendem Purgen des Wheezy-Kernels inklusive seiner Headers, einem apt-get --purge autoremove und Leeren des apt-Caches sagt df das:

Code: Alles auswählen

Dateisystem    1K-Blöcke Benutzt Verfügbar Verw% Eingehängt auf
/dev/sda1        9717280 3460620   5740004   38% /

(Paketliste: 38665)
Hier kommen gegenüber der ursprünglichen Wheezy-Installation also auch nochmal 350MB hinzu, was wegen des Release-Wechsels für sich allein genommen wiederum uninteressant ist. Interessant ist aber, dass sich zwei Systeme die deren Ziel es meinem Verständnis nach sein sollte möglichst gleich zu sein um über 600MB voneinander unterscheiden.

Man möge jetzt deborphan als weiteren Reinigungsschritt einwerfen. Dessen Auswirkung ist aber mit unter 2MB in der Standardeinstellung bzw. 23MB beim (nicht gewollten) Löschen aller Endpakete vernachlässigbar:
38666

Natürlich ließe sich das dist-upgrade-Jessie per Hand auf den Zustand des neu installierten Systems zusammenstutzen, aber die Pakete zu vergleichen ist mühsam, da man ja in der Praxis keine Referenzinstallation hat zu der man ein diff machen könnte. Und automatische Tools die das für einen übernehmen sind mir nicht bekannt.
Als Fazit stellt das für mich das dist-upgrade als Mittel zum Release-Wechsel in bestimmten Szenarien in Frage. Als Beispiel: Ich habe ein Netbok mit einer 4GB-SSD. Da tun 600MB durchaus weh.

[kalle123]

Interessant! Hab eine Neuinstallation eigentlich schon immer bei Versionssprüngen gemacht. Aus nem Gefühl raus, man müllt sich die Maschine mit der Zeit zu ...

[inne]

Vergleich mal die Paketlisten:

Code: Alles auswählen

comm -3 <(awk '$1=="ii" {print $2}' 38663.txt|cut -d: -f1|sort) <(awk '$1=="ii" {print $2}' 38665.txt|cut -d: -f1|sort) 

38663.txt Neuinstallation
38665.txt Dist-Upgrade

richtig verstanden?

Dann fehlen wohl auch Sachen, die man als eigenstäniges ganzen/geschlossenes ansehen kann z.B. Python3, JRE. Oder werte ich das hier flasch aus?
600MB sind schon krass.

[hikaru]

Vergleich mal die Paketlisten:

Code: Alles auswählen

comm -3 <(awk '$1=="ii" {print $2}' 38663.txt|cut -d: -f1|sort) <(awk '$1=="ii" {print $2}' 38665.txt|cut -d: -f1|sort) 

Ein deutliches Ergebnis:

Code: Alles auswählen

$ comm -2 -3 jessie.txt wheezy.txt | wc -l
8
$ comm -1 -3 jessie.txt wheezy.txt | wc -l
318

jessie.txt ist die Neuinstallation (38664), wheezy.txt das von Wheezy hochgezogene dist-upgrade inklusive aller Reinigungsmaßnahmen außer deborphan (38665).
comm -3: 38667

38663.txt Neuinstallation
38665.txt Dist-Upgrade

richtig verstanden?

Fast. 38664 ist die Neuinstallation. 38663 war das Wheezy-System vor dem dist-upgrade.

Dann fehlen wohl auch Sachen, die man als ganzen/geschlossenes ansehen kann z.B. Python3, JRE. Oder werte ich das hier flasch aus?
600MB sind schon krass.

Sieht so aus. Der Neuinstallation fehlen auch die Kernelheader und gcc-Compiler. Werden die zum dist-upgrade gebraucht, was sonst vieleicht das Installersystem macht?

[inne]

Kannst du interesse halber noch alle Pakete auflisten, die nicht als Abhänigkeit installiert wurden.
Edit:
Ne andesrum!
Es kann ja fast nur daher kommen, das der Debian-Installer in Wheezy mehr Pakete installiert als der von Jessie?
Vielleicht hatte man mit Wheezy mehr End-User-Programme vor-installiert...

[hikaru]

Ich kann dir nicht folgen.

[inne]

Wenn unter Wheezy Brasero als Brennprogramm installiert wurde und nun unter Jessie Xfburn, dann wird Brasero beim Dist-Upgrade imo mit durchgeschliffen und bei der Neuinstallation wird nur Xfburn installiert und Brasero samt Abhänigleiten fehlt dann dort.
Als konkretes Beispiel, wo mir nun einfällt das es so sein könnte.


Mal die Ausgaben von apt-mark showmanual vergleichen.

Edit:
Oder z.B. auch solche Abhänigkeisstrukturen: exfalso: Suggests: brasero | k3b | xfburn. Solche sich dann anhäufenden Abhänigkeiten werden ja imo auch nicht entfernt.

[hikaru]

Ja, das ist natürlich ein Argument.
Bei Brasero wäre die Sache vermutlich noch recht einfach. Wenn ich es schon unter Wheezy nicht benutzt hätte, dann hätte ich es wohl schon vor dem dist-upgrade runtergeschmissen. Aber bei diversen Libs bei denen man nie so genau weiß wozu sie gut sind wird die Sache schon komplizierter.

[inne]

Ja, das ist natürlich ein Argument.

Wenn man annimmt das Verhält sich bei jedem Release so.

Aufschrei(TM)

[dirk11]

Interessante Beobachtung!

Da ich aber eigentlich in den letzten 15 Jahren keine nennenswerten Platzprobleme mehr hatte, habe ich das nicht beobachtet und seit Debian 3.0 ausschließlich dist-upgrades gemacht. Ich bin sogar so weit gegangen, daß ich alle Rechner von einer Master-Maschine per netcat installiert habe. Einen Schnitt habe ich nur beim Schritt auf Jessie gemacht, weil ich dort auch auf 64Bit gewechselt habe.

Worauf ich aber hinaus will: Ich mache dist-upgrades (ja, auch von Wheezy zu Jessie) immer und zunehmend problemlos mit aptitude. Dort habe ich den Riesen-Vorteil, daß ich sehen kann, was das System machen will. Ich behebe "broken"-Fehler von vornherein, und alle als "d" markierten Pakete setze ich von Hand auf "p" wie purge. Oft schaue ich auch noch durch, worauf ich verzichten kann, weil es mir seit dem vorigen upgrade nicht mehr begegnet ist
Das einzige, wo das System nicht funktioniert, ist bei libs, welche vielleicht ohne Abhängigkeit "einfach so da" sind, denn da habe ich absolut keinen Durchblick. Aber da kann man sich ja zumindest teilweise mit deborphan --guess-dev und mit debfoster behelfen.

[inne]

.

[rendegast]

Ich habe vorgestern eine VM
etch > lenny > squeeze > wheezy > jessie
gemacht, und es mit 'dist-upgrade --without-recommends' im Zaum halten müssen.
Der Platz der Installation ist von ~1,5GB auf ~2.5GB gewachsen.

[hikaru]

Der Platz der Installation ist von ~1,5GB auf ~2.5GB gewachsen.

Ich habe gestern ebenfalls zwei weitere Test-VMs (wieder Xfce/amd64) hochgezogen - eine von Lenny nach Jessie, die andere von Squeeze nach Jessie. Dabei habe ich ähnliche Beobachtungen gemacht wie du. (später mehr dazu)
Allerdings überrascht mich dieser Umstand nicht. Software wird im Zuge ihrer Weiterentwicklung komplexer, diese Kompexität drückt sich in Codezeilen aus und letztendlich auch in der Größe der daraus compilierten Binaries.

Worauf ich mit diesem Thread eigentlich hinaus will ist, dass ein per dist-upgrade auf ein bestimmtes Release gebrachtes System sich stark von dem frisch installierten System des gleichen Releasenamens unterscheidet, auch wenn der User das System vor dem dist-upgrade nicht verändert hat. Ich bin im Grunde kurz davor in Frage zu stellen, ob man überhaupt noch ein hinreichend ähnliches Verhalten beider Systeme annehmen kann um ohne Angabe wie das System zustande gekommen ist Aussagen darüber treffen zu können.

Beispiel:
Ein neuer User macht einen Thread auf in dem er sagt, dass er gerade Wheezy frisch installiert hat (z.B. weil er eine CD von Weihnachten wiedergefunden hat). Nun möchte er zu Jessie wechseln und fragt, ob eine Aktualisierung per dist-upgrade oder eine Neuinstallation der bessere Weg ist.
Man wird ihm hier in aller Regel sagen, dass es keine Rolle spielt, da am Ende eh das gleiche herauskommt. Genau diese Aussage finde ich nun fraglich.


Nochmal zu den Beobachtungen von oben (in Klammern die Paketlisten):
Die Lenny-VM hatte folgendes Wachstumsverhalten von einem Release zum anderen: (38668 38669 38670 38671)

Code: Alles auswählen

1,29GB 1,63GB 2,06GB 2,46GB

Die bei Squeeze startende VM: (38672 38673 38674)

Code: Alles auswählen

       2,47GB 3,03GB 3,30GB

Zum besseren Vergleich nochmal die beiden aus meinem ersten Beitrag:
Wheezy: (38663 38665)

Code: Alles auswählen

              2,95GB 3,30GB

Jessie: (38664)

Code: Alles auswählen

                     2,69GB

Ich hätte ursprünglich erwartet, dass alle VMs etwa den gleichen Speicherplatz benötigen wenn sie bei Jessie angekommen sind. Bei der bei Squeeze und der bei Wheezy startenden VM passt das* , die Lenny- und die Jessie-VM weichen davon allerdings ab. Interessant ist aber auch, dass die Lenny-VM unter Jessie den geringsten Speicherplatzbedarf hat. Ohne im Detail in die Paketlisten geschaut zu haben würde ich das so interpretieren, dass die Xfce-Standardinstallation unter Squeeze stark aufgeblasen wurde.

Einschränkend muss ich sagen, dass die Ergebnisse nur bedingt vergleichbar sind, denn von Squeeze nach Wheezy wurde der Standard-Loginmanager für Xfce von GDM zu LightDM gewechselt. Bei der Lenny- und der Squeeze-VM wurde dieser Übergang beim Jessie-dist-upgrade nicht sauber umgesetzt. GDM wurde zwar entfernt, LightDM aber nicht installiert, so dass ich ohne Loginmanager da stand. Ich habe LightDM dann händisch nachinstalliert um wenigstens keine offensichtlichen Unterschiede stehen zu lassen.
Etwas Ähnliches ist beim Übergang von Openoffice zu Libreoffice passiert. Die Lenny-VM hat beim Squeeze-Wheezy-dist-upgrade zwar die gemeinsamen Pakete von Libreoffice installiert, nicht jedoch die Pakete für die eigentlichen Anwendungen. Gemerkt habe ich es leider erst als die VM auf Jessie war. Ich habe dann Libreoffice nachinstalliert, was etwa 260MB ausmachte. Die Squeeze-VM hatte dieses Problem nicht.
Die Speicherplatzahlen oben sind jeweils nach den Nachinstallationen (abgesehen vom unvollständigen Libreoffice der Wheezy-Zahl für die Lenny-VM).


*) Die 80MB Unterschied auf Wheezy-Niveau wäre gerade noch im Rahmen meiner rein intuitiven, auf keinen Fakten basierenden Erwartung gewesen.

[rendegast]

Man wird ihm hier in aller Regel sagen, dass es keine Rolle spielt, da am Ende eh das gleiche herauskommt. Genau diese Aussage finde ich nun fraglich.

Die nachgefragte Systeminfo wird umfangreicher

Code: Alles auswählen

apt-cache policy
//var/lib/apt/extended_states
aptitude -F "%c %M %p %40v" search "?installed"
aptitude -F "%c %M %p %40v" search "?installed(?obsolete)"

dpkg -l | egrep -v "^ii"

weiterhin der Status von diversions, alternatives, dkms.
Gleich nach nopaste.

[uname]

Wenn es dir keine Mühe macht könntest du für die ganzen VMs /Releases/Update-Wege noch eben die Paketgrößen nach Nopaste schieben:

Code: Alles auswählen

dpkg-query -Wf '${Installed-Size}\t${Package}\n' | sort -rn | awk '{ print $1 }'

Dann könnte man automatisiert Differenzpakete ermitteln und absteigend nach Datenmenge sortieren.

[hikaru]

Ich habe leider keine Snapshots/Backups von den VMs angelegt. D.h. ich habe die alten Releases nicht mehr sondern jetzt 4 Jessie-VMs.

[dirk11]

Ich bin im Grunde kurz davor in Frage zu stellen, ob man überhaupt noch ein hinreichend ähnliches Verhalten beider Systeme annehmen kann um ohne Angabe wie das System zustande gekommen ist Aussagen darüber treffen zu können.

Beispiel:
Ein neuer User macht einen Thread auf in dem er sagt, dass er gerade Wheezy frisch installiert hat (z.B. weil er eine CD von Weihnachten wiedergefunden hat). Nun möchte er zu Jessie wechseln und fragt, ob eine Aktualisierung per dist-upgrade oder eine Neuinstallation der bessere Weg ist.
Man wird ihm hier in aller Regel sagen, dass es keine Rolle spielt, da am Ende eh das gleiche herauskommt. Genau diese Aussage finde ich nun fraglich.

Nein, ich halte die Aussage nicht für fraglich. Ein upgegradetes System beinhaltet ja auch schon Daten, die auf einem neuen System nicht vorhanden sind: in /var/lib/cache, im home, in /usr/lib, in /etc und an diversen anderen Stellen sicherlich auch. Im Grunde mußt Du erstmal einen Vergleich starten und schauen, welche Pakete *wirklich* überflüssig sind und *trotzdem* beim dist-upgrade geblieben sind - das wäre dann eine belastbare Aussage.

[hikaru]

Ein upgegradetes System beinhaltet ja auch schon Daten, die auf einem neuen System nicht vorhanden sind:

Genau das ist mein Punkt. Die Altlasten werden beim dist-upgrade nicht entsprechend behandelt, so dass ein ansonsten jungfräuliches System das per dist-upgrade auf Release X gebracht wurde nicht vergleichbar ist mit einer Neuinstallation von Release X.

Im Grunde mußt Du erstmal einen Vergleich starten und schauen, welche Pakete *wirklich* überflüssig sind und *trotzdem* beim dist-upgrade geblieben sind

Pakete die eindeutig überflüssig sind sollten beim dist-upgrade oder einer automatischen nachfolgenden Bereinigung entfernt werden, wenn die Distribution den Anspruch hat, das beide Varianten zu Release X zu kommen austauschbar sind.
Debian hat diesen Anspruch entweder nicht oder wird ihm nicht gerecht. In jedem Fall sollte man nicht behaupten, dass die Varianten äquivalent sind. Das gilt sowohl für uns hier im Forum als auch für die Medien. Beide behaupten jedoch regelmäßig, dass es egal sei ob man über ein dist-upgrade oder eine Neuinstallation zum neuen Release kommt und empfehlen daher im Interesse der Bequemlichkeit des Users das dist-upgrade. Die Empfehlung mag nach wie vor richtig sein, aber die Begründung ist es nicht.

Insofern verstehe ich diese Aussage nicht:

Nein, ich halte die Aussage nicht für fraglich.

[Radfahrer]

Die Altlasten werden beim dist-upgrade nicht entsprechend behandelt, so dass ein ansonsten jungfräuliches System das per dist-upgrade auf Release X gebracht wurde nicht vergleichbar ist mit einer Neuinstallation von Release X.

Naja, ist das nicht der Sinn eines Upgrades?
Dass nämlich Änderungen am System, die man gemacht hat, übernommen werden? Wenn ich ein Upgrade auf ein neues Release mache, dann möchte ich ja gar kein jungfräuliches System haben. Im Gegenteil, ich möchte, dass meine Konfigurationen, Caches, Änderungen, usw. erhalten bleiben.

Die Aussage, dass es keinen Unterschied zwischen einer Neuinstallation und einem Upgrade gibt, heißt meiner Meinung nach nur, dass es keine Versionsunterschiede der installierten Software gibt und beide Varianten, was Sicherheitsaspekte betrifft, auf dem gleichen Stand sind.
Auf persönliche Einstellungen trifft es aber natürlich nicht zu, denn diese gibt es bei einer Neuinstallation ja nicht. Man denke da nur mal an die Profile von Browser und Mail-Client, die ja schon mal ein paar hundert MB groß sein können.

[dirk11]

Naja, ist das nicht der Sinn eines Upgrades?
Dass nämlich Änderungen am System, die man gemacht hat, übernommen werden? Wenn ich ein Upgrade auf ein neues Release mache, dann möchte ich ja gar kein jungfräuliches System haben. Im Gegenteil, ich möchte, dass meine Konfigurationen, Caches, Änderungen, usw. erhalten bleiben.

Genau so sehe ich das auch. Ein System nur wegen Versionssprung komplett neu installieren zu wollen ist doch sinnfrei. Ich mach' mir doch nicht die ganze Frickelarbeit der Einrichtung und Individualisierung nur deshalb nochmal, weil es eine neue Versionsnummer gibt...

[uname]

Anstatt einer Neuinstallation kann man jedoch versuchen vor dem Dist-Upgrade unnötige Dinge (Desktop-Environment, nachinstallierte GUI-Anwendungen, ...) zu deinstallieren und das System zu einer Art Minimalinstallation herunter zu scalieren. Da durch den Dist-Upgrade sowieso fast alles ausgetauscht wird ist dieser Schritt nicht wirklich aufwendiger. Vorteil ist jedoch vielleicht, dass erstens das Dist-Upgrade übersichtlicher bleibt und unnötige Pakete (z.B. GUI-Pakete) besser erkannt werden und dass Programme aus alten z.B. Xfce4-Abhängigkeiten mit der Neuinstallation des task-desktop-Paketes (z.B. Xfce4) nach dem Dist-Upgrade nicht mehr vorhanden sind. Mit etwas Pech hat man jedoch irgendein kleines Paket übersehen, welches durch vollkommen falsche Paketabhängigkeiten irgendein Zeug installiert, was man gar nicht haben wollte.

[dirk11]

Anstatt einer Neuinstallation kann man jedoch versuchen vor dem Dist-Upgrade unnötige Dinge (Desktop-Environment, nachinstallierte GUI-Anwendungen, ...) zu deinstallieren und das System zu einer Art Minimalinstallation herunter zu scalieren.

Das mache ich eigentlich immer schon so. Beim ersten Mal war das ein bißchen frickelig, weil man erstmal die Abhängigkeiten durchblicken muß, aber man muß das ja nich oft machen.

[hikaru]

Naja, ist das nicht der Sinn eines Upgrades?
Dass nämlich Änderungen am System, die man gemacht hat, übernommen werden? Wenn ich ein Upgrade auf ein neues Release mache, dann möchte ich ja gar kein jungfräuliches System haben. Im Gegenteil, ich möchte, dass meine Konfigurationen, Caches, Änderungen, usw. erhalten bleiben.

Ja. Aber es geht dabei um die Änderungen die der Nutzer veranlasst hat. Wenn du Programm X nachinstalliert hast, dann möchtest du das natürlich auch nach dem diust-upgrade behalten, denn du hast es für gewöhnlich aus gutem Grund installiert.
Wenn aber das Debian-Projekt meint, eine andere Software für eine bestimmte Aufgabe als Standardsoftare verwenden zu wollen (siehe Xfburn/Brasero im Beispiel), dann sollte der Nutzer davon im Zuge des dist-upgrades zumindest in Kenntnis gesetzt, idealerweise sogar nach der Vorgehensweise gefragt werden. Das wäre meinem Verständnis nach jedenfalls notwendig, falls man den Anspruch hat, dass ein dist-upgrade und eine Neuinstallation zu einem vergleichbaren Ergebnis führen (können).
Ob man diesen Anspruch seitens Debian hat ist, wie gesagt, eine andere Frage.

Die Aussage, dass es keinen Unterschied zwischen einer Neuinstallation und einem Upgrade gibt, heißt meiner Meinung nach nur, dass es keine Versionsunterschiede der installierten Software gibt und beide Varianten, was Sicherheitsaspekte betrifft, auf dem gleichen Stand sind.

Mit der Definition könnte ich mich nach Stand der Dinge arrangieren. Dann sollten wir hier aber nicht beide Varianten um auf ein Release zu kommen leichtfertig durcheinanderwürfeln.

Ein System nur wegen Versionssprung komplett neu installieren zu wollen ist doch sinnfrei. Ich mach' mir doch nicht die ganze Frickelarbeit der Einrichtung und Individualisierung nur deshalb nochmal, weil es eine neue Versionsnummer gibt...

Sinnfrei ist es nicht. Denn wie gezeigt unterscheiden sich die resultierenden Systeme teils erheblich. Und die Frickelarbeit bei der Neueinrichtung beschränkt sich auf das Einspielen des Backups.

Anstatt einer Neuinstallation kann man jedoch versuchen vor dem Dist-Upgrade unnötige Dinge (Desktop-Environment, nachinstallierte GUI-Anwendungen, ...) zu deinstallieren und das System zu einer Art Minimalinstallation herunter zu scalieren.

Ich habe das mal versucht um ein von Lenny auf Squeeze gehobenes chroot mit LXDE auf Wheezy zu heben. Das war eine fürchterliche Frickelei, insbesondere die ganze Puzzelei mit den Libs. Ein wichtiges Ziel war ein möglichst geringer Speicherplatzbedarf des chroots, also wollte ich keine Altlasten behalten. Am Ende war es einfacher, ein neues Wheezy-chroot aufzusetzen.

[dirk11]

Ein System nur wegen Versionssprung komplett neu installieren zu wollen ist doch sinnfrei. Ich mach' mir doch nicht die ganze Frickelarbeit der Einrichtung und Individualisierung nur deshalb nochmal, weil es eine neue Versionsnummer gibt...

Sinnfrei ist es nicht. Denn wie gezeigt unterscheiden sich die resultierenden Systeme teils erheblich. Und die Frickelarbeit bei der Neueinrichtung beschränkt sich auf das Einspielen des Backups.

Das habe ich aber ganz anders erlebt. Wenn es in der benutzten Software einen größeren Versionssprung gab, dann kannst Du dir ganz schön die Karten legen, wenn Du einfach ein Backup einspielst. Neinnein, configs u.ä. müssen dann grundsätzlich von Hand gegengelesen werden. Erlebt man immer wieder. Von Debian 7 auf 8 war das zwar eher harmlos, aber dort muß man z.B. die CUPS-settings genau prüfen, denn es sind Optionen weggefallen, deren Vorhandensein u.U. den CUPS-Server so stört, das er nicht mehr richtig anläuft...

[uname]

Sehe ich ähnlich. Daher verzichte ich eher gleich auf Konfigurations-Backups und pflege aktiv eine paralle Verzeichnisstruktur mit etc-Konfigurationen, Benutzer-Konfigurationen und einer Liste nachinstallierter Pakete. Daraus kann man dann bei einer Neuinstallation recht schnell ein fast identisches System zusammenbauen.