Hallo, Am Sun, 30 Dec 2012, Sebastian Siebert schrieb:
Am 30.12.2012 16:09, schrieb David Haller: [...]
Ich hab's mal mit dem grafischen YaST versucht. (Ja, ich wollte mal rumexperimentieren).
Ist nicht so geeignet, auch wenn ich sonst fast immer Yast verwende um Krams zu installieren (und fast nie zypper), für's "dup" hab ich zypper verwendet, auch wenn die Textausgabe das bei "gebrochenen" Paketen sehr unübersichtlich werden kann.
Also, Pakete installiere und suche ich ganz gerne via zypper. Das ist für mich halt auf der Konsole komfortabel. ;-)
Hm. Ich glaub ich hab Tomaten auf den Augen, jedenfalls wenn ich per 'zypper se' was suche und finde und dann per 'zypper in' installieren will (bzw. beides gleich in einem 'zypper sh'), dann vermisse ich da irgendwie die Möglichkeit ne bestimmte Version bzw. ein Repo auszuwählen. Äh, Korrektur: geht. Per '-r' und/oder genauer Version. Aber IMHO umständlich(er). Wie man als nicht-Listen-Newbie wissen sollte bevorzuge ich ja generell die Kommandozeile, aber das ist eines der weningen Dinge wo ich eine (halbwegs gut gemachte) GUI der Kommandozeile vorziehe ;) Speziell die Repo-Sicht in Yast (wobei alle Pakete eines Repos angezeigt werden, via Version aber immer noch alle aus anderen Repos zugänglich sind) ist IMO ein Killerfeature ;) Und ja, meine SW-Auswahl tendiert zu "sehr speziell", teils gemischt mit eigenen gepatchten RPMs im "/usr/src/packages" Repo (z.B. gtk2).
Repos auf die 12.2 umgeschrieben (inklusive KDE3), im YaST alle rpms auflisten lassen und dann auf alles aktualisieren geklickt. Vier Pakete wollten nicht, da habe ich mich dann von Hand entschieden, was damit passieren soll.
Jap. Im Gegensatz zur offiziellen Anleitung und Sebastian's hab ich hier auch immer _alle_ Repos umgeschrieben und aktiv gelassen.
Ich hatte testweise erstmal nur die offiziellen Repos (bzw. die DVD als iso-Quelle) aktiv gelassen, das wäre kolossal schiefgegangen, weil z.B. dem ganze Packman-Kram und vielem anderen aus Extra-Repos diverse Libs gefehlt hätten und somit deinstalliert hätten werden müssen. Und die vielen Extra-Pakete zu notieren (bzw. per RPM --qf rausprokeln) und anschließend nachinstallieren macht keinen Spaß... Mit allen Repos aktiv hat's bisher einige Male geklappt.
Ich habe hier die Standardkonfiguration /etc/zypp/zypp.conf von zypper/libzypp belassen und dieser löscht keine Pakete vom Packman-Repo bzw. von anderen Repos.
Meine conf ist nur geringfügig geändert. ==== /etc/zypper/zypp.conf [teils nur defaults explizit gesetzt] ==== [main] arch = x86_64 download.use_deltarpm = true download.media_preference = volatile commit.downloadMode = DownloadInAdvance solver.onlyRequires = true multiversion = provides:multiversion(kernel) ==== Wobei ich grad seh, da gibt's nen .rpmnew, mit 2 neuen Optionen ;) Und wenn z.B. dem MPlayer von Packman dann z.B. ne lib fehlt? ISTR, daß der MPlayer nicht von selbst installiert bleibt. Man bekommt nen Fehler und muß die Lib dazuwählen (die's aber nicht in den oS Repos gibt) oder eben MPlayer deinstallieren, oder die Abhängigkeit ignorieren => (MPlayer oder alle nicht-erfüllten Abhängigkeiten notieren und später nachinstallieren = A...-Karte). Und wie gesagt, bei mir hat das Upgrade schon mehrfach mit allen Repos aktiv funktioniert, Probleme gab's nur, wenn ein home:* Repo noch keine Pakete für die jew. neue Version hatte, die wenigen zu notieren ist aber kaum problematisch.
Und das habe ich bei 2 openSUSE-Installationen getestet. Ich habe keine Ahnung was bei dir anders ist.
s.o. wg. Paketen mit Abhängigkeiten, die nicht aus den oS oss/non-oss bzw. auch "nur von der DVD" erfüllt werden können. Wie gesagt, ich hab jetzt auch schon 2-3 Upgrades hinter mir und v.a. davon das 11.2 (32bit) auf 11.4 (64bit) ... Das war zwar komplett vergeigt, aber da konnte zypper nun wirklich nix für, da ich vergessen hatte, die 'arch='-Variable in zypp.conf anzupassen. Nachdem ich dann per Hand den zypper oder yast (weiß nimmer) Krams aus dem ISO per Hand mit 'rpm --root=' rausgeprokelt und installiert hatte, hat mir zypper letztlich nur noch die zu erwartenden Probleme bei 32-vs-64bit und wg. Locks um die Ohren gehauen. ISTR sogar nur wg. locks, den 32bit Krams hab ich dann selber irgendwann mal entsorgt. Kurzum: zypper hat sich besser als erhofft verhalten! Auch beim letzten Upgrade von 11.4 auf 12.1 bekam ich sogar weniger als erwartet Probleme wg. Locks. Ah, doch, ein paar gab's noch wg. neuer libs (libfoo0 -> libfoo1 usw., aber das fällt beim Upgrade erstmal gar nicht auf, es wird halt einfach libfoo1 installiert und die Kiste läuft ;)
[...]
Ah, weiß jetzt nimmer ob's dort so steht: nach dem 'dup' usw. _unbedingt_ die /boot/grub/menu.lst bzw. die Config von grub2 prüfen! Da ging immer mal wieder was schief ...
Ja, das war mal notwendig wegen /dev/sdX und /dev/disk/by-id/... Da hatte es mal nicht so geklappt. Manchmal waren bei der Verwendung von Soft-RAID auch falsche Einträge in Grub geschrieben worden. *roll_eyes* Das ist allerdings etwas länger her. Aber sicher ist sicher und man schaut sich die Einträge einfach nochmal an.
Auch sonst hat sich Yast gern mal in der "grub-installieren-Phase" verhaspelt und/oder unvollständige Configs geschrieben. Vertrauen (auf sinnvolle Vorarbeit von yast/zypper) ist gut, Kontrolle ist besser. Und ein 'grub-install.unsupported /dev/sda' bzw. was das jetzt bei grub2 ist (hab ich schon vor Jahren mal bei nem Bekannten So. Nacht nach 24 Uhr mit Ubuntu gemacht ;) ist ja auch kein Hexenwerk, nachdem man die Config von grub[2] kontrolliert hat. Oh, und ein prophylaktisches mkinitrd nach Kontrolle von INITRD_MODULES in /etc/sysconfig/kernel kann auch nicht schaden ;) Ich selber kann mir ja mit jeder bel. Live-/Installations-CD/DVD/USB-Stick Distri, die halbwegs aktuell genug ist helfen, aber für ONU gilt definitv "better safe than sorry". Mach ich ja auch so, weil's einfacher ist. Wie in den verlinkten Mails geschrieben: - '/' Klonen - grub/lilo/grub2 des Originals anpassen, daß es den Klon bootet - fstab des Klons anpassen - Klon booten - zypper dup im Klon - Nacharbeiten (immer noch vom "Originalen" grub gebootet) - wenn alles tut: grub[2]/[e]lilo Config im Klon anpassen und als "Haupt" Bootmanager installieren (im MBR oder die aktive Partition anpassen, wenn man nen generischen DOS-like Chainloader verwendet, der einfach die aktive Partition startet). - Original löschen oder als Backup behalten bis zur nächsten Iteration. Ich mach z.Z. letzteres, also regelmäßig ein 'rsync' neuen Hauptsystem (ehemals der Klon) aufs ehemalige Original. (wird z.Z. nur etwas verkompliziert dadurch, daß Haupt jetzt auf SSD und Backup/ehem. Original auf HDD liegt und ich nach der nächsten Interation das Hauptsystem gern wieder auf der SSD haben will ;)
Die Nachsorge hab ich IIRC mit Yast gemacht (statt nochmal 'zypper dup', da konnte ich besser das jew. richtige Repo auswählen etc., Tabus setzen, Abhängigkeiten "brechen", bestimmte Versionen wählen und "locken" (beim nächsten Mal) usw.).
Hier mache ich es lieber mit meinem Skript list-old-opensuse-packages.sh. Damit habe ich gleich eine Liste mit den Unstimmigkeiten, die ich dann via zypper oder YaST bereinige. ;-)
Muß ich mir mal angucken, dein Script ... (ja, das ist ne Drohung :-P) -dnh --
Was ist eigentlich das Grüne auf dem Glastisch? Miniatur-Tentakel? Radioaktiv verseuchte Pinguine? -- J. Sauer und... Nein. Das sind Pinguine nach Anwendung aller SuSE - Patches. -- Hans Bonfigt über Plüsch-Suse-Chamäleons auf einer Messe -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org