Fedora 30: dnf segfaults wegen zchunks

Ja wir haben den 1. April, heißt aber nicht, daß alle Meldungen gleich auf einem Pseudobayrischen Verschlüsselungsmodus laufen  müssen 😀

Leider sind meine Nachrichten nicht dem 1.April geschuldet, sondern dem Umstand, daß DNF kleinere Probleme unter Fedora 30 hat. Um genau zu sein, hat die librepo das Problem und kann zeitweise keine Updates vom Fedora 30 Testrepo empfangen, weil die Metadaten als zchunk kommen, also komprimiert. Dafür gabs eigentlich einen Fix, aber der wurde durch ein Update der librepo zunichte gemacht, der ein noch größeres Loch aufriss, als er stopfte. Passiert halt mal.

Betroffene User sollen einfach mal zchunks in der dnf.conf abschalten und solange warten, bis die Patche durchgelaufen sind :

„I have submitted a fix[2] for the bug, but for now any F30 users need to do one of the following:
* Wait until the next updates push is out. It won’t have zchunk metadata, so updates will work normally again.
* Set zchunk=False in /etc/dnf/dnf.conf. This will force dnf to fall back to non-zchunk metadata, bypassing the bug.
Many apologies for the inconvenience.“

[2] https://github.com/rpm-software-management/librepo/pull/148

Dann macht das einfach mal, wenn Ihr schon Fedora 30 benutzt 😉

DNF Optionen für Eillige

Wer kennt das nicht: Der 9 Uhr Termin rückt unaufhaltsam näher, aber am Konferenzort gibt es kein oder nur mobiles Internet per Hotspot. Das Laptop will aber unbedingt noch Updates einspielen! Die Zeit drängt, was tun ?

Das Internet ist doch nicht so ubiquitär wie man denkt

So allgegenwärtig wie man es gern hätte, ist es zumindest in Deutschen Ballungsräumen eben doch nicht zu haben, in Schweden auf einer Bergwandertour dagegen schon, da könnt ihr nebenbei NetFlix in 4k streamen.

Zurück zu unserem Problem:  Was machen also? Na klar, wir laden die Updates erstmal nur und spielen die dann später ein, wenn wir da sind.

Das geht so : Schritt 1

sudo dnf update -y –downloadonly

Nun lädt dnf zu hause erstmal nur die Pakete und lagert Sie auf der Platte ein. Man kann den PC abschalten. Am Tagungsort kommt dann Schritt 2:

sudo dnf -C update

Jetzt versucht dnf nicht erst in Netz die Repoquellen zu ziehen, sondern arbeitet lokal,  aus dem Cache halt.

Problem gelöst. Während Ihr Euch entspannt dem „Meeting“ widmet, spielt Eurer LinuxLaptop locker seine Updates ein.

Kann es auch zu Problemen kommen?

In der Theorie … JA . Es kann nämlich sein, daß Eurer Laptop mit dem neuen Softwarestand nicht funktionieren möchte. Das Risiko hat man ja immer. Im Kernelbereich geht es noch, weil die letzten zwei Versionen vorgehalten werden und wegupdaten kann er die ja auf dem Meeting ohne Netz nicht, aber für alle anderen Programme gilt das nicht. Startet also bspw. Thunderbird mit dem neuesten Stand nicht sauber, kann man das ohne Netz nur beheben, wenn man ein altes Paket bereit gelegt hat. Das würde wohl auch unter Backup fallen.

… ich hatte da grade eine Idee. Laßt mich mal machen 😉

selinux-policies auf den letzten funktionierenden Stand bringen

Wie Ihr ( und .tux. )  im letzten Bericht zu selinux-policy lesen konntet, wurde das SEL Problem mit einem generellen Downgrade erstmal behoben. Heute schauen wir uns an, wie man das trotz aller Gegenwehr von Red Hat wieder auf den letzten aktuellen Stand geupdated bekommt 😉

Fedora und die Repostrukturen

Wenn man dnf downgrade benutzt, bekommt man nicht automatisch die letzte Version von einem Paket installiert, sondern nur die nächst kleinste im Repository (Repo) und genau da happerts meiner Meinung nach bei Fedora und Red Hat. Man sollte ja annehmen, daß die aktuelle Version und die vorherige Version eines Paketes zur Verfügung stehen, tun Sie aber nicht. Fedora betreibt ein Basis Repo und ein Updates Repo. Eine funktionierende alte Fassung liegt im Basis Repo, die aktuellste im Updates Repo. Zwischenversionen gibt es leider keine und das ist, denke ich, ein Fehler von Seiten der Distribution.

Immer wieder Koji

Und wieder ist es Koji, die Buildverwaltung für Fedora, die uns bei der Sache als nützliche Datenquelle dient:

https://koji.fedoraproject.org/koji/buildinfo?buildID=1076199

Dort holen wir uns die nötigen RPMs für die lokale Installation:

https://kojipkgs.fedoraproject.org//packages/selinux-policy/3.13.1/283.34.fc27/noarch/selinux-policy-targeted-3.13.1-283.34.fc27.noarch.rpm
https://kojipkgs.fedoraproject.org//packages/selinux-policy/3.13.1/283.34.fc27/noarch/selinux-policy-devel-3.13.1-283.34.fc27.noarch.rpm
https://kojipkgs.fedoraproject.org//packages/selinux-policy/3.13.1/283.34.fc27/noarch/selinux-policy-doc-3.13.1-283.34.fc27.noarch.rpm
https://kojipkgs.fedoraproject.org//packages/selinux-policy/3.13.1/283.34.fc27/noarch/selinux-policy-3.13.1-283.34.fc27.noarch.rpm

Wer meiner Anweisung gefolgt ist, und in die dnf.conf eine Sperre für das Paket eingetragen hat, muß diese Sperre jetzt natürlich wieder entfernen, bevor er das Update durchführen kann.

Manuelles DNF Update

Der Befehl „dnf update ./selinux-policy-*“ ist unser Freund:

[root]# dnf update ./selinux-policy-*
Letzte Prüfung auf abgelaufene Metadaten: vor 0:24:25 am Di 10 Jul 2018 09:59:33 CEST.
Abhängigkeiten sind aufgelöst.
================================================================================================================================================================================================================================================================================
Paket Arch Version Paketquelle Größe
================================================================================================================================================================================================================================================================================
Aktualisieren:
selinux-policy noarch 3.13.1-283.34.fc27 @commandline 541 k
selinux-policy-devel noarch 3.13.1-283.34.fc27 @commandline 1.4 M
selinux-policy-doc noarch 3.13.1-283.34.fc27 @commandline 2.7 M
selinux-policy-targeted noarch 3.13.1-283.34.fc27 @commandline 10 M

