Der (IT) Blog aus Braunschweig
Diesmal nur die Kurzfassung, der Ausfall bei Fedora ist soweit behoben, Koji ist auch schneller als sonst und der Fehler ist auch bereits bekannt: ein Level 8 Problem.
Ursache war ein Fix für einen anderen Fehler, der kurzerhand alles zerlegt hat. Da muß man jetzt zwangsweise eine Parallele zu diesem Beitrag ziehen: Kernel 5.3.16 mit HDMI-Audio Problemen Wobei das nicht die gleichen Leute waren 😉
Das Fedora Buildsystem Koji ist derzeit außer Betrieb aka. Offline. Da es dazu keine Ankündigung gab, kann man nur von einem Ausfall sprechen. Da hiervon aber auch alle Downloads aus dem Buildbereich betroffen sind, kann man derzeit nichts recherchieren oder ausprobieren. Dies bedeutet auch, daß alle Koji Links aus diesem Blog derzeit offline sind.
Seit einigen Tagen ProblemeIn der Entwickler Mailingliste wurden schon seit einigen Tagen dubiose Fehlermeldungen und lange Prozesslaufzeiten gemeldet. Ein Neustart des System brachte wohl nur kurzfristig Entlastung. Ein Zusammenhang mit dem derzeit laufenden 36C3 kann man wohl ausschließen, da Kevin Fenzi schon vor 7 Tagen darüber berichtet hat:
Ihr formatiert nicht gerade zufällig ein großes USB-Laufwerk mit Verschlüsselung und allem und plant für heute noch mehr, außer ein animiertes GIF dabei zu beobachten, sich zwanghaft im Kreis zu drehen?
„Du wirst ganz Müde! Du möchtest nicht wissen, wann ich fertig bin! Mach die Augen zu! Du schläfst ein!“
So oder so ähnlich versucht Gnome-Disks den Benutzer so lange einzulullen, bis der wirklich schlafen gegangen ist, weil er nicht weiß, wann das Formatieren seines TB-Laufwerks fertig ist. Das Problem haben sehr viele Nutzer schon sehr lange, aber nie hat sich etwas getan und Hilfe war nicht ersichtlich.
Das hat sich geändert, wobei „geändert“ ist das falsche Wort. Besser wäre: Ich hatte da eine Idee.
Während Gnome-Disks läuft, zeigt es keinen Progressbar, obwohl es das ganz leicht könnte, denn es benutzt lediglich die API vom udisks-Service. Udisks stellt aber auch einen Monitorservice zur Verfügung, den man einfach als Root aufrufen kann:
sudo udisksctl monitor
Das Ergebnis ist ein kontinuierlicher Strom an Fortschritten dieser Gestalt:
15:07:34.339: /org/freedesktop/UDisks2/jobs/11: org.freedesktop.UDisks2.Job: Properties Changed
ExpectedEndTime: 1576505289340729
Rate: 38343810
Progress: 0.98951756217805409
Jetzt darf man mal raten, was 0.98 bedeutet, genau, hier waren es 98.95% Fortschritt 🙂
Alles was gnome-disks machen müßte, wäre die API nach seiner Job ID (hier 11) zu fragen und das Ergebnis anzuzeigen. Das es das schon seit Jahren nicht tut, ist nicht schön, aber Ihr habt jetzt einen Weg, wie man das einfach umgehen kann.