Description of problem: Postinstall and preuninstall scripts contain onresolved rpm macro. $ rpm -qp --scripts rtkit-0.11-19.fc29.i686.rpm preinstall scriptlet (using /bin/sh): getent group rtkit >/dev/null 2>&1 || groupadd \ -r \ -g 172 \ rtkit getent passwd rtkit >/dev/null 2>&1 || useradd \ -r -l \ -u 172 \ -g rtkit \ -d /proc \ -s /sbin/nologin \ -c "RealtimeKit" \ rtkit :; postinstall scriptlet (using /bin/sh): %systemd_post rtkit-daemon.service <<<<<<<<<<<<<<<<<<<<<<<< dbus-send --system --type=method_call --dest=org.freedesktop.DBus / org.freedesktop.DBus.ReloadConfig >/dev/null 2>&1 || : preuninstall scriptlet (using /bin/sh): %systemd_preun rtkit-daemon.service <<<<<<<<<<<<<<<<<<<<<<<< postuninstall scriptlet (using /bin/sh): %systemd_postun <<<<<<<<<<<<<<<<<<<<<<<< $ rpm -qp --scripts rtkit-0.11-19.fc29.x86_64.rpm preinstall scriptlet (using /bin/sh): getent group rtkit >/dev/null 2>&1 || groupadd \ -r \ -g 172 \ rtkit getent passwd rtkit >/dev/null 2>&1 || useradd \ -r -l \ -u 172 \ -g rtkit \ -d /proc \ -s /sbin/nologin \ -c "RealtimeKit" \ rtkit :; postinstall scriptlet (using /bin/sh): %systemd_post rtkit-daemon.service <<<<<<<<<<<<<<<<<<<< dbus-send --system --type=method_call --dest=org.freedesktop.DBus / org.freedesktop.DBus.ReloadConfig >/dev/null 2>&1 || : preuninstall scriptlet (using /bin/sh): %systemd_preun rtkit-daemon.service <<<<<<<<<<<<<<<<<<<< postuninstall scriptlet (using /bin/sh): %systemd_postun <<<<<<<<<<<<<<<<<<<<<
rtkit-0.11-20.fc29 has been submitted as an update to Fedora 29. https://bodhi.fedoraproject.org/updates/FEDORA-2018-66f441eb34
rtkit-0.11-20.fc29 has been pushed to the Fedora 29 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2018-66f441eb34
Proposing as a blocker. rtkit-0.11-19.fc29.x86_64 is currently stable and can't be updated, the transaction fails: ... Running scriptlet: rtkit-0.11-19.fc29.x86_64 99/132 /var/tmp/rpm-tmp.3Jy2SS: 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 Error in PREUN scriptlet in rpm package rtkit ... Failed: rtkit-0.11-19.fc29.x86_64 Error: Transaction failed $ sudo dnf check [sudo] password for kparal: rtkit-0.11-19.fc29.x86_64 is a duplicate with rtkit-0.11-20.fc29.x86_64 Error: Check discovered 1 problem(s) The only way to remove it is using: $ sudo rpm -e rtkit-0.11-19.fc29.x86_64 --noscripts This broken package is installed by default (at least in Workstation) and prevents future updates. We need to fix it before making a stable F29 release. Also, this is probably a good candidate for common bugs, because it will affect most existing F29 pre-release users.
Proposed as a Freeze Exception for 29-final by Fedora user frieben using the blocker tracking app because: Package rtkit-0.11-19.fc29 is included in the live image Fedora-Workstation-Live-x86_64-29-20181009.n.0 but because of present issue, it cannot be upgraded to rtkit-0.11-20.fc29. The updated package should therefore be an exception to the current freeze.
(In reply to Fedora Update System from comment #1) > rtkit-0.11-20.fc29 has been submitted as an update to Fedora 29. > https://bodhi.fedoraproject.org/updates/FEDORA-2018-66f441eb34 This fixes the problem.
*** Bug 1637882 has been marked as a duplicate of this bug. ***
(In reply to Kamil Páral from comment #3) > Proposing as a blocker. rtkit-0.11-19.fc29.x86_64 is currently stable and > can't be updated, the transaction fails: > > ... > Running scriptlet: rtkit-0.11-19.fc29.x86_64 > 99/132 > /var/tmp/rpm-tmp.3Jy2SS: 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 > Error in PREUN scriptlet in rpm package rtkit > ... > Failed: > rtkit-0.11-19.fc29.x86_64 > > > Error: Transaction failed > > $ sudo dnf check > [sudo] password for kparal: > rtkit-0.11-19.fc29.x86_64 is a duplicate with rtkit-0.11-20.fc29.x86_64 > Error: Check discovered 1 problem(s) > > > The only way to remove it is using: > $ sudo rpm -e rtkit-0.11-19.fc29.x86_64 --noscripts > > > This broken package is installed by default (at least in Workstation) and > prevents future updates. We need to fix it before making a stable F29 > release. Also, this is probably a good candidate for common bugs, because it > will affect most existing F29 pre-release users. It can get worse: If you ever reinstalled rtkit-0.11-19.fc29.x86_64 then you are left with a duplicate entry in the rpm data base, and rpm will refuse to remove the duplicate.
(In reply to Villy Kruse from comment #7) > It can get worse: If you ever reinstalled rtkit-0.11-19.fc29.x86_64 then > you are left with a duplicate entry in the rpm data base, and rpm will > refuse to remove the duplicate. Like this: [aakcaagac@localhost ~]$ rpm -qa | grep -i "rtk" rtkit-0.11-20.fc29.x86_64 rtkit-0.11-19.fc29.x86_64 [aakcaagac@localhost ~]$ I usually enfore "rpm -e --nodeps rtkit" to remove all traces of rtkit from the rpm database. Then I re-install rtkit from scratch. Still... Annoying...
(In reply to Ali Akcaagac from comment #8) > (In reply to Villy Kruse from comment #7) > Like this: > > [aakcaagac@localhost ~]$ rpm -qa | grep -i "rtk" > rtkit-0.11-20.fc29.x86_64 > rtkit-0.11-19.fc29.x86_64 > [aakcaagac@localhost ~]$ > > No, like this. rtkit-0.11-19.fc29.x86_64 rtkit-0.11-19.fc29.x86_64 I had rtkit-0.11-19.fc29.x86_64 installed and the re-install created a second rtkit-0.11-19.fc29.x86_64
Is there a workaround? I tried `rpm -e --nodeps` but still get: ``` /var/tmp/rpm-tmp.ga0qth: line 1: fg: no job control error: %preun(rtkit-0.11-19.fc29.x86_64) scriptlet failed, exit status 1 error: rtkit-0.11-19.fc29.x86_64: erase failed ```
"rpm -e --nopreun rtkit-0.11-19.fc29.x86_64" worked for me.
(In reply to Villy Kruse from comment #9) > (In reply to Ali Akcaagac from comment #8) > > (In reply to Villy Kruse from comment #7) > > > Like this: > > > > [aakcaagac@localhost ~]$ rpm -qa | grep -i "rtk" > > rtkit-0.11-20.fc29.x86_64 > > rtkit-0.11-19.fc29.x86_64 > > [aakcaagac@localhost ~]$ > > > > > > No, like this. > rtkit-0.11-19.fc29.x86_64 > rtkit-0.11-19.fc29.x86_64 > > I had rtkit-0.11-19.fc29.x86_64 installed and the re-install created a > second rtkit-0.11-19.fc29.x86_64 More specifically [root@secondbux ~]# rpm -q rtkit rtkit-0.11-19.fc29.x86_64 rtkit-0.11-20.fc29.x86_64 rtkit-0.11-19.fc29.x86_64 [root@secondbux ~]# rpm -e --nodeps --noscript rtkit error: "rtkit" specifies multiple packages: rtkit-0.11-19.fc29.x86_64 rtkit-0.11-20.fc29.x86_64 rtkit-0.11-19.fc29.x86_64 [root@secondbux ~]# rpm -e --nodeps --noscript rtkit-0.11-19.fc29.x86_64 error: "rtkit-0.11-19.fc29.x86_64" specifies multiple packages: rtkit-0.11-19.fc29.x86_64 rtkit-0.11-19.fc29.x86_64 [root@secondbux ~]#
(In reply to kxra from comment #10) > Is there a workaround? I tried `rpm -e --nodeps` but still get: > > ``` > /var/tmp/rpm-tmp.ga0qth: line 1: fg: no job control > error: %preun(rtkit-0.11-19.fc29.x86_64) scriptlet failed, exit status 1 > error: rtkit-0.11-19.fc29.x86_64: erase failed > ``` See comment no 3.
Sorry my bad. I had to reconstruct the line out of memory. rpm -e --nodeps --justdb rtkit -e = erase --nodeps = skip dependency --justdb = work on database only Means! It only removes the entries from the db. The package still exists on your system. But you can then dnf install rtkit again. Now that we don't have the yumdb stuff anymore, you can issue the rpm install from commandline, in case dnf fails.
At least +1 FE for me.
+1 FE
That's +3, marking as accepted FE.
#!/bin/bash --login # Begin rtkit.sh rtkit=`rpm -qa rtkit` for i in ${rtkit} ; do echo "processing: \"${i}\"" rpm -e --nodeps --justdb "${i}" done dnf -y install rtkit exit # End rtkit.sh
Please save above as rtkit.sh and run it as root. This will erase all entries of rtkit from rpm (database only) and then installs rtkit fresh from repository. Also note! As far as I remember, there was plenty of other duplicate entries early, when I tried F29 before the branch was created. So in doubt please check for other duplicate entries in your rpm database.
I can confirm, that Ali's approach (comment #19) works. Even if you do not want to use a script but issue the commands individually. Also, the new rtkit (0.11.20) can be installed without any issues.
rtkit-0.11-20.fc29 has been pushed to the Fedora 29 stable repository. If problems still persist, please make note of it in this bug report.
*** Bug 1638946 has been marked as a duplicate of this bug. ***
> [root@secondbux ~]# rpm -e --nodeps --noscript rtkit > error: "rtkit" specifies multiple packages: > rtkit-0.11-19.fc29.x86_64 > rtkit-0.11-20.fc29.x86_64 > rtkit-0.11-19.fc29.x86_64 to remove all instances of the same v19 package use sudo rpm -e --nodeps --allmatches --justdb rtkit-0.11-19.fc29.x86_64 the bash script will not help you either as each call in the loop to drop a package will fail as you have multiple instances of the same package installed and cannot delete them without --allmatches!! after that, just reinstall the 20 again: sudo dnf reinstall rtkit-0.11-20.fc29.x86_64 problem solved ;-)
*** Bug 1639138 has been marked as a duplicate of this bug. ***
*** Bug 1641214 has been marked as a duplicate of this bug. ***
*** Bug 1646864 has been marked as a duplicate of this bug. ***
*** Bug 1674108 has been marked as a duplicate of this bug. ***
*** Bug 1691201 has been marked as a duplicate of this bug. ***
Same for me, just did upgrade to F30 (F29 was up-to-date), but still had rtkit-0.11-19.fc29 present in the system. Manual cleanup worked, but still not good for overall upgrade experience
The way RPM works, if you were unfortunate enough to get 0.11-19.fc29 there's not much we can do about it, that package is just a trap :/ All we could do is get the fixed 0.11-20.fc29 out as fast as possible so people who installed F29 *after that point* weren't affected, but if you were running F29 when 0.11-19.fc29 came out you were basically always going to be stuck with this. Sorry about that :(
(In reply to Adam Williamson from comment #31) > The way RPM works, if you were unfortunate enough to get 0.11-19.fc29 > there's not much we can do about it, that package is just a trap :/ All we > could do is get the fixed 0.11-20.fc29 out as fast as possible so people who > installed F29 *after that point* weren't affected, but if you were running > F29 when 0.11-19.fc29 came out you were basically always going to be stuck > with this. > > Sorry about that :( That fix was done before official release of fc29, so only people who installed fc29-beta were affected.
*** Bug 1700551 has been marked as a duplicate of this bug. ***
Just wow, realized that I still have rtkit-0.11-19.fc29.x86_64 on my system without ability to get rid of it easily (for what's expected experience of your average Fedora user). The way out: rpm -e --noscripts rtkit-0.11-19.fc29.x86_64 (You noticed it was already suggested in [comment 3].) Looks like it would be nice to have some sort of out-of-RPM (so as to be able to call RPM commands, which shall be frowned upon within transaction itself, correct?) pattern matching system (like "rtkit = 0.11-19 && rtkit > 0.11-19") that would either make some suggestions (send a message to some admin queue, like implemented in Gentoo, for instance) or act right away. Otherwise Fedora is rather far from either no-touch or no-active-info-solicitation. Would be nice to at least have the latter (push model for important tasks to do rather than pull -- be checking MLs, wikis and all other thinkable channels in parallel). (Makes me think if Fedora is really ready for long-term gradual upgrade journey ... will for instance dnf grow the history logs indefinitely or is there some vacuuming so there's no danger that the package change transacations will eventually occupy most of the system -- curiously, I see the transaction history back to 2017-01-05 on this system, which is nice, but not sure if that makes for a resonable footprint in case this system would happen to continue next 10+ years like this ... especially when slihtly hidden burps like with rtkit will add up over time).
(In reply to Jan Pokorný [poki] from comment #34) > (Makes me think if Fedora is really ready for long-term gradual > upgrade journey ... will for instance dnf grow the history logs > indefinitely or is there some vacuuming so there's no danger that > the package change transacations will eventually occupy most of the > system -- curiously, I see the transaction history back to 2017-01-05 > on this system, which is nice, but not sure if that makes for > a resonable footprint in case this system would happen to continue > next 10+ years like this ... especially when slihtly hidden burps > like with rtkit will add up over time). On one computer I have dnf with ~2500 history entries since 2015-11-01 (Fedora 23). So as long as dnf is old I've not had an issue breaking my system or dnf history/database completely. I had to work around a few issues like this one though. dnf logs have log rotation (after 1MB in my case, adding up to about 10MB of logs for dnf/rpm/librepo/hawkey in total). /var/lib/dnf is 135MB out of which 21MB is for history.sqlite and 96MB is the history/ subfolder (looks like old backups). In other words: given that fedora is relatively close to bleeding-edge, this looks quite good. If you want more stability, use a different distro ;)
Fair enough, but even on bleeding edge, you'd rather have some assurances you may stay in the saddle for ages, not that you'll be marked a fossil and recommended to start the ride anew. This discontinuity is material, e.g. [bug 1598523 comment 11] (which was exactly of this sort ... all works nicely on fresh install, too bad that no-touch migration from older ones are not a concern, IIRC). Enough of off-topic and nagging, though, doesn't belong here, I guess :-)
I have 1856 transactions going back to 2013-12-15 in my dnf history. /var/lib/dnf/history is 99M. This box was installed as Fedora 15 and is still going, so I'd say long-term upgrading is fine...