Transaktionsübersicht
================================================================================================================================================================================================================================================================================
Aktualisieren 4 Pakete

Gesamtgröße: 15 M
Ist dies in Ordnung? [j/N]:j
Pakete werden heruntergeladen:
Transaktionsüberprüfung wird ausgeführt
Transaktionsprüfung war erfolgreich.
Transaktion wird getestet
Transaktionstest war erfolgreich.
Transaktion wird ausgeführt
Vorbereitung läuft : 1/1 
Aktualisieren : selinux-policy-3.13.1-283.34.fc27.noarch 1/8 
Ausgeführtes Scriptlet: selinux-policy-3.13.1-283.34.fc27.noarch 1/8 
Ausgeführtes Scriptlet: selinux-policy-targeted-3.13.1-283.34.fc27.noarch 2/8 
Aktualisieren : selinux-policy-targeted-3.13.1-283.34.fc27.noarch 2/8 
Ausgeführtes Scriptlet: selinux-policy-targeted-3.13.1-283.34.fc27.noarch 2/8 
Aktualisieren : selinux-policy-doc-3.13.1-283.34.fc27.noarch 3/8 
Aktualisieren : selinux-policy-devel-3.13.1-283.34.fc27.noarch 4/8 
Ausgeführtes Scriptlet: selinux-policy-devel-3.13.1-283.34.fc27.noarch 4/8 
Aufräumen : selinux-policy-devel-3.13.1-283.14.fc27.noarch 5/8 
Aufräumen : selinux-policy-doc-3.13.1-283.14.fc27.noarch 6/8 
Aufräumen : selinux-policy-targeted-3.13.1-283.14.fc27.noarch 7/8 
Ausgeführtes Scriptlet: selinux-policy-targeted-3.13.1-283.14.fc27.noarch 7/8 
Aufräumen : selinux-policy-3.13.1-283.14.fc27.noarch 8/8 
Ausgeführtes Scriptlet: selinux-policy-3.13.1-283.14.fc27.noarch 8/8 
Running as unit: run-ra699effd01cd4ceba2ad927e7889ce3b.service
Running as unit: run-r27b6453c4a5e4d2ab971a1766a434a30.service
Überprüfung läuft : selinux-policy-3.13.1-283.34.fc27.noarch 1/8 
Überprüfung läuft : selinux-policy-targeted-3.13.1-283.34.fc27.noarch 2/8 
Überprüfung läuft : selinux-policy-doc-3.13.1-283.34.fc27.noarch 3/8 
Überprüfung läuft : selinux-policy-devel-3.13.1-283.34.fc27.noarch 4/8 
Überprüfung läuft : selinux-policy-targeted-3.13.1-283.14.fc27.noarch 5/8 
Überprüfung läuft : selinux-policy-3.13.1-283.14.fc27.noarch 6/8 
Überprüfung läuft : selinux-policy-devel-3.13.1-283.14.fc27.noarch 7/8 
Überprüfung läuft : selinux-policy-doc-3.13.1-283.14.fc27.noarch 8/8

Aktualisiert:
selinux-policy.noarch 3.13.1-283.34.fc27 selinux-policy-devel.noarch 3.13.1-283.34.fc27 selinux-policy-doc.noarch 3.13.1-283.34.fc27 selinux-policy-targeted.noarch 3.13.1-283.34.fc27

Fertig.

Nicht vergessen die dnf.conf wieder mit einer Sperre zu versehen :

# cat /etc/dnf/dnf.conf
[main]
gpgcheck=1
installonly_limit=3
clean_requirements_on_remove=True
exclude=selinux-pol*

Damit wären wir jetzt auf dem Stand, vor dem defekten Paket und bekommen erstmal keine Updates mehr für die selinux-policies.

Ob das so clever war, die automatischen Tests zu umgehen?

Wenn ich der Darstellung im Buildsystem glauben darf, dann wurde für den Push Tests umgangen. Da es nachweislich in die Hose gegangen ist, ist das wohl keine gute Idee.

Wissen eigentlich alle was diese Policies so machen ?

mit dem Befehl „rpm -qi selinux-policy“ bekommen wir eine Beschreibung des Pakets. Leider ist die in diesem Fall äußerst schmal geraten:

„SELinux Base package for SELinux Reference Policy – modular.
Based off of reference policy: Checked out revision 2.20091117“

Daher schauen wir doch mal in ein solches Paket rein. Jetzt ist selinux-policy kein sehr nützliches Beispiel, es setzt nämlich lediglich die System-Konfiguration und andere Metainfos. Viel spannender ist das selinux-policy-targeted Paket, daß die eigentlichen Regeln enthält. U.a. finden wir dies File darin:

/usr/share/selinux/targeted/default/active/modules/100/gnome/cil

Wenn man sich das jetzt mit less ansieht, sieht man nichts, da es bzip2 komprimiert ist. Daher brauchen wir jetzt das hier:

bzless /usr/share/selinux/targeted/default/active/modules/100/gnome/cil

u.A. findet man dann dort die Beschreibungen welche Dateien welche SEL-Contexte haben sollen:

(Die Liste ist nicht vollständig und nur für die eine Gnome Klasse)

