# Safe way to free up space in /usr?

## ExecutorElassus

okay, bear with me. I know the /usr directory is super-risky to run around in deleting stuff willy-nilly. That's why I'm asking.

I have /usr on a 10GB partition, with /usr/portage, /usr/portage/distfiles and /var/tmp (to which /usr/tmp links) on separate partitions. However, /usr keeps gradually fililng up. The only thing I know for sure I can delete safely are the old kernels (that is, /usr/src/linux-2.6.3*-gentoo*, etc), and those only free up a little bit of space.

Are there other options for things that I can safely delete from /usr? Will installing multible library packages gradually fill up /usr/lib64 with old, unneeded versions of libraries? Does 'emerge --prune' clear anything there out safely (and is it relatively straightforward to use?)? 

I'd rather not have to keep adding space on /usr every six months or so, since that seems to be a poor way to run a system.

Thanks in advance for the help.

EE

----------

## leifbk

I've used up 9.1 GB of my 40 GB /usr partition on a fairly stuffed workstation, and that includes /usr/portage as well. I wouldn't recommend less than 15 GB on /usr on a modern system.

The one thing that's really efficient, is to run eclean -d distfiles regularly. That will clean out obsolete tarballs from /usr/portage/distfiles. And of course, do a rm -r on every directory in /usr/src/ that doesn't contain active kernel stuff.

----------

## Hu

 *ExecutorElassus wrote:*   

> I have /usr on a 10GB partition, with /usr/portage, /usr/portage/distfiles and /var/tmp (to which /usr/tmp links) on separate partitions. However, /usr keeps gradually fililng up. The only thing I know for sure I can delete safely are the old kernels (that is, /usr/src/linux-2.6.3*-gentoo*, etc), and those only free up a little bit of space.

 I have a 12GB /usr, but I can usually keep it below 10GB used, even with distfiles and packages on /usr.  You said you moved distfiles, so you should be using even less space than I am.  Would you mind posting (preferably to a pastebin) the output of du -k --one-file-system --max-depth=3 /usr?

 *ExecutorElassus wrote:*   

> Are there other options for things that I can safely delete from /usr? Will installing multible library packages gradually fill up /usr/lib64 with old, unneeded versions of libraries? Does 'emerge --prune' clear anything there out safely (and is it relatively straightforward to use?)?

 Slotted packages will coexist, and could use up space unnecessarily.  Non-slotted packages will automatically be removed as newer versions are installed, so there should be few unneeded libraries in /usr/lib64.  I would not recommend emerge --prune until you have reviewed its plans and decided that its proposed removals are appropriate to your system.  You might find emerge --depclean useful as a more cautious version, but even that should be manually checked before you allow it to start removing packages.

 *leifbk wrote:*   

> The one thing that's really efficient, is to run eclean -d distfiles regularly. That will clean out obsolete tarballs from /usr/portage/distfiles.

 This is good advice in general, but the OP already indicated that he has distfiles on a separate volume, so it will not help him here. *leifbk wrote:*   

> And of course, do a rm -r on every directory in /usr/src/ that doesn't contain active kernel stuff.

 To be clear, you should first emerge --unmerge sys-kernel/sources-package each unwanted kernel in /usr/src, so that the package manager cleans it out.  If you have done an out-of-tree kernel build, the package manager will remove the /usr/src/sources-package directory as well.  If you did an in-tree kernel build, then there will be unowned files littering /usr/src/sources-package, so the package manager will not remove it.  However, per the suggestion from leifbk, it is safe to manually remove those unowned files.

----------

## nordic bro

I don't use gnome/kde but presumably you do?  I sure hope so  :Smile:  because my / is 5G w/1.5G of it free - that's pretty much every typical / dir except for /home, portage, /usr/src and /boot.

