Resizing root partition (no empty space between partitions)

sethgi · 2020-03-27 21:18:37

Hi all,

Being foolish, when I installed Arch (almost a year ago) I made my root partition much too small. While I've generally been able to just delete a few things here and there to get it to work, it's finally getting to the point where I really need to just make the partition bigger (I'm trying to install Cuda and just can't make it work). So I got the classic error:

:: Proceed with installation? [Y/n] 
(4/4) checking keys in keyring                     [######################] 100%
(4/4) checking package integrity                   [######################] 100%
(4/4) loading package files                        [######################] 100%
(4/4) checking for file conflicts                  [######################] 100%
(4/4) checking available disk space                [######################] 100%
error: Partition / too full: 1491710 blocks needed, 407795 blocks free
error: not enough free disk space
error: failed to commit transaction (not enough free disk space)
Errors occurred, no packages were upgraded.
Error installing repo packages

The output of df:

Filesystem     1K-blocks      Used Available Use% Mounted on
dev              8122196         0   8122196   0% /dev
run              8129796      1256   8128540   1% /run
/dev/nvme0n1p2  30832548  27612120   1631180  95% /
tmpfs            8129796    309384   7820412   4% /dev/shm
tmpfs            8129796         0   8129796   0% /sys/fs/cgroup
tmpfs            8129796   2097388   6032408  26% /tmp
/dev/nvme0n1p3 459941260 125025824 311481948  29% /home
tmpfs            1625956        52   1625904   1% /run/user/1000

And a screenshot of gparted:

https://i.imgur.com/HKLC7WJ.png

I couldn't find any posts saying how to deal when the partition really has no space to expand. My thought was to back it up, then wipe the drive and make a new file system, then use dd to copy it back into the resized partitions... but that feels somewhat barbaric. Any other thoughts?

Thanks!

moderator edit -- replaced oversized image with link.
Pasting pictures and code

Last edited by 2ManyDogs (2020-03-27 22:24:10)

teckk · 2020-03-27 22:14:04

What file system is it? If it's ext4 then you'll need to remove nvme0n1p3, move the end of nvme0n1p2 to where you want it, extend the file system on nvme0n1p2, then remake the second partition.

Edit:
Using dillo with images off. Did not see that pic.

Last edited by teckk (2020-03-27 22:16:31)

WorMzy · 2020-03-27 22:17:29

There is no easy solution to this. Your options are (in increasing levels of difficulty and risk):

a) Clean up your root filesystem -- 30G is more than sufficient in most cases, where is your space being used? Do you need all of what is filling it?
b) Move some directories to your home partition, then use bind mounts to make them accessible at their original location.
c) Shrink your home partition by the amount you want to add to root, move the shrunken partition to the right of the disk, then expand your root partition accordingly.

Tools like ncdu can help you with a) and b). Gparted is probably the easiest way to do c), although you should make backups before even attempting it as moving partitions can easily cause data loss if it goes wrong.

sethgi · 2020-03-28 17:31:00

WorMzy wrote:

There is no easy solution to this. Your options are (in increasing levels of difficulty and risk):
a) Clean up your root filesystem -- 30G is more than sufficient in most cases, where is your space being used? Do you need all of what is filling it?
b) Move some directories to your home partition, then use bind mounts to make them accessible at their original location.
c) Shrink your home partition by the amount you want to add to root, move the shrunken partition to the right of the disk, then expand your root partition accordingly.
Tools like ncdu can help you with a) and b). Gparted is probably the easiest way to do c), although you should make backups before even attempting it as moving partitions can easily cause data loss if it goes wrong.

I spent quite a while on (a), which is what lead me to this post. I think I'm at a bit of a dead end.

(b) is a better option I think. I'll try to do that. The stuff filling the partiton is a lot of libraries, tools, and whatnot. Matlab, cuda, python 2/3, ROS and related packages, etc etc just take a lot of space.

@WorMzy Is it safe to move whole root directories (like /opt or /usr) to home and then use bind mounts? If so I'll just do that, it just feels a bit sus (in my Newbie view of the world)

Thanks all!

hainjedaf · 2020-03-28 18:15:36

Why not move /tmp and /var/tmp to a ramdisk?

I have these entries in all my linux installs:

# Temporary filesystems in ramdisks
# system
tmpfs           /tmp    tmpfs    noatime,nosuid    0 0
tmpfs           /var/tmp    tmpfs    noatime,nosuid    0 0

# user
tmpfs           /root/.cache      tmpfs    noatime    0 0
tmpfs           /home/administrator/.cache tmpfs    noatime,nosuid    0 0
tmpfs           /home/userabcd/.cache    tmpfs    noatime,nosuid    0 0

This way all cache and temp data simply vanishes after each reboot.

on a server system, you could have a cron job empty these directories based on age of contents and users being logged in or not.