(filecon „/var/run/user/[^/]*/\.orc(/.*)?“ any (system_u object_r gstreamer_home_t ((s0) (s0))))
(filecon „/var/run/user/[^/]*/dconf(/.*)?“ any (system_u object_r config_home_t ((s0) (s0))))
(filecon „/var/run/user/[^/]*/keyring.*“ any (system_u object_r gkeyringd_tmp_t ((s0) (s0))))
(filecon „/root/\.cache(/.*)?“ any (system_u object_r cache_home_t ((s0) (s0))))
(filecon „/root/\.color/icc(/.*)?“ any (system_u object_r icc_data_home_t ((s0) (s0))))
(filecon „/root/\.config(/.*)?“ any (system_u object_r config_home_t ((s0) (s0))))
(filecon „/root/\.kde(/.*)?“ any (system_u object_r config_home_t ((s0) (s0))))
(filecon „/root/\.gconf(d)?(/.*)?“ any (system_u object_r gconf_home_t ((s0) (s0))))
(filecon „/root/\.dbus(/.*)?“ any (system_u object_r dbus_home_t ((s0) (s0))))
(filecon „/root/\.gnome2(/.*)?“ any (system_u object_r gnome_home_t ((s0) (s0))))
(filecon „/root/\.gnome2/keyrings(/.*)?“ any (system_u object_r gkeyringd_gnome_home_t ((s0) (s0))))
(filecon „/root/\.gstreamer-.*“ any (system_u object_r gstreamer_home_t ((s0) (s0))))
(filecon „/root/\.cache/gstreamer-.*“ any (system_u object_r gstreamer_home_t ((s0) (s0))))
(filecon „/root/\.local.*“ any (system_u object_r gconf_home_t ((s0) (s0))))
(filecon „/root/\.local/share(/.*)?“ any (system_u object_r data_home_t ((s0) (s0))))
(filecon „/root/\.local/share/icc(/.*)?“ any (system_u object_r icc_data_home_t ((s0) (s0))))
(filecon „/root/\.Xdefaults“ any (system_u object_r config_home_t ((s0) (s0))))
(filecon „/root/\.xine(/.*)?“ any (system_u object_r config_home_t ((s0) (s0))))
(filecon „/etc/gconf(/.*)?“ any (system_u object_r gconf_etc_t ((s0) (s0))))
(filecon „/tmp/gconfd-USER/.*“ file (system_u object_r gconf_tmp_t ((s0) (s0))))
(filecon „/usr/share/config(/.*)?“ any (system_u object_r config_usr_t ((s0) (s0))))
(filecon „/usr/bin/gnome-keyring-daemon“ file (system_u object_r gkeyringd_exec_t ((s0) (s0))))
(filecon „/usr/bin/mate-keyring-daemon“ file (system_u object_r gkeyringd_exec_t ((s0) (s0))))
(filecon „/usr/libexec/gconf-defaults-mechanism“ file (system_u object_r gconfdefaultsm_exec_t ((s0) (s0))))
(filecon „/usr/libexec/gnome-system-monitor-mechanism“ file (system_u object_r gnomesystemmm_exec_t ((s0) (s0))))
(filecon „/usr/libexec/kde(3|4)/ksysguardprocesslist_helper“ file (system_u object_r gnomesystemmm_exec_t ((s0) (s0))))

und in der findet sich dann kein Hinweis auf den gdm-greeter oder die gnome-session .. Womit es undefiniert ist.

Ich hab versucht da  durchzusteigen, aber das ist echt komplex das Zeugs 😉 Vielleicht will ja mal einer ein Diagnosetool dafür bauen, da berichte ich dann gerne drüber.

Mitten im DBUS Update poweroff

Es fing wie immer harmlos an, obwohl, tut es das nicht immer ?  Hmm.. also.. es fing harmlos an :

Berlin: „0:10 Ping…Bist Du da ?“
Ich: „0:12 Ja, klar. Was gibt es denn?“
Berlin: „0:12 Mein Rechner bootet nicht mehr..Ich schick Dir mal ein Foto“

Womit das Unheil seinen Lauf nahm …Fehlermeldung von system-logind und anderen DienstenIch: „Also logind geht nicht ? Starten wir doch mal mit einem anderen Kernel… “
Berlin: „Mist, gleiches Ergebnis.“

Das ist natürlich eine Kaskade, wenn ein wichtiger Dienst nicht startet und andere auf den angewiesen sind, dann starten die auch nicht. Es wird daher nur eine Sache nicht gehen, das stand zu dem Zeitpunkt eigentlich schon fest.

Nun startet man den Rechner im Debugmodus…

Dazu im Kernelauswahlmenü auf die Taste „e“ drücken und in der Zeile mit „linux /vmlinuz….“ am ENDE “ 1″ anfügen. Dann mit STRG+X booten.

Was nun passiert ist, daß sobald ein Minimalsystem von der Platte startet, der Admin sein Passwort eingeben kann und in der Shell den Fehler beheben kann, wenn man ihn denn findet.

Ich: „schauen wir mal in die Logs vom letzten Boot..  journalctl –boot=-1“

Fehler von systemd im letzten BootlogIch: „Connection timed out… also hat er versucht einen Systemdienst zu kontaktieren, der nicht geantwortet hat. Wir starten den mal so, vielleicht gibt es noch mehr Ausgabe“

Ich: „systemctl start systemd-logind“
Berlin: „Nichts..“
Ich:  „Also der logind will nicht…  suchen wir mal die Service Datei“

[root /]# locate logind.service
/usr/lib/systemd/system/systemd-logind.service
/usr/lib/systemd/system/multi-user.target.wants/systemd-logind.service
/usr/share/man/man8/systemd-logind.service.8.gz

[root /]# cat /usr/lib/systemd/system/systemd-logind.service | grep Exec
ExecStart=/usr/lib/systemd/systemd-logind
MemoryDenyWriteExecute=yes

Ich: „Na dann starten wir mal systemd-logind von Hand. Gib ein was in der ExecStart hinter dem = steht“
Berlin: „Passiert nichts“
Ich: „Also jetzt müßte man strace benutzen, das traue ich Dir zu, aber die Ausgabe zu interpretieren ist eine Sache für sich. Ich muß auf Deinen Rechner.“

Zu dem Zeitpunkt liefen außer dem PID=1 Prozess noch genau 3 andere auf dem Rechner 😀

Ich: „start mal das Netzwerk … systemctl start network“
Berlin: „Geht nicht. Hängt.“
Ich: „Mist.. aber kein Beinbruch.. STRG+C und dann brauche ich mal die IP der Portfreigabe für SSH aus Deinem Fritz-Router.“

Jetzt muß man dazu wissen, daß man in der Fritzbox eine Portfreigabe für den SSHD machen kann und die leitet man auf die feste LAN IP des Pcs, den man von außen kontaktieren will. Das hat den Vorteil, daß der befreundete Admin, jederzeit helfen kann. Es setzt aber auch voraus, daß das Netzwerk da ist, was es nicht war…

Nachhilfe – Wie konfiguriert man eine Netzwerkkarte von Hand

Nachdem die IP kennt, gibt man ein:

ifconfig enp1s5  192.168.178.22 network 255.255.255.0 up
route add default gw 192.168.178.1
/usr/sbin/sshd

Wobei man hier natürlich die ermittelte IP einträgt und das richtige Netzwerkkarteninterface wählen muß. Wer seins nicht kennt, kann das mit „ip l“ auflisten:

# ip l
1: lo: <loopback,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000</loopback,
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: enp2s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP mode DEFAULT group default qlen 1000 link/ether 50:13:3e:47:35:31 brd ff:ff:ff:ff:ff:ff

Ab der Stelle kann man dann per SSH auf dem Rechner einloggen, was sehr praktisch ist. Es stellte sich jetzt recht schnell raus, daß die ganzen Programm dem Init Prozess eine Message schicken wollen, aber keine Antwort mehr bekommen. Was daran lag, daß der DBUS-Daemon nicht lief. Jetzt konnte man endlich suchen, was dafür die Ursache war und das geht z.b. so :