if you're not leaving src dirs unclean or uncompressed then I don't think there's a lot of things to check in /usr except share and local (presuming portage is indeed on a separate partition).  if you du /usr/share/docs you may see it's chewing up a lot of space - make sure everything there is compressed or move it to another partition and link back.

you'd also find things with "du --max-depth=1" in /usr/share that don't need to be uncompressed.  obv I'd only do this for standalone or known apps or things I'm reasonably sure aren't going to cause widespread trouble but I'd only focus on dirs du says are large, not a bunch of relatively tiny ones.

I'm not sure how much it would help you but I'd also run localepurge which is a pkg to routinely delete locale files you don't need which can free up a fair amount of otherwise wasted space.  for some reason "./configure --disable-nls" and I think the -nls use flag often still allow unneeded locale files to get installed so you could have more there than you think.

wrt distfiles no matter where you have it living, I don't do a ton of syncing so invariably what can happen if you delete from distfiles is that you want to re-emerge something but emerge can no longer find the tar on internet.  sometimes you can google for it but many times you're just sol or have to work very hard to get emerge to accept your substitute.

so in distfiles I isolate tars for major pkgs I have and preserve them - the only things I delete are things I'm at least 99% I don't need or care about.Last edited by nordic bro on Sun Mar 20, 2011 8:01 pm; edited 1 time in total

----------

## ExecutorElassus

well, let me post the full output to a pastebin for you. For now, here's the short version:

```
# du -k --one-file-system -h --max-depth=1 /usr

500M    /usr/lib32

56M     /usr/libexec

1.2G    /usr/src

18M     /usr/sbin

2.2G    /usr/lib64

4.9M    /usr/games

3.0G    /usr/share

5.0K    /usr/portage

24K     /usr/qt

6.1M    /usr/x86_64-pc-linux-gnu

52M     /usr/local

228K    /usr/imports

16K     /usr/lost+found

1.1M    /usr/kde

251M    /usr/include

370M    /usr/bin

4.0K    /usr/tmp-domo-kun

7.5G    /usr

```

for those of you with time on your hands, and interest (?), here's the full output:

http://pastebin.com/0gQ4RTaT

let me know if anything pops out at you.

Thanks!

EE

----------

## NeddySeagoon

ExecutorElassus,

```
3.0G    /usr/share 
```

/usr/share contains lots of documents, that you may decide you can do without, and lots of default settings that you must keep.

Does your USE contain doc ?

That adds lots of optional documents.  There is no quick fix if you decide to turn it off, you can either rebuild all the affected packages to drop the documents or your regular updates will gradualy do it for you.

man pages are not removed - only optional documents.

----------

## ExecutorElassus

make.conf does not contain the doc flag. Should I disable it explicitly?

Thanks,

EE

----------

## nordic bro

in addition, /usr/src is too big unless this is temporary.  I don't know how you do it but I don't use genkernel or whatever so my suggestion might not work here but when I emerge or d/l kernel src, at most I only have one dir untar'd.  those dirs are like 300M+ and even bigger after running make so unless I'm actively adding/updating kernel, the src dirs are tar'd/compressed (run "make clean" first).  you should be labelling and saving ".config" (and patches you've applied) but other than that there really isn't anything you need from a src dir.

in general what I notice from your link is that you a) let things install possibly unnecessary deps and b) perhaps not remove something you maybe wanted to try but decided you don't like?  for example, I see lots of kde stuff as if that's what you use but I also see a few xfce pkgs like themes and whatnot.  I see 3(?) browsers, 3 video tools, tons of fonts and other things.  by themselves they don't amount to much but if you're not careful either preventing unneeded deps from being installed or installing something and never unmerging it/its deps then naturally one will have free space probs.

when I emerge anything, I do "emerge -pv" first and redirect it to a unique text file - this way if I decide I don't want the pkg, I unmerge it, view that text file and remove its deps too (have to be careful though, a pkg installed in the meantime may be using one of the new deps - "equery d" can help as can "revdep-rebuild --pretend" or whatever).

