-
Notifications
You must be signed in to change notification settings - Fork 61
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
dnf upgrade to Fedora 35 using --downloaddir just wiped out my entire home dir ! #200
Comments
kontura
added a commit
to kontura/dnf-plugins-extras
that referenced
this issue
Nov 24, 2021
dnf automatically cleans up packages used in a transaction, this can be configured by `keepcache` option. cachedir still gets cleaned up completely but it is hardcoded to: `var/lib/dnf/system-upgrade` and cannot be overwritten. For: rpm-software-management#200 https://bugzilla.redhat.com/show_bug.cgi?id=2024430
kontura
added a commit
to kontura/dnf-plugins-extras
that referenced
this issue
Nov 25, 2021
dnf automatically cleans up packages used in a transaction, this can be configured by `keepcache` option but we have to preserve the persistor which contains their paths. The persistor file remains after each run of dnf so it remains either way, if we delete it dnf creates it again when finalizing base. cachedir still gets cleaned up but it is hardcoded to: `var/lib/dnf/system-upgrade` and cannot be overwritten. For: rpm-software-management#200 https://bugzilla.redhat.com/show_bug.cgi?id=2024430
pkratoch
pushed a commit
that referenced
this issue
Nov 26, 2021
dnf automatically cleans up packages used in a transaction, this can be configured by `keepcache` option but we have to preserve the persistor which contains their paths. The persistor file remains after each run of dnf so it remains either way, if we delete it dnf creates it again when finalizing base. cachedir still gets cleaned up but it is hardcoded to: `var/lib/dnf/system-upgrade` and cannot be overwritten. For: #200 https://bugzilla.redhat.com/show_bug.cgi?id=2024430
Despite not being tagged to close the issue, this was fixed in #201. This can be closed. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
So... went to do an upgrade to Fedora 35 and found that I was lacking room for the downloads. I have /home set up on a separate drive, so I did the following:
dnf system-upgrade download --downloaddir=/home --releasever=35
The upgrade went well, except when I rebooted into F35 I couldn't log into my home directory. So I rebooted and logged into a console session. When I did, I got an error message stating that /home/ was missing. ls /home showed me that all my home directories are missing.
I'm guessing that dnf downloaded all the packages for the upgrade to /home and then did a rm -rf * on them, taking out my home directories in the process.
Just confirmed the dnf system-upgrade probably does a rm-rf on the "download" dir.
From dnf-plugins-extras/plugins/system_upgrade.py:
=======================================================================
def clear_dir(path):
if not os.path.isdir(path):
return
========================================================================
I'm guessing that dnf.util.rm_rf does a #rm -rf ! Which explains where my home directories went !
I am beyond angry that this happened.
This is crazy coding ? If the developer wanted to delete only dnf created files, s/he could have easily grouped them by creating a sub directory within the --downloaddir, downloaded the files there and then did an rm -rf from within that directory.
I just lost a couple months worth of work.
The text was updated successfully, but these errors were encountered: