• Willkommen im Linux Club - dem deutschsprachigen Supportforum für GNU/Linux. Registriere dich kostenlos, um alle Inhalte zu sehen und Fragen zu stellen.

[gelöst] Smart Upgrade vs. Neuinstallation / Repositories

m00nraker

Newbie
Hallo.

Vorab: Ich nutze SmartPM und habe dazu einige Fragen an die Experten unter Euch, die sich auch mit den Repositories auskennen.

Ich heisse Kai und habe mich eben in diesem Forum neu angemeldet. Das Forum nutze ich schon lange als stiller Leser und finde es hervorragend. Dafür möchte ich mich bei den Administratoren dieses Forums bedanken und auch bei den Nutzern für die vielen schönen Beiträge.

Linux, genauer Suse Linux, nutze ich hingegen schon einige Jahre.

Z.Zt. OpenSuse OSS-Factory 10.1 (i386), KDE 3.5.1.x, Kernel 2.6.x

Zur Situation:

Als Paketmanager habe ich unter Suse seit Jahren APT benutzt. Damit habe ich stets mein System aktualisiert und auch auf neue KDE-Versionen aktualisiert, sogar immer aus dem laufenden Betrieb heraus. Seit kurzem habe ich Smart entdeckt. Ich habe viel über Smart gelesen, FAQs, Forenbeiträge, etc. und weiss eigentlich, wie Smart funktioniert und wie man es benutzt. Allerdings fehlt mir ganz bestimmtes Hintergrundwissen über die Repositories und Systemupgrades bei Suse, was ich nirgendwo nachlesen konnte.

Auf meinem Rechner habe ich letztens OpenSuse 10.1-RC2 via. 5-CD-Set (ISO-Images gebrannt) neu installiert. Dann habe ich mittels Smart mein System auf die aktuelle Entwicklerversion SL-OSS-Factory 10.1 aktualisiert. Bevor ich weiter schreibe, poste ich hier mal meine Channels und Mirrors, damit es keine Missverständnisse gibt:

Meine Channel-Liste:

Code:
[opensuse-sl-oss-factory_yast2]
 type = yast2
 name = OpenSuse Linux 10.1 - SL-OSS-Factory (YAST2)
 baseurl = ftp://ftp.gwdg.de/pub/opensuse/distribution/SL-OSS-factory/inst-source/

[suse-extra_yast2]
 type = yast2
 name = Suse Linux 10.1 - Extra (YAST2)
 baseurl = ftp://ftp.gwdg.de/pub/suse/install/10.1/inst-source-extra/

[suse-packman_yast2]
 type = yast2
 name = Suse Linux 10.1 - Packman (YAST2)
 baseurl = http://packman.iu-bremen.de/suse/10.1/

[guru_yum]
 type = rpm-md
 name = Suse Linux 10.1 - Guru (YUM)
 baseurl = http://ftp.gwdg.de/pub/linux/misc/suser-guru/rpm/10.1/RPMS/

[suse-update_yum]
 type = rpm-md
 name = Suse Linux 10.1 - Update (YUM)
 baseurl = ftp://ftp.suse.com/pub/suse/i386/update/10.1/

[suse-base_apt]
 type = apt-rpm
 name = Suse Linux 10.1 - Base (APT)
 baseurl = ftp://ftp.gwdg.de/pub/linux/suse/apt/SuSE/10.1-i386/
 components = base

[suse-extra_apt]
 type = apt-rpm
 name = Suse Linux 10.1 - Extra (APT)
 baseurl = ftp://ftp.gwdg.de/pub/linux/suse/apt/SuSE/10.1-i386/
 components = extra

[suse-kolab_apt]
 type = apt-rpm
 name = Suse Linux 10.1 - Kolab (APT)
 baseurl = ftp://ftp.gwdg.de/pub/linux/suse/apt/SuSE/10.1-i386/
 components = kolab

[suse-packmani686_apt]
 type = apt-rpm
 name = Suse Linux 10.1 - Packman-i686 (APT)
 baseurl = ftp://ftp.gwdg.de/pub/linux/suse/apt/SuSE/10.1-i386/
 components = packman-i686

