Hello
I have been happily running Rocky 8 for sometime on my portable as the sole OS. But every so often, I start getting issue with the root partition filling up with … stuff.
The Disk utility shows that
/dev/rl/root 75 GB — 4.8 GB free (93.6% full)
This has been stopping me installing / upgrading apps.
I don’t understand why this partition is getting filled up so quickly? Are there ways to manage this space? From what I understand, I cannot expand the root space and reduce the home size.
Since everything on your system will go to / for packages installed, best way to check it would be:
cd /
du -sh *
find the largest directories, and then cd into these and repeat the du command, to try to find out what is eating up the space and where. For example, maybe it’s installed packages under /usr or perhaps something under /var.
Obviously you can ignore /home since it’s on a separate partition.
Snap and Flatpak seem to take up a huge amount of space with God knows what. I find managing apps to be far more challenging in Linux than the more “popular” systems. Maybe there is a lazy way of managing apps?
Snap, Flatpak, SQL engines, httpd, libvirt, ABRT, rsyslogd, podman, mock, etc are applications that store “data” in /var. Some of that data are “programs”. (Quite many in a KVM VM guest image.)
A “lazy way” is to use only the programs that are (RPM) packaged and not resort to snaps, etc.
(The VMs are obviously an exception.)
IMHO, the “big data” should not be it the / filesystem. I do mount more appropriate volumes under /var
in order to separate and control each “app”.
Can’t agree more, / should only contain almost static information like /dev /root (root user home dir) and of course /etc. Linux place /sbin as a link to /usr/sbin I do not agree with that, /sbin is supposed to contain only binaries that are statically linked, but that is not true anymore, so it’s better ignore it.
root@zeno:/sbin # file pwconv
pwconv: ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, BuildID[sha1]=8a7a68385227d1cbb54ea84fb259121b9679790c, for GNU/Linux 3.2.0, stripped
I’m not a huge fan of having filesystems mounted “inside” system filesystems, ie, I don’t like to see /var/something, specially when /var comes from an internal disk and /var/something comes from a SAN LUN, it can get messy really fast and you have to make sure the mounts are done in the correct order, ie, /var is mounted before /var/something.
Personally, I use Rocky for more “political” reasons, not because I am IT master (which I certainly am not), therefore, when I installed Rocky, I used the default setup. The default setup does not seem to correspond to what is being shared above. It seems to me logical that reasonably static volumes have specific sizes whilst dynamic data like apps are elsewhere. This is certainly pertinent for desktop usage but probably less so if you are running a server that has a specific function.
So, in short, you need to know what you are doing (not particularly my case), or the setup procedure incorporates questions that will adapt the install to specific needs.
Snap and Flatpak take up way more room than I think make them worth it. It is like each app takes up nearly a whole embedded OS’s worth of disk space. Certainly try to use the “native” RPM packages for apps when you can using snap or flatpak only for apps you cannot find as RPMs. And then stick with one or the other, not both snap and flatpak.
One could also probably move /var/lib/flatpak to /home and symlink to it there. But only if the flatpak service is not running at the time.
Windows is pretty bad about this problem so I use the Windows port all the time:
Once the analysis phase is done, hover your mouse pointer over the squares that seem to be hogging space and you’ll see the path for that square in the status bar. Click a square and the matching entry in the directory tree will be highlighted.
I believe that the original reason to have /bin and /usr/bin was to have some needed programs when you had to boot in single user mode and only / was mounted. Linux mounts everything but what if /usr is damaged and needs to be fsck ?
On Solaris 2.x (at least until 2.7) the root shell was /sbin/sh and it was not recommended to change it, because /sbin/sh was linked statically and did not depend of any .so files that could be in other filesystem. If you changed that you wouldn’t have a root shell in single user mode, you had to boot from CD and live CDs were not a thing at that time.
Last week I played a bit with booting linux in single user mode just to see if I could tidy up things making /tmp, /var and /usr ext4 filesystems and freeing up space that I’ll never use in /home.
But, unless there is a way to stop systemd from running on boot I think there is no solution except booting from a live cd or usb drive. Sometimes I like to do this kind of things just for the fun, I don’t really need to do it for a desktop machine like the one I’m using.
The easy answer is that I should have used manual configuration when installing, but it was the 1st time I was using RL so I had no idea of what it was going to do and I wanted to make sure that it would detect the windows partition and installed the boot loader correctly, as I don’t trust myself to know how to do it.
I’m not criticizing the “ways of linux” just getting myself up to date. I still think that systemd was a mistake but who am I to say that.
Separate the /var/log directory onto a separate filesystem, /var may be enough, but many people place it on a separate filesystem with the same name (/var/log).
Apply logrotate policies that will control how often the logs are rolled to an archive-state (not the active log) and then configure the total quantity of logs to keep for each of those log files in question.
For some time now Linux boots into an initial RAM disk with critical utilities like fsck for all your filesystems. This replaces the old Solaris-style scheme of separate /bin and /usr/bin directories on different partitions.
If you’re using a Flash filesystem such as an SSD or a microSD, I suggest putting /usr on its own Flash partition. You can experiment with mounting it read-only to avoid wearing out the Flash. Only write-enable it when you update packages. Use a separate device for root and (optionally) var that will take all the write “damage”.
Making /usr read-only will also “harden” the system against attack, since malware would have to write-enable the partition to install any malicious material.
There is actually. Just set the init kernel parameter to /bin/bash or /bin/sh (or the shell of your choice). This tells the Linux kernel to directly boot the shell as PID 1 and completely bypasses the init system: init=/bin/bash. I have done this before when I needed to bypass systemd for troubleshooting.
