Bug 1091702 - [rfe] complete-transaction support
Summary: [rfe] complete-transaction support
Keywords:
Status: NEW
Alias: None
Product: Fedora
Classification: Fedora
Component: dnf
Version: rawhide
Hardware: Unspecified
OS: Unspecified
medium
unspecified
Target Milestone: ---
Assignee: Packaging Maintenance Team
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
: 1242135 (view as bug list)
Depends On:
Blocks: 1723126
TreeView+ depends on / blocked
 
Reported: 2014-04-27 12:25 UTC by Susi Lehtola
Modified: 2019-07-24 08:40 UTC (History)
40 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2014-04-28 05:57:32 UTC


Attachments (Terms of Use)


Links
System ID Priority Status Summary Last Updated
Red Hat Bugzilla 1382063 None NEW RFE - Expand Upgrade function to optionally perform "offline" upgrades 2019-09-16 22:40:10 UTC
Red Hat Bugzilla 1382224 None CLOSED RFE: dnf transactions should run in a transient systemd service 2019-09-16 22:40:10 UTC

Internal Links: 1382063 1382224

Description Susi Lehtola 2014-04-27 12:25:19 UTC
It would be useful to have an analogous tool to yum-complete-transaction in dnf.

Sometimes it happens e.g. that the battery runs out while installing updates to a laptop, which is then pretty painstaking to fix without an automatic tool.

Comment 1 Ales Kozumplik 2014-04-28 05:57:32 UTC
I am reluctant about adding complete-transaction again, because DNF can not control what happens with the RPMDB until the complete-transaction is run again and faces applying outdated transaction to the system (dependencies have gone missing, packages depending on now duplicate versions might have been installed etc.) Closign this as WONTFIX with a vote, i.e. once enough people are CCed in the bug, we will see about adding this.

Note that the problem of unfinished transaction generally means two different things:

a) transaction was terminated during the install phase and some packages are left to be installed. In this case, running 'dnf upgrade' again will do the right thing and install the remaining packages.

b) transaction was terminated during the erase phase. Some packages are left to be installed. In this case the duplicate versions of packages will be removed on their next upgrade. Alternatively, the autoremove plugin should be eventually capable of removing duplicate, non-installonly packages from the system (bug 963345).

Comment 2 Honza Silhan 2015-07-29 14:01:24 UTC
*** Bug 1242135 has been marked as a duplicate of this bug. ***

Comment 3 Mathieu Bridon 2015-09-09 17:36:40 UTC
> a) transaction was terminated during the install phase and some packages
> are left to be installed. In this case, running 'dnf upgrade' again will
> do the right thing and install the remaining packages.

Really?

Running "dnf upgrade" will install the remaining packages... even if the transaction which had failed was a "dnf install foo bar baz"?

If that's the case, then at the very least, please add a message about that (similarly to how yum used to ask us to run yum-complete-transaction), because I (and I suspect others) would have never figured that I could finish an **install** transaction by running a new **upgrade**.

Comment 4 Vladimir Stackov 2016-01-28 19:11:35 UTC
(In reply to Ales Kozumplik from comment #1)
> b) transaction was terminated during the erase phase. Some packages are left
> to be installed. In this case the duplicate versions of packages will be
> removed on their next upgrade. Alternatively, the autoremove plugin should
> be eventually capable of removing duplicate, non-installonly packages from
> the system (bug 963345).

In this case I'm still forced to use package-cleanup or clean by hands because autoremove won't help.

Comment 5 Miroslav Suchý 2016-06-30 21:04:37 UTC
I have been upgrading from F23 -> F24 and my notebook run out of power and switched off. The transaction was not finished.
"package-cleanup --cleandupes" done the job. But ordinary user has very little chance to identify whether he fit in a) or b) and what is the right action to do.

Comment 6 Kevin Kofler 2016-10-05 16:56:22 UTC
This is a vital feature to recover from crashes during the upgrade process. And of course people will only notice that it is missing when they actually have a messed up system! So user demand is almost certainly much higher than what you can see in this bug.

Comment 7 Kevin Kofler 2016-10-05 17:00:56 UTC
In the unified DNF 2 world, the accounting needs to be handled at libdnf level so that PackageKit-dnf transactions will also be protected.

Comment 8 Adam Williamson 2016-10-06 04:20:27 UTC
I agree that it would be a sensible improvement to have this feature. The issue with completing 'outdated' transactions doesn't seem significant enough to block this feature, to me.