[suse-packman_apt]
 type = apt-rpm
 name = Suse Linux 10.1 - Packman (APT)
 baseurl = ftp://ftp.gwdg.de/pub/linux/suse/apt/SuSE/10.1-i386/
 components = packman

[suse-security_apt]
 type = apt-rpm
 name = Suse Linux 10.1 - Security (APT)
 baseurl = ftp://ftp.gwdg.de/pub/linux/suse/apt/SuSE/10.1-i386/
 components = security

[suse-update_apt]
 type = apt-rpm
 name = Suse Linux 10.1 - Update (APT)
 baseurl = ftp://ftp.gwdg.de/pub/linux/suse/apt/SuSE/10.1-i386/
 components = update

[suse-rpmkeys_apt]
 type = apt-rpm
 name = Suse Linux 10.1 - RPMKeys (APT)
 baseurl = ftp://ftp.gwdg.de/pub/linux/suse/apt/SuSE/10.1-i386/
 components = rpmkeys


Meine Mirror-Liste

Code:
ftp://ftp.gwdg.de/pub/opensuse/distribution/SL-OSS-factory/
    ftp://ftp.uni-heidelberg.de/pub/linux/opensuse/distribution/SL-OSS-factory/
    ftp://ftp.tu-chemnitz.de/pub/linux/opensuse/distribution/SL-OSS-factory/
    ftp://ftp.heanet.ie/mirrors/ftp.opensuse.org/opensuse/distribution/SL-OSS-factory/
    http://linux.integrity.hu/pub/opensuse/distribution/SL-OSS-factory/
    ftp://mandril.creatis.insa-lyon.fr/linux/opensuse/distribution/SL-OSS-factory/
    ftp://ftp.fi.muni.cz/pub/linux/opensuse/distribution/SL-OSS-factory/

ftp://ftp.gwdg.de/pub/opensuse/distribution/SL-10.1-OSS/
    ftp://sunsite.rwth-aachen.de/pub/comp/Linux/opensuse/distribution/SL-10.1-OSS/
    ftp://ftp.tu-ilmenau.de/Mirrors/opensuse/distribution/SL-10.1-OSS/
    ftp://ftp.rz.uni-ulm.de/pub/mirrors/opensuse/distribution/SL-10.1-OSS/
    ftp://ftp.man.poznan.pl/pub/linux/opensuse/distribution/SL-10.1-OSS/
    ftp://gd.tuwien.ac.at/linux/opensuse/distribution/SL-10.1-OSS/
    ftp://ftp.belnet.be/mirror/ftp.opensuse.org/opensuse/distribution/SL-10.1-OSS/
    ftp://ftp.skynet.be/pub/ftp.opensuse.org/opensuse/distribution/SL-10.1-OSS/
    ftp://ftp.tu-cottbus.de/pub/unix/linux/opensuse/distribution/SL-10.1-OSS/
    ftp://mirrors.netbg.com/opensuse/distribution/SL-10.1-OSS/
    ftp://ftp.uni-erlangen.de/mirrors/opensuse/distribution/SL-10.1-OSS/
    ftp://ftp.rz.uni-wuerzburg.de/pub/linux/opensuse/distribution/SL-10.1-OSS/
    ftp://ftp.uniroma2.it/Linux/opensuse/distribution/SL-10.1-OSS/
    ftp://ftp.jaist.ac.jp/pub/Linux/opensuse/distribution/SL-10.1-OSS/
    ftp://mirror.switch.ch/mirror/opensuse/distribution/SL-10.1-OSS/

