[SOLVED] Slackware hard disk usage growing and need help since not finding it in threads.

Please be kind and gentle, I've only been on Slackware since October and I've googled and scoured this site for help with my issue, but it's just not clear to me what happened and how to proceed.

Configuration: HP Laptop with linux kernel 3.10.17, Slackware 14.1 64 bit, with nouveau and e17 desktop. HD is 60GB, partitioned with 512K swap, 12 GB "/", 24 GB "/home", extended partition with 5 GB "/usr/local", 5 GB "/opt", 5 GB "/var", and 5 GB "/tmp". The Slackware install was started from a 14.0 ISO and then upgraded to 14.1 with slackpkg (AlienBob's method) and added multilib to support some WIN apps my wife needs, which will execute under WINE. I've also installed slacke17 for desktop, claws-mail which stores it's imapcache under the users /home directory. ApacheOpenOffice was built locally and installed under /opt. GNUCash was also built and installed. I attempted to build ICECAT, but it always failed because the RAM was only 512M until a week ago when I upgraded to 2 Meg.

Problem: The "/" is nearly full! I thought 8 GB was the needed amount if installing full, so I gave it extra just in case Slackware upgrades needed the space. I thought additional software would be installed in /usr/local by Slackpkg and slackbuilds, "the standards and upstream" way. That was a bad assumption on my part, because it seems Slackware isn't using /opt or /usr/local as the standards suggest ( or did I miss a environment setting that sets the install partition). I've executed df to confirm the "/" is 100% full, and I've tried using du to list the larger files, where I see a lot of cache files. I've also installed FileLight to see if there are large unused areas. I've tried Bleachbit to eliminate old cache, thumbnails, and browser cache, but it resulted in only freeing about 800Kb.

Questions,
1) What is the minimum size for a full Slackware 14.1 64 that will also have added multilib and WINE?
2) Why doesn't Slackware store non-standard binaries under /usr/local and is there a way for me to get it to do so in the future for both slackbuilds and Slackware packages, like AlienBob's chromium? I use pkgtools, slackpkg+, sbopkg mostly, which should allow me to keep track of what was added that isn't standard, right?
3) Do I proceed with a clean re-install or can I use GParted on SystemRescue CD to a) expand and move "/", b) expand swap to 2 Meg, c) shrink the /home and extended partitions to add to "/", and not ruin the boot point? Please explain, because I'm afraid if I move the "/" which has /boot then lilo won't find it? (do I have that right).
4) I wish I hadn't upgraded to 14.0 since I lost X ver 12 for my old NVIDIA card and now have to live with nouveau and lack of some power controls. I suspect that the only way back to 14.0 is to re-install fresh. Or is there another way?
5) I see that kernel 3.2.45 is now 3.2.61 at kernel.org. If I re-install but want to upgrade the kernel, do I simply install the patches from kernel.org or do I need to wait for PV to send out patches?
6) What is using the additional 4 GB of space on "/" if slackware really only needs 8GB?

I'm sorry this is long. I just feel like I'm missing something in understanding "/" space usage. I'm open to criticism of my partition scheme, but still want to know why "/" maybe growing so quickly.

Here's a counter-question, and not to sound of anything bad but...

Why are you using a quota based file system lay-out rather than a standard single partition when you have a single disk in the system?

A quota lay-out is best used for servers, distributed cloud-based systems, and systems with multiple disks with limited space. If you have a personal desktop or laptop you should only be using a single partition design for /(root), or a dual-partition scheme for /(root) + /boot only.

_My_ rule-of-thumb:
1) Do not fragment your disk (especially if it's 'small') into all the /var /opt ...
2) I always set aside 20 gigs for the root filesystem (no matter which distro I use), but I do not fragment it - everything lives under '/'
Typically, my entire root filesystem occupies some 14 gigs

