Upgrade from F41 to F42 failing due to lack of space on /

Hi Guys,

Been running Fedora for quite a long time and never ran into this before.

the dnf system-upgrade download --releasever=42 is failing due to lack of space on /

I have 16G for / and /usr which is under / is at 12G

I have plenty of disk space available on other drives and I can move things around, but I had some bad experiences when specific filesystems are not mounted under / so I don’t know what to do here. According to the latest errors I need 3G and I only have 1.8G left.

Please let me know how I can resolve this. Thank you,

Bill

edit: it appears there is an option for dnf to download the packages to an alternate directory, but the manpage is confusing to me. If anybody knows the magic sauce that would be great.

Hello,

Thank you, that doesn’t help.

My question is if it is safe to move some of the subdirectories of / to their own filesystem on another disk. Sorry if I didn’t ask it clearly.

When moving “system” directory trees you want to boot from another drive, usually a “Live USB Installer”. Back when drives were much smaller than they are now I often had to move bloated trees like /usr/local because “mission critical” software needed specific compilers and libraries not available from the distro. It was not hard to move the tree to another drive and the replace it with a symbolic link. Before making such changes it can be important to check for “hidden files”: usually application crashes that left big output files with file or directory names beginning with a . . Since colleagues worked with similar base configurations, it was easy to see when some directory was using an unusual amount of space.

You haven’t mentioned your filesystem. Modern filesystems like btrfs use a “storage pool” and you can just add space from another drive to the pool for your system.

Thank you.

In the past when certain directories were not physical subdirectories of / it caused problems. I don’t remember it was Linux or the various BSD UNIX I run.

I have enough disk space and I know how to move directories. I don’t know if moving /usr to its own mount point will break dnf system-upgrade.

Anyway, there seems to be some option or options to download the packages to a different directory but I tried a few commands and dnf didn’t like the syntax.

If anybody has experience with that feature of dnf, that would help in my case where I have plenty of room on other drives on the box.

You can run sudo du -ah /var |sort -h to see if there are temporary or cache files you no longer need.

Thank you,

/var is on its own mountpoint, has around 500G left.

On Fedora 41, is there a way to specify an alternate download directory for the

dnf system-upgrade download --releasever=42

command, and then direct dnf system-upgrade upgrade
to use packages from the alternate location?

If using dnf4 you can specify

   --downloaddir=<path>
          Redirect download of packages to provided <path>. By default, packages are downloaded into (per repository created)
          subdirectories of /var/lib/dnf/system-upgrade.

For dnf5 the download directory is var/lib/dnf/offline/ anyway. But F41 is too old for me to investigate further.

Thank you. I tried adding that argument

dnf --downloaddir=/var/packages system-upgrade download --releasever=42

and it returned

Unknown argument “–downloaddir=/var/packages” for command “dnf5”

I cannot determine where the default command downloads packages, but it is not in /var since my /var has more than 500G available.

It seems the packages are downloaded somewhere under / in a filesystem which I don’t have on a seperate mountpoint and drive, unlike /var and /tmp which I have separate drives for.

Is there a command to determine where

dnf system-upgrade download --releasever=42 is saving the packages?

Hello,

you could use symbolics link: ln -s /var/lib/dnf/system-upgrade /data/system-upgrade/.

It works well…

Hello, thank you.

The packages are not downloaded under /var

I have over 500G available in /var and the system-upgrade download breaks.

I found the answer here https://superuser.com/questions/1277412/where-do-packages-installed-with-dnf-get-stored

in the last post in the thread, Garrett Mitchener says:

“I’m upgrading some machines from Fedora 41 to 42. Running dnf system-upgrade download --releasever=42 today, I discovered that RPMs are now being stored in /usr/lib/sysimage/libdnf5/offline/packages/ which is different from where they used to go. I’m guessing this is a change made going from DNF version 4 to 5.”

Seems to me an extremely poor choice of package download target. But now my upgrade is proceeding after I moved the existing sysimage directory to my /var and symlinked it from /usr/lib

man dnf4.conf has a cachedir option, but I wonder if dnf just checks the free space in the root partition.

Thanks, I did set cachedir in dnf.conf but it didn’t change anything.

It would be nice if that worked but I have a workaround and my system-upgrade succeeded.

And therefore it was changed to /var/lib/dnf in some later release.

dnf5 switched to /var/cache/libdnf5 but apparently not system-upgrade.
just started system-upgrade download in a f43 vm..

 ll /usr/lib/sysimage/libdnf5/offline/packages/ |head
total 288212
-rw-r--r--. 1 root root    210107 Jul 29 18:49 aajohan-comfortaa-fonts-3.105-0.9.20210729git2a87ac6.fc44.noarch.rpm
-rw-r--r--. 1 root root    276398 Jul 29 18:49 abattis-cantarell-fonts-0.301-17.fc44.noarch.rpm
-rw-r--r--. 1 root root    123255 Jul 29 18:49 abattis-cantarell-vf-fonts-0.301-17.fc44.noarch.rpm
-rw-r--r--. 1 root root    547764 Jul 29 18:49 abrt-2.17.8-3.fc44.x86_64.rpm
-rw-r--r--. 1 root root    108090 Jul 29 18:49 abrt-addon-ccpp-2.17.8-3.fc44.x86_64.rpm
-rw-r--r--. 1 root root     44502 Jul 29 18:49 abrt-addon-kerneloops-2.17.8-3.fc44.x86_64.rpm
-rw-r--r--. 1 root root     19226 Jul 29 18:49 abrt-addon-pstoreoops-2.17.8-3.fc44.x86_64.rpm
-rw-r--r--. 1 root root     28590 Jul 29 18:49 abrt-addon-vmcore-2.17.8-3.fc44.x86_64.rpm
-rw-r--r--. 1 root root     35753 Jul 29 18:49 abrt-addon-xorg-2.17.8-3.fc44.x86_64.rpm

On my f44 system, the packages used to upgrade from F43 have not been removed…

$ du -sh /usr/lib/sysimage/*
5.5G	/usr/lib/sysimage/libdnf5
453M	/usr/lib/sysimage/rpm

$ du -sh /usr/lib/sysimage/libdnf5/offline/
5.3G	/usr/lib/sysimage/libdnf5/offline/

$ ll /usr/lib/sysimage/libdnf5/offline/packages/ |head
total 5505056
-rw-r--r--. 1 root root   1351868 Mar 21 15:26 7zip-25.01-5.fc44.x86_64.rpm
-rw-r--r--. 1 root root    785106 Mar 21 15:26 7zip-standalone-25.01-5.fc44.x86_64.rpm
-rw-r--r--. 1 root root    210107 Mar 21 15:26 aajohan-comfortaa-fonts-3.105-0.9.20210729git2a87ac6.fc44.noarch.rpm
-rw-r--r--. 1 root root     70000 Mar 21 15:26 aalib-libs-1.4.0-0.58.rc5.fc44.x86_64.rpm
-rw-r--r--. 1 root root    906471 Mar 21 15:26 aardvark-dns-1.17.0-3.fc44.x86_64.rpm
-rw-r--r--. 1 root root    276398 Mar 21 15:26 abattis-cantarell-fonts-0.301-17.fc44.noarch.rpm
-rw-r--r--. 1 root root    123255 Mar 21 15:26 abattis-cantarell-vf-fonts-0.301-17.fc44.noarch.rpm
-rw-r--r--. 1 root root    547764 Mar 21 15:26 abrt-2.17.8-3.fc44.x86_64.rpm
-rw-r--r--. 1 root root    108090 Mar 21 15:26 abrt-addon-ccpp-2.17.8-3.fc44.x86_64.rpm

$ ll /usr/lib/sysimage/libdnf5/offline/packages/ |wc -l
3621

$ dnf history list |grep system-upgrade |head -1
1849 dnf system-upgrade download --release 2026-03-21 15:20:32              7052

$ sudo dnf system-upgrade clean  

so that later release must then be f44 because when you do the download for upgrading 44 to 45 it will use /var/lib/dnf.

O.K.

I remeber that, “/var/lib/dnf/system-upgrade” was changed to /usr/? (Fedora 44). I don’t know why, but ln -s is still working. Yes, it is workaround, but…

That date indicates it was upgraded from f43 to f44 while f44 was still branched and over a month before it was released on April 28. Thus changes within the f44 release would not have taken place yet.

But you do realize that the download takes place while still running F42/43, right?

I think the reason while the files were not removed is quite simple. I may have set keepcache=1 to prevent cache from being accidentally cleared while I was resolving potential conflicts that were preventing the ugrade.

Correct, and that would explain why the info for f44 does not match what is seen on earlier versions. Which is what my comment highlights.

What you’re saying doesn’t make any sense.. You pointed out that I upgraded to F44 while in beta. How would that have changed following the general release of F44?