ftp://ftp.suse.com/pub/suse/i386/update
    ftp://ftp.gwdg.de/pub/linux/suse/ftp.suse.com/suse/i386/update/
    ftp://ftp.tu-ilmenau.de/Mirrors/ftp.suse.com/i386/update/
    ftp://sunsite.informatik.rwth-aachen.de/pub/Linux/suse/i386/update/
    ftp://ftp.uni-bremen.de/pub/mirrors/suse/i386/update/
    ftp://ftp.tu-chemnitz.de/pub/linux/suse/ftp.suse.com/suse/i386/update/
    ftp://ftp.tu-cottbus.de/pub/unix/linux/suse.com/suse/i386/update/
    ftp://linux.mathematik.tu-darmstadt.de/pub/linux/distributions/suse/ftp.suse.com/suse/i386/update/
    ftp://ftp.uni-erlangen.de/pub/Linux/MIRROR.suse/pub/suse/i386/update/
    ftp://ftp-stud.fht-esslingen.de/pub/Mirrors/ftp.suse.com/pub/suse/i386/update/
    http://ftp-stud.fht-esslingen.de/pub/Mirrors/ftp.suse.com/pub/suse/i386/update/
    ftp://ftp.rrzn.uni-hannover.de/pub/mirror/linux/suse/i386/update/
    ftp://ftp.hosteurope.de/mirror/ftp.suse.com/pub/suse/i386/update/
    http://ftp.hosteurope.de/mirror/ftp.suse.com/pub/suse/i386/update/
    ftp://ftp.uni-rostock.de/pub/systems/unix/linux/suse/i386/update/
    ftp://ftp.rz.uni-ulm.de/pub/mirrors/suse/i386/update/
    ftp://mirror.switch.ch/mirror/SuSE/suse/i386/update/

http://packman.iu-bremen.de/suse/
    ftp://ftp.mb3.tu-chemnitz.de/mirrors/packman.iu-bremen.de/suse/
    ftp://ftp.cesnet.cz/MIRRORS/packman.iu-bremen.de/suse/
    http://packman.rsync.zmi.at/suse/
    ftp://packman.rsync.zmi.at/suse/
    http://mirror.geht-schon.de/packman.links2linux.de/suse/
    http://ftp.uni-erlangen.de/pub/mirrors/packman/suse/
    ftp://ftp.uni-erlangen.de/pub/mirrors/packman/suse/
    http://packman.mirrors.skynet.be/pub/packman/suse/
    ftp://packman.mirrors.skynet.be/pub/packman/suse/
    http://ftp.gwdg.de/pub/linux/misc/packman/suse/
    ftp://ftp.gwdg.de/pub/linux/misc/packman/suse/
    http://packman.inode.at/suse/
    ftp://packman.inode.at/suse/
    http://packman.unixheads.com/suse/
    ftp://packman.unixheads.com/suse/

ftp://ftp.gwdg.de/pub/linux/suse/apt/SuSE/
    http://ftp.gwdg.de/pub/linux/suse/apt/SuSE/
    ftp://mirrors.mathematik.uni-bielefeld.de/pub/linux/suse/apt/SuSE/
    ftp://ftp.uni-erlangen.de/pub/Linux/MIRROR.suse/apt/SuSE
    http://ftp.rz.tu-bs.de/pub/mirror/SuSE/apt/SuSE/
    ftp://ftp.heanet.ie/mirrors/gwdg.de/pub/linux/suse/apt/SuSE
    ftp://ftp.tu-chemnitz.de/pub/linux/suse/apt/SuSE
    ftp://ftp.uni-oldenburg.de/linux/ftp.suse.com/apt/SuSE/
    ftp://ftp.sunsite.org.uk/sites/ftp.gwdg.de/SuSE/apt/SuSE/
    http://fau.pdacentral.com/pub/mirrors/suse/apt/SuSE/
    ftp://ftp.linux.ee/mount/hdd/mirror/suse/apt/SuSE/
    ftp://ftp.kde.org/pub/suse/apt/SuSE/



So bin ich beim Upgrade von RC2 auf die aktuelle Entwicklerversion SL-OSS-Factory vorgegangen:

1)
Ausgehend von einem installierten OpenSuse 10.1-RC2 starte ich 'smart --gui' als root und aktualisiere zunächst alle Channel (Update).

