Linux - KernelThis forum is for all discussion relating to the Linux kernel.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
Hello,
I am in trouble with an Ubuntu lapto where the / partition is now too small, but without space 'at right' to enlarge it.
The partitioning order is the following : efi, swap, / and /home. (I also have a second internal HD, with lots of space)
df -h gives the following :
I understand, maybe wrongly, that
- I cannot move or expand / without booting from elsewhere (at least this is not available in GParted)
- it would be very dangerous, and long, to try moving the enormously filled /home
- maybe it is similarly bad to touch the / itself, even though it's smaller.
Any ideas on how to proceed?
As far as I can see, the latest Ubuntu upgrade won't pass, because of the lack of space...
Generally speaking linux filesystems (XFS excluded) can be resized at will, and easily moved around. gparted used to permit it, but maybe they got too many problem reports they didn't want to handle.
That mount for .Private implies /home is an encfs - ugh. Everything should still be do-able from a gparted liveUSB.
Let's see the (uneditted) output from these commands - add sudo in need.
Does your system now use LVM = Logical Volume Management, or can you now install it? This might well get rid of your problem entirely.
Under LVM, physical space is described as "storage pools" which can span multiple partitions and volumes. Then, filesystems are allocated from "logical volumes" defined within those pools. If you run low on space, you can simply expand the storage pool, then reformat the filesystem to recognize the added space. (An operation which can be performed without downtime.)
Does your system now use LVM = Logical Volume Management, or can you now install it?
A quick look at the OP's "df" output shows that LVM is not in use, and an in-place conversion to LVM is one of those operations that fall in the category of, "If you have to ask how, you probably should not be attempting it." Converting by migrating the data to a new disk is fairly straightforward, and a web search will reveal several suggestions for a procedure.
Thank you all for these very significant comments!
I discovered that it's not /tmp but /var/temp that is overloaded, with lots of 80-Mb files more than one year old.
I also understood that, contrary to the files in /tmp, those in /var/tmp are NOT cleaned at startup.
So after a lot of hesitation I issued the following command :
sudo find /var/tmp -type f -atime +300 -delete
I used type f to only address files not folders, atime 300 looks very conservative, keeping almost one year of old files.
I saved a LOT of space, and the system seems stable including after reboot.
I'll wait a bit, launching more apps before maybe cleaning further. But at this moment it seems I don't need resizing partitions anymore...
Again, thank you, you were precious!
H.
You haven't given much (any) info, but a systemd based system should clean up both - using different durations. From memory 30 days for /var/tmp. Depends on how often you boot of course.
you can use ncdu -x / to check it. For root partition 50G is more than enough, you ought to clean/remove unnecessary things. Otherwise you need to move personal files (videos, databases, any huge files ) onto another partition.
Have you read the thread ?. Seems the OP has been cleaning up.
Perhaps, but user errors also have to be ruled out...
Nonetheless it might be worth double checking.. (and mapping the issue)
Code:
du -sh /lib/modules/ /tmp/ /usr/src/ /usr/
Anyways, if he wants to resize things, it is ALWAYS adviced to make backups FIRST. It should be possible to take from /home if he unmounts it first. Possibly making a partition for /usr and rsync (or cp -aR or use tar) the old stuff from /usr /usr-new.
One common solution to this issue in the first place is to use a separate partition for /usr.. That might sound very old fashion, ...
Very old-fashioned. For at least 10 years now, most distributions have not supported a separate /usr filesystem. Indeed, in Ubuntu the /bin directory is just a symlink to /usr/bin, so the system simply will not boot unless /usr is mounted by the initrd early in the boot sequence. It is possible to arrange that, but a mounted /usr will cause the automatic boot-time fsck to fail for that filesystem.
Does your system now use LVM = Logical Volume Management, or can you now install it? This might well get rid of your problem entirely.
Under LVM, physical space is described as "storage pools" which can span multiple partitions and volumes. Then, filesystems are allocated from "logical volumes" defined within those pools. If you run low on space, you can simply expand the storage pool, then reformat the filesystem to recognize the added space. (An operation which can be performed without downtime.)
Was going to suggest biting the bullet and reinstalling on LVM, or BTRFS (if you avoid the raid 5 / 6 stuff) as well. This allows easy volume resizing while online, at least growing them for root in this case. I switched to lvm a long time ago now and it has saved me a world of difficulty as I tend to distro hop a ton and add and dump volumes quite often. I've debated trying it on BTRFS but I'm just lazy at this point. That and I've set a goal to use a single distro instead of hopping. In this case a year without deviating installation.
Very old-fashioned. For at least 10 years now, most distributions have not supported a separate /usr filesystem. Indeed, in Ubuntu the /bin directory is just a symlink to /usr/bin, so the system simply will not boot unless /usr is mounted by the initrd early in the boot sequence. It is possible to arrange that, but a mounted /usr will cause the automatic boot-time fsck to fail for that filesystem.
Ooh, that's right.. Forgot about distroes symlinking system files into /usr.. Then ofcourse you can't have seperate /usr, which means you MUST have a big root partition if you install alot of software. Not smart.
My bad.
Does Ubuntu use /usr/local? In that case, he could do it with /usr/local
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.