Hallo Liste, ich habe nun drei Maschinen auf 15.3 upgedated. Erneut ein Kotau an alle Entwickler und Mitarbeiter des Suse-Teams. Dabei habe ich ewig Zeit damit verbracht, in der Conflictliste jeweils die Zustimmung zum "allow vendor update" anzuklicken. Der Rest hat wie erwartet prima funktioniert. Meine Frage: Habe ich übersehen, eine zentrale Konfig zum allow vendor update auszuwählen, oder könnte in Zukunft ein solcher im Update vorhanden sein ? mfg K. Müller
On 20.06.21 15:53, Kasimir Müller wrote:
ich habe nun drei Maschinen auf 15.3 upgedated.
Erneut ein Kotau an alle Entwickler und Mitarbeiter des Suse-Teams.
Dabei habe ich ewig Zeit damit verbracht, in der Conflictliste
jeweils die Zustimmung zum "allow vendor update" anzuklicken.
Der Rest hat wie erwartet prima funktioniert.
Meine Frage:
Habe ich übersehen, eine zentrale Konfig zum allow vendor update auszuwählen, oder
könnte in Zukunft ein solcher im Update vorhanden sein ?
Wie hast Du das Update denn angestoßen? Mir sind zwei Optionen bekannt: - /etc/zypp/repos.d/* anpassen, 'zypper dup' ausführen - vom neuen ISO booten, Upgrade auswählen. In beiden Fällen ist m.W. der Vendor Change der Default. Viele Grüße Ulf
Ich habe von der Install-DVD gebooted, upgrade ausgewählt , die Repos werden gesetzt, bei Repos habe ich behalten und die den Link auf 15.3 geändert. Bei der nächsten und letzten Installation werde ich mal dein Rezept benutzen. Danke, K. Müller Am 20.06.21 um 21:39 schrieb Ulf Volmer:
On 20.06.21 15:53, Kasimir Müller wrote:
ich habe nun drei Maschinen auf 15.3 upgedated.
Erneut ein Kotau an alle Entwickler und Mitarbeiter des Suse-Teams.
Dabei habe ich ewig Zeit damit verbracht, in der Conflictliste
jeweils die Zustimmung zum "allow vendor update" anzuklicken.
Der Rest hat wie erwartet prima funktioniert.
Meine Frage:
Habe ich übersehen, eine zentrale Konfig zum allow vendor update auszuwählen, oder
könnte in Zukunft ein solcher im Update vorhanden sein ? Wie hast Du das Update denn angestoßen?
Mir sind zwei Optionen bekannt:
- /etc/zypp/repos.d/* anpassen, 'zypper dup' ausführen - vom neuen ISO booten, Upgrade auswählen.
In beiden Fällen ist m.W. der Vendor Change der Default.
Viele Grüße Ulf
Am So., 20. Juni 2021 um 21:56 Uhr schrieb Kasimir Müller
Bei der nächsten und letzten Installation werde ich mal dein Rezept benutzen.
Das offizielle Rezept ist etwas anders: https://doc.opensuse.org/documentation/leap/startup/html/book-startup/cha-up... Gruß Martin
On 20.06.21 22:38, Martin Schröder wrote:
Am So., 20. Juni 2021 um 21:56 Uhr schrieb Kasimir Müller
: Bei der nächsten und letzten Installation werde ich mal dein Rezept benutzen.
Das offizielle Rezept ist etwas anders:
https://doc.opensuse.org/documentation/leap/startup/html/book-startup/cha-up...
Das stimmt. Danke für die Korrektur. Viele Grüße Ulf
Hallo, ich gehe schon seit vielen Jahren allen Update-Problemen aus dem Weg, indem ich keine Updates mache, sondern Neuinstallationen. Erster Schritt: Sichern von /home inklusive aller Config-Dateien darin. Zweiter Schritt: Installation der neuen Version. Dritter Schritt: Zurückkopieren von /home. Zugegeben, ist ein bisschen aufwendig, aber dafür problemfrei. VG Patrick
Am Sonntag, 20. Juni 2021, 23:55:10 CEST schrieb Patrick Flügel:
Hallo,
ich gehe schon seit vielen Jahren allen Update-Problemen aus dem Weg, indem ich keine Updates mache, sondern Neuinstallationen.
Erster Schritt: Sichern von /home inklusive aller Config-Dateien darin. Zweiter Schritt: Installation der neuen Version. Dritter Schritt: Zurückkopieren von /home.
Zugegeben, ist ein bisschen aufwendig, aber dafür problemfrei.
VG Patrick
mach doch /home als eigene partition - dann musst du bei einer neuinstallation nur angeben dass die ohne formatieren gemountet werden soll. Cheers MH -- Mathias Homann Mathias.Homann@openSUSE.org Jabber (XMPP): lemmy@tuxonline.tech IRC: [Lemmy] on freenode and ircnet (bouncer active) telegram: https://telegram.me/lemmy98 keybase: https://keybase.io/lemmy gpg key fingerprint: 8029 2240 F4DD 7776 E7D2 C042 6B8E 029E 13F2 C102
Hallo, Am 21.06.21 um 07:10 schrieb Mathias Homann:
mach doch /home als eigene partition - dann musst du bei einer neuinstallation nur angeben dass die ohne formatieren gemountet werden soll.
da /home auf eine externe Festplatte gesichert wird, bringt ein Mounten von /home nach der Neuinstallation nichts. Ich müsste ja die externe HD dann permanent angeschlossen haben. VG Patrick
Am 21.06.21 um 17:05 schrieb Patrick Flügel:
Hallo,
Am 21.06.21 um 07:10 schrieb Mathias Homann:
mach doch /home als eigene partition - dann musst du bei einer neuinstallation nur angeben dass die ohne formatieren gemountet werden soll.
da /home auf eine externe Festplatte gesichert wird, bringt ein Mounten von /home nach der Neuinstallation nichts. Ich müsste ja die externe HD dann permanent angeschlossen haben.
Man(n) kann home vom System einfach auf der Systemplatte anlegen lassen und nach der Grundinstallation das "neue" home gegen das "alte" mit geeigneten Maßnahmen austauschen, Link sei dank. Peter
Kasimir Müller schrieb:
ich habe nun drei Maschinen auf 15.3 upgedated.
Erneut ein Kotau an alle Entwickler und Mitarbeiter des Suse-Teams.
Dabei habe ich ewig Zeit damit verbracht, in der Conflictliste
jeweils die Zustimmung zum "allow vendor update" anzuklicken.
Etliche Pakete haben zwischen OpenSuse 15.2 und 15.3 den Vendor von OpenSuse auf Suse LLC gewechselt. Wenn das passiert, erfolgt NORMALERWEISE tatsächlich pro Paket ein Konflikt, den man jeweils einzeln bestätigen kann ODER man macht eben ein "zypper --allow-vendor-change", dann entsteht der Konflikt gar nicht erst, dies aber mit der Gefahr, dass man ungewollte andere Vendor-Wechsel macht, wenn man "seltsame" Repos angebunden hat. Es gibt aber noch eine dritte Möglichkeit, man kann nämlich den "neuen" Vendor in eine Whitelist eintragen, dann erfolgt auch genau beim Wechsel auf DIESEN Vendor KEIN Konflikt. Das ist aufgrund der vorgenannten Dinge die beste Variante. Und das wurde bei OpenSuse 15.2 irgendwann per Update "stillschweigend" gemacht. Als ich im Dezember 2020 auf einer Test-VM die damalige 15.3 Alpha installiert habe, musste ich noch "--allow-vendor-change" machen, bei Upgrade meiner Arbeits-VM auf 15.3 Final musste ich das NICHT MEHR machen. Das entsprechende Update muss also irgendwann in der Zwischenzeit erfolgt sein. Ich hatte bislang keine Lust "rauszuknuffeln", welches Update das GENAU war. Es kann auch recht knapp vor dem Erscheinen von 15.3 gekommen sein, ich weiß es nicht. Dieses Update fehlte wohl bei Dir. Und genau solche Phänomene sind auch der Grund, warum vor einem Upgrade auf 15.3 dazu geraten wird, die letzten Patches von 15.2 vorher einzuspielen. -- Manfred Härtel, DB3HM mailto:Manfred.Haertel@rz-online.de http://rz-home.de/mhaertel
Danke, endlich eine konstruktive Antwort. Ich hatte natürlich vor dem Update ein zypper refresh, zypper update gemacht. Jetzt ist ja ausgestanden, aber wo und wie liegt die bewusste Whitelist. mfg K. Müller Am 21.06.21 um 19:12 schrieb Manfred Haertel, DB3HM:
Kasimir Müller schrieb:
ich habe nun drei Maschinen auf 15.3 upgedated.
Erneut ein Kotau an alle Entwickler und Mitarbeiter des Suse-Teams.
Dabei habe ich ewig Zeit damit verbracht, in der Conflictliste
jeweils die Zustimmung zum "allow vendor update" anzuklicken.
Etliche Pakete haben zwischen OpenSuse 15.2 und 15.3 den Vendor von OpenSuse auf Suse LLC gewechselt.
Wenn das passiert, erfolgt NORMALERWEISE tatsächlich pro Paket ein Konflikt, den man jeweils einzeln bestätigen kann ODER man macht eben ein "zypper --allow-vendor-change", dann entsteht der Konflikt gar nicht erst, dies aber mit der Gefahr, dass man ungewollte andere Vendor-Wechsel macht, wenn man "seltsame" Repos angebunden hat.
Es gibt aber noch eine dritte Möglichkeit, man kann nämlich den "neuen" Vendor in eine Whitelist eintragen, dann erfolgt auch genau beim Wechsel auf DIESEN Vendor KEIN Konflikt. Das ist aufgrund der vorgenannten Dinge die beste Variante. Und das wurde bei OpenSuse 15.2 irgendwann per Update "stillschweigend" gemacht.
Als ich im Dezember 2020 auf einer Test-VM die damalige 15.3 Alpha installiert habe, musste ich noch "--allow-vendor-change" machen, bei Upgrade meiner Arbeits-VM auf 15.3 Final musste ich das NICHT MEHR machen. Das entsprechende Update muss also irgendwann in der Zwischenzeit erfolgt sein. Ich hatte bislang keine Lust "rauszuknuffeln", welches Update das GENAU war. Es kann auch recht knapp vor dem Erscheinen von 15.3 gekommen sein, ich weiß es nicht.
Dieses Update fehlte wohl bei Dir. Und genau solche Phänomene sind auch der Grund, warum vor einem Upgrade auf 15.3 dazu geraten wird, die letzten Patches von 15.2 vorher einzuspielen.
Hallo, das müsste /etc/zypp/vendors.d/00-openSUSE.conf sein, sieht bei mir derzeit (schon unter 15.3) wie folgt aus: [main] vendors=openSUSE,SUSE,SUSE LLC https://www.suse.com/ Laut "rpm -qf" gehört die Datei übrigens zum Paket openSUSE-release-15.3-lp153.146.1.x86_64 , womit das auch geklärt wäre. :-) Warum sich dein System anders verhalten hat als meins, kann ich leider auch nicht erklären. Viele Grüße Manfred Kasimir Müller schrieb:
Danke, endlich eine konstruktive Antwort.
Ich hatte natürlich vor dem Update ein zypper refresh, zypper update gemacht.
Jetzt ist ja ausgestanden, aber wo und wie liegt die bewusste Whitelist.
mfg
K. Müller
Am 21.06.21 um 19:12 schrieb Manfred Haertel, DB3HM:
Kasimir Müller schrieb:
ich habe nun drei Maschinen auf 15.3 upgedated.
Erneut ein Kotau an alle Entwickler und Mitarbeiter des Suse-Teams.
Dabei habe ich ewig Zeit damit verbracht, in der Conflictliste
jeweils die Zustimmung zum "allow vendor update" anzuklicken.
Etliche Pakete haben zwischen OpenSuse 15.2 und 15.3 den Vendor von OpenSuse auf Suse LLC gewechselt.
Wenn das passiert, erfolgt NORMALERWEISE tatsächlich pro Paket ein Konflikt, den man jeweils einzeln bestätigen kann ODER man macht eben ein "zypper --allow-vendor-change", dann entsteht der Konflikt gar nicht erst, dies aber mit der Gefahr, dass man ungewollte andere Vendor-Wechsel macht, wenn man "seltsame" Repos angebunden hat.
Es gibt aber noch eine dritte Möglichkeit, man kann nämlich den "neuen" Vendor in eine Whitelist eintragen, dann erfolgt auch genau beim Wechsel auf DIESEN Vendor KEIN Konflikt. Das ist aufgrund der vorgenannten Dinge die beste Variante. Und das wurde bei OpenSuse 15.2 irgendwann per Update "stillschweigend" gemacht.
Als ich im Dezember 2020 auf einer Test-VM die damalige 15.3 Alpha installiert habe, musste ich noch "--allow-vendor-change" machen, bei Upgrade meiner Arbeits-VM auf 15.3 Final musste ich das NICHT MEHR machen. Das entsprechende Update muss also irgendwann in der Zwischenzeit erfolgt sein. Ich hatte bislang keine Lust "rauszuknuffeln", welches Update das GENAU war. Es kann auch recht knapp vor dem Erscheinen von 15.3 gekommen sein, ich weiß es nicht.
Dieses Update fehlte wohl bei Dir. Und genau solche Phänomene sind auch der Grund, warum vor einem Upgrade auf 15.3 dazu geraten wird, die letzten Patches von 15.2 vorher einzuspielen.
-- Manfred Härtel, DB3HM mailto:Manfred.Haertel@rz-online.de http://rz-home.de/mhaertel
Danke, ist bei mir auf den neuen 15.3 Systemen auch vorhanden. Aber wie kann das beim Update von 15.2 mit dem Boot des Install-Sticks helfen ? K. Müller Am 23.06.21 um 05:21 schrieb Manfred Haertel, DB3HM:
Hallo,
das müsste /etc/zypp/vendors.d/00-openSUSE.conf sein, sieht bei mir derzeit (schon unter 15.3) wie folgt aus:
[main] vendors=openSUSE,SUSE,SUSE LLC https://www.suse.com/
Laut "rpm -qf" gehört die Datei übrigens zum Paket openSUSE-release-15.3-lp153.146.1.x86_64 , womit das auch geklärt wäre. :-)
Warum sich dein System anders verhalten hat als meins, kann ich leider auch nicht erklären.
Viele Grüße
Manfred
Kasimir Müller schrieb:
Danke, endlich eine konstruktive Antwort.
Ich hatte natürlich vor dem Update ein zypper refresh, zypper update gemacht.
Jetzt ist ja ausgestanden, aber wo und wie liegt die bewusste Whitelist.
mfg
K. Müller
Am 21.06.21 um 19:12 schrieb Manfred Haertel, DB3HM:
Kasimir Müller schrieb:
ich habe nun drei Maschinen auf 15.3 upgedated.
Erneut ein Kotau an alle Entwickler und Mitarbeiter des Suse-Teams.
Dabei habe ich ewig Zeit damit verbracht, in der Conflictliste
jeweils die Zustimmung zum "allow vendor update" anzuklicken.
Etliche Pakete haben zwischen OpenSuse 15.2 und 15.3 den Vendor von OpenSuse auf Suse LLC gewechselt.
Wenn das passiert, erfolgt NORMALERWEISE tatsächlich pro Paket ein Konflikt, den man jeweils einzeln bestätigen kann ODER man macht eben ein "zypper --allow-vendor-change", dann entsteht der Konflikt gar nicht erst, dies aber mit der Gefahr, dass man ungewollte andere Vendor-Wechsel macht, wenn man "seltsame" Repos angebunden hat.
Es gibt aber noch eine dritte Möglichkeit, man kann nämlich den "neuen" Vendor in eine Whitelist eintragen, dann erfolgt auch genau beim Wechsel auf DIESEN Vendor KEIN Konflikt. Das ist aufgrund der vorgenannten Dinge die beste Variante. Und das wurde bei OpenSuse 15.2 irgendwann per Update "stillschweigend" gemacht.
Als ich im Dezember 2020 auf einer Test-VM die damalige 15.3 Alpha installiert habe, musste ich noch "--allow-vendor-change" machen, bei Upgrade meiner Arbeits-VM auf 15.3 Final musste ich das NICHT MEHR machen. Das entsprechende Update muss also irgendwann in der Zwischenzeit erfolgt sein. Ich hatte bislang keine Lust "rauszuknuffeln", welches Update das GENAU war. Es kann auch recht knapp vor dem Erscheinen von 15.3 gekommen sein, ich weiß es nicht.
Dieses Update fehlte wohl bei Dir. Und genau solche Phänomene sind auch der Grund, warum vor einem Upgrade auf 15.3 dazu geraten wird, die letzten Patches von 15.2 vorher einzuspielen.
Hallo allerseits da es anscheinend bei einigen Probleme mit dem Update 15.2 -> 15.3 gab möchte ich hier nur kurz positives rückmelden. mit folgende Kommandos hat bei mir alles problemlos geklappt: zypper ref && \ zypper up && \ zypper patch && \ zypper rr -a # delete all repros! V=15.3 ; \ zypper ar -n "openSUSE-$V OSS" http://download.opensuse.org/distribution/leap/$V/repo/oss/ repo-$V-oss && \ zypper ar -n "openSUSE-$V Non-OSS" http://download.opensuse.org/distribution/leap/$V/repo/non-oss/ repo-$V-non-oss && \ zypper ar -n "openSUSE-$V Updates OSS" http://download.opensuse.org/update/leap/$V/oss/ repo-$V-update-oss && \ zypper ar -n "openSUSE-$V Updates Non-OSS" http://download.opensuse.org/update/leap/$V/non-oss/ repo-$V-update-non-oss zypper mr -aef && \ zypper clean -a && \ zypper ref && \ zypper dup --allow-vendor-change auf meinen beiden LAMP-Servern (Produktiv&Test) und auch auf den Desktops. Auf den Desktops musste ich nur die multimedia-Codes wieder von "hand" nachrüsten . Aber der Klick auf "Install Multimedia Codes" auf der Seite http://opensuse-guide.org/codecs.php reichte aus. Herzlichen Dank an die Macher und den Schreiber auf der Liste der den Tip mit der --allow-vendor-change Option gab, bei der ersten test-Installation habe ich mir noch die "Finger wundgetippt" mit dem "ja zum Wechsel des Anbieters"..... Bye Jürgen
Hallo Liste,
ich habe nun drei Maschinen auf 15.3 upgedated.
Erneut ein Kotau an alle Entwickler und Mitarbeiter des Suse-Teams.
Dabei habe ich ewig Zeit damit verbracht, in der Conflictliste
jeweils die Zustimmung zum "allow vendor update" anzuklicken.
Der Rest hat wie erwartet prima funktioniert.
Meine Frage:
Habe ich übersehen, eine zentrale Konfig zum allow vendor update auszuwählen, oder
könnte in Zukunft ein solcher im Update vorhanden sein ?
mfg
K. Müller
-- Dr.rer.nat. Jürgen Vollmer, Am Rennbuckel 21, D-76185 Karlsruhe Tel: +49(721) 92 04 87 1 Fax: +49(721) 92 04 87 2 Juergen.Vollmer@informatik-vollmer.de www.informatik-vollmer.de ------------------------------------------------------------------------------- Diese EMail ist elektronisch mittels GPG / PGP signiert. Diese elektronische Unterschrift ist in einem EMail-Anhang enthalten. Leider kann die Signatur ohne die Installation entsprechender Programme weder geprüft noch angezeigt werden. Mehr dazu unter: http://www.gnupg.org oder auch http://www.pgpi.org -------------------------------------------------------------------------------
Auch ein Hallo allerseits :-) vielen Dank für die Liste der Kommandos zum Update. Ich hatte mir das Update für dieses WE vorgenommen, dank der super Vorarbeit von euch allen ging das in deutlich weniger als einer Stunde und ich habe noch Zeit für Gartenarbeit ;-) . Einen Schritt hab ich noch gemacht, da ich neben den Suse und Packman Repos auch noch ein paar andere drin habe. Vor den unten aufgeführten Schritten zuerst die bestehen Repos gesichert, (zypper lr --export Repos_15.2.repos) dann bereinigt (also in der Datei nur meine zusätzlichen drin gelassen) und nach dem 'dup' und Neustart wieder eingespielt (zypper ar Repos_15.2.repos). Viele liebe Grüße Werner Am 26.06.21 um 14:36 schrieb Dr. Juergen Vollmer:
Hallo allerseits
da es anscheinend bei einigen Probleme mit dem Update 15.2 -> 15.3 gab möchte ich hier nur kurz positives rückmelden.
mit folgende Kommandos hat bei mir alles problemlos geklappt:
zypper ref && \ zypper up && \ zypper patch && \ zypper rr -a # delete all repros!
V=15.3 ; \ zypper ar -n "openSUSE-$V OSS" http://download.opensuse.org/distribution/leap/$V/repo/oss/ repo-$V-oss && \ zypper ar -n "openSUSE-$V Non-OSS" http://download.opensuse.org/distribution/leap/$V/repo/non-oss/ repo-$V-non-oss && \ zypper ar -n "openSUSE-$V Updates OSS" http://download.opensuse.org/update/leap/$V/oss/ repo-$V-update-oss && \ zypper ar -n "openSUSE-$V Updates Non-OSS" http://download.opensuse.org/update/leap/$V/non-oss/ repo-$V-update-non-oss
zypper mr -aef && \ zypper clean -a && \ zypper ref && \ zypper dup --allow-vendor-change
auf meinen beiden LAMP-Servern (Produktiv&Test) und auch auf den Desktops.
Auf den Desktops musste ich nur die multimedia-Codes wieder von "hand" nachrüsten . Aber der Klick auf "Install Multimedia Codes" auf der Seite http://opensuse-guide.org/codecs.php reichte aus.
Herzlichen Dank an die Macher und den Schreiber auf der Liste der den Tip mit der --allow-vendor-change Option gab, bei der ersten test-Installation habe ich mir noch die "Finger wundgetippt" mit dem "ja zum Wechsel des Anbieters".....
Bye Jürgen
Hallo Liste,
ich habe nun drei Maschinen auf 15.3 upgedated.
Erneut ein Kotau an alle Entwickler und Mitarbeiter des Suse-Teams.
Dabei habe ich ewig Zeit damit verbracht, in der Conflictliste
jeweils die Zustimmung zum "allow vendor update" anzuklicken.
Der Rest hat wie erwartet prima funktioniert.
Meine Frage:
Habe ich übersehen, eine zentrale Konfig zum allow vendor update auszuwählen, oder
könnte in Zukunft ein solcher im Update vorhanden sein ?
mfg
K. Müller
-- Werner Dittmann email: Werner.Dittmann@t-online.de cell: +49 173 44 37 659 PGP key: 82EF5E8B
participants (9)
-
Dr. Juergen Vollmer
-
Kasimir Müller
-
Manfred Haertel, DB3HM
-
Martin Schröder
-
Mathias Homann
-
Patrick Flügel
-
Peter McD
-
Ulf Volmer
-
Werner Dittmann