[root /]# locate dbus.service
/usr/lib/systemd/system/dbus.service
/usr/lib/systemd/system/multi-user.target.wants/dbus.service
/usr/lib/systemd/user/dbus.service
/usr/lib/systemd/user/dbus.service.d
/usr/lib/systemd/user/dbus.service.d/flatpak.conf
[root /]# cat /usr/lib/systemd/system/dbus.service | grep Exec
ExecStart=/usr/bin/dbus-daemon –system –address=systemd: –nofork –nopidfile –systemd-activation –syslog-only
ExecReload=/usr/bin/dbus-send –print-reply –system –type=method_call –dest=org.freedesktop.DBus / org.freedesktop.DBus.ReloadConfig

Also starten wir den dbus-daemon von Hand und stellen fest, daß er nicht startet. In dem Fall, weil seine libdbus.so.3 ein Target nicht enthielt, was nur sein kann, wenn die Version des Daemons und der lib nicht zusammen passen.

Ein „rpm -qa | grep dbus | sort “ brachte dann auch gleich den Fehler zutage. Statt 1.11.18 war der dbus-daemon nur als 1.11.16 installiert. Offensichtlich war der Rechner beim Update unsanft gestört worden oder der Updateprozess hing aus irgendeinem anderen Grund. Das kann man ja leicht mit einem Update beheben, oder ? 😉

Wie sich rausstellte, konnte man das nicht, weil für das Update durch RPM der DBUS-Daemon laufen müßte. Nun Starten Sie mal einen Update um den DBUS Daemon zu updaten, weil der nicht startet, weil er die falsche Version hat.

Das Ende naht ?

Hier hätte das Ende der Geschichte sein können, weil zu dem Zeitpunkt auch keine Livedisk vorhanden war, um den Rechner mal sauber zu starten und in einer Chroot dann das ausstehende Update zu applien.

Hey… wir haben doch einen SSH Zugang .. da geht doch auch … SCP 😀 Und wie der Zufall das so wollte, hatten beide Rechner das gleiche OS drauf.

Lösung:

scp /usr/bin/dbus-daemon root@externeipdeszielrechners:/usr/bin/

Dann den dbus von Hand starten und die dbus pakete installieren die noch im DNF-Cache  auf der Platte lagen. Das findet man unter /var/cache/dnf/updates…./  Da müßt Ihr ggf. mit find mal nach“.rpm“ suchen. Das Cache kann ziemlich unaufgeräumt sein.

Nun noch sauber den dbus über systemd neugestartet und „dnf update -y“  benutzen um alle ausstehenden Updates einzuspielen. Das wärs dann.

Kleiner Tip: Zwei Shells benutzen, weil der Updateprozess wird gemäß den Anweisungen in den RPMS die Dienste neustarten wollen, was wegen des nicht vorhandenen Systemstarts nicht klappt. d.h. die Hängen alle beim „systemctl start blahblah.service„, was man mit ps auxf leicht sehen kann.

Einfach die Pids von den Starts mit kill abschiessen, wir rebooten danach eh frisch.

Berlin: „2:12 Hey, da passiert was“
Ich: „2:12 Ja, ich hab den Reboot ausgelöst, sollte jetzt starten“

Jetzt sind wir fertig. Der Rechner bootet wieder und mehr als 2 Stunden hat es gedauert, denn natürlich haben wir noch einige andere Dinge probiert 😉 Da die aber nicht zur Lösung geführt haben, war ich mal so frei die Euch zu ersparen 🙂

Genauso wenig hilfreich waren :

Microsoft – Skype Zwangstrennung nach 1 Stunde reden .. args!
DTAG – DSL Zwangstrennung  mitten im Debug ! Das kann man sowas von gebrauchen wenn man einen Notfall hat!
SystemD – mangels Fehlermeldung, daß DBUS nicht gestartet werden konnte ! Das hätte die Suche ja nur um knapp 90 Minuten verkürzt! Dafür wird noch jemand bezahlen … muharharhar …

 

 

GDM crasht im Endlosloop

Heute morgen der Schreck des Tages: Ein Login in Cinnamon war nicht möglich.

Der Versuch endete einem erneuten Loginscreen. Auch Gnome war nicht zur Kooperation zu bewegen. Nachdem ich die Xorg Logs gelesen hatte, stach mir die Datei „gnome-settings-daemon.desktop“ ins Auge, weil diese nicht „formal korrekt parsebar“ war, also der Inhalt einen Fehler hatte. Nachdem diese Desktopdatei aus /etc/xdg/autostart entfernt wurde, startete zumindest Cinnamon wieder und ich dachte, daß das Problem damit behoben sein.

Wie man sich irren kann..

Nach einem kleinen Ausflug wurde der Rechner abends neugestartet und hier kam der Schock: GDM restartete in einem Endlosloop alle paar Sekunden neu!

Nach einigen Reinstalls von GLIB -> mesa -> lightdm und glib2, die alle ohne Wirkung waren, fiel meine Aufmerksamkeit auf:

Jun  3 22:38:52 eve gnome-session: gnome-session-binary[15330]: WARNING: Unable to find required component ‚gnome-settings-daemon‘
Jun  3 22:38:52 eve gnome-session-binary[15330]: WARNING: Unable to find required component ‚gnome-settings-daemon‘
Jun  3 22:38:52 eve gnome-session-binary: Entering running state
Jun  3 22:38:52 eve gnome-session: Unable to init server: Could not connect: Connection refused
Jun  3 22:38:52 eve kernel: gnome-session-f[15337]: segfault at 0 ip 00007f94983fa4b9 sp 00007fff41c22bf0 error 4 in libgtk-3.so.0.2200.15[7f949811b000+6f9000]
Jun  3 22:38:52 eve abrt-hook-ccpp: Process 15337 (gnome-session-failed) of user 42 killed by SIGSEGV – ignoring (repeated crash)
Jun  3 22:38:54 eve dbus-daemon[15374]: [session uid=42 pid=15374] Activating via systemd: service name=’org.a11y.Bus‘ unit=’at-spi-dbus-bus.service‘ requested by ‚:1.2‘ (uid=42 pid=15380 comm=“/usr/libexec/gnome-session-check-accelerated “ label=“system_u:system_r:xdm_t:s0-s0:c0.c1023″)
Jun  3 22:44:23 eve gdm: GLib: g_hash_table_find: assertion ‚version == hash_table->version‘ failed

„Unable to find required component ‚gnome-settings-daemon'“ und das, obwohl ich die Autostartdatei wieder zurück geschrieben hatte. Hmm.. zu welchem Paket gehört die doch gleich ? Ah.. gnome-settings-daemon, klar oder ? 🙂 Während  GDM noch im Endlessloop war, reinstallierte ich dieses Paket und oh Wunder… plötzlich war alles wieder normal. Wie konnte das passieren ?  Tja, keine Ahnung .. Die Datei wurde nicht aktualisiert. Sie muß im laufenden Betrieb eine Macke abgekommen haben. Ein Hoch auf „dnf reinstall“ 😀

