On 2021-10-15, cho...@jtan.com <cho...@jtan.com> wrote: > Bingo. I was even told about it in the email I ignored (there's > nothing wrong with *69):
:) Been there done that. (If I am anywhere near tight on space in /usr I usually try to upgrade with the "untar on running system" method with a root shell open so I have some hope of fixing it..) And I have a number of systems where I have a gap in partition letters after growfs'ing /usr into what was previously the partition after it on disk. > Time to reinstall on a bigger disc. Thanks for the pointer, that > saves me some perplexed digging around. Good files to kill if you need to quickly make some breathing space (but of course will come back after reinstalling all sets): /usr/lib/lib[a-bd-z]*.a /usr/share/man Unless you are doing installs directly under /usr (usually self built software), removing everything reported by "sysclean | grep ^/usr" should be safe. It takes care of libraries needed for installed packages so you can try cleaning, making sure you have xbase and base sets fully unpacked, update packages, then run sysclean again and it will probably allow you to free up some more shared libraries. > btw Some of the space used on /usr will be old libraries (it's at > least as old as 6.8, clearly), but for the record it looks like the > minimum sizes on amd64 are approx. 1.25GB for /usr/!(X11R6|local), > 240MB for /usr/X11R6 and <75MB for everything else if the box isn't > doing a great deal. FWIW I usually try to give /usr at least 5GB. Maybe slight overkill but it's such a pain to shuffle partitions I'd rather waste a bit of space than have to do that again. The other place I often run out is / on systems where I run current as I often have a few different kernels lying around from trying to bisect when a problem was introduced. -- Please keep replies on the mailing list.
