PDA

View Full Version : Fedora 25 to 26 space needed on the / filesystem - move or delete packages



MrNice
2nd December 2017, 03:01 PM
Hi there,
I run Fedora 25 and I tried upgrade to 26.
I came across the error

Disk Requirements:
At least 2072MB more space needed on the / filesystem.

So df says

Filesystem 1M-blocks Used Available Use% Mounted on
devtmpfs 3958 0 3958 0% /dev
tmpfs 3969 69 3901 2% /dev/shm
tmpfs 3969 10 3959 1% /run
tmpfs 3969 0 3969 0% /sys/fs/cgroup
/dev/sda2 19559 17509 1035 95% /
tmpfs 3969 1 3968 1% /tmp
none 397 10 388 3% /var/log
/dev/sda1 100 10 91 10% /boot/efi
/dev/sda3 100275 37414 57745 40% /home
/dev/sdc1 3754552 574879 2988885 17% /St2
/dev/sdb 2816557 1034649 1638813 39% /St1
tmpfs 794 1 794 1% /run/user/1000

/dev/sda2 is almost full. I have this install for few years, few upgrades, less space.
I tried to clean the HD with "dnf clean all" but not enough space collected.
I tried as well with Bleachbit unsuccessfully.
The gap looks too wide.
I see 2 options:
1-Find a way to move the v26 packages from to /home and upgrade
2-Keep v25 for now but I need to delete all the v26 packages. I'll see later to resize the / dir.
In both cases, I don't know how to manage (move or delete) with the v26 packages.

Could someone help me, maybe you have a better idea, just I don't have a lot of time right now for a full reinstall.
Thanks for you help
Edit: v26 packages from /var/lib/dnf/system-upgrade to /home (it take 3.5GB)

donatom
2nd December 2017, 05:12 PM
This should help: https://forums.fedoraforum.org/showthread.php?316276-No-space-in-filesystem-for-upgrade

Note: follow both steps in comment #2 (digititus) -- in other words make sure you do this as well as the "sudo journalctl --vacuum-size 100M":
Also check in /var/cache/PackageKit for older distribution cached packages and remove them.

MrNice
2nd December 2017, 05:38 PM
Thank for you help
Unfortunately, this didn't help.
I did the commands and got "Vacuuming done, freed 0B of archived journals on disk."
Moreover /var/cache/PackageKit is empty.

Any other suggestion?

donatom
2nd December 2017, 07:25 PM
I noticed you had a similar problem in 2016 https://forums.fedoraforum.org/showthread.php?310662-Upgrade-to-F24-error-dur-to-HD-space In this thread antikythera (comment #2) recommends that you remove some larger programs (libreoffice, etc) and then reinstall after the upgrade. In any case, 20 gigs for the root directory leaves you little room for manipulating data, etc.

On another note, there may be a large, unnecessary file in root. Have you run "sudo find / -xdev -type f -size +100M". If you see large files that you might not need, google them and, if possible, delete them to free up more space. I found the find command at:
https://unix.stackexchange.com/questions/140367/finding-all-large-files-in-the-root-filesystem

donatom
2nd December 2017, 07:35 PM
I did the commands and got "Vacuuming done, freed 0B of archived journals on disk."

That seems strange; I just ran "sudo journalctl --vacuum-size 100M" on my system and it shaved 500M off of journalctl.

MrNice
2nd December 2017, 08:12 PM
sudo find / -xdev -type f -size +100M
/root/.cache/tmpCxgZkcS6iGf0Vdra9fLfrg7LWlJKHTXVFalFQt8UdC0tkBW SI.ctgEVjAhoDLLPCLLeG35.Hhder1hYKaVP7hSsw8BVhJr4Fk 8uhz1b3U.ZkWT0i0GHUvHuWvZxVAM3TIJCWXYS5MOWB2RNSuGU OWzdDZmnGLKImXYl3AJj7LqE6051OWhkbo1Rc740kx-yE4llr_2-rVd.iPpD7gErOvQ_8.4cjSNTwi7wOrhd8UJ7OKY01USOzVB6
/var/cache/yum/x86_64/24/fedora/gen/primary_db.sqlite
/var/cache/yum/x86_64/23/fedora/gen/primary_db.sqlite
/var/spool/abrt/ccpp-2015-10-31-12:51:45-1083/coredump
/var/lib/rpm/Packages
/var/lib/mlocate/mlocate.db
/var/lib/dnf/system-upgrade/f26-backgrounds-animated-26.2.7-2.fc26.noarch.rpm
/var/lib/dnf/system-upgrade/fluid-soundfont-gm-3.1-16.fc26.noarch.rpm
/usr/lib/locale/locale-archive
/usr/share/soundfonts/FluidR3_GM.sf2

What Can I delete? How?
File number= size around
1= 1182Mb
2=128Mb
3=116Mb
4=219Mb
5=213Mb
6=110Mb
7=111Mb
8=148Mb

@ donatom, I did a clean previously with BleachBit, I'd guess it deleted journalctl

marko
2nd December 2017, 08:51 PM
Try this:


du-k --max-depth 1 / | sort -rn | head

The directory at the top of that list is the biggest, then drill down into that one by changing the "/" in the command above to that directory.
That will help you find the big files so you can decide if they are deleteable. You can also run:


tune2fs -m 1 /dev/sda2

that would reduce the reserved block amount on /dev/sda2 (which is / ) from the default ext reserve block % of 5 to 1, giving you back 4% of 20GB back or about 800 MB
That's assuming that's a ext3,4 style partition

donatom
2nd December 2017, 09:10 PM
I did a clean previously with BleachBit, I'd guess it deleted journalctl

That definitely explains why vacuum was not able to get rid of some to the journalctl log.

