enlarging the / partition in crowded context
 

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 :

~$ df -h
size user avail used on
/dev/nvme0n1p3 50G 45G 1,7G 97% /
/dev/nvme0n1p1 512M 5,0M 507M 1% /boot/efi
/dev/sda1 1,8T 1,4T 453G 75% /datadisk
/dev/nvme0n1p4 882G 201G 681G 23% /home
/home/frederique/.Private 882G 201G 681G 23% /home/frederique

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...


Thank you!
Herve

Herve5,

What really helped me in Linux Mint was to remove older kernels, apart from the current one and its predecessor:

Update Manager > View > Linux kernels > Continue >

Select 5.15 (in my case) and then keep latest two kernels.

Remove all earlier kernels.

Now again run:

The percentage of root partition in use should have fallen.

When you next do a fresh installation, make sure you create a larger root partition.

A dangerous command (for several reasons) that is unnecessary when /tmp can be properly cleared by a simple reboot.

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.)

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)
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.

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.

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.

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