• 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] yast/zypper wie deaktivieren einer bestimmten version eines Pakets

G

gorgonz

Env: OSS 15.2

Der Grund der Frage ist schnell erklärt: Der momentan aktuelle kernel-default (*60-1) ist sehr fehlerhaft, sodass ich den auf keinen Fall haben will . Leider passiert es mir von Zeit zu Zeit, dass ich unaufmerksam bin und den kernel "versehentlich" doch mitinstalliere.

Ich kann ein Update des ganzen Pakets unterbinden, aber was ich gerne hätte, wäre, dass nur diese eine Version des Pakets nicht installiert wird. Habt ihr da Ideen dazu?

offtopic: Nachdem die schlechte Qualität des Kernels inzwischen schon länger bekannt und auch per bug-report gemeldet ist, verstehe ich nicht ganz, warum das mit einem neueren Kernel so lange dauert ???
 
S

Sauerland

Code: 
zypper al kernel-default-5.3.18-lp152.60.1

Bedeutet:
Code: 
zypper addlock NAME-VERSION
NAME und VERSION aus:
Code: 
zypper se -s NAME

So kannst du auch eine bestimmte Version installieren/löschen, einfach al durch das entsprechende ersetzen.
 
OP
G

gorgonz

ja super, Sauerland, danke Dir :D

Ich habs gleich eingetragen. Kann allerdings nicht testen, ob ich wegen manueller Abwahl des Kernels am vormittag erst wieder einen Boot brauche - stecke mitten in der Arbeit und kann nicht booten.

Folgender Effekt ist daher bei mir (derzeit noch) zu sehen, auch wenn ich zusätzlich die genaue Bezeichnung "kernel-default-5.3.18-lp152.60.1-x86_64" verwende:
  • YaST zeigt die selektive Sperre nicht an
  • Software Updater würde den kernel weiterhin aktualisieren
Gegentest "zypper ll" zumindest sieht vernünftig aus:
Code: 
# | Name                                    | Type    | Repository
--+-----------------------------------------+---------+-----------
1 | kernel-default-5.3.18-lp152.60.1        | package | (beliebig)
2 | kernel-default-5.3.18-lp152.60.1-x86_64 | package | (beliebig)
 
OP
G

gorgonz

Ja, das tat ich ;-)
=> Hmm, bin jetzt doch nicht sicher, ob wir vom gleichen reden. Ich habe in YaST nach kernel-default gesucht und im Reiter "Versionen" nachgesehen.

Inzwischen konnte ich auch mal booten und sehen, dass dies die Situation nicht ändert. Und zypper meldet die locks auch nach dem Boot weiter
Ich denke, das ist ein Bug im SW Updater und in YaST
 
OP
G

gorgonz

Hab nachgesehen und nichts Gleichartiges unter den SUSE Bugs gesehen. Daher mal als normalen Fehler eingetragen.

Bei Interesse: https://bugzilla.opensuse.org/show_bug.cgi?id=1181622
 
susejunky

susejunky

Moderator
Teammitglied
Hallo gorgonz,

Soweit mir bekannt benutzen sowohl YaST als auch zypper letztendlich libzypp und auch für PackageKit (was vermutlich hinter dem von Dir zitierten Software Updater steckt) gibt es ein PackageKit-backend-zypp. Ich würde daher erwarten, dass sich alle drei Anwendungen gleich verhalten und die in /etc/zypp/locks gesetzten Sperren respektieren; d.h. die gesperrten Pakete entweder nicht installieren/aktualisieren oder zumindest nachfragen, ob die Sperre aufgehoben werden soll.

Du sagst, dass Dir YaST anzeigt, dass für von Dir gesperrte Pakete eine Aktualisierung zur Verfügung steht. Das an sich ist meines Erachtens noch kein Fehler.

Es stellt sich die Frage:

Aktualisiert YaST diese gesperrten Pakete ohne weitere Nachfrage, wenn Du YaST -> Software installieren oder löschen -> Paket -> Alle Pakete -> Aktualisieren, falls neuere Version verfügbar auswählst?

Ich verwende openSUSE Tumbleweed und habe PackageKit deinstalliert. Meine Installation ist mit der Deinen daher nur bedingt vergleichbar. Aber bei mir verhalten sich YaST und zypper korrekt; d.h. gesperrte Pakete werden weder installiert noch, wenn sie bereits installiert sind, aktualisiert.

Viele Grüße

susejunky
 
OP
G

gorgonz

Klar susejunky, Dein Einwand ist berechtigt. Für die SW Updater App weiß ich es bereits, da ich in unaufmerksamen Momenten einfach auf "Updates installieren" geklickt hatte ;-).
Für YaST mach ich den Versuch zur Sicherheit, also
  • YaST starten
  • auf übernehmen klicken

=> der *60 kernel wird installiert
 
susejunky

susejunky

Moderator
Teammitglied
Hallo gorgonz,
gorgonz schrieb:
Klar susejunky, Dein Einwand ist berechtigt. Für die SW Updater App weiß ich es bereits, da ich in unaufmerksamen Momenten einfach auf "Updates installieren" geklickt hatte ;-).
Für YaST mach ich den Versuch zur Sicherheit, also
  • YaST starten
  • auf übernehmen klicken

=> der *60 kernel wird installiert
Zum Vergrößern anklicken....
Dein Ablauf war also YaST -> Software installieren oder löschen -> Übernehmen und Du hast keine weitere Aktion (z.B. den gelockten Kernel zum Aktualisieren ausgewählt) vor dem Aktivieren der Übernehmen-Schaltfläche mehr ausgeführt?

Könntest Du bitte einmal den Inhalt Deiner Datei /etc/zypp/locks hier (oder über susepaste) zeigen ?

Viele Grüße

susejunky
 
OP
G

gorgonz

Nicht ganz, susejunky.

Ich habe YaST -> Online Aktualisierung gewählt. Ich will ja keine neue SW installieren.
Daraufhin wird der Reiter "Patches" aktiviert und links in der Zusammenfassung "Security update for the Linux kernel" mit blauem Pluszeichen angezeigt.

Wenn ich jetzt "übernehme", dann wird der gelockte kernel installiert.

Anbei noch der Inhalt von /etc/zypp/locks:
Code: 
type: package
match_type: glob
case_sensitive: on
solvable_name: kernel-default-5.3.18-lp152.60.1


type: package
match_type: glob
case_sensitive: on
solvable_name: kernel-default-5.3.18-lp152.60.1-x86_64
 
susejunky

susejunky

Moderator
Teammitglied
Hallo gorgonz,
gorgonz schrieb:
... Ich habe YaST -> Online Aktualisierung gewählt. ... Daraufhin wird der Reiter "Patches" aktiviert und links in der Zusammenfassung "Security update for the Linux kernel" mit blauem Pluszeichen angezeigt.

Wenn ich jetzt "übernehme", dann wird der gelockte kernel installiert.

Anbei noch der Inhalt von /etc/zypp/locks:
Code: 
type: package
match_type: glob
case_sensitive: on
solvable_name: kernel-default-5.3.18-lp152.60.1


type: package
match_type: glob
case_sensitive: on
solvable_name: kernel-default-5.3.18-lp152.60.1-x86_64
Zum Vergrößern anklicken....
Die zypper-Dokumentation sagt:
Code: 
> man zypper
Package Types
       Zypper works with several types of resource objects, called resolvables. A resolvable might be a package, patch, pattern, product; basically any kind
       of object with dependencies to other objects.
...
       patch
           A released patch conflicts with the affected/vulnerable versions of a collection of packages. As long as any of these affected/vulnerable versions
           are installed, the conflict triggers and the patch is classified as needed, or as unwanted if the patch is locked.

           Selecting the patch, the conflict is resolved by updating all installed and affected/vulnerable packages to a version providing the fix.