2)
Um das Basis-System (RC2) auf die aktuelle SL-OSS-Factory Entwicklerversion zu aktualisieren, deaktiviere ich in der GUI alle Channel (Base, Packman, Guru, etc.) bis auf RPM-SYS (Lokale Paketdatenbank) und den [opensuse-sl-oss-factory_yast2] Channel.

3)
Nun wähle ich in der GUI 'Bearbeiten/Aktualisiere alles' (also Upgrade). In der folgenden Zusammenfassung kontrolliere ich nochmal manuell, ob mir irgendetwas schräges auffällt und lasse Smart dann den Rest machen. Danach boote ich den Rechner.



Nun habe ich einige generelle Fragen:

A)
Ist es richtig, dass auf den FTP-Servern in dem Verzeichnis 'sl-oss-factory' stets ein tagesaktueller Snapshot der aktuellen Entwicklerversion vorzufinden ist?

B)
Ist es richtig, dass die Release-Kandidaten RC1, RC2 und RC3 jeweils Snapshots dieser SL-OSS-Factory Version sind?
Wenn ich also auf einem OpenSuse 10.1-RC2 System nach dem offiziellen Erscheinen des 10.1-RC3 ein Upgrade mittels Smart gemacht habe, bin ich dann auch automatisch auf dem Mindeststand der RC3?

C)
Wie kann ich bei Suse Linux feststellen, welche exakte Versionnummer das Basis-System hat, also ob z.B. 10.1-RC1, RC2, Factory, etc. installiert ist? Die maximale Information die ich bekommen kann, ist dass Version 10.1 installiert ist.

D)
Dies ist mir besonders wichtig:
Wie werden Neuerungen von einem Versionsübergang z.B. von 10.0 auf 10.1 bei einem Upgrade sei es direkt durch Yast oder andere Paketmanager wie z.B. Smart gehandhabt?
Mal angenommen ich upgrade von einer installierten 10.0-Final auf eine 10.1-Final. Der Networkmanager ist dabei ein gutes Beispiel. In 10.0 gab es z.B. keinen Networkmanager. BTW, ich weiss, dass der Networkmanager noch gravierende Mängel hat. Angenommen er funktioniert in der 10.1-Final einwandfrei und würde standardmäßig installiert/aktiviert werden. Ist der Networkmanager nach einem Upgrade durch Smart und Co. von 10.0 auf die 10.1 automatisch aktiviert? Ich glaube nicht.
Ich denke, wenn man sein System mittels Smart und Co. auf eine nächst höhere Version upgradet, muss man ggf. doch auf bestimmte Neuerungen verzichten. Smart analysiert die installierten Pakete der installierten 10.0 Version und schaut, ob in den Repositories neuere Versionen liegen. Diese werden dann runtergeladen und die lokal installierten Pakete damit ersetzt. Wenn aber ein Paket wie z.B. der Networkmanager bei der 10.0 nicht installiert war, weil es den Networkmanager in 10.0 noch nicht gab, wird Smart den Networkmanager bei einem Upgrade von 10.0 auf 10.1 doch denke ich nicht installieren, obwohl dieser in einer Standardinstallation von 10.1 installiert worden wäre. Wenn man also nicht weiss, dass es in der 10.1 einen Networkmanager gibt, wird man wohl trotz Online-Upgrade via Smart und Co. auf die neue 10.1 diese Feature nicht nutzen können, weil es nicht installiert wird. Sehe ich dies richtig? Der Networkmanager soll nur ein Beispiel sein. Wenn man also solche 'neuen Funktionen' einer Distribution auch nutzen möchte, sollte man dann nicht doch besser ein System-Update per Yast oder noch besser eine Neuinstallation wählen, als 'nur' ein Upgrade per Smart und Co. zu machen, weil einem ansonsten viel schöne neue Funktionalität durch die Lappen gehen könnte (überspitzt ausgedrückt)? Dies ist nur ein Beispiel, denn woher soll ich wissen, welche Pakete ist zusätzlich zu meinem Online-Upgrade installieren soll, damit mein System den Funktionsumfang hat, als wenn ich eine Neuinstallation der neuen Version wählen würde, wo dann bestimmte Pakete standardmäßig installiert werden?
Ein anderes Beispiel wäre, wenn bei einem Versionswechsel z.B. von 10.0 auf 11.0 gravierende Änderungen in der Distribution vorgenommen werden, wie z.B. Ersetzung des Paketsystem durch ein anderes Paketsystem. Müsste ein Upgrade via Smart und Co. dort nicht zwangsweise scheitern?
Die Frage ist, ob es nicht generell besser ist, bei einer neuen Version stets eine Neuinstallation zu fahren..!?!?

