Tag Archives: yum

Mit Yum Paketupdates rückgängig machen

Posted on by

Ab und zu kann es vorkommen, daß neue Pakete von Treiber oder Programmen zu Fehlern führen. Jüngstes Beispiel ist der Nvidia Treiber für Fedora 20. Da die Auswirkungen erst nach dem Neustart des Computers wirksam werden, benötigt man zum Beheben des Problems Rootrechte.

Pakete identifizieren

Zunächst einmal muß man die Pakete finden, die aktualisiert wurden. Dazu schaut man sich die letzten Zeilen des Yum Logfiles an :

# tail /var/log/yum.log
Jan 29 00:42:04 Updated: 1:kmod-nvidia-340xx-3.17.8-200.fc20.x86_64-340.65-4.fc20.x86_64
Jan 29 00:42:04 Updated: 1:kmod-nvidia-340xx-340.65-4.fc20.x86_64
Jan 29 00:45:22 Installed: 1:kmod-nvidia-3.17.8-200.fc20.x86_64-331.113-1.fc20.1.x86_64

Pakete die mit der Sache nichts zu tun haben, könnten natürlich auch installiert worden sein, im obigen Beispiel ist das nicht der Fall.

Pakete downgraden

Die Pakete wieder los zu werden ist ganz einfach, wenn man den korrekten Namen ermittelt hat:

# yum downgrade kmod-nvidia-340xx-3.17.8-200.fc20.x86_64
# yum downgrade kmod-nvidia-340xx-340

Updates verhindern

Damit die Pakete beim nächsten Update nicht wieder mit eingespielt werden, trägt man diese in die Liste der ausgeklammerten Pakete in der YUM Konfiguration ein:

# vi /etc/yum.conf

[main]
cachedir=/var/cache/yum/$basearch/$releasever
keepcache=0
debuglevel=2
logfile=/var/log/yum.log
exactarch=1
obsoletes=1
gpgcheck=1
plugins=1
installonly_limit=3
exclude=kmod-nvidia-340xx*

Damit wäre man vorerst vor Updates sicher.  Das nächste Kernelupdate kommt aber todsicher und dann braucht man die neue Version der Pakete für diesen neuen Kernel. Man muß sich also jetzt sofort darum kümmern, daß dieser Fehler bekannt und natürlich behoben wird.

Bugzilla

RPMFusion und Fedora haben jeweils eine eigen Fehlertrackersoftware namens Bugzilla im Einsatz. Da die Nvidiatreiber über RPMFusion bekommen sind, muß man das Paket dort als Fehlerhaft melden.

Details zur Anmeldung kann man auf rpmfusion.org finden.

Es geht aber auch direkter, was in diesem Fall wohl dringend nötig ist. Dazu lädt man sich die defekten RPMS aus dem Repository direkt auf die Platte. Wie das geht habe ich hier beschrieben: Aus Yum ableiten wo ein RPM findet

Dann schaut man sich die Infos zu diesem RPM an : less xorg-x11-drv-nvidia-340xx-*

Neben allerlei Informationen zu dem Paket selbst, kann man hier auch direkt das Changelog sehen:

* Di Jan 27 2015 Leigh Scott <leigh123linux@googlemail.com> – 1:340.65-5
– revert last commit

Nun können Sie das direkt an den Entwickler melden, der das „verbockt“ hat 🙂

wenn das Paket bereits installiert ist …

geht das Aufrufen des Changelogs wesentlich einfacher :

# rpm -q –changelog xorg-x11-drv-nvidia-340xx
* Do Jan 15 2015 Przemysław Palacz <pprzemal@gmail.com> – 1:340.65-4
– Replace main nvidia driver in F20 with this legacy version

* So Jan 11 2015 Przemysław Palacz <pprzemal@gmail.com> – 1:340.65-3
– Switch libnvidia-ml and nvidia-debugdump to the cuda subpackage again

… die Logs gehen bis zur ersten Release des Pakets zurück …

* So Jun 22 2003 Andreas Bierfert (awjb) <andreas.bierfert[at]awbsworld.de> – 0:1.0.4363-0.fdr.1
– Initial RPM release, still some ugly stuff in there but should work…

Kein Wunder, daß die Pakete immer länger brauchen bis sie geladen worden sind.

aus YUM ableiten, wo man ein RPM findet

Posted on by

Ich werde immer gern gefragt, wo ich den die Links zu den RPMs finde, wenn ich brauche, aber nicht finde. Ein Weg ist das YUM Repo direkt fragen. Zunächst einmal suchen wir uns das passende Repository aus:

# ls -la /etc/yum.repos.d/
insgesamt 68
drwxr-xr-x.   2 root root  4096 18. Jun 14:25 .
drwxr-xr-x. 172 root root 12288  4. Aug 08:35 ..
-rw-r--r--.   1 root root   179 25. Jul 2007  adobe-linux-i386.repo
-rw-r--r--.   1 root root   183  1. Apr 2011  adobe-linux-x86_64.repo
-rw-r--r--.   1 root root  1254 19. Feb 14:46 fedora.repo
-rw-r--r--.   1 root root  1213 19. Feb 14:46 fedora-updates.repo
-rw-r--r--.   1 root root  1271 19. Feb 14:46 fedora-updates-testing.repo
-rw-r--r--.   1 root root  1241 15. Dez 2013  rpmfusion-free-rawhide.repo
-rw-r--r--.   1 root root  1172 15. Dez 2013  rpmfusion-free.repo
-rw-r--r--.   1 root root  1170 15. Dez 2013  rpmfusion-free-updates.repo
-rw-r--r--.   1 root root  1230 18. Mär 2013  rpmfusion-free-updates-testing.repo