...
UND BEI zypper install steht noch
...
-t, --type type
               ...
               If patch is specified, zypper will install and/or remove packages to satisfy specified patch. This is a way to ensure that specific bug fix is
               installed. Use zypper list-patches to look for applicable patches.
...
Ist kernel-default-5.3.18-lp152.60.1 bei Dir noch installiert (d.h. in /boot vorhanden)?

Da sich Dein Lock auf ein Paket (nicht auf einen Patch) bezieht, könnte es sein (falls der gelockte Kernel noch vorhanden ist), dass für ihn Patches eingespielt werden, obwohl das Paket selbst gelockt ist.

Ich muss jedoch sagen, da ich openSUSE Tumbleweed benutze, bin ich mit YaST -> Online-Aktualisierung und dem Einspielen von Patches nicht wirklich vertraut (ich aktualisiere Tumbleweed ausschließlich mit zypper dup).

Vielleicht helfen Dir
Code: 
> man zypper
und
Code: 
> man locks
weiter.

Meines Erachtens solltest Du auch Deinen Bugreport (insbesondere den Titel) dahingehend konkretisieren, dass klar wird, dass YaST Online-Aktualisierung einen Patch für ein gelocktes Paket einspielen will.

Viele Grüße

susejunky
 
OP
G

gorgonz

Hmm, das ist auch eine gute Überlegung, susejunky. Ich bin selbst stutzig geworden als ich zum ersten mal bewusst wahrgenommen habe, dass es sich um einen Security Patch handelt, was vielleicht irgendwie eine Abhängigkeit bei der Problematik nach sich zieht.

Ich habe/hatte aber den Kernel *60 sauber deinstalliert - mit YaST. Trotzdem nachgesehen in /boot. Da sind nur Dateien vom Typ *57.

Werde die neuen Erkenntnisse in den bug report übertragen, beim richtigen Titel bin ich nicht so sicher, kann ja nicht einschätzen, ob das nur bei Patches passiert oder generell, wird Schritt 2 ;-).
 
S

Sauerland

Ich habe YaST -> Online Aktualisierung gewählt. Ich will ja keine neue SW installieren.
Zum Vergrößern anklicken....
Das hab ich in meinem 15 Jahren noch nie benutzt.

Entweder
Code: 
zypper up
oder
Yast----Software installieren----Pakete----alle Pakete-----aktualisieren falls neuere Version verfügbar
 
OP
G

gorgonz

Hihi, ich habe seit Jahren meine YaST Updates über Online aktualisieren gemacht und nie über Software installieren ;-)
Egal, Beides ist möglich.

In meinem Tumbleweed System arbeite ich fast zu 100% mit zypper dup, da taugt die SW Updater App nicht viel und zypper ist schneller gemacht als YaST.
 
OP
G

gorgonz

@susjunky, @sauerland: Wow, der Vorschlag im bug report funktioniert :)

Allerdings kann das im Hilfetext von zypper wirklich nicht erraten werden, wie die richtige Syntax dafür lautet. Daher habe ich den Vorschlag dort übernommen, den Fehler an die Dokumentation weiterzuleiten, um den Hilfetext zu ergänzen.

Nur für diejenigen, die sich im bug report nicht zurecht gefunden haben:
Um eine spezifische Version eines Pakets zu sperren genügt es nicht
Code: 
zypper al kernel-default-5.3.18-lp152.60.1
zu verwenden. Die richtige Syntx lautet:
Code: 
zypper al 'kernel-default = 5.3.18-lp152.60.1'

Hey, das war eine schwierige Geburt, aber wieder alles gut. Danke für die guten Gedanken und Beiträge :)
 
OP
G

gorgonz

Hihi, genau. Der ist vorhin auch beim normalen Update aufgetaucht und ich hab den *63 gleich installiert ... geht wieder :)
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Oben