Beim nächsten derartigen Problem suche nicht stundenlang nach dem Fehler, dann kommt „dnf reinstall *“ zum Einsatz 😀

 

 

DNF: Upgradeprozess unterbrechbar

Neulich hatte ich den Worst Case Fall den man sich bei einem Update eines Os’s vorstellen kann: aus  Versehen CTRL-C gedrückt.

Bei ca.1940 Schritten von rund 6500 geschah es… dabei wollte ich nur in einem anderen Fenster die IO-Leistung der SSD während des Updates anschauen und das dortige Programm abbrechen. Zum Glück, muss man sagen, ist DNF an der Stelle noch in der Lage gewesen, einfach bei der Stelle weiterzumachen, wo es aufgehört hat und das Update dann doch noch durchzuführen.

Also, ein großes Lob an die DNF Entwickler.

Nach dem Booten von Fedora 24 kamen dann allerdings auch die mit der Unterbrechung einhergehenden Fehler ans Licht, die sich aber im Rahmen hielten:

FC24 Bootkernel nicht in Grub eingetragen
Initramfs nicht mit meinem Plymouththeme versehen
eine Lib nicht installiert

Der Rest lief überraschenderweise gleich. Alles in allem, trotz Worst-Case-Szenario kein Beinbruch. Vielleicht wars auch nicht der Worst-Case, der wäre wohl dann noch ein Stromausfall gewesen, aber dicht dran wars schon.

ups … DNF deinstalliert und nu ?

Da will man ein harmloses Update einspielen und angeblich stört so eine Lib dabei. Naja, nichts besonders. Kommt öfters vor. Man deinstalliert das fragliche Programm und installiert es wieder: fertig.  Soweit in der Theorie.

„Götter irren sich nie – Root schon!“

Der Befehl : „dnf update –allowerasing“ sollte das eigentlich auch so gleich machen, wenn man Abhängigkeitsprobleme hat.
Vielleicht hätte er das auch, wenn man stattdessen nicht versucht hätte das Paket direkt zu löschen ( dnf erase packagename ). Den dabei unterlief mir ein Fehler bei der Blindbenutzung der Bash :

dnf erase dnf update –allowerasing

Und natürlich blind auf Ja gedrückt 🙂 Schon war DNF , YUM, YUMEX und ABRT verschwunden 🙁 Jetzt versucht mal ohne Paketmanager den Paketmanager DNF zu reinstallieren. Die Lösung ist natürlich relativ einfach: RPM direkt benutzen.

Jetzt ist natürlich nur die Frage: Woher nehmen ?

Die Frage hatte ich zum Glück schon mal in einem anderen Zusammenhang gestellt : Koji

Beispiel für HTTPD: http://koji.fedoraproject.org/koji/packageinfo?packageID=280

Koji ist eine Webseite des Fedoraprojekts, auf dem alle Builds für alle Fedoraversionen verfügbar sind. Dort können alte wie Betaversionen und natürlich die aktuellen Pakete gefunden werden. Einfach Downloaden und mit rpm installieren.

Wenn man die RPMS alle in einem Verzeichnis hat ist das ganz einfach: rpm -i *rpm

Sind alle Pakete mit Abhängigkeiten vorhanden, ist das Malheur in Minuten beseitigt. Allerdings muß man ganz schön viele Pakete runterladen, deswegen zuerst nur DNF und seine Abhängigkeiten installieren, dann per DNF alles, was bei dem Erase mit eliminiert wurde.

Wer eine Liste braucht :  grep Erased /var/log/dnf.rpm.log

Oct 18 00:37:20 INFO Erased: abrt-desktop-2.8.0-5.fc23.x86_64
Oct 18 00:37:20 INFO Erased: abrt-cli-2.8.0-5.fc23.x86_64
Oct 18 00:37:20 INFO Erased: abrt-addon-vmcore-2.8.0-5.fc23.x86_64
Oct 18 00:37:21 INFO Erased: anaconda-23.19.10-1.fc23.x86_64
Oct 18 00:37:21 INFO Erased: abrt-addon-python3-2.8.0-5.fc23.x86_64
Oct 18 00:37:21 INFO Erased: initial-setup-gui-0.3.37-1.fc23.x86_64
Oct 18 00:37:21 INFO Erased: anaconda-gui-23.19.10-1.fc23.x86_64
Oct 18 00:37:21 INFO Erased: initial-setup-0.3.37-1.fc23.x86_64
Oct 18 00:37:21 INFO Erased: abrt-addon-python-2.8.0-5.fc23.x86_64
Oct 18 00:37:21 INFO Erased: anaconda-core-23.19.10-1.fc23.x86_64
Oct 18 00:37:21 INFO Erased: anaconda-tui-23.19.10-1.fc23.x86_64
Oct 18 00:37:21 INFO Erased: python3-meh-gui-0.43-1.fc23.noarch
Oct 18 00:37:21 INFO Erased: python3-meh-0.43-1.fc23.noarch
Oct 18 00:37:21 INFO Erased: yumex-3.0.17-2.fc23.noarch
Oct 18 00:37:22 INFO Erased: yum-utils-1.1.31-508.fc23.noarch
Oct 18 00:37:22 INFO Erased: yum-langpacks-0.4.5-2.fc23.noarch
Oct 18 00:37:22 INFO Erased: python-meh-gui-0.43-1.fc23.noarch
Oct 18 00:37:22 INFO Erased: python-meh-0.43-1.fc23.noarch
Oct 18 00:37:22 INFO Erased: dnf-plugin-system-upgrade-0.7.1-1.fc23.noarch
Oct 18 00:37:22 INFO Erased: createrepo-0.10.3-3.fc21.noarch
Oct 18 00:37:22 INFO Erased: anaconda-yum-plugins-1:1.0-10.fc20.noarch
Oct 18 00:37:22 INFO Erased: abrt-python-2.8.0-5.fc23.x86_64
Oct 18 00:37:22 INFO Erased: abrt-addon-ccpp-2.8.0-5.fc23.x86_64
Oct 18 00:37:22 INFO Erased: abrt-gui-2.8.0-5.fc23.x86_64
Oct 18 00:37:23 INFO Erased: abrt-addon-pstoreoops-2.8.0-5.fc23.x86_64
Oct 18 00:37:23 INFO Erased: abrt-tui-2.8.0-5.fc23.x86_64
Oct 18 00:37:23 INFO Erased: yum-3.4.3-507.fc23.noarch
Oct 18 00:37:23 INFO Erased: dnf-yum-1.1.10-1.fc23.noarch
Oct 18 00:37:23 INFO Erased: abrt-addon-kerneloops-2.8.0-5.fc23.x86_64
Oct 18 00:37:23 INFO Erased: gnome-abrt-1.2.2-3.fc23.x86_64
Oct 18 00:37:23 INFO Erased: abrt-retrace-client-2.8.0-5.fc23.x86_64
Oct 18 00:37:23 INFO Erased: libreport-python-2.6.4-2.fc23.x86_64
Oct 18 00:37:23 INFO Erased: abrt-addon-xorg-2.8.0-5.fc23.x86_64
Oct 18 00:37:24 INFO Erased: abrt-plugin-bodhi-2.8.0-5.fc23.x86_64
Oct 18 00:37:24 INFO Erased: setroubleshoot-3.3.11-1.fc23.x86_64
Oct 18 00:37:24 INFO Erased: policycoreutils-devel-2.4-21.fc23.x86_64
Oct 18 00:37:24 INFO Erased: abrt-java-connector-1.1.0-6.fc23.x86_64
Oct 18 00:37:24 INFO Erased: abrt-dbus-2.8.0-5.fc23.x86_64
Oct 18 00:37:24 INFO Erased: abrt-python3-2.8.0-5.fc23.x86_64
Oct 18 00:37:24 INFO Erased: abrt-2.8.0-5.fc23.x86_64
Oct 18 00:37:24 INFO Erased: libreport-python3-2.6.4-2.fc23.x86_64
Oct 18 00:37:24 INFO Erased: dnf-1.1.10-1.fc23.noarch

