What to do when the root partition is full?
Posted by lloyd on Tue 17 Feb 2009 at 12:08
I just upgraded from an older version of Lenny to latest. When the upgrade finished, an alert appeared noting that root partition is full. As a consequence of this problem (I think) I can't save or print Open Office documents.
Here's what df shows:
lloyd@Cube1:~$ df Filesystem 1K-blocks Used Available Use% Mounted on /dev/hda1 6728280 6670808 0 100% / tmpfs 242168 0 242168 0% /lib/init/rw udev 10240 68 10172 1% /dev tmpfs 242168 0 242168 0% /dev/shm /dev/hda6 70651388 12484248 54578224 19% /home overflow 1024 16 1008 2% /tmp
My disk usage analyzer tells me I've used 24.8% e.g. 18.3 GB out of 73.8 GB.
I've found references on the net on how to expand the root partition, but would like to query for lastest info and technique.
What's the safest way to expand the root partition?
Many thanks,
If you've got spare space somewhere, an easy way would be to create a new root partition, copy your root partition there and adjust fstab accordingly.
If you can grow your existing partition then that's also an option. I did this recently and was using jfs/LVM.
Just needed to grow the LV and then issue a "mount / -o remount, resize" command and job done.
--
Charles Darke
http://digitalconsumption.com
[ Parent | Reply to this comment ]
delete only the older deb files
[ Parent | Reply to this comment ]
After you clean up some space, a reboot (to a new default kernel) is a good idea - this will "fix" your problem with overflow on /tmp as well.
Cheers,
rjc
[ Parent | Reply to this comment ]
6.5GB of disk for / should be sufficient for Debian. This Ubuntu system is only using 3GB. Once you have cleaned up a few files you should have more then enough space. Filling up / on a *nix system is actually pretty bad. Lots of system and users processes will fail. But you don't need a lot of free space because many of the files that will be written are small.
The command aptitude clean, or apt-get clean will delete unneeded .deb files stored in /var.
You can also delete /var/log/*.gz to remove old achieved log files (unless you have a need to keep them).
You should also look in /boot to see if you old kernel images that you don't need. Do not delete these files, but use aptitude or apt-get to remove the linux-image- packages.
You can use 'du -s ' to hunt down unexpectedly large files.
Finally boot into single user mode (recovery mode??). Umount /tmp and /home and look in those directories to see if you have any hidden files. Linux will happily mount a filesystem over top of a directory full of files. It is a easy mistake to make if you convert from a single filesystem to multiple.
BEFORE REBOOTING: run aptitude update && aptitude upgrade. I suspect that if you / filled up during the upgrade the upgrade may be incomplete.
[ Parent | Reply to this comment ]
ciao!
[ Parent | Reply to this comment ]
[ Parent | Reply to this comment ]
[ Parent | Reply to this comment ]
Your root directory is full of the *.deb files you downloaded to upgrade (they are located in /var/cache/apt). Just do
# apt-get clean
from a root prompt, and you'll have space again.
Have fun with lenny!
[ Parent | Reply to this comment ]
You folks are the greatest.
All the best,
LRP
[ Parent | Reply to this comment ]
[ Parent | Reply to this comment ]
1. `aptitude autoclean` might be sufficient. Although `aptitude clean` shouldn't be problematic either.
2. You can mount tmpfs on /tmp so it will be in RAM rather than on root partition (in fstab it will be something like 'tmpfs /tmp tmpfs auto,size=256M,uid=0,gid=0,mode=1777 0 0'). Doesn't even use much RAM usually, but you might get problems if something tries to unpack into there.
3. You might want to use some system-cleaning tools (deborphan, debfoster, cruft). I think there are some articles regarding these.
[ Parent | Reply to this comment ]
What is missing in your configuration is separated /var.
Normal users on debian system can write to /var/tmp i /var/lock directly.
Not directly he/she can fill additional directories in /var like:
/var/log (via logger)
/var/spool/cron/crontabs/ (via crontab -e)
/var/spool/mail/
and so on.
So IMHO separated /var is a must.
[ Parent | Reply to this comment ]
Many thanks for your response to my post to Debian Administrator.
I don't understand what you mean by "separated /Var." How do I implement it and why?
Thanks again,
LRP
[ Parent | Reply to this comment ]
Separated /var means putting it to a dedicated partition, just like you already have for /home.
In the old days, it was pretty common to have separate partitions for /usr, /home, /var, and even /var/tmp. The rationale behind this is that these directories all have different access patterns. For example / and /usr shouldn't be written to by regular users: having them on a separate partition allows you to mount them read-only. Conversely, /home should be mounted read/write, but can have the options noexec,nodev,nosuid for extra security.
You can search Google for "Filesystem Hierarchy Standard" for more on this topic.
[ Parent | Reply to this comment ]
[ Parent | Reply to this comment ]
mv /var/cache/apt /home/apt_cache
ln -s /home/apt_cache /var/cache/apt
[ Parent | Reply to this comment ]
also av being wondring the same problem.. i wuz thinkin of editing my partition location for the /usr folder.. av made a c script which can mount lyk the mount comand idependent off the shell cmdns.. can this be sort of embeded within the start scripts.. ryte afta it finshes loadin my hardware drivers..? can it be inserted into the initramfs? such that wen i move my /usr to another harddisk,, this script will mount the /usr to the original location lyk it wuz before..??
[ Parent | Reply to this comment ]
Do the right thing and convert to LVM and then you can expand, and on some file systems shrink, the size of the filsystem (some mounted other unmounted).
But best is to locate where those large file theifs are and remove them. Like with "aptitiude clean" and cleaning out /var/log as has been mentioned earlier.
[ Parent | Reply to this comment ]
al let you know if its anygood..
[ Parent | Reply to this comment ]
I have started in / running `du -sh *`
the problem with that is that it scans your other mounts and funky virtual file systems like proc.
I would recommend running 'du -sh *' in each local sub-dir (/usr, /var, /boot, etc) to track down the issues.
Unless it is some large file(s) you have manually installed.
It is probably in /var. Probably either an overfull package archive (solution: run aptitude clean). Or an exploded log file. /var/log/* just delete the .gz and log files will get you space to work, but you might want to view the log file to find out why it is so full. Maybe there is an error getting logged over and over again. Try to fix the error rather than just continually deleting logs.
This is actually the reason that many people recommend putting /var on its own partition.
If you want to make a larger root partition and aren't using lvm you can install a new hardrive, boot to a cd based distro (knoppix) use dd (`dd if=/dev/sda1 of=/dev/sdb1')to copy the contents to a new partion and then use resize2fs(`resize2fs /dev/sdb1`) to grow the file system to fill the new partion. it might require some shifting of drive positions and reinstall of lilo to get the drive to boot properly, and have new names match old names, but I have pulled it off in the past.
[ Parent | Reply to this comment ]
$ du -x / | sort -nwhere -x tells du to ignore directories on other partitions, and -n forces numeric sort (and not alphabetic). In the resulting output, the last rows are the directories where you should begin to do your cleaning.
[ Parent | Reply to this comment ]
[ Parent | Reply to this comment ]
Problem is, Linux documentation, including information on best practices, is fragmented, contradictory, often dated, incomplete and/or so poorly written as to be marginally useful.
That said, I'm grateful for the time and effort that has gone into every line of it.
But it does create mega frustration and heartburn for the new self-taught Linux admin.
Forums help and this one is particularly awesome. But some forums treat newbies like dirt.
Maintaining excellent documentation and keeping it up-to-date is probably of the same magnitude of effort as creating and maintaining the code upon which it's based. But few programmers have a stomach for it; and volunteer effort leaves us with what we've got.
I believe that this is a HUGE problem. Don't know how to solve it. Three simple thing would help: 1) work toward documentation quality standards; 2) date all documentation; 3) find a way to tag or remove erroneous of out-of-date documentation from the web.
I can only ask Linux wizards to 1) understand; 2) be patient with newbies; 3) contribute what you can to documentation of every higher quality.
Thanks.
A Linux admin newbie
[ Parent | Reply to this comment ]
I'm sure it would be possible to develop e.g. a plugin for firefox/iceweasel which simply determines the date of last change of a loaded file
Unfortunately, most of the pages are dynamically created vie php, javascript, etc. so that will not be a sufficient solution. At least, maybe there is only the way of a "best practice" what to think about, when writing a how-to or a tutorial.
I'm not sure if something similar exists, yet (RFC, etc.). Let's see.
[ Parent | Reply to this comment ]
[ Parent | Reply to this comment ]
For reference, I'm currently running a Debian(etch) LAMP server with LVM and a 275MB root virtual partition. This is about three times what I need according to the output from "df -h".
I ran into a problem similar to yours when I tried to install Nessus. It tried to install itself into /opt which is mounted under the root partition. This quickly filled up my partition and prevented me from being able to update my system among other problems.
The short answer is to read the text file found at http://tinyurl.com/bftl8e and do what it says. But basically root should never be/need to be extended if your system and applications are setup correctly. Nothing should ever be installed in /opt for example although I know nessus and maybe openOffice do.
You can't just run lvextend because you have to unmount whatever partition you want to work on first. Whoever said they need 6.5 gigs for a root partition is stoned out of their mind.
Here are a few steps I tried before having to go through the steps found in my linked txt file.
1) run "apt-get autoclean"
2) delete everything in root's home directory or move it somewhere else(it's stored on the root partition)
3) check out /opt if there is anything installed there, copy it to a different directory and symlink back to it.
Good luck, I hope this helps you.
[ Parent | Reply to this comment ]
Execution of apt-get autoclean opened up enough room to enable me to take more fundamental steps.
One responder suggested a finer-grained partitioning scheme than I have now. This interests me. But the thought of repartitioning terrifies me. I have back-up with Infrant ReadyNAS, but still don't feel at all comfortable with any operations beyond current routine back-ups.
I've been considering installing LVM, but need time to get my head around it.
Thanks all,
LRP
[ Parent | Reply to this comment ]
http://en.wikipedia.org/wiki/XFS
http://en.wikipedia.org/wiki/IBM_Journaled_File_System_2_(JFS2)
[ Parent | Reply to this comment ]
/srv is also a good point for having data for a server. Ex. I usually move data storage for samba server to /srv/samba/ and music storage for mt-daapd to /srv/public/music. That way it's easier to make backup, I think.
[ Parent | Reply to this comment ]