rpm-software-management / dnf-plugins-extras

repository for DNF community plugins
GNU General Public License v2.0
65 stars 62 forks source link

dnf upgrade to Fedora 35 using --downloaddir just wiped out my entire home dir ! #200

Closed linuxguy123 closed 1 year ago

linuxguy123 commented 2 years ago

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

for entry in os.listdir(path):
    fullpath = os.path.join(path, entry)
    try:
        if os.path.isdir(fullpath):
            dnf.util.rm_rf(fullpath)
        else:
            os.unlink(fullpath)
    except OSError:
        pass

========================================================================

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.

ferdnyc commented 1 year ago

Despite not being tagged to close the issue, this was fixed in #201. This can be closed.