Natürlich kann man das jetzt mit etwas Bashmagie automatisch reinstallieren lassen. Kleiner Denkanstoß :

grep „Erased:“ /var/log/dnf.rpm.log | sed -e „s/^.*Erased:/dnf install -y/g“ | bash

Eine kleine Nacharbeit muß man dann aber noch tun: die Configfiles für YUM und DNF sollten restauriert werden, denn nach dem Install sind die wieder default. Zum Glück ist RPM clever und legt bei sowas eine Sicherungsdatei an:

-rw-r–r–. 1 root root 833 18. Okt 01:00 /etc/yum.conf
-rw-r–r–. 1 root root 833  3. Apr 2016  /etc/yum.conf.rpmsave

Und immer dran denken: bis auf  „dd if=/dev/zero of=/dev/sda1“ aka „format c:“ kann man alles unter Linux reparieren.

Upgrade auf Fedora 24

Ein paar Worte vorweg:

Es gibt mehrere Wege seinen Rechner zu upgraden. DNF zu benutzen ist nur einer davon. Da ich seit Fedora 15 Upgrades per YUM und DNF mache, nehm ich diesen Weg.
Alternativ kann man auch FedUP benutzen. Bei YUM ging bislang alles rutschfrei, auch wenn die Fedora Webseite meint, daß DNF nicht der empfohlene Weg wäre. Letztlich macht aber auch Fedup nichts anderes, da kann man es auch gleich nehmen.

Warnung: Ein Upgrade ist naturgemäß eine destruktive Sache.

Geht es mitten im Upgradeprozess schief, ist das System üblicherweise hinüber. Deswegen: BACKUP machen.

Wenn es dagegen z.b. beim Download der neuen Pakete Probleme gibt, passiert nichts wildes, weil der Upgradeprozess vor dem eigentlichen Upgrade erstmal prüft, ob alles nötige vorhanden ist.

Um sein System auf Fedora 24 zu aktualisieren, braucht man lediglich eine Kommandokonsole (Terminal) und ausreichend Platz auf der Festplatte.

Als erstes sollte man ein Systembackup machen:

cd /
tar czvf /home/backup_sys.fc23.tgz –exclude=sys –exclude=proc –exclude=home *

idealerweise räumt man vorher noch Tempfiles auf und löscht Programme, die man eh nicht mehr benutzen will, aber nie einen Grund, sah sie zu entfernen. Jetzt wäre der richtige Zeitpunkt.

Vor dem Upgrade bitte sicherstellen, daß die Externen Repositories auch bereits alle Fedora 24 unterstützen, weil sonst fehlen ggf. am Ende Programme, die Ihr nutzen wolltet/müßt.
GANZ wichtig, wenn Ihr Nvidia Treiber von RPMFusion benutzt.

Ok. Alles gepüft ? Gut, dann kann es losgehen :

rpm –import /etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-24-$(uname -i);
dnf upgrade;dnf clean all;dnf –releasever=24 –setopt=deltarpm=false distro-sync –allowerasing

Es kommen einige Fragen, ob man die neuen Keys bestätigen will; Ja, wollt Ihr.. und dann, obs wirklich losgehen kann. Einmal bestätigt, lädt dnf jetzt alles Files runter. Bei meinem Laptop waren es 3.3 GB und rund 4500 Updateschritte. Mit 50 Mbps und SSD dauert das zusammen ca. 25 Minuten.

Ist der Prozess durchgelaufen, einfach Rechner per Reboot neu starten. Fertig.

Die After-Upgrade-Schlacht

Mein Laptop hat brav gebootet, geht soweit wieder, aber was ist das ? Der Gnome Desktop sieht so leer aus…  ? ok, die Apps sind veraltet.

Einmal bitte http://extentions.gnome.org aufrufen, auf „installed Extentions“ gehen und Updates einspielen.

Tip: App nicht gleich löschen, nur weil noch kein Update da ist. Die können einige Zeit brauchen. Einfach in 2 Wochen noch mal nachsehen.

Für die Probleme mit QMMP gibt es morgen einen eigenen Beitrag.

 

Mehr Fedora gibt es hier : http://fedoraproject.org/

DNF: gezielt downgraden

Neulich bei Wine : „Es geht mal wieder nicht, aber gestern gings noch.“

In einem anderen Beitrag habe schon einmal auf Downgrades hingewiesen. Wenn man mit DNF/YUM einen Downgrade eines Paketes durchführt, geht das erstmal sehr einfach:

dnf downgrade paketname

Aber leider kann es vorkommen, daß bis auf die Basisversion eines Pakets zurück gegraded wird. Wie kommt das, wo doch lediglich eine kleine Revisionsänderung durchgeführt wurde ?

Ganz einfach: Weil das alte Paket nicht mehr im Update-Repository ist und nur noch die uralte Basisversion im Fedorahauptrepository zu finden ist.