It's really a big problem if you manage to get an incomplete update transaction. There's no very clean way for a user to recover. package-cleanup doesn't really do it; it can probably get your database back to a 'clean' state but it can't do anything about the missed scriptlets (and maybe there are other things dnf does in the missed phases that package-cleanup can't cover, I dunno).

Obviously we could refuse to (or warn hard about) completing a transaction which isn't the most recent transaction. As for non-DNF transactions, well, I don't know enough about the internals to make concrete suggestions, but some thoughts:

1. If we can tell the *time* of the last modification to the RPM database, can't we just check if it's after the aborted transaction failed?

2. For each package in the aborted transaction, we could check if the RPM database reports any EVR other than one that was involved in the aborted transaction, and abort / warn in that case?

The need for this feature is of course correspondingly greater so long as https://bugzilla.redhat.com/show_bug.cgi?id=1382063 and/or https://bugzilla.redhat.com/show_bug.cgi?id=1382224 (or similar) are not implemented.

Comment 9 Hedayat Vatankhah 2016-12-10 06:51:44 UTC
There is always the possibility of loss of power (or other hardware failure) during dnf operations. So, having complete-transaction is always needed.

Comment 10 Matthew Miller 2016-12-15 00:52:30 UTC
Could the DNF team please re-evaluate this, in the light of the comments above? Thanks!

Comment 11 Honza Silhan 2016-12-19 13:49:05 UTC
ok, reconsidered. The new plugin may call passively removal of duplicates (bug 1284981) + fix other easily detected problems. The solution will not be 100% bullet proof though.

Comment 12 Matthew Miller 2016-12-19 13:51:16 UTC
Thanks! I don't think bulletproof is expected, but hopefully we can provide something in at least some situations which would otherwise be painful.

Comment 13 Kevin Kofler 2016-12-19 18:09:21 UTC
It's best to take into account what the last, failed, transaction was.

Comment 14 Hedayat Vatankhah 2016-12-20 06:54:29 UTC
(In reply to Honza Silhan from comment #11)
> ok, reconsidered. The new plugin may call passively removal of duplicates
> (bug 1284981) + fix other easily detected problems. The solution will not be
> 100% bullet proof though.

How would you remove duplicates? When I use 'advised' methods (like the one in #1284981), it doesn't work as it tries to remove lots of packages as 'dependencies'. So, each time I was in such a situation, the only way out of it for me was to 'rpm -e --nodeps OLD_VER_PACKAGES'. I didn't find ANY way to deal with such cases using dnf alone. I agree with Kevin that it should try to finish the last transaction.

Comment 15 Zdenek Kabelac 2017-08-22 12:39:53 UTC
So - yesterday during  mass-rebuild upgrade of rawhide I've 'witnessed' again kill of 'dnf' in the middle of upgrade  of  4000 packages  (thankfully in cleanup phase)

But I've been left with 1000 duplicate packages.

It's quite annoying manual work to clean-up this mess left after 'dnf' being aborted.

I'm amazed why there is not at least a SIMPLE reporting tool showing me older packages for removal in year 2017....

It should be even built-in  'rpm' functionality - since  RPM simply HAS to know which of the duplicated package is the file owner - eventually marking packages that needs full reinstall.

Something as simple as    'rpm --resolve-duplicates' should be there for years - rpm DB has ALL the info....

Also note:

dnf  repoquery  --duplicated  --latest-limit -1 

No longer works!  '-1' is not an accepted argument - even though it's even printed in --help....

Comment 16 Joseph D. Wagner 2017-08-22 15:32:22 UTC
Last I heard, Lennart Poettering was working on systemd-rpm, which should take care of it. :D

Comment 17 Mikhail 2017-08-22 15:35:03 UTC
If you on Rawhide you can remove all duplicate packages with command:
# dnf remove --duplicates --setopt=protected_packages=

Comment 18 Parag Nemade 2017-08-23 06:19:25 UTC
I too got the same problem when I updated f26 to rawhide last week, I managed to remove many duplicates with 
dnf distro-sync --releasever=rawhide

but now left with sudo and systemd-* duplicate packages. I am not able to find yet a way to remove these duplicate packages.

Anyone knows how to remove duplicates of sudo and systemd* packages?

Comment 19 Parag Nemade 2017-08-23 06:21:20 UTC
(In reply to Mikhail from comment #17)
> If you on Rawhide you can remove all duplicate packages with command:
> # dnf remove --duplicates --setopt=protected_packages=

ah I missed to see this comment. I just used this command and it removed sudo and systemd duplicate packages.

Thanks Mikhail.

Comment 20 Richard Shaw 2017-09-13 19:44:49 UTC
(In reply to Mikhail from comment #17)
> If you on Rawhide you can remove all duplicate packages with command:
> # dnf remove --duplicates --setopt=protected_packages=

I just tried this on a f26 system which had the transaction interrupted because it couldn't find a package which was on an NFS share.

Now both rpm and dnf have been removed so I'm basically screwed.

Comment 21 Matthew Miller 2017-09-13 19:57:51 UTC
Ouch. You should be able to repair that by booting with a rescue CD and using `rpm --root`. 

But: that shouldn't happen anyway, as "--duplicates" should only remove the older versions and leave newer versions intact. There might be a (separate) bug there. :(

Comment 22 Richard Shaw 2017-09-13 20:09:13 UTC
(In reply to Matthew Miller from comment #21)
> Ouch. You should be able to repair that by booting with a rescue CD and
> using `rpm --root`. 

That's pretty much the plan but I was trying to fix it remotely, now I have to wait until I can get in front of it. dnf has the --installroot option so that should work I'm guessing. About 500+ packages were removed. Should I try group installing "Workstation" to make sure I have a basic functioning system?

 
> But: that shouldn't happen anyway, as "--duplicates" should only remove the
> older versions and leave newer versions intact. There might be a (separate)
> bug there. :(

Not sure I want to reproduce the problem to verify it :)


Note You need to log in before you can comment on or make changes to this bug.