ie my partition table is something like this:
sda1 - 64 megs, ext2 - 'grub' partition (master boot)
sda2 - 2 gigs, swap
sda3 - 20 gigs, 1st distro (always slackware :-)
sda4 - remainder, extended
sda5 - 20 gigs, 2nd distro
sda6 - remainder, xfs - mounted as /work, all my personal files go here (rather than /home)


If you have only 60 gigs, I would use sda4 for /work - should give some 40 gigs to work with

I'm not saying this is for everyone - it's _my_ way of working - for better or worse

I guess you could use sda4 as /home instead - my approach is really for multi-distro use ...
With only 60 gigs, you are not likely to have more than one distro on it.

Mind you - you ought to be able to pick some cheap disks - $40 for some 320 gigs? - unless, of course, you ony have an ide-interface, then they may be harder to come by. ebay is your friend!

@ReaperX7: My partition layout was based on what I found in a number of the Slackware tutorials, including PV's, on how to partition the available disk. About two months ago I had to wipe /tmp because it filled up with SBo and build packages which I found weren't necessary to keep. I also would like to protect my added applications from a system upgrade or re-installation. Lastly I understood it was better to keep /home in a separate partition for ease of backup and potential loss if volume crashed or needed recovery. I accept that it doesn't always make sense to partition a small drive, the reason are valid whether dealing with 60 GB or 60 TB IMHO. @perbh: I agree that I should look in to a large drive, which I'll do shortly. But my main question is "what is using up all the space on "/" and secondarily why isn't Slackware using the standards way for installation of non-Slackware standard packages and builds? Can you tell me why you use a grub master partition instead of lilo and a /boot?

Patrick's partitioning method is mostly aimed at people using Slackware not just as a desktop system but as a server system equally. It's a valid method, but it's not something for everyone or general usage.

Keeping /home separate is best used when dealing with a distributed disk system, such as a network file system in which /home for user /John_Smith is on a file server with a quota limit.

However with a single disk system, keeping anything separate is really not a good policy. A single partition often works best due to the fact you don't put a quota on any particular directory with a partition mounted to it.

The only reason I recommend a separate /boot partition is the fact you can disable the auto-mount for security purposes.

Here's my partitioning method (my system is GPT on BIOS):

/boot     - sda1 - Ext4 - 50 MB
bios-boot - sda2 - 1 KB
swap      - sda3 - 8 GB
/(root)   - sda4 - JFS - Remainder of disk space

Now granted if I had a UEFI system my bios-boot partition would be an ESP(ef00) partition at 512 MB.

I make it a rule to not go past 8 GB of swap space as honestly once you have more than 4 GB of RAM, you shouldn't need any more swap space than 8 GB even for software compiling.

The UEFI and BIOS-Boot are just the recommended sizes per documentation on them.

I keep /boot at 50 MB for the fact I run a Huge kernel and use Grub and other extras of Grub-2.x for aesthetic reasons.

Everything else get's dropped in /(root) on the rest of the disk so that just-in-case, I have extras in one part of the system, I don't need to micro-manage my resources.

I only listed the partition methods for completion purposes.

If you want to get a look at where the space is being used, try this alias:

alias ducks='du -xcks * | sort -rn | head -25'

Then just cd / and give it a shot. Of course it will pickup the other partitions so maybe you need to use it in the main / subdirs instead.

*Edit: of course you could do this from the install disk after mounting your HDD / partition only, then it wouldn't pick up /opt etc.

Originally Posted by dive If you want to get a look at where the space is being used, try this alias: alias ducks='du -xcks * | sort -rn | head -25' Then just cd / and give it a shot. Of course it will pickup the other partitions so maybe you need to use it in the main / subdirs instead.

Why so complicated? Try ncdu! If you have trouble with growing /tmp mainly from sbopkg, set CLEANUP in /etc/sbopkg/sbopkg.conf

CLEANUP=${CLEANUP:-YES}

which will auto-clean sources and build environment. Packages will of course still be there, but this should save some disk space.