Umgehen kann man das so, aber ein bisschen Arbeit ist es schon:

  1. Einen Webserver einrichten oder idealerweise einen bereits fertigen Webserver auf folgende URL konfigurieren :http://dnf.meinedomain.de/$basearch/$releasever/fedora-old/Was in dem Fall meint, daß das Docroot in dem Pfad rauskommt, wo die BASEARCH, also die Basisarchitektur liegt. siehe Punkt 3 als Beispiel.
  2. folgende Datei anlegen : /etc/yum.repos.d/fedora-downgrade.repo  und das reinschreiben:[fedora-old]
    name=Fedora $releasever – $basearch – OLD
    baseurl=http://dnf.meinedomain.de/$basearch/$releasever/fedora-old/
    enabled=1
    gpgcheck=0
  3. jetzt von Koji ( koji.fedoraproject.org/koji/ )  das Paket heraussuchen und die nötigen Dateien der Versionen die man gern hätte, in das Verzeichnis seines Apaches kopieren, in dem das Repo erstellt wurde. Das könnte so aussehen : /home/meinusername/repository/x86_64/23/fedora-old/
    drwxr-xr-x 3 root root     4096  6. Mär 16:09 .
    drwxr-xr-x 4 root root     4096  6. Mär 16:00 ..
    drwxr-xr-x 2 root root     4096  6. Mär 16:09 repodata
    -rw-r--r-- 1 root root    54078  6. Mär 16:07 wine-1.9.3-1.fc23.i686.rpm
    -rw-r--r-- 1 root root    54390  6. Mär 16:07 wine-1.9.3-1.fc23.x86_64.rpm
    -rw-r--r-- 1 root root   106054  6. Mär 16:07 wine-alsa-1.9.3-1.fc23.i686.rpm
    -rw-r--r-- 1 root root   108178  6. Mär 16:07 wine-alsa-1.9.3-1.fc23.x86_64.rpm
    -rw-r--r-- 1 root root   143442  6. Mär 16:07 wine-arial-fonts-1.9.3-1.fc23.noarch.rpm
    -rw-r--r-- 1 root root    59662  6. Mär 16:07 wine-capi-1.9.3-1.fc23.i686.rpm
    -rw-r--r-- 1 root root    59874  6. Mär 16:07 wine-capi-1.9.3-1.fc23.x86_64.rpm
    -rw-r--r-- 1 root root    74474  6. Mär 16:07 wine-cms-1.9.3-1.fc23.i686.rpm
    -rw-r--r-- 1 root root    75418  6. Mär 16:07 wine-cms-1.9.3-1.fc23.x86_64.rpm
    -rw-r--r-- 1 root root   108838  6. Mär 16:07 wine-common-1.9.3-1.fc23.noarch.rpm
    -rw-r--r-- 1 root root 22652170  6. Mär 16:08 wine-core-1.9.3-1.fc23.i686.rpm
    -rw-r--r-- 1 root root 22292142  6. Mär 16:08 wine-core-1.9.3-1.fc23.x86_64.rpm
    -rw-r--r-- 1 root root   133074  6. Mär 16:08 wine-courier-fonts-1.9.3-1.fc23.noarch.rpm
    -rw-r--r-- 1 root root 38597470  6. Mär 16:08 wine-debuginfo-1.9.3-1.fc23.x86_64.rpm
    -rw-r--r-- 1 root root   159390  6. Mär 16:08 wine-desktop-1.9.3-1.fc23.noarch.rpm
    -rw-r--r-- 1 root root    84534  6. Mär 16:08 wine-filesystem-1.9.3-1.fc23.noarch.rpm
    -rw-r--r-- 1 root root    66710  6. Mär 16:08 wine-fixedsys-fonts-1.9.3-1.fc23.noarch.rpm
    -rw-r--r-- 1 root root    53654  6. Mär 16:08 wine-fonts-1.9.3-1.fc23.noarch.rpm
    -rw-r--r-- 1 root root   115838  6. Mär 16:08 wine-ldap-1.9.3-1.fc23.i686.rpm
    -rw-r--r-- 1 root root   117914  6. Mär 16:08 wine-ldap-1.9.3-1.fc23.x86_64.rpm
    -rw-r--r-- 1 root root    65850  6. Mär 16:08 wine-marlett-fonts-1.9.3-1.fc23.noarch.rpm
    -rw-r--r-- 1 root root  1738630  6. Mär 16:09 wine-ms-sans-serif-fonts-1.9.3-1.fc23.noarch.rpm
    -rw-r--r-- 1 root root    66506  6. Mär 16:09 wine-openal-1.9.3-1.fc23.i686.rpm
    -rw-r--r-- 1 root root    68030  6. Mär 16:09 wine-openal-1.9.3-1.fc23.x86_64.rpm
    -rw-r--r-- 1 root root    65110  6. Mär 16:09 wine-opencl-1.9.3-1.fc23.i686.rpm
    -rw-r--r-- 1 root root    66114  6. Mär 16:09 wine-opencl-1.9.3-1.fc23.x86_64.rpm
    -rw-r--r-- 1 root root    96042  6. Mär 16:09 wine-pulseaudio-1.9.3-1.fc23.i686.rpm
    -rw-r--r-- 1 root root    96866  6. Mär 16:09 wine-pulseaudio-1.9.3-1.fc23.x86_64.rpm
    -rw-r--r-- 1 root root    68910  6. Mär 16:09 wine-small-fonts-1.9.3-1.fc23.noarch.rpm
    -rw-r--r-- 1 root root    79874  6. Mär 16:09 wine-symbol-fonts-1.9.3-1.fc23.noarch.rpm
    -rw-r--r-- 1 root root    54238  6. Mär 16:09 wine-systemd-1.9.3-1.fc23.noarch.rpm
    -rw-r--r-- 1 root root    72858  6. Mär 16:09 wine-system-fonts-1.9.3-1.fc23.noarch.rpm
    -rw-r--r-- 1 root root   160394  6. Mär 16:09 wine-tahoma-fonts-1.9.3-1.fc23.noarch.rpm
    -rw-r--r-- 1 root root    55270  6. Mär 16:09 wine-tahoma-fonts-system-1.9.3-1.fc23.noarch.rpm
    -rw-r--r-- 1 root root   150314  6. Mär 16:09 wine-times-new-roman-fonts-1.9.3-1.fc23.noarch.rpm
    -rw-r--r-- 1 root root    85858  6. Mär 16:09 wine-twain-1.9.3-1.fc23.i686.rpm
    -rw-r--r-- 1 root root    87210  6. Mär 16:09 wine-twain-1.9.3-1.fc23.x86_64.rpm
    -rw-r--r-- 1 root root    66466  6. Mär 16:09 wine-wingdings-fonts-1.9.3-1.fc23.noarch.rpm
    
  4. Nun wechselt man in das Verzeichnis und führt den Befehl „createrepo .“ aus. Damit werden die repodata-Files erzeugt, die DNF und YUM brauchen.
  5. Wenn alles geklappt hat, kann man das Repo jetzt mit DNF finden.

