need advice on freeing space...

[the dsc]

I've installed kubuntu root on a 5gb partition, which is now nearly full...

Kleansweep marks a reasonable amount of files on the root partition (scanning for a few minutes, and it found that could free me more than 280mb, which is something already), but I also know that it hasn't any sort of list to which it can't delete in order to the system work...

(actually, just now I saw that actually I can make a list of folders to exclude from the scan, and the default list includes /sys and /proc... if this is enough to assure that the system will work if I delete anything it suggests, I don't know)

So... which are the folders or files I need to leave alone? Would that be a very complex list or I could follow some simple rules, a few key folders and files that I need to keep?

Or is it so complicated that the better thing to do would be to back up what I have on the home partition and reinstall linux with a larger root partition? (Or maybe alternatively backup just a bit and then expand the root partition with some program, but I really don't know)


BTW... I was setting to uninstall some things I don't use (things I know I can safely remove, programs and games I've installed, nothing that I don't know what is)..... and I noticed that there are two "kernel images" installed... one is 2.6.15-23-386 and the other is 2.6.15-28-386... is it supposed to be this way or the one with 23 is an outdated one that I could remove?

[anomie]

5GB is fairly small to begin with. Install a few apps and that will fill up quickly. For starters you can begin to track down some of the worst (directory) offenders with this command:
sudo du -ks /* | sort -nr | head

noticed that there are two "kernel images" installed... one is 2.6.15-23-386 and the other is 2.6.15-28-386... is it supposed to be this way or the one with 23 is an outdated one that I could remove?

Assuming you're booting from the newer one (and it works correctly) it is probably safe to remove the old one. Do this using whatever package manager Kubuntu provides so that you don't bork anything.

[the dsc]

Assuming you're booting from the newer one (and it works correctly) it is probably safe to remove the old one. Do this using whatever package manager Kubuntu provides so that you don't bork anything.

Thanks for the advice, I'm going to check which one I'm using, I think it's shown in the grub menu, if I recall... but I'll find out anyway...

About finding which are the folders occupying more space, that wouldn't be of much utility since I can't just erase the largest ones... as I'm talking about freeing space on the root partition...

Kleansweep is an utility that scans the disk for file duplicates, empty directories and files, broken symlinks, broken executables, backup files, orphaned files (whatever it may be), dead menu entries, and obsolete thumbnails... than it gives you a huge lists of files but it also tells you that isn't perfect and could erase something that is required for the system to work...

It finds a myriad of tiny (of any size, actually) files spread all over the directories, list them, with check-in boxes to check the ones you want to delete... the problem is that, since I'm scanning the root folder, I don't know which ones aren't safe to delete... I've deleted only all "obsolete thumbnails", which I assumed that would be pretty safe, but for the most part, I have no idea...

Take a peek of the list if you want:


[-] 9 /var/backups/passwd.bak
[-] 9 /var/backups/group.bak
[-] 9 /var/backups/shadow.bak
[-] 9 /var/backups/gshadow.bak
[-] 9 /var/backups/infodir.bak
[-] 9 /var/cache/debconf/config.dat
[-] 9 /var/cache/debconf/config.dat-old
[-] 9 /var/cache/debconf/templates.dat
[-] 9 /var/cache/debconf/templates.dat-old
[-] 9 /var/cache/man/local/index.db
[-] 9 /var/cache/man/oldlocal/index.db

[...]

[-] 9 /var/cache/setup-tool-backends/debug/network/9/in.xml
[-] 6 /var/lib/apt/lists/archive.ubuntu.com_ubuntu_dists_dapper_Release.gpg

[...]

[-] 4 /var/lib/dpkg/info/kate.postinst
[-] 4 /var/lib/dpkg/info/grep.preinst
[-] 4 /var/lib/dpkg/info/gzip.preinst

[...]

[-] 6 /var/lib/scrollkeeper/ml/scrollkeeper_cl.xml
[-] 6 /var/lib/scrollkeeper/ml/scrollkeeper_extended_cl.xml

[...]

[-] 6 /var/lib/x11/X.roster
[-] 6 /var/lib/x11/xorg.conf.roster
[-] 9 /var/log/Xorg.0.log.old
[-] 9 /var/log/Xorg.1.log.old

[...]

[-] 6 /etc/alternatives/policytool
[-] 6 /etc/alternatives/policytool.1.gz
[-] 6 /etc/alternatives/rmid
[-] 6 /etc/alternatives/rmid.1.gz
[-] 6 /etc/alternatives/unpack200

[...]


And the whole list has more than 1mb on a pure text file... and is mostly nonsense from a newbie point of view. I can only spot a few files I know that are at least "useful" such as fluxbox menu somewhere on /etc, eve though my fluxbox menu is entire actually in my home folder (something I think I have to fix anyway)... but that's it... and those files reach nearly 300mb, which is a big deal only when I got only ~70mb free on the root partition

[anomie]

About finding which are the folders occupying more space, that wouldn't be of much utility since I can't just erase the largest ones... as I'm talking about freeing space on the root partition...

Sure it would. I didn't make any suggestion that you delete a folder. For now just identify which ones are largest, and you can recurse into those and run the same command again. You might find something unexpected, such as an application core dump file or something else that is eating up space unnecessarily.

Also, it'll be more clear what we are working with if you post the output of:
df -h

[the dsc]

Yeah, I didnt thought of that possibility, I was just expecting to find space by large quantities of tiny unuseful files...

The output of df -h command... that's almost embarrassing, but here it is

/dev/hda1             4.6G  4.3G  102M  98% /
varrun                379M   72K  379M   1% /var/run
varlock               379M  4.0K  379M   1% /var/lock
udev                  379M  148K  379M   1% /dev
devshm                379M     0  379M   0% /dev/shm
lrm                   379M   19M  361M   5% /lib/modules/2.6.15-28-386/volatile
/dev/hda3              31G   27G  2.2G  93% /home
/dev/hdc1              20G   19G  704M  97% /media/hdc1
/dev/hdd1             9.8G  9.4G  426M  96% /media/hdd1
/dev/hdd2              28G   20G  7.8G  72% /media/hdd2

BTW, I've successfuly removed the old kernel image already

[anomie]

Well, you've utilized to near max capacity, so there is not a lot of room to grow.

I think what you are asking (from earlier in the thread) is for a way to free up some space on the / filesystem.

Since there are not separate mount points/partitions for /usr, /tmp or /var, those are all likely candidates for space hogs.

In order, some very basic strategies are:

• /usr -- deinstall any apps you don't need (especially games and other gui apps).
• /var -- make sure you're rotating log files regularly via something like logrotate.
• /tmp -- files older than a day or two can usually be safely deleted. If you're concerned that one may still be in use, you can determine whether that's true using lsof.

Also, do you really need that 27GB of stuff in /home? If you could free up a lot of space there you could (maybe) resize it and create a new partition to mount /usr, /tmp, or /var to. That's starting to get dangerous, though.

[the dsc]

Thanks, anomie, you've been very helpful

I'll keep screening a little bit more for larger files by the method you taught, but as far as I could find up to now, there isn't something blatantly wrong with any file... the largest ones are related with acrobat reader, and I think they're supposed to be that big.

An interesting solution I've found was to delete everything on /var/cache/apt/archives, which are safe to delete, according to this blog. He says that for some reason linux stores lots of packages of things we've installed a long time ago... deleting these files freed me nearly 800mb, which leaves the situation a bit more tenable while I don't reinstall everything in a more organized manner with more space to linux installation.

Only one thing went wrong, that for some reason konqueror file manager wasn't being able to show any folder content, it was giving the message "cannot talk to klauncher"... but I've searched a little bit and found how to solve on this very forum:

I had the same problem and I just figured out what to do. You don't actually need to restart anything by the way. Just open a terminal and type this in as your user.

dcopserver_shutdown
kdeinit

There problem fixed.

I'll try the other things you said too, except for that thing of resizing the partition, I prefer to play it safe and eventually reinstall everything.

[scm]

Can I put in a pedantic plea for accuracy in describing sizes, please? The abbreviation for mega is 'M', and for milli is 'm'; and the abbreviation for bytes is 'B' and bits is 'b'. So if I'm told that something freed 800 mb I'm going to think "mmm, 800 millibits isn't very much". And although it may be obvious from the context what you mean, things can get confusing when you're talking about download rates over ADSL where bits and bytes can be equally relevant.

[flipjargendy]

You could remove any apps you don't use, i usually do this right away so I don't have to worry about it later.

I usually remove all the games that come with KDE or GNOME, knotes, kppp, kopete (i don't Instant Message). After removing a few minor apps you can free up about a gig sometimes. Of course all of this is done using apt-get. It's easier because of dependancies and you don't have to worry about screwing anything up.

You could also run apt-get autoremove with removes packages that were, probably, automatically installed with other packages. The packages that are removed are not needed by any application.