Upgrading to F39 from F38 dnf errors out due to space


Problem when installing F39 while on F38. Running out of install space.

dnf seems to have downloaded the packages? but install cannot proceed due to lack of space on the “/” filesystem.
Whats the best way to proceed from this error?
Below, I have included space on different drives.

*) Is there a way to tell dnf to use a different part of the filesystem other than “/” to use for installs?? this sounds like the easiest way to proceed.

(not sure what --installroot=path does?)

*) I could start deleting packages like maven, mono, … which seems
like a tedious project. This involves going through a list of
installed packages and trying to figure out what I need to delete or

*) Also include below is the contents of /root/rpmbuild directory
which somehow has been left behind.


$ sudo dnf system-upgrade download --releasever=39 --skip-broken --allowerasing

  installing package fedora-chromium-config-gssapi-3.0-2.fc39.noarch needs 1449MB more space on the / filesystem
  installing package fedora-bookmarks-28-28.fc39.noarch needs 1449MB more space on the / filesystem
  installing package comps-extras-24-14.fc39.noarch needs 1449MB more space on the / filesystem
  installing package atmel-firmware-1.3-30.fc39.noarch needs 1449MB more space on the / filesystem

Error Summary
Disk Requirements:
   At least 1554MB more space needed on the / filesystem.


$ lsblk
sda      8:0    0 698.6G  0 disk 
├─sda1   8:1    0 317.5G  0 part 
├─sda2   8:2    0   548M  0 part 
├─sda3   8:3    0     1K  0 part 
└─sda5   8:5    0 380.6G  0 part 
sdb      8:16   0 465.8G  0 disk 
├─sdb1   8:17   0   476M  0 part /boot
├─sdb2   8:18   0 372.5G  0 part /home
├─sdb3   8:19   0  18.6G  0 part /
├─sdb4   8:20   0     1K  0 part 
├─sdb5   8:21   0  18.6G  0 part /var
└─sdb6   8:22   0  16.8G  0 part [SWAP]
sr0     11:0    1  1024M  0 rom  
zram0  252:0    0     8G  0 disk [SWAP]


$ sudo du -d 1 -x /
4	/mnt
4	/srv
14223640	/usr
16	/lost+found
4	/media
4	/.cache
697576	/opt
46596	/etc
60428	/root
4	/afs
15028280	/


$ sudo du -d 1 -x /home
24800	/home/svn-repo
16	/home/lost+found
12244	/home/eoms
12848	/home/referenceData
779624	/home/3plibs
19796	/home/3plibs-test
1818624	/home/3pbin
4	/home/downloads
9225600	/home/sunil
5548528	/home/eomsdev
263988	/home/backups
17706076	/home


 sudo du -d 1 -x /usr
5208116	/usr/lib64
1160	/usr/i686-w64-mingw32
5562724	/usr/share
195524	/usr/libexec
1160	/usr/x86_64-w64-mingw32
61592	/usr/include
4	/usr/games
809360	/usr/bin
286408	/usr/local
1767696	/usr/lib
4	/usr/etc
95168	/usr/sbin
234720	/usr/src
14223640	/usr


I tried installing padre a long time ago. Not sure why these files
still remain??
*) Any issue with me just deleting this directory: /root/rpmbuild?

ls -lR /root/rpmbuild
total 8
drwxr-xr-x. 2 root root 4096 Nov 22  2017 SOURCES
drwxr-xr-x. 2 root root 4096 Nov 22  2017 SPECS

total 1688
-rw-r--r--. 1 root root    1634 Feb 11  2017 Padre-0.90-Change-synchronous-SQLite-level-before-opening-trans.patch
-rw-r--r--. 1 root root    1314 Feb 11  2017 Padre-0.90-Disable-Test-NoWarnings-t-01-load.t-tests.patch
-rw-r--r--. 1 root root   10231 Feb 11  2017 Padre-0.90-Migrating-to-the-delete_where-method-for-bulk-deleti.patch
-rw-r--r--. 1 root root     987 Feb 11  2017 Padre-0.90-No-exit-in-Pod-Perldoc.patch
-rw-rw-r--. 1 root root 1690985 Aug 29  2011 Padre-0.90.tar.gz
-rw-r--r--. 1 root root    1376 Feb 11  2017 Padre-0.90-The-text-of-the-error-has-changed-in-perl-5.21.4.-RT.patch
-rw-r--r--. 1 root root    1061 Feb 11  2017 Padre-1.00-eliminate-precedence-issue.patch
-rw-r--r--. 1 root root     261 Feb 11  2017 padre.desktop

total 28
-rw-r--r--. 1 root root 24742 Feb 11  2017 perl-Padre.spec


Make sure you have good backups (installs stress filesystems, so disk failures are more likely). It is good practice to clean out old data before upgrading.

Once you are well prepared, you could free up space in / with sudo mv /opt /home/ and create a symbolic link: ln -s /home/opt /opt.