Ist das der Fall und man downgraded wine, ist das die nächst neueste Version zu der, die bereits installiert ist und damit downgraded dnf das erst mal im Beispiel auf 1.9.3, bevor es dann mit einem weiteren Downgrade auf die Basisversion 1.7.x geht. Wenn man jetzt mehr als eine Version von Wine in dem OLD Repo hat, kann man sich recht komfortabel von einer Version zur nächsten bewegen und muß nicht erst alles per dnf erase löschen und dann mit rpm -i *rpm die gewünschte Version installieren. Aber nicht vergessen das Paket in der /etc/dnf/dnf.conf zu deaktivieren, sonst kommt das Update abends gleich wieder drauf.

Natürlich kann man in so einem Repo auch eigene RPM’s speichern. So ein Repo ist auch ein prima Cache, wenn man viele, viele Server hat, die sich dann die neusten Versionen aus dem eigenen Cache ziehen, statt alle von Fedora. Der Traffic bliebe dann z.b. im LAN.

DNF: das neue YUM, oder?

DNF ist seit Fedora 21 das Tool für Softwareupdates.  DNF soll die Probleme von YUM lösen, indem es andere Algorithmen zur Abhängigkeitsauflösung anwendet, unter anderem.

Zunächst mal muß man keine Angst vor der Umstellung haben, denn DNF ist sogut wie es geht YUM kompatibel, was die Befehle in der Shell angeht, und YUM kann zur Not auch weiter verwenden. Das geht so gut, daß die gleichen alten Probleme auf die gleiche Art gelöst werden müssen.

Ich hatte ja mal gezeigt, wann und wie man Updates abschaltet:

# cat /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=qmmp* gedit*
...

DNF gibt sich da etwas schlanker :

# cat /etc/dnf/dnf.conf 
[main]
gpgcheck=1
installonly_limit=3
clean_requirements_on_remove=true
exclude=gedit*

Es macht aber am Ende genau das gleiche.

Warum habe ich jetzt Gedit von weiteren Updates ausgenommen ?

Für alle die es nicht wissen, Gedit ist der standardmäßig installiere Texteditor für Gnome. In Fedora 20 war er : schlank, schlicht, schnell, nützlich. Mit dem Update auf Fedora 21 fallen mir nur folgende Attribute ein: Mozilladesign, unnütz, bloated (rpms), absoluter Schrott.

Gedit war in Fedora 20 der mit Abstand nützlichste Editor, weil er optisch nicht so überladen war wie z.b. Blue Fish, aber dennoch alles hatte : Tabs, Syntaxhighlighting, Rechtschreibkorrektur und Platz!

Die neue Version ist umgangssprachlich für den Arsch. Die Menüführung ist abenteuerlich und komplett umständlich. Die Icons sind weg, man müßte jetzt Menüfunktionen aufrufen. Das Layout ist überdesigned zur absoluten Nutzlosigkeit verschönt. Ganz sicher mußte der Designer diese Änderungen nicht mit seinem Geditdesign machen, sonst wäre ihm aufgefallen, was für einen Müll er da produziert. Ist ja häufig so, daß Produkte bis zur Unkenntlichkeit umdesigned werden, nur damit man mal was gemacht hat als Hersteller. Ob das Update am Ende nützlich war, interessiert doch am Ende keinen mehr, Hauptsache es ist neu.

Zu allem übel, kann man den Gedit nicht optisch auf nützlich zurückstellen, weswegen es tatsächlich nur zwei Lösungen gab: 1. Auf einen anderen Texteditor umsteigen oder 2. yum erase „gedit*“; rpm -i –nodeps gedit*f20*rpm .

Jetzt gibt es zwei Wege an die RPMS zu kommen:

1. KOJI benutzen. Das hat aber trotzdem noch viel Gesuche zur Folge.

oder 2. Einfach im alten Fedora 20 Repository nachsehen:

# cat /etc/yum.repos.d/fedora.repo 
[fedora]
name=Fedora $releasever - $basearch
failovermethod=priority
#baseurl=http://download.fedoraproject.org/pub/fedora/linux/releases/$releasever/Everything/$basearch/os/
metalink=https://mirrors.fedoraproject.org/metalink?repo=fedora-$releasever&arch=$basearch
enabled=1
metadata_expire=7d
gpgcheck=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-$releasever-$basearch
skip_if_unavailable=False
...

Die BaseURL zeigt wird nun einfach etwas angepaßt und dann im Browser aufgerufen ( bitte: Nicht bei Google eingeben, sondern in die Adressleiste des Browsers! ). Das wäre dann diese hier:

http://download.fedoraproject.org/pub/fedora/linux/releases/20/Everything/x86_64/os/

Der Repobesuch mit dem Browser erlaubt auch eine einfache Navigation durch die Repos, was bei Koji nicht der Fall ist. Damit kann man viele Programme sehr viel schneller finden, als im Koji Buildsystem.

Nachdem die RPMS auf der Platte geparkt wurden, müssen Sie dan mit rpm -i --nodeps installiert werden, weil die Abhängikeiten im RPM natürlich auf Fedora20 lauten und nicht auf Fedora 21 Pakete. Wer sich mit dem Gedanken trägt sein Gedit auch zu downgraden, der sollte folgende Pakete nehmen, die restlichen sind so schwer abhängig, das klappt vermutlich nicht:
2588 -rw-rw-r--. 1 marius marius 2646356  5. Jul 23:26 gedit-3.10.2-1.fc20.x86_64.rpm
  16 -rw-rw-r--. 1 marius marius   13944  6. Jul 00:04 gedit-beesu-plugin-0.4-13.fc20.x86_64.rpm
 124 -rw-rw-r--. 1 marius marius  124560  6. Jul 00:04 gedit-code-assistance-0.2.0-4.fc20.x86_64.rpm
  56 -rw-rw-r--. 1 marius marius   53584  6. Jul 00:04 gedit-cossa-3.2.0-6.fc20.x86_64.rpm
 836 -rw-rw-r--. 1 marius marius  853444  5. Jul 23:26 gedit-plugins-3.10.0-1.fc20.x86_64.rpm
  20 -rw-rw-r--. 1 marius marius   16920  5. Jul 23:26 gedit-zeitgeist-3.10.2-1.fc20.x86_64.rpm

Damit ist Gedit dann wieder einsetzbar. Sieht zwar nicht mehr so schick auch wie früher, aber es tut seinen Job.