Ubuntu automatic LVM partitioning killing me -- ideas from anyone?

[MiniKnight]

I installed Ubuntu awhile back and just did automated partitioning. This is a story about a test system that I thought I'd wipe in a week but started doing useful stuff so I'd rather not re-install.

Here's where I'm at:

$ df -h
Filesystem                      Size  Used Avail Use% Mounted on
udev                             63G     0   63G   0% /dev
tmpfs                            13G  1.4G   12G  11% /run
/dev/mapper/porkbuns--vg-root  9.9G  9.9G     0 100% /
tmpfs                            63G  4.6M   63G   1% /dev/shm
tmpfs                           5.0M     0  5.0M   0% /run/lock
tmpfs                            63G     0   63G   0% /sys/fs/cgroup
/dev/sdb1                       471M  423M   25M  95% /boot
/dev/mapper/porkbuns--vg-home   19G  519M   17G   3% /home
tmpfs                            13G     0   13G   0% /run/user/1000

and here's lvm lvs:

  home   porkbuns-vg -wi-ao----  18.52g
  root   porkbuns-vg -wi-ao----  10.18g
  swap_1 porkbuns-vg -wi-ao---- 652.00m

Docker installs into porkbuns--vg-root which is full and holding a dozen containers being used now.

Ideally I'd like to shrink home and grow root. Ok really I want to know WTF Ubuntu is doing with this layout but here I am.

I don't think lvresize and lvreduce work on a live system. If I bring it down, I'm going to re-install.

Frustrating POS.

 

[marcoi]

not sure if this will work but have you tried apps like gparted to resize the partition? I havent played with it much so not sure if it will even do what you need but figured it wouldnt hurt to mention it.

 

[ColdCanuck]

I installed Ubuntu awhile back and just did automated partitioning. This is a story about a test system that I thought I'd wipe in a week but started doing useful stuff so I'd rather not re-install.

Here's where I'm at:

$ df -h
Filesystem                      Size  Used Avail Use% Mounted on
udev                             63G     0   63G   0% /dev
tmpfs                            13G  1.4G   12G  11% /run
/dev/mapper/porkbuns--vg-root  9.9G  9.9G     0 100% /
tmpfs                            63G  4.6M   63G   1% /dev/shm
tmpfs                           5.0M     0  5.0M   0% /run/lock
tmpfs                            63G     0   63G   0% /sys/fs/cgroup
/dev/sdb1                       471M  423M   25M  95% /boot
/dev/mapper/porkbuns--vg-home   19G  519M   17G   3% /home
tmpfs                            13G     0   13G   0% /run/user/1000

and here's lvm lvs:

  home   porkbuns-vg -wi-ao----  18.52g
  root   porkbuns-vg -wi-ao----  10.18g
  swap_1 porkbuns-vg -wi-ao---- 652.00m

Docker installs into porkbuns--vg-root which is full and holding a dozen containers being used now.

Ideally I'd like to shrink home and grow root. Ok really I want to know WTF Ubuntu is doing with this layout but here I am.

I don't think lvresize and lvreduce work on a live system. If I bring it down, I'm going to re-install.

Frustrating POS.

Have you tried lvresize as opposed to assuming it won't work. Since your plan B is a reinstall cant hurt..

But I would boot from a USB stick and resize.

 

[ttabbal]

If you installed the normal Ubuntu, I can kind of see why they would do that. It's designed as a desktop OS and /home will likely need a decent amount of space. The server version doing that would be stupid, I agree.

That's one thing I like about ZFS root, I can have many filesystems and each just uses whatever space it needs, no need to pre-allocate like that. I haven't used LVM in a while now, but I think that the resize tools work live, but you need the FS to support it as well. When shrinking, I always did the filesystem first, to make sure that it would still fit.

With that small of a dataset, I would probably just back up the whole thing to a USB drive and reinstall with a single root FS covering the whole drive. With resizing, I always make a full backup, as I've had those tools fail and eat filesystems.

 

[rubylaser]

You can certainly reduce the size of an existing volume group and expand the other. You will need to also reduce/grow the partitions as well. If you go with the resizing route, I would definitely do it from a livecd. You will just need Gparted and a terminal to run all of the commands on an unmounted system.

Another option could be to run your Docker containers out of your /home directory instead of /root. I would echo the above and just do a ZFS root mirror (if you have the disks to do it), or just a plain non-LVM install (use the whole disk).

 

[MBastian]

Got no time so in short:

copy /home to some safe place
then
and delete the /home LVM, adding it to the root LVM,
or
copy your docker directory to /home, then change it to the normal docker dir. You could also do a softlink but I'd seen that overwritten on a docker RPM update on a CentOS 7 hosts.

 

[Patrick]

@MiniKnight I can see your point on partitioning.

What I would do is to re-install. I know you have network storage and it looks like you are on a small boot drive.

 

[Blinky 42]

A cheat to get back going w/o wiping things yet would be to move things from under /var/blah to /home/temp_var/blah and symlink it back. Same for /usr/local/* if there is a lot of stuff there.

Also prune out all the stuff under /var/log if you have not yet to get some free space back so you can create inodes.

That is why I only do default partitioning on small VMs - the defaults always suck and screw you over some how eventually. I like to leave some space free in the VG as well so I can add space in a pinch to whatever is full to keep things alive until I can source more storage or fix it proper.

 

[whitey]

You can extend root VG...something like this. Didn't show fdisk, n, p, enter, enter, t, 8e (LVM), w stuff AND it takes a reboot from what I've tested today. Had to do this for a system at work.

I HATE (read WILL NOT if at all possible) shrink stuff...makes me cringe everytime i go down that path.

So yeah resize root/OS VM/disk (hope it's a VM) then this is the general jist.



EDIT: love my 'hot' in my history out to .txt file...apparently not so hot but those were my intentions, I think we've covered data disks and doing those HOT, OS PV/VG/LV is another ball o' wax.

 

[EffrafaxOfWug]

`lvresize -r` is your friend here as it will try and extend/shrink the filesystem at the same time (have only ever used it with ext4 myself).

What is the PV and VG topology here?

If you don't want to go down the whole shrink/extend route, just provision a new LV (perhaps for /var or whatever it is that's chewing the space?) and move all the data over to that?

 

[MiniKnight]

Thanks guys. I've been burned by resizing before so I bit the bullet and did a 15 min re-install.

Like a swift kick in the nuts the new container image I downloaded wasn't faster or better than the old container. That's a short sided view. At least now I can pull another container image later and not run into this again.

I'm still perplexed why the default installer isn't just / and no more of this extra volume mumbo jumbo.

 

[sfbayzfs]

It's been years since I had to deal with LVM at work, but you can just add a whole new disk to your LVM pool and then extend the root volume group onto it with pvcreate and lvextend, followed by resize2fs or your filesystem's equivalent. Failure of either drive would be bad of course. While I like the concept of the flexibility LVM gives you, it definitely lets you paint yourself into a corner in lots of different ways, only to escape the corner into a different corner until you run out of corners, and then you're SOL to continue the analogy, which is why I nearly always manually partition and make 1 big root partition (and often a swap partition) for most of my linux installs at home.