And for the hdd partitioning, I keep have separate /boot (for multiple distributions), /home (invaluable if you have to reinstall system from scratch) and /root (everything else). But I also use LVM, so I can create new logical volume at any time (eg. for steam and wine games). Any more fragmentation on desktop is IMO pointless.
On my laptop I designated 10 GB for /root (with separate /home) and right now I have only 1 GB free. But keep in mind, that main purpose of this machine is development, therefore I have all sorts of databases, IDE's and similar tools installed and everything I need fits within 10 GB boundary.

Originally Posted by yenn Why so complicated? Try ncdu!

Mine doesn't count dotfiles/dirs. I have a separate alias that only checks dotfiles/dirs.

Originally Posted by bamunds 2) Why doesn't Slackware store non-standard binaries under /usr/local and is there a way for me to get it to do so in the future for both slackbuilds and Slackware packages, like AlienBob's chromium? I use pkgtools, slackpkg+, sbopkg mostly, which should allow me to keep track of what was added that isn't standard, right?

If you want to keep track of your non-Slackware packages, just do 'ls /var/log/packages | grep -v '[0-9]$'. If you want to know what files are in package x, just do 'cat /var/log/packages/x'. If you want to know what package file y is in, just do 'grep y /var/log/packages/*'.

Frankly, the wording of the recommendation about /usr/local is one of the more boneheaded parts of the FHS. The rationale in the FHS is all about protecting stuff in /usr/local from upgrades, but with proper package management that is a solved problem.

The really difficult problem is non-package-managed stuff. Specifically, the really difficult problem is *removing* non-package-managed stuff, and there are threads here on LQ all the time where people have made an incontinent mess of their systems by manually installing stuff that doesn't work or conflicts. Sysadmins have known the answer for years: package-managed stuff goes in /usr, and non-package-managed stuff goes in /usr/local, or even /opt/local, and to hell with the FHS. And if someone has totally lost track of their manually installed shit, just blow away /usr/local.

The FHS also mandates /usr/share/man, and Slackware ignores that too

Even if you were to make extensive use of /usr/local and /opt, there is no need to have them as separate partitions, and you lose a lot of flexibility (and gigabytes) if you do.

The FHS is more of a guideline, but not a rule. There is even D.J. Bernstein's proposal of Slash-Packaging as well.

FHS works, and can help with some implementations, but it's not a law.

Originally Posted by ReaperX7 Here's a counter-question, and not to sound of anything bad but... Why are you using a quota based file system lay-out rather than a standard single partition when you have a single disk in the system? A quota lay-out is best used for servers, distributed cloud-based systems, and systems with multiple disks with limited space. If you have a personal desktop or laptop you should only be using a single partition design for /(root), or a dual-partition scheme for /(root) + /boot only.

My desktop system:

$ df -h
Filesystem                      Size  Used Avail Use% Mounted on
/dev/mapper/mdgroup-rootlv      4.0G  1.5G  2.6G  37% /
/dev/md0                        496M   43M  428M  10% /boot
/dev/mapper/mdgroup-qemulv       47G   29G   19G  62% /spare/1
/dev/mapper/mdgroup-archstore   4.0G  2.7G  1.1G  72% /spare/5
/dev/mapper/mdgroup-extraslv    4.5G  4.0G  546M  89% /extras
/dev/mapper/mdgroup-home         55G   46G  8.6G  85% /home
/dev/mapper/mdgroup-varlv       8.0G  4.9G  3.2G  61% /var
/dev/mapper/mdgroup-spare3lv     67G   61G  7.0G  90% /spare/3
/dev/mapper/mdgroup-java         13G   12G  1.2G  91% /spare/4
/dev/mapper/mdgroup-xconqlv     4.0G  496M  3.6G  13% /var/mcp
/dev/mapper/mdgroup-slaptlv     4.5G  451M  4.1G  10% /var/slapt-get
/dev/mapper/mdgroup-tmplv       8.0G  4.5G  3.6G  56% /var/tmp
/dev/mapper/mdgroup-newhomelv    10G  8.6G  1.5G  86% /newhome
/dev/mapper/mdgroup-newroot      30G   26G  4.0G  87% /newroot
/dev/mapper/mdgroup-opt         8.5G  3.6G  5.0G  42% /opt
/dev/mapper/mdgroup-newmusiclv   17G   16G  1.3G  93% /opt/music
/dev/mapper/mdgroup-sourcelv     27G   17G   11G  62% /source
/dev/mapper/mdgroup-usr          16G   15G  1.1G  94% /usr
/dev/mapper/mdgroup-usrlocal    2.4G  1.8G  626M  75% /usr/local
/dev/mapper/mdgroup-winimage     30G   25G  3.4G  88% /usr/local/winimage
/dev/mapper/mdgroup-libvirtlv   191G   50G  142G  26% /var/lib/libvirt
/dev/mapper/mdgroup-pgsqllv     2.0G   75M  2.0G   4% /var/lib/pgsql
/dev/mapper/mdgroup-mongostore   10G  529M  9.5G   6% /var/lib/mongodb
/dev/mapper/mdgroup-tacllv      2.0G  1.3G  613M  68% /mnt/backups
tmpfs                           7.9G     0  7.9G   0% /dev/shm
tmpfs                           7.9G   12K  7.9G   1% /tmp

Let's just say that I disagree. My laptop (one disk) has a similar setup, at least as far as using lvm and having logical volumes for /, /home, /usr, /usr/local, /var, /var/tmp, and /opt.

Originally Posted by Richard Cranium Let's just say that I disagree. My laptop (one disk) has a similar setup, at least as far as using lvm and having logical volumes for /, /home, /usr, /usr/local, /var, /var/tmp, and /opt.

Me too.

root@ws1:~# lsblk
NAME                      MAJ:MIN RM   SIZE RO TYPE  MOUNTPOINT
sda                         8:0    0 931.5G  0 disk  
|-sda1                      8:1    0    36G  0 part  /maint
|-sda2                      8:2    0   124G  0 part  
|-sda3                      8:3    0 146.4G  0 part  
`-sda4                      8:4    0 625.1G  0 part  
  |-rootvg-lvroot (dm-0)  253:0    0    16G  0 lvm   /
  |-rootvg-lvvar (dm-1)   253:1    0    16G  0 lvm   /var
  |-rootvg-lvhome (dm-2)  253:2    0     8G  0 lvm   /home
  |-rootvg-lvlocal (dm-3) 253:3    0    96G  0 lvm   /srv/local
  |-rootvg-lvcrypt (dm-4) 253:4    0    16G  0 lvm   
  | `-crypt (dm-7)        253:7    0    16G  0 crypt /srv/crypt
  |-rootvg-lvswap0 (dm-5) 253:5    0     4G  0 lvm   
  `-rootvg-lvsrc (dm-6)   253:6    0     8G  0 lvm   /usr/src
sr0                        11:0    1  1024M  0 rom

I don't see the point in having separate /usr, /opt, and /usr/local these days, but I still like to separate other things out.


On the subject of /usr/local: On a traditional/commercial UNIX system, there's a clear distinction between things that belong with the OS, and things that are add-ons, so it makes sense to separate the add-ons into a separate /usr/local hierarchy. Given that a linux system is just a collection of parts thrown together, there really is no clear distinction between OS and add-ons, and there is little value in keeping things separate.

Personally, I use /usr/local for truly local stuff: i.e. admin scripts and suchlike that I've written to make my life easier. Any add-on software that I think is standalone enough to make sense splitting out, I install to /opt. Having said that, both /opt and /usr/local I keep in the rootfs. If I ever need to reformat the rootfs, its easy enough just to tar them up.



@bamunds

Non destructively extending a filesystem in-place is usually possible, assuming you can make some free-space directly after it. Moving the start of the rootfs is much higher risk, and will almost certainly require you to reinstall the bootloader.

If you've got a spare disk, then backup, repartition, restore might be an option, but again, you're probably going to end up having to reinstall the bootloader to get it to boot.

Sometimes you just find that you've painted yourself into a corner and its actually going to be less effort to start-over.

Can't believe how helpful people are here. The guy asks a question and gets back loads of criticism for doing what he thought was right.

Anyway, Bamunds. I'll try and help, but you're going to need to do some heavy duty reading to achieve this and not guaranteeing how successfull this will be.

If it was me, I'd be booting from some live CD. Loads of them to choose from. Then on original installation, copy /tmp to an external drive of some sort, then remove it (/tmp) from fstab. Grow / by the 5Gb this frees then copy /tmp back to the now expanded /

Then rinse and repeat for /var /opt and /usr/local

Eventually leaving just root, home and swap partitions in fstab

You should now have just 3 partitions left. Your 512Kb Swap, 24Gb /home and the remainding 36Gb (give or take) as /

No promises though and this might just screw your drive up completely.

Good luck with it if you try.

Originally Posted by vdemuth Can't believe how helpful people are here. The guy asks a question and gets back loads of criticism for doing what he thought was right.

What are you talking about? The only thing that came close to criticism was Reaper asking why he hadn't used a simpler filesystem layout, and expressing his opinion that a single partition is the way to go, and both myself and Richard posted to say we didn't agree with that viewpoint.

Originally Posted by vdemuth If it was me, I'd be booting from some live CD. Loads of them to choose from. Then on original installation, copy /tmp to an external drive of some sort, then remove it (/tmp) from fstab. Grow / by the 5Gb this frees then copy /tmp back to the now expanded /

I saw no detail to say that the disk was laid out in a way that would support that. In fact, if the order in which he listed them in his initial posting is how they are on disk then it will look something like this:
sda1 swap
sda2 12G /
sda3 24G /home
sda4 ext partition containing:
- sda5 5G /usr/local
- sda6 5G /opt
- sda7 5G /var
- sda8 5G /tmp

...and deleting /tmp, /opt and /var will not allow him to extend the rootfs in the manner you describe, because /home is stuck between them. If the above is how it actually is, then he's going to have to do something with the /home partition to free up space to extend the rootfs.

I've painted myself into a corner like this before and while you can sometimes wiggle your way out of it, it can be a lot of messing, and booting from a live cd and doing a complete file backup, repartition, restore, can be the best option. If you're comfortable with the command line the slackware install-cd makes a nice rescue environment, and you can also use it to restore the bootloader once you've moved everything around by entering a chroot environment.

Originally Posted by GazL What are you talking about? The only thing that came close to criticism was Reaper asking why he hadn't used a simpler filesystem layout, and expressing his opinion that a single partition is the way to go, and both myself and Richard posted to say we didn't agree with that viewpoint. I saw no detail to say that the disk was laid out in a way that would support that. In fact, if the order in which he listed them in his initial posting is how they are on disk then it will look something like this: sda1 swap sda2 12G / sda3 24G /home sda4 ext partition containing: - sda5 5G /usr/local - sda6 5G /opt - sda7 5G /var - sda8 5G /tmp .

With respect, that is just an assumption on your part. You might be right, you might not be. Maybe if the OP could give some better info, that would help.
And as I said, he's looking for help. You know. That constructive way in which ideas can be forwarded to try out, even if they turn out to not be quite what are needed. But everything needs a starting point.

So as I said, the guy asked for help, so maybe instead of critcism as per Reaper, or telling him how you wouldn't have chosen that particular disk layout, how about something constructive the guy can work with rather than just

"Sometimes you just find that you've painted yourself into a corner and its actually going to be less effort to start-over"

That may be the case, but do you learn from it?

You know, my idea might not work, hell, it probably wont, but at least it's something.
I always thought that anything was possible with Slackware without re-installing. Are you now saying that's not the case?