dann holen wir uns die BaseURL aus dem Repo ( was anderes macht Yum eigentlich auch nicht )

# cat /etc/yum.repos.d/rpmfusion-free.repo | grep baseurl
#baseurl=http://download1.rpmfusion.org/free/fedora/releases/$releasever/Everything/$basearch/os/
#baseurl=http://download1.rpmfusion.org/free/fedora/releases/$releasever/Everything/$basearch/debug/
#baseurl=http://download1.rpmfusion.org/free/fedora/releases/$releasever/Everything/source/SRPMS/

Die BaseURL kann mit einem normalen Browser aufgerufen werden, wenn man die Variablen ersetzt.

$releasever = Fedora Nummer z.b. 20
$basearch = Basearchitecture also i686 für 32 bit oder x86_64 für 64 bit.

Beispiel:

http://download1.rpmfusion.org/free/fedora/releases/20/Everything/x86_64/os/

Jetzt rufen Sie das noch mit dem Browser auf und siehe da, alle RPMs liegen vor Ihnen.

Es kann vorkommen, wenn die Repos besonders groß sind, daß diese in mehrere Teile aufgeteilt sind. Üblicherweise nach dem ersten Zeichen des Dateinamens also A B C usw. .

RPMFIND.net

Wenn Sie ein spezielles RPM suchen, daß nicht in Ihren Repos enthalten ist, kann http://rpmfind.net/ Ihnen helfen. Sie finden dort eine Vielzahl von Paketen, die nicht mit Fedora ausgeliefert werden, aber trotzdem benötigt werden. Oder auch einfach nur ältere Versionen.

Koji – Alte Pakete finden, die Fedora aus dem Repo gelöscht hat.

Rufen Sie mal diese URL auf :  http://koji.fedoraproject.org/koji/packageinfo?packageID=280

Sie werden dort die Liste aller HTTPD Pakete finden, die jemals für Fedora gebaut wurden.

alle jemals gebauten Pakete für ein Programm

alle jemals gebauten Pakete für ein Programm

Suchen Sie sich die Version aus, die Sie gern hätten und klicken Sie auf den Link. Sie bekommen dann die Paketinformationen angezeigt. Diese enthält auch alle Downloadlinks zu den jeweiligen Architekturen.

genaue Paketinformationen und Downloadlinks

genaue Paketinformationen und Downloadlinks

YUM: Abhängigkeitsprobleme lösen

Posted on by

Es kann vorkommen, daß einzelne Abhängigkeiten bei einem Update über mehrere Repositories nicht aufgelöst werden können. Z.b. weil im Fedora Hauptrepo eine neuere Version des Pakets verteilt werden soll, wie in den anderen Repos referenziert werden. Oder anders ausgedrückt, jemand hat sein Update noch nicht fertig und hinkt hinterher.

Am Beispiel des jüngsten QMMP Updates, möchte ich das mal verdeutlichen :

---> Paket qmmp.x86_64 0:0.7.4-1.fc20 markiert, um aktualisiert zu werden
 --> Abhängigkeit qmmp(x86-64) = 0.7.4 wird für Paket qmmp-plugins-freeworld-0.7.4-1.fc20.x86_64 verarbeitet
 --> Abhängigkeitsauflösung beendet
 --> Transaktionsprüfung wird ausgeführt
 ---> Paket qmmp.x86_64 0:0.7.4-1.fc20 markiert, um aktualisiert zu werden
 --> Abhängigkeit qmmp(x86-64) = 0.7.4 wird für Paket qmmp-plugins-freeworld-0.7.4-1.fc20.x86_64 verarbeitet
 --> Abhängigkeitsauflösung beendet
 Fehler: Paket: qmmp-plugins-freeworld-0.7.4-1.fc20.x86_64 (@rpmfusion-free-updates)
 Benötigt: qmmp(x86-64) = 0.7.4
 Entfernen: qmmp-0.7.4-1.fc20.x86_64 (@updates)
 qmmp(x86-64) = 0.7.4-1.fc20
 Aktualisiert durch: qmmp-0.7.7-1.fc20.1.x86_64 (updates)
 qmmp(x86-64) = 0.7.7-1.fc20.1
 Verfügbar: qmmp-0.7.2-1.fc20.x86_64 (fedora)
 qmmp(x86-64) = 0.7.2-1.fc20
 Sie können versuchen, mit --skip-broken das Problem zu umgehen.
 Sie könnten Folgendes versuchen: rpm -Va --nofiles --nodigest

Was steht da jetzt wirklich ?

QMMP soll von 0.7.4 auf 0.7.7 aktualisiert werden,
ABER das qmmp-plugins-freeworld-0.7.4-1 Paket braucht 0.7.4-1 und nicht 0.7.7 .

Den Vorschlag SKIP BROKEN kann man einfach vergessen. Der Zustand kommt öfter vor,
deswegen hier gleich mal die Lösung:

 #  vi /etc/yum.conf

Ans Ende der Main-Sektion schreibt man nun einfach „exclude=qmmp*“ .

Das könnte dann so aussehen :

[main]
cachedir=/var/cache/yum/$basearch/$releasever
keepcache=0
debuglevel=2
logfile=/var/log/yum.log
exactarch=1
obsoletes=1
gpgcheck=1
plugins=1
installonly_limit=3
exclude=qmmp*

#  This is the default, if you make this bigger yum won't see if the metadata

Ein „yum update“ wird jetzt durchlaufen. In einer Woche können wir dann mal nachsehen, ob das qmmp-plugins-freeworld Paket auf Stand ist.