Created attachment 1521415 [details] .tgz of journal files timestamped day of & day after dnf system-upgrade Adam asked I file this without saying what to put in it, only to report against dnf- plugins-core. Copied and pasted from my original mailing list post: <https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org/thread/COP6TD2TDYETLZW75OGDKCVWCW4TORGZ/> [copy] Output messages (partial, typed): [] Preparing: Traceback (most recent call last): file /usr/lib/python3.7/site-packages/dnf/yum/rpmtrans.py, line 260 in callback self._elemProgress(key,amount) ...line 303, in _elemProgress transaction_list=self._extract_cbkey(key) ...line 244, in _extract_cbkey raise RuntimeError("TransactionItem not found for key: %s % cbkey) RuntimeError: Transaction not found for key: rtkit Complete! Download complete! Use 'dnf system-upgrade reboot' to start the upgrade.... [/] dnf system-upgrade reboot seems to be proceeding normally. :-p install 9 upgrade 655 downgrade 9 Total size: 724M...[/copy] Fedora 30 (Rawhide) system seems to have normal function now: # inxi -bxx System: Host: big41 Kernel: 5.0.0-0.rc1.git0.1.fc30.x86_64 x86_64 bits: 64 compiler: gcc v: 8.2.1 Console: tty 3 dm: KDM Distro: Fedora release 30 (Rawhide) Machine: Type: Desktop Mobo: BIOSTAR model: T41 HD v: ' serial: N/A BIOS: American Megatrends v: 080015 date: 09/22/2009 CPU: Dual Core: Intel Core2 Duo E7600 type: MCP arch: Penryn speed: 1596 MHz Graphics: Device-1: Intel 4 Series Integrated Graphics vendor: Biostar Microtech Intl Corp driver: i915 v: kernel bus ID: 00:02.0 chip ID: 8086:2e32 Display: tty server: X.org 1.20.3 driver: modesetting unloaded: fbdev,vesa tty: 180x56 Message: Advanced graphics data unavailable in console for root. Network: Device-1: Realtek RTL8111/8168/8411 PCI Express Gigabit Ethernet vendor: Biostar Microtech Intl Corp driver: r8169 v: kernel port: e800 bus ID: 01:00.0 chip ID: 10ec:8168 Drives: Local Storage: total: 465.76 GiB used: 26.89 GiB (5.8%) Info: Processes: 114 Uptime: 2m Memory: 3.82 GiB used: 154.1 MiB (3.9%) Init: systemd v: 240 runlevel: 3 target: multi-user.target Compilers: gcc: N/A Shell: bash v: 4.4.23 running in: tty 3 inxi: 3.0.30
Please can you provide version of following component before upgrade? dnf, libdnf, python3-dnf-plugin-system-upgrade
Created attachment 1521662 [details] in /var/log/, tar -cvzf /root/dnfF30logs.tgz dnf*log* resulting file I got lost trying. This PC keeps resetting its clock to December 21, making timestamps confusing. This is current from the F29 cloned from before the system-upgrade: # rpm -qa | grep dnf (redacted) dnf-4.0.9-2.fc29.noarch libdnf-0.22.3-1.fc29.x86_64 This is current from the resulting F30: # rpm -qa | grep dnf (redacted) dnf-4.0.10-1.fc30.noarch libdnf-0.24.1-1.fc30.x86_64 python3-dnf-plugin-system-upgrade-4.0.1-1.fc30.noarch I think from the subsequent day's dnf.rpm.log that: the prior plugin was 4.0.0-1.fc29 the prior libdnf was 0.22.3-1.fc29 the prior dnf was 4.0.9-2.fc29 The attachment is from the resulting F30. The system-upgrade was performed on 12 January. I am in UTC-0500.
Repeated. Host g5eas. I found the following after the download but before the reboot to actually install. dnf-4.0.9-2.fc29.noarch libdnf-0.22.3-1.fc29.x86_64 python3-dnf-plugin-system-upgrade-4.0.0-1.fc29.noarch
From which dnf and libdnf versions did you upgrade? Could you also provide a complete list of package NEVRAs from which you have upgraded? We need that to narrow down the problem and create a reproducer.
(In reply to Daniel Mach from comment #4) > From which dnf and libdnf versions did you upgrade? Comments #2 & #3 don't answer this? > Could you also provide a complete list of package NEVRAs from which you have upgraded? I'm not succeeding to find instructions to do this.
Created attachment 1525189 [details] tar.gz of /var/log/dnf*log* Maybe NEVRA is buried in dnf* logs? Still no luck finding instructions to a precise answer to comment #4.
Error: Transaction check error: file /usr/libexec/rtkit-daemon from install of rtkit-0.11-21.fc30.x86_64 conflicts with file from package rtkit-0.11-19.fc29.x86_64 file /usr/sbin/rtkitctl from install of rtkit-0.11-21.fc30.x86_64 conflicts with file from package rtkit-0.11-19.fc29.x86_64 Remove 1 Package Freed space: 152 k Is this ok [y/N]: y Running transaction check Transaction check succeeded. Running transaction test Transaction test succeeded. Running transaction Preparing : 1/1 Running scriptlet: rtkit-0.11-19.fc29.x86_64 1/1 /var/tmp/rpm-tmp.TrYc8o: line 1: fg: no job control error: %preun(rtkit-0.11-19.fc29.x86_64) scriptlet failed, exit status 1 Error in PREUN scriptlet in rpm package rtkit Verifying : rtkit-0.11-19.fc29.x86_64 1/1 Failed: rtkit-0.11-19.fc29.x86_64 Error: Transaction failed
I also ran into this issue while trying to upgrade to F30. Might be related to https://bugzilla.redhat.com/show_bug.cgi?id=1637496 using dnf distro-sync was trying to remove rtkit package but failed: ========================================================================================================= Package Architecture Version Repository Size ========================================================================================================= Abhängige Pakete werden entfernt: rtkit x86_64 0.11-19.fc29 @@System 152 k Transaktionsübersicht ========================================================================================================= Entfernen 1 Paket Freigegebener Speicherplatz: 152 k Ist dies in Ordnung? [j/N]: j 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 Ausgeführtes Scriptlet: rtkit-0.11-19.fc29.x86_64 1/1 /var/tmp/rpm-tmp.vDYdYP: Zeile 1: fg: Keine Job Steuerung in dieser Shell. Fehler: %preun(rtkit-0.11-19.fc29.x86_64) Scriptlet fehlgeschlagen, Beenden-Status 1 I then tried running this command suggested by Kamil Páral: $ sudo rpm -e rtkit-0.11-19.fc29.x86_64 --noscripts After that dnf system-upgrade runs without throwing an error.
I had the same issue. The upgrade from f29 to f30 appears to be successful, but the rtkit package is still around and can not be removed. $ dnf repoquery --extras --exclude=kernel,kernel-\* rtkit-0:0.11-19.fc29.x86_64 $ sudo dnf remove rtkit-0:0.11-19.fc29.x86_64 Dependencies resolved. ======================================================================================================================== Package Architecture Version Repository Size ======================================================================================================================== Removing: rtkit x86_64 0.11-19.fc29 @@System 152 k Transaction Summary ======================================================================================================================== Remove 1 Package Freed space: 152 k Is this ok [y/N]: y Running transaction check Transaction check succeeded. Running transaction test Transaction test succeeded. Running transaction Preparing : 1/1 Running scriptlet: rtkit-0.11-19.fc29.x86_64 1/1 /var/tmp/rpm-tmp.sn8oO0: line 1: fg: no job control error: %preun(rtkit-0.11-19.fc29.x86_64) scriptlet failed, exit status 1 Error in PREUN scriptlet in rpm package rtkit Verifying : rtkit-0.11-19.fc29.x86_64 1/1 Failed: rtkit-0.11-19.fc29.x86_64 Error: Transaction failed
So, this bug seems a bit confused now... It is known that if you have rtkit-0.11-19.fc29 installed you will get an error on update to any future version of the package and the old version will remain 'installed' so far as the RPM db is concerned. This is not really fixable, unfortunately: the package was built in such a way that it has scriptlets which are literally the text of a macro that was meant to be expanded during build, e.g. its %preun scriptlet is literally the text "%systemd_preun rtkit-daemon.service". That is always going to cause an error on execution. We fixed this bug in package version -20.fc29 and later, but we cannot do anything about the bad scriptlets baked into -19 at this point, it's just impossible. That's what #1637496 is about. So if you have that version of the package installed (BTW, it was only in a pre-release of F29, it was never in the final release), you're going to have some level of problems with it that will require manual cleanup. This bug seems to have lots of comments from people who had rtkit-0.11-19.fc29 installed at some point and see errors related to it, but...lots of the comments aren't clear about exactly what problem they are actually trying to report or get fixed, and it is not clear that all of you are seeing the same problem. So can I ask each reporter to be clearer about exactly what the issue they're reporting is? Did you try and upgrade and it failed? Did you try an upgrade and it succeeded but you wound up with duplicate rtkit packages? Did you run into some kind of bug and find some errors about rtkit somewhere and found your way to this bug report, but you're not actually sure the rtkit errors are related to the bug? Thanks a lot!
This happened too long ago to remember much, other than it happened on at least 3 different PCs, maybe as many as 7, trying to get from F29 to F30 using dnf system-upgrade. Ultimately all were eventually upgraded, most likely by doing rpm -e --nodeps rtkit-<badversion> at some point, but possibly instead or in addition by adding rtkit* to an /etc/dnf/dnf.conf excludes= line.
> will require manual cleanup Sorry for abusing this bug ticket, but would you mind sharing more details on what "manual cleanups" could be done on a f30 host with the -19.fc29 package?
rpm -e --justdb --noscripts rtkit-0.11-19.fc29.x86_64 please keep any further follow up on that in https://bugzilla.redhat.com/show_bug.cgi?id=1637496 , thanks.
The issue that is related to rtkit's postscript is fixed in bug#1637496 and a workaround suggested by Adam in comment#13 can be used to fix the system. I tried to reproduce the issue "RuntimeError: Transaction not found for key: rtkit" in a container, but with no success. The transaction always failed on a postscript but never failed with the message above. I'm closing the bug INSUFFICIENT_DATA, but if the problem occurs again and someone manages to create a reliable reproducer, we'll definitely deliver a fix.