Dies würde meiner Meinung nach auf auf neue KDE-Versionen zutreffen. Angenommen ich update von KDE3.5 auf später KDE4. KDE4 wird gravierende Neuerungen haben. Evtl. wird ein Update per Smart möglich sein. Aber ist mein System nach einem Neustart dann so, als wenn ich KDE komplett neu installiert hätte? Würden dann nicht evtl. einige Pakete nicht mitinstalliert werden bzw. würden sich nicht alte vorhandene Konfigurationsdateien störend auswirken? Eine neue KDE Version hat u.U. ein noch genialeres Look&Feel als eine vorher installierte, ältere Version. Auf dieses Look&Feel würde ich dann verzichten müssen, weil nach dem Update auf die neue KDE-Version eben doch noch die alten Konfigurationsdateien verwendet werden. Klar kann man bei der neuen Version alle Einstellungen manuell ändern, aber darum geht es mir nicht.

Machen also Online-Updates via Smart nicht deshalb nur Sinn bei kleinen Versionssprüngen, z.B. OpenSuse 10.0RC2 auf 10.0RC3 oder KDE 3.5.0 -> 3.5.1? Beim Übergang von OpenSuse 10.0 auf 10.1 gibt es ja schon gravierende Änderungen (Paketdatenbank, Networkmanager,..).

Es geht mir also nicht um technische Probleme beim upgraden auf eine nächst höhere Version, sondern nur um die Funktionalität bzw. neue Funktionen.

E)
Bei den diversen FTP-Servern bzw. Mirrors existiert eine teilweise unterschiedliche Verzeichnisstruktur, was die Repositories angeht.
Wie kann man die einzlenen Repository-Verzeichnisse bzw. Typen in der Verzeichnisstruktur der FTP-Server bzgl. Smart unterscheiden?

type=yast2: Dies ist eine Yast-Installationsquelle.
Kennzeichnend dafür ist das Vorhandensein einer 'directory.yast' Datei. Richtig?

type=apt-md: Dies ist eine Yum Quelle für RPM-Metadaten.
Kennzeichnend dafür ist das Vorhandensein der beiden Verzeichnisse 'repodata' und 'rpm'. Richtig?

type=apt-rpm: Dies ist ein APT-Repository.
Hier muss ein Verzeichnis 'base' sowie weitere Verzeichnisse 'RPMS.blabla' existieren. Richtig

F)
Im APT Repository für die Opensuse 10.1 gibt es ein Verzeichnis 'RPMS.base'. Was genau stellt dieses Verzeichnis in den APT-Repositories dar? Liegen in diesem Verzeichnis später mal alle Pakete, die auch auf den CDs der Final-Version vorzufinden sind? Ist dieses APT-Repository im Prinzip ein Abbild der Pakete der jeweiligen Finalversion?


Stellt dann 'RPMS.update' das APT-Repository-Äquivalent der Suse-Updates bereit, die man auch über Suse YOU einspielen kann?

G)
Angenommen ich möchte via Smart ein Ugrade von 10.0 auf die 10.1 Final durchzuführen.
In meiner Channel-Liste steht natürlich noch folgender Factory Channel:

Code:
[opensuse-sl-oss-factory_yast2]
 type = yast2
 name = OpenSuse Linux 10.1 - SL-OSS-Factory (YAST2)
 baseurl = ftp://ftp.gwdg.de/pub/opensuse/distribution/SL-OSS-factory/inst-source/