sethgi · 2020-03-28 18:20:07

hainjedaf wrote:

Why not move /tmp and /var/tmp to a ramdisk?
I have these entries in all my linux installs:
# Temporary filesystems in ramdisks
# system
tmpfs           /tmp    tmpfs    noatime,nosuid    0 0
tmpfs           /var/tmp    tmpfs    noatime,nosuid    0 0

# user
tmpfs           /root/.cache      tmpfs    noatime    0 0
tmpfs           /home/administrator/.cache tmpfs    noatime,nosuid    0 0
tmpfs           /home/userabcd/.cache    tmpfs    noatime,nosuid    0 0
This way all cache and temp data simply vanishes after each reboot.
on a server system, you could have a cron job empty these directories based on age of contents and users being logged in or not.

Good point - bit of an oversight on my part. I'll do that now. Thanks!

WorMzy · 2020-03-28 18:45:29

/tmp is already a tmpfs. /var/tmp isn't but there shouldn't be anything particularly large in that directory.

/opt is a valid candidate, but I would recommend against moving /usr or /etc. These are both "essential" directories and should ideally be part of the root filesystem. /boot can be on a dedicated partition, but setting up as a subdir on /home isn't something that I would recommend.

Where is the space actually being used? Show us the output of

# mount --bind / /mnt
# du -hd1 /mnt | sort -h

sethgi · 2020-03-31 03:45:11

WorMzy wrote:

/tmp is already a tmpfs. /var/tmp isn't but there shouldn't be anything particularly large in that directory.
/opt is a valid candidate, but I would recommend against moving /usr or /etc. These are both "essential" directories and should ideally be part of the root filesystem. /boot can be on a dedicated partition, but setting up as a subdir on /home isn't something that I would recommend.
Where is the space actually being used? Show us the output of
# mount --bind / /mnt
# du -hd1 /mnt | sort -h

4.0K	/mnt/dev
4.0K	/mnt/home
4.0K	/mnt/mnt
4.0K	/mnt/proc
4.0K	/mnt/run
4.0K	/mnt/sys
4.0K	/mnt/tmp
12K	/mnt/srv
16K	/mnt/lost+found
11M	/mnt/etc
101M	/mnt/boot
1.8G	/mnt/opt
2.4G	/mnt/root
6.6G	/mnt/var
15G	/mnt/usr
26G	/mnt

Wild Penguin · 2020-03-31 13:08:12

For a single-user workstation, IMO it makes little sense to make a separate /home and /partition. It is a bit difficult to anticipate how much space / will take in the end, and also there is little to gain in a separate /home.

How much space does your /home partition currently have left? If there is a lot of free space (>50%), I would consider the following procedure, to avoid having data in a non-consistent state at any point (you should always have an intact /home data, since files are only copied here):

shrink the fs on /home
shrink the actual partition for /home (to something larger than the FS!)
Make sure you have not screwed up in part 1) or 2). Your partition should now be bigger than actual FS on it!
create another partition after /home.
copy data from /home to the new partition
change fstab to point to new partition. Check everything is in order and works after reboot!
delete old /home partition -> now you have free space in between /root and /newhome!
resize /root partition and then the root fs to take up the freed up space. Then optionally:
make a new directory on /root partition and copy data from /home partition to the new directory
update fstab to not to refer to the /newpartition anymore. Rename directory from previous step to /home
check everything works without using a separate /home partition
repeat steps from 7) to 8)

EDIT: A few errors were in the list above: most importantly, move instead of copy!

Last edited by Wild Penguin (2020-03-31 13:14:19)

cmurf · 2020-04-05 02:52:34

sethgi wrote:

2.4G	/mnt/root
6.6G	/mnt/var

Ordinarily /root is essentially empty. You might dig in there to find out what's going on.

/var/cache around 500M is probably OK. But much bigger than 750M I'd rm -rf its contents, and let whatever's using it rebuild.

Arch Linux

#1 2020-03-27 21:18:37

Resizing root partition (no empty space between partitions)

#2 2020-03-27 22:14:04

Re: Resizing root partition (no empty space between partitions)

#3 2020-03-27 22:17:29

Re: Resizing root partition (no empty space between partitions)

#4 2020-03-28 17:31:00

Re: Resizing root partition (no empty space between partitions)

#5 2020-03-28 18:15:36

Re: Resizing root partition (no empty space between partitions)

#6 2020-03-28 18:20:07

Re: Resizing root partition (no empty space between partitions)

#7 2020-03-28 18:45:29

Re: Resizing root partition (no empty space between partitions)

#8 2020-03-31 03:45:11

Re: Resizing root partition (no empty space between partitions)

#9 2020-03-31 13:08:12

Re: Resizing root partition (no empty space between partitions)

#10 2020-04-05 02:52:34

Re: Resizing root partition (no empty space between partitions)

Board footer