As far as the large files, I would back up your root partition (maybe with rsync) and after a google search you should be able to delete file number 2 and file number 3 (they are data bases for Fedora 23 and 24) and perhaps file number one (some sort of tmp file cache). I believe that you could delete the mlocate.db file (the file will be regenerated at reboot so it wouldn't be a permanent gain in space).

Hopefully other members will chime in about deleting large files so you get other opinions from people who are more knowledgeable than I.

Another possibility would be to copy / and /home onto another (larger) drive with dd. You would have to change fstab file and install/update grub -- if you have the time (and the harddrive) right now to do so.

marko
2nd December 2017, 09:23 PM
dnf clean all

may not get all you expect, try


dnf clean all --enablerepo=\*

because 'dnf clean all' doesn't clean disabled repos

for example on my 'asus' host


root@asus:~]$ du -k --max-depth 1 /var/cache/dnf |sort -rn
182308 /var/cache/dnf
51700 /var/cache/dnf/fedora-310f9d37d74ceec1
24500 /var/cache/dnf/updates-87ad44ec2dc11249
2236 /var/cache/dnf/updates-testing-f6c979a199285acf
544 /var/cache/dnf/rpmfusion-free-3b0384c58ed34d8e
492 /var/cache/dnf/rpmfusion-free-updates-8b261166f7b8f005
172 /var/cache/dnf/rpmfusion-nonfree-462046750e16364a
92 /var/cache/dnf/rpmfusion-nonfree-updates-677591191b2372ce
84 /var/cache/dnf/virtualbox-3e349fb2cec88222
60 /var/cache/dnf/slack-1ee9c41fbc29791b
40 /var/cache/dnf/mongodb-651b79f0c09ee67d
32 /var/cache/dnf/adobe-linux-x86_64-38ad0a49b0acdf73
8 /var/cache/dnf/updates-2854b3113b7a3c6c
8 /var/cache/dnf/rpmfusion-nonfree-updates-3a121f680572bc84
8 /var/cache/dnf/rpmfusion-nonfree-d8e2099596b5b756
8 /var/cache/dnf/rpmfusion-free-updates-326d941b38a63deb
8 /var/cache/dnf/rpmfusion-free-bc396e189901306c
8 /var/cache/dnf/fedora-6dbd63560daef6bf


dnf clean all --enablerepo=\*
78 files removed


root@asus:~]$ du -k --max-depth 1 /var/cache/dnf |sort -rn
8408 /var/cache/dnf
36 /var/cache/dnf/updates-87ad44ec2dc11249
12 /var/cache/dnf/updates-testing-f6c979a199285acf
12 /var/cache/dnf/slack-1ee9c41fbc29791b
12 /var/cache/dnf/rpmfusion-nonfree-updates-677591191b2372ce
12 /var/cache/dnf/rpmfusion-free-updates-8b261166f7b8f005
12 /var/cache/dnf/mongodb-651b79f0c09ee67d
12 /var/cache/dnf/fedora-310f9d37d74ceec1
12 /var/cache/dnf/adobe-linux-x86_64-38ad0a49b0acdf73
8 /var/cache/dnf/virtualbox-3e349fb2cec88222
8 /var/cache/dnf/updates-2854b3113b7a3c6c
8 /var/cache/dnf/rpmfusion-nonfree-updates-3a121f680572bc84
8 /var/cache/dnf/rpmfusion-nonfree-d8e2099596b5b756
8 /var/cache/dnf/rpmfusion-nonfree-462046750e16364a
8 /var/cache/dnf/rpmfusion-free-updates-326d941b38a63deb
8 /var/cache/dnf/rpmfusion-free-bc396e189901306c
8 /var/cache/dnf/rpmfusion-free-3b0384c58ed34d8e
8 /var/cache/dnf/fedora-6dbd63560daef6bf


or 8.5 MB instead of 182 MB

Mark

William Haller
2nd December 2017, 09:33 PM
You could also upgrade in stages. For example, just doing a dnf upgrade of rpm will upgrade a bunch of packages. You could then try upgrading another package group like the workstation desktop or the like. This would prevent having as large a area committed to the new .rpm files until the old ones could be deleted.

MrNice
2nd December 2017, 10:26 PM
@marko,
The first is not a dir, this is a file

-rw-------. 1 root root 1182251400 Jul 8 2016 tmpCxgZkcS6iGf0....
I need at least 2.1 GB so 800M is not enough

@ William
I did

dnf clean all --enablerepo=\*
I got few hundred MB but not enough.

The only solutions are
1- To move /var/lib/dnf/system-upgrade to /home (it take 3.5GB)
2- To delete all the v26 downloaded packages and see later
The second should be the easier. How to do it in a clean, smart way?
I can't find any info about it. Can I just delete all inside the directory?

MrNice
3rd December 2017, 01:07 PM
So, I deleted all the files inside the dir /var/lib/dnf/system-upgrade with rm. I have now

/dev/sda2 19559 13801 4742 75% /
or
/dev/sda2 20G 14G 4.7G 75% /

Restarted, it seems to run well.
I'll think on what to do now, maybe resize the / partition with parted or reinstall from scratch.
BTW, dnf have an option to download the upgrade packages in another place

--downloaddir=<path>
Redirect downloaded packages to provided directory. The option has to by [be?] used together with --downloadonly command line option or with download command (dnf-plugins-core).
from man

Thank you all of you for your help

marko
3rd December 2017, 04:20 PM
In the future if this happens you can remove all the yum stuff too rm -fr /var/cache/yum/*
and mlocate.db since that can be regenerated easily. The yum cache /var/cache/yum only gets files put in if you force the system back to yum with yum-deprecated. All you'd lose is some yum history related only to those transactions.