Reicht es nun aus, diesen Channel zu entfernen und dann folgenden Channel hinzuzufügen?

Code:
[suse-base_apt]
 type = apt-rpm
 name = Suse Linux 10.1 - Base (APT)
 baseurl = ftp://ftp.gwdg.de/pub/linux/suse/apt/SuSE/10.1-i386/
 components = base

Was passiert, wenn man beide Channel parallel aktiviert?

H)
Kann man unter der 10.1 OSS-Factory auch einen Channel für das APT KDE-Repository der OSS-10.0 hinzufügen oder handelt man sich Probleme ein?
Die Factory hat z.B. KDE 3.5.1.x, wahrend im KDE-Repository für 10.0-OSS KDE 3.5.2.x liegt.

Eigentlich müsste das doch keine Probleme machen, oder sind die KDE 3.5.1 Pakete der Factory-Version anders gebaut, als die Pakete der OSS-10.0 Version?


Eine Menge Fragen. Vielleicht profitieren von evtl. Antworten auch andere Leute.
Am liebsten wäre mir, wenn Ihr zu den einezlnen Punkten A) B) oder E) separat kurz antworten würdet.

Herzlichen Dank dafür.

Ansonsten komme ich mit Smart gut zurecht. Mein System läuft trotz der Probleme mit dem Networkmanager sehr gut und ich kann mein gesamtes System inkl. Kernel, KDE, etc. im laufenden Betrieb unter KDE komplett aktualisieren. Danach booten und alles ist prima. Natürlich habe ich mein Sytsem auch mal zerschossen. Aber dies stellt an sich klein Problem für mich da. Das bekomme ich meist irgendwie immer wieder ans Laufen. Smart ist toll, jedoch finde ich es grotten langsam. Damit aber kann ich gut leben. Das letzte Gesamtupdate hat doch glatt 2,3GB RPMs runtergeladen, mein gesamtes System aktualisiert und danach hat alles einwandfrei funktioniert.

LG, Kai
 

Grothesk

Ultimate Guru
A) Ja.
B) Ja.
C) cat /etc/SuSE-release mal probieren. Evtl. steht das da drin.
D)
Die Frage ist, ob es nicht generell besser ist, bei einer neuen Version stets eine Neuinstallation zu fahren..!?!?
Definitiv: Ja, besser neuinstallieren...
E) Hast du doch selber schon beantwortet...
F) Ja. Dort liegen die Basis-Pakete der Distribution. Zu weiten teilen ist das identisch mit dem Inhalt der CDs/DVD.
G) ---
H) Riecht nach Ärger. Würde ich nie machen.
 
OP
M

m00nraker

Newbie
Hallo Grothesk.

Danke für Deine kurze aber ausreichende Antwort.

Was mir allerdings noch nicht ganz klar ist:

Mal abgesehen vom Auflösen der Abhängigkeiten, worin unterscheidet sich ein System-UPGRADE durch Yast oder smart? Macht das Yast-Tool bei einem Upgrade noch etwas anderes als nur Pakete durch höhere Versionen zu ersetzen, als z.B. smart?

Warum rätst Du persönlich bei einem Versionssprung des Basissystems zu einer Neuinstallation statt zu einem Upgrade via. yast oder smart?

Danke.

Gruss, Kai
 

Grothesk

Ultimate Guru
m00nraker schrieb:
Mal abgesehen vom Auflösen der Abhängigkeiten, worin unterscheidet sich ein System-UPGRADE durch Yast oder smart? Macht das Yast-Tool bei einem Upgrade noch etwas anderes als nur Pakete durch höhere Versionen zu ersetzen, als z.B. smart?
So genau kenne ich die Unterschiede im Vorgehen von yast und smart nicht. Kann ich also nichts zu sagen.

