Note: This bug is displayed in read-only format because
the product is no longer active in Red Hat Bugzilla.
RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Description of problem:
The command "dnf install --downloadonly --download-dir" is used to download a set of packages and dependencies to a directory.
The location of these package is saved into /var/cache/dnf/tempfiles.json and these package are deleted from the directory on the next successful transaction which can be unrelated to the packages downloaded at the specified directory.
For example,
Use "dnf install tcpdump --downloadonly --downloaddir=/local_repo" command downloads packages in the location /local_repo
~~~
# dnf install tcpdump --downloadonly --downloaddir=/local_repo
Dependencies resolved.
===============================================================================================================================
Package Architecture Version Repository Size
===============================================================================================================================
Installing:
tcpdump x86_64 14:4.9.3-3.el8 rhel-8-for-x86_64-appstream-rpms 453 k
Transaction Summary
===============================================================================================================================
Install 1 Package
Total download size: 453 k
Installed size: 1.1 M
YUM will only download packages for the transaction.
Is this ok [y/N]: y
Downloading Packages:
tcpdump-4.9.3-3.el8.x86_64.rpm 924 kB/s | 453 kB 00:00
--------------------------------------------------------------------------------------------------------------------------------
Total 922 kB/s | 453 kB 00:00
Complete!
The downloaded packages were saved in cache until the next successful transaction.
You can remove cached packages by executing 'dnf clean packages'.
~~~
Here above it does list that the "packages were saved in cache until the next successful transaction" and we see that the package are removed after any successful transaction of dnf. Also using "dnf clean packages" here does not remove the packages from /local_repo or entry from /var/cache/dnf/tempfiles.json
I do not see this behavior in RHEL 7 with yum.
Running it under strace revealed that it keeps location of the downloaded packages in a list structure stored in /var/cache/dnf/tempfiles.json
~~~
# ls -l /local_repo
total 456
-rw-r--r--. 1 root root 463984 Dec 13 15:30 tcpdump-4.9.3-3.el8.x86_64.rpm
# cat /var/cache/dnf/tempfiles.json ; echo
["/local_repo/tcpdump-4.9.3-3.el8.x86_64.rpm"]
~~~
Later when ever the next dnf transaction is run (and its successful) , whether its related to the the earlier downloaded packages or not it clear the packages downloaded at /local_repo (referring the list in /var/cache/dnf/tempfiles.json ) and then clear the packages list /var/cache/dnf/tempfiles.json
~~~
# dnf install nano
Updating Subscription Management repositories.
Last metadata expiration check: 0:57:22 ago on Tue 13 Dec 2022 02:37:45 PM EST.
Dependencies resolved.
=========================================================================================================================
Package Architecture Version Repository Size
=========================================================================================================================
Installing:
nano x86_64 2.9.8-1.el8 rhel-8-for-x86_64-baseos-rpms 580 k
Transaction Summary
=========================================================================================================================
Install 1 Package
Total download size: 580 k
Installed size: 2.2 M
Is this ok [y/N]: y
Downloading Packages:
nano-2.9.8-1.el8.x86_64.rpm 1.2 MB/s | 580 kB 00:00
-------------------------------------------------------------------------------------------------------------------------
Total 1.2 MB/s | 580 kB 00:00
Running transaction check
Transaction check succeeded.
Running transaction test
Transaction test succeeded.
Running transaction
Preparing : 1/1
Installing : nano-2.9.8-1.el8.x86_64 1/1
Running scriptlet: nano-2.9.8-1.el8.x86_64 1/1
Verifying : nano-2.9.8-1.el8.x86_64 1/1
Installed products updated.
Installed:
nano-2.9.8-1.el8.x86_64
Complete!
~~~
We see that the tcpdump rpm is now gone and the file /var/cache/dnf/tempfiles.json is empty
~~~
# ls -l /local_repo/
total 0
# cat /var/cache/dnf/tempfiles.json ; echo
[]
~~~
Dnf logs also show the packages is being removed
~~~
2022-12-13T15:35:19-0500 DDEBUG Cleaning up.
2022-12-13T15:35:19-0500 DDEBUG /local_repo/tcpdump-4.9.3-3.el8.x86_64.rpm removed
2022-12-13T15:35:19-0500 DDEBUG /var/cache/dnf/rhel-8-for-x86_64-baseos-rpms-51b3b78d5698246b/packages/nano-2.9.8-1.el8.x86_64.rpm removed
~~~
Version-Release number of selected component (if applicable):
dnf-4.7.0-8.el8.noarch
libdnf-0.63.0-8.1.el8_6.x86_64
How reproducible:
Everytime
Steps to Reproduce:
1. Download the packages with options "--downloadonly --downloaddir". Verify the package exist and its entry in /var/cache/dnf/tempfiles.json
# dnf install tcpdump --downloadonly --downloaddir=/local_repo
# ls -la /local_repo
# cat /var/cache/dnf/tempfiles.json ; echo
2. Now do other dnf transaction which is successful like dnf install/reinstall operations and the confirm that the package no longer exist at /local_repo
# dnf install nano
# ls -la /local_repo
# cat /var/cache/dnf/tempfiles.json ; echo
3. To workaround I found that we needed to delete the file /var/cache/dnf/tempfiles.json so it won't be read and dnf will not be able to delete the earlier downloaded packages.
# Run "rm /var/cache/dnf/tempfiles.json" after "dnf --downloadonly --downloaddir" is used to download a package and its dependencies.
OR to use "dnf download --resolve" instead.
# dnf download --resolve <package_name>
Actual results:
The downloaded packages are removed from the location where they are downloaded
Expected results:
I expected that the package be present at the location because these were downloaded by the user for some future need and hence I feel like the package being removed later on a unrelated successful transaction to be un-intuitive and can be confusing to the user and also its not documented in man page either.
Also this behavior is not seen in yum on RHEL 7.
Let me know your though on this and if you agree/disagree ?
Additional info:
This issue is seen on all version of DNF i.e. also the one on RHEL 8.0
The issue is not seen when using "dnf download" or "yumdownloader"
Issue does not happen with yum on RHEL 7.
Hello, this issue was already discussed many times and was resolved by updating the documentation in the dnf-4.7.0-13.el8, see https://bugzilla.redhat.com/show_bug.cgi?id=2100811. Also there are other ways how to get the expected result. Therefore I am for closing this as a duplicate.
Description of problem: The command "dnf install --downloadonly --download-dir" is used to download a set of packages and dependencies to a directory. The location of these package is saved into /var/cache/dnf/tempfiles.json and these package are deleted from the directory on the next successful transaction which can be unrelated to the packages downloaded at the specified directory. For example, Use "dnf install tcpdump --downloadonly --downloaddir=/local_repo" command downloads packages in the location /local_repo ~~~ # dnf install tcpdump --downloadonly --downloaddir=/local_repo Dependencies resolved. =============================================================================================================================== Package Architecture Version Repository Size =============================================================================================================================== Installing: tcpdump x86_64 14:4.9.3-3.el8 rhel-8-for-x86_64-appstream-rpms 453 k Transaction Summary =============================================================================================================================== Install 1 Package Total download size: 453 k Installed size: 1.1 M YUM will only download packages for the transaction. Is this ok [y/N]: y Downloading Packages: tcpdump-4.9.3-3.el8.x86_64.rpm 924 kB/s | 453 kB 00:00 -------------------------------------------------------------------------------------------------------------------------------- Total 922 kB/s | 453 kB 00:00 Complete! The downloaded packages were saved in cache until the next successful transaction. You can remove cached packages by executing 'dnf clean packages'. ~~~ Here above it does list that the "packages were saved in cache until the next successful transaction" and we see that the package are removed after any successful transaction of dnf. Also using "dnf clean packages" here does not remove the packages from /local_repo or entry from /var/cache/dnf/tempfiles.json I do not see this behavior in RHEL 7 with yum. Running it under strace revealed that it keeps location of the downloaded packages in a list structure stored in /var/cache/dnf/tempfiles.json ~~~ # ls -l /local_repo total 456 -rw-r--r--. 1 root root 463984 Dec 13 15:30 tcpdump-4.9.3-3.el8.x86_64.rpm # cat /var/cache/dnf/tempfiles.json ; echo ["/local_repo/tcpdump-4.9.3-3.el8.x86_64.rpm"] ~~~ Later when ever the next dnf transaction is run (and its successful) , whether its related to the the earlier downloaded packages or not it clear the packages downloaded at /local_repo (referring the list in /var/cache/dnf/tempfiles.json ) and then clear the packages list /var/cache/dnf/tempfiles.json ~~~ # dnf install nano Updating Subscription Management repositories. Last metadata expiration check: 0:57:22 ago on Tue 13 Dec 2022 02:37:45 PM EST. Dependencies resolved. ========================================================================================================================= Package Architecture Version Repository Size ========================================================================================================================= Installing: nano x86_64 2.9.8-1.el8 rhel-8-for-x86_64-baseos-rpms 580 k Transaction Summary ========================================================================================================================= Install 1 Package Total download size: 580 k Installed size: 2.2 M Is this ok [y/N]: y Downloading Packages: nano-2.9.8-1.el8.x86_64.rpm 1.2 MB/s | 580 kB 00:00 ------------------------------------------------------------------------------------------------------------------------- Total 1.2 MB/s | 580 kB 00:00 Running transaction check Transaction check succeeded. Running transaction test Transaction test succeeded. Running transaction Preparing : 1/1 Installing : nano-2.9.8-1.el8.x86_64 1/1 Running scriptlet: nano-2.9.8-1.el8.x86_64 1/1 Verifying : nano-2.9.8-1.el8.x86_64 1/1 Installed products updated. Installed: nano-2.9.8-1.el8.x86_64 Complete! ~~~ We see that the tcpdump rpm is now gone and the file /var/cache/dnf/tempfiles.json is empty ~~~ # ls -l /local_repo/ total 0 # cat /var/cache/dnf/tempfiles.json ; echo [] ~~~ Dnf logs also show the packages is being removed ~~~ 2022-12-13T15:35:19-0500 DDEBUG Cleaning up. 2022-12-13T15:35:19-0500 DDEBUG /local_repo/tcpdump-4.9.3-3.el8.x86_64.rpm removed 2022-12-13T15:35:19-0500 DDEBUG /var/cache/dnf/rhel-8-for-x86_64-baseos-rpms-51b3b78d5698246b/packages/nano-2.9.8-1.el8.x86_64.rpm removed ~~~ Version-Release number of selected component (if applicable): dnf-4.7.0-8.el8.noarch libdnf-0.63.0-8.1.el8_6.x86_64 How reproducible: Everytime Steps to Reproduce: 1. Download the packages with options "--downloadonly --downloaddir". Verify the package exist and its entry in /var/cache/dnf/tempfiles.json # dnf install tcpdump --downloadonly --downloaddir=/local_repo # ls -la /local_repo # cat /var/cache/dnf/tempfiles.json ; echo 2. Now do other dnf transaction which is successful like dnf install/reinstall operations and the confirm that the package no longer exist at /local_repo # dnf install nano # ls -la /local_repo # cat /var/cache/dnf/tempfiles.json ; echo 3. To workaround I found that we needed to delete the file /var/cache/dnf/tempfiles.json so it won't be read and dnf will not be able to delete the earlier downloaded packages. # Run "rm /var/cache/dnf/tempfiles.json" after "dnf --downloadonly --downloaddir" is used to download a package and its dependencies. OR to use "dnf download --resolve" instead. # dnf download --resolve <package_name> Actual results: The downloaded packages are removed from the location where they are downloaded Expected results: I expected that the package be present at the location because these were downloaded by the user for some future need and hence I feel like the package being removed later on a unrelated successful transaction to be un-intuitive and can be confusing to the user and also its not documented in man page either. Also this behavior is not seen in yum on RHEL 7. Let me know your though on this and if you agree/disagree ? Additional info: This issue is seen on all version of DNF i.e. also the one on RHEL 8.0 The issue is not seen when using "dnf download" or "yumdownloader" Issue does not happen with yum on RHEL 7.