also you should be careful with "use" flags.  review yours against /usr/portage/profiles/use* to see what you actually need.  for example, w/something like mplayer which can have a ton of optional deps, I don't let it call in everything under the sun.  what I mean is, I've used mplayer/mencoder for ages and have yet had a need for ogg/vorbis or whatever therefore use "-ogg/vorbis" in make.conf to ensure neither mplayer or anything else tries to pull them in.  (I'm not picking on those two, you may have the pref but the idea is, review use flags for what you actually need then omit or "-" for those you decided you definitely don't want; "emerge -pv" helps here because you might say "do I even want xyz dep?  I better chk use flags before continuing".)

----------

## Hu

 *nordic bro wrote:*   

> when I emerge anything, I do "emerge -pv" first and redirect it to a unique text file - this way if I decide I don't want the pkg, I unmerge it, view that text file and remove its deps too (have to be careful though, a pkg installed in the meantime may be using one of the new deps - "equery d" can help as can "revdep-rebuild --pretend" or whatever).

 You can use emerge --depclean, optionally with specific package atoms, to do this.  It will catch cases where you subsequently installed something else which is known to depend on the otherwise unnecessary package.  However, it will not catch undeclared dependencies, so a revdep-rebuild is still a good idea afterward.

----------

## NeddySeagoon

ExecutorElassus,

The doc flag could be on in your profile.  Look at the USE line in 

```
emerge --info
```

 if doc is there, put -doc in your USE in make.conf.

----------

## cwr

On a small system, emerged _with_ documentation,  I get:

```

florin / # for i in usr opt var bin sbin lib etc ; do du -s $i ; done

  4398940   usr

  845568   opt

  342084   var

  5884   bin

  9588   sbin

  11136   lib

  8000   etc

```

My desktop has several hundred packages emerged, again with documentation,

and /usr fills about 13G of a 16G partition.  On the whole I wouldn't start

deleting stuff from /usr until you've found out whats taking up the space;

as a last resort, I suppose, you could clear out any docs under /usr/share/gtk-doc,

although I'd be inclined to archive them in case they are needed.

Will

----------

## Goverp

The numbers, 3G /usr/share, and 7.5G /usr, look similar to my system.

By way of comparison my system (profile default/linux/amd64/10.0/desktop/kde) has 7.4G for rootfs (which is mainly /usr, but no /var, /home, /tmp or DISTFILES) and 2.1G for /usr/share.  I don't have the "doc" use flag.

Interestingly, I have an old box I've not updated since September 2009, and that uses only 5.3G for rootfs, and 1.2G /usr/share, so there's some software bloat.

Maybe Old Moore's Law applies to disk space for software too.  (FWIW, 5.3G growing to 7.4G over that period is a growth factor of 9 in a decade, which is pretty much Moore's Law!  /usr/share's growth rate is 40 times per decade, which must be anomalous, Linux developers are notorious for hating documentation   :Wink:   )

----------

## leifbk

 *Hu wrote:*   

> 
> 
>  *leifbk wrote:*   And of course, do a rm -r on every directory in /usr/src/ that doesn't contain active kernel stuff. To be clear, you should first emerge --unmerge sys-kernel/sources-package each unwanted kernel in /usr/src, so that the package manager cleans it out.  If you have done an out-of-tree kernel build, the package manager will remove the /usr/src/sources-package directory as well.  If you did an in-tree kernel build, then there will be unowned files littering /usr/src/sources-package, so the package manager will not remove it.  However, per the suggestion from leifbk, it is safe to manually remove those unowned files.

 

Sure, I should have said to run 'emerge --depclean sys-kernel/gentoo-sources' first. Just forgot it   :Smile: 

BTW, I hate how depclean will flush the active kernel tree, if that's not the newest version. I think that it should check for whatever kernel tree that's linked from /usr/src/linux, and protect that one.

----------