Warum rätst Du persönlich bei einem Versionssprung des Basissystems zu einer Neuinstallation statt zu einem Upgrade via. yast oder smart?
Erfahrungen...
Generell habe ich die Erfahrung gemacht, das ein Update dann doch nicht so richtig wie gewünscht oder gedacht funktioniert. Und eh das dann alles wieder gerade gerückt ist hast du auch schnell neuinstalliert. /home auf einer separaten Partition macht es doch supereasy, so vorzugehen. Oft dauert auch ein Update auf einer bestehenden Installation wesentlich länger, als einfach über die /Partition drüber zu bügeln.
 
OP
M

m00nraker

Newbie
Also ein komplettes System-Upgrade funktionierte bei mir bisher immer einwandfrei. Ich schwanke aber jedesmal zwischen Neuinstallation und Upgrade durch z.B. smart, auch wenn es augenscheinlich gut funktioniert.

Allerdings finde ich nicht, dass eine Neuinstallation schnell geht, so dass sich das neu installierte System im selben Zustand befindet, wie das zuvor installierte System. Mit einem einfachen "drüber bügeln" ist es ja nicht getan. Das reine Kopieren der Dateien geht zwar relativ schnell, die Konfiguration aber dauert entsprechend lange. Gegen eine Neuinstallation spricht für mich, dass ich sämtliche Systemeinstellungen per Hand neu vornehmen muss, wie z.B. diverse Mountpoints setzen, bestimmte Verzeichnis-Rechte ändern, Benutzer/Gruppen-Verwaltung, Hardware-Konfiguration (Drucker, Scanner, Monitor, Grafikkarte, TV, etc.), Systemdienste neu einrichten, Firewall-Konfiguration, Netzwerkeinrichtung, Smart-Konfiguration, Samba, Schriften-Installation, usw. Hinzu kommen diverse Programme, die in keinem Repository zu finden sind. Diese müssen manuell nachinstalliert werden und ggf. konfiguriert werden (Beispiel: klibido). Eine komplette Neuinstallation dauert bei mir nicht unter 5-7 Stunden (P3) (komplette Installation per CD inkl. Add-On, anschließende Konfiguration des Systems gemäß eigenen Wünschen sowie anschließendes smart-update). Davon ausgenommen ist die Konfiguration meines KDE-Desktops sowie der von mir verwendeten KDE-Anwendungen und deren Einstellungen (Mail, Bookmarks, etc.), da mein Home-Verzeichnis auf einer anderen Partition liegt und ich es natürlich wieder einbinde. Fazit: Eine Neuinstallation kann praktisch doch sehr aufwändig sein.

Für eine Neuinstallation spricht hingegen die Gewissheit, dass mir auch garantiert alle neu hinzugekommenen Funktionen und Dienste des neuen Systems zur Verfügung stehen und ich keine alten Konfigurationsdateien mit rumschleppe, die evtl. falschen Inhalt haben könnten, weil sie von älteren Programmversionen erstellt wurden. Nur kostet dies erheblich mehr Zeit. Dafür ist das System aber garantiert gut aufeinander abgestimmt. Leider ist mir nicht so ganz klar, wie Upgrades gehandhabt werden und was dabei mit Konfigurationsdateien passiert.

Ich habe meine Opensuse 10.1GM diesmal komplett neu installiert. Vorher hatte ich ein Upgrade von 10.0 auf die Factory gemacht, wo mein k3b nicht mehr richtig lief: kein Brenner erkannt, obwohl cdrecord ohne Probleme funktionierte und der Networkmanager hat meine Kabel-Verbindung nicht erkannt. Ich dachte zuerst, dass dies an dem smart Upgrade gelegen hatte. Eine komplette Neuinstallation der 10.1GM hatte exakt die selben Probleme, die ich zuvor nach dem Upgrade festgestellt hatte: kein Brennen mit k3b möglich und der Networkmanager funktionierte noch immer nicht. Somit war die Neuinstallation für mich persönlich leider nicht erforderlich. Ein Upgrade hätte es also auch getan und wäre deutlich weniger zeitintensiv gewesen. Bzgl. meines k3b-Problems poste ich nochmal im Multimedia-Forum. Vielleicht kann mir dort jemand helfen.

Vielen Dank.

Gruss, Kai
 
Oben