If you are using a btrfs file system moving /opt would have no effect.
We could see the filesystem types and available space with the output of lsblk -f and df

Please try and post all text you copy & paste using the preformatted text tags with the </> button or by enclosing the text within triple backquotes like this.
paste your text here
Using this method will retain on-screen formatting and make things much more readable.

Nope, its ext4 type filesystem for linux as shown below.
Ive moved /opt to /home/opt so help with the space as suggested by gnwiii above. with a symlink ofcourse. Not enough space reclaimed though.

├─sda1 ntfs         OS    762272DA22729EB5                                    
├─sda2 ntfs               F036E2AB36E271D0                                    
└─sda5 ntfs         data  34D82C97D82C58FE                                    
├─sdb1 ext4   1.0   boot  ef81cf0b-79be-4a78-b7c3-0624d3556628  163.2M    58% /boot
├─sdb2 ext4   1.0   home  3839de2b-44a3-4f6a-a859-8bac6e277e82  330.3G     5% /home
├─sdb3 ext4   1.0   root  f5403316-c46f-4600-a099-956f50b83e79    3.7G    74% /
├─sdb5 ext4   1.0         26e684b7-4c86-40f0-a97d-2a4bc5900486    5.7G    63% /var
└─sdb6 swap   1     swap  236303c5-9fa9-4c9d-b732-6887a8f41712                [SWAP]
zram0                                                                         [SWAP]


George, did as you suggested by moving the /opt to /home/opt and created the symlink.
I guess you are saying that the symlink should not be a problem for linux working.
Do you know if its safe to move /var as well too? But one step at a time.
I’ll try to reboot and see how it goes with the /opt move.


You can remove this, but it won’t give you much.

It can be used if you for example boot the live system and uses the dnf from the live system to install packages on the real root file system. This is can be useful if the dnf on the real root file system is damaged and can’t be used. It is not relevant to your problem.

1 Like

Not much at all. But trying to save whatever space I can to get this upgrade to 39 proceeding. And this directory seems to just contain useless data including a tarball left behind probably from a botched install.

Check your lost+found directories:

$ sudo du -sm /lost+found /boot/lost+found
0       /lost+found
1       /boot/lost+found

I assume you started with a much older (and smaller) version of Fedora.
There are advantages to staying close to the current default configuration as more people will be familiar with it and can help when you have problems. Consider backing up important files (e.g., 2 copies of /home on USB media) , making notes of changes from the default configuration, and doing a fresh install of Fedora.

Nothing in either of those directories: /lost+found and /boot/lost+found.

Yes, but what gives you the indication that i’ve been upgrading fedora since the betamax video player?

Interesting point though, I have been updating fedora versions for a long time. I have quite a few libraries built and needed, so going full install would be tedious.
I had thought of upgrades of fedora versions to be equivalent (mostly?) to a fresh install.
But your suggestion makes sense. Time to wipe the partition and do a full install.

*) btw, how often do you do a full install of fedora vs upgrades?


merge all this into one partition (/), and then reinstall FEdora. Make sure to have backups and don’t reformat your /home partition

Using a very small ext4 root partition suggests a Fedora install from the days when 80GB drives were common.

Before retiring I maintained some software that was originally developed on a CDC Cyber and used by a user base numbering maybe a few hundred people mostly in university and government labs that mandated the OS versions they could use. Replacing orphaned libraries with currently maintained and widely available libraries was a challenge.

It is time for a fresh install when libraries I use are no longer available across major distros (Ubuntu, RHEL, SUSE, debian) or when Fedora has made significant (and widely adopted) changes (e.g., btrfs) to the default configuration.

1 Like

This line tells me you only have aproximately 10G in the root partition and I see about another 10G in the /var partition and maybe 300M in /boot. Those sizes are extremely small for the current releases of fedora which by default uses 1G for /boot and realistically needs 20G plus (50G or larger is much better) for the root (/) partition.

The suggestion to reinstall seems very wise to me.

The drive where fedora is installed (sdb) shows as 465G total. Note that if space is limited and you are using 330G for /home it may not allow sufficient space for the main OS(but should be adequate if handled properly). I would suggest that you reinstall, and in the process remove /, /boot, /var, and SWAP then reinstall while retaining /home. This should allow ~120G for the system. SWAP is not normally needed on the drive, and has not been used by fedora in that way for several years since ZRAM is now used for swap.

I guess I’m going to have to do a full clean install every few versions.

Interesting. I remember the days when 10G was more than adequate for the root partition according to fedoras own patitioning scheme.

Nice suggestions though. I could siphon about 30-40G from the /home partition and allocate to the root partition (which would also include /boot, /opt AND /var).

You are saying that ~50G is good enough for the root partition then? hope so. Thats a massive change from way past fedoras.

Ideally I should just wipe out ntfs and use entire 750G drive for linux to make life simpler, but thats the next step in the coming weeks.

1 Like

Has been quite some time since that was recommended, but certainly was valid several years back.