2

I've got an old server that will be re-purposed. Part of this means rearranging the partitions. The current layout is:

$ lsblk
NAME                    MAJ:MIN RM   SIZE RO TYPE MOUNTPOINT
sda                       8:0    0 558.7G  0 disk 
├─sda1                    8:1    0 243.5M  0 part /boot
├─sda2                    8:2    0     1K  0 part 
└─sda5                    8:5    0 558.5G  0 part 
  ├─root                254:0    0   9.3G  0 lvm  /
  ├─swap_1              254:1    0  21.8G  0 lvm  [SWAP]
  └─home                254:2    0 527.4G  0 lvm  /opt
sr0                      11:0    1  1024M  0 rom  

The root partition is very small, and I need to merge it with home to make one single partition. Is it possible to merge these without losing data? I'm concerned that if data is lost in either partition, I might not be able to log in again - I only have ssh access. The machine is in a data centre that I can't get physical access to should something go wrong. I can't just pop in a Live CD and repartition from there.


I know there are many GUI tools that can manage partitions, I need a CLI solution.

12
  • I think what you want is safe and easy with LVMs, but I am not sure so let's wait for someone who knows LVMs better. In the mean time, do you need to merge? Why not make /usr a symlink pointing to /home/usr for example? – terdon Feb 5 '19 at 20:52
  • @terdon: The server is already a bit of a mess with symlinks doing things like that (and some are broken...), and I suspect it's been like that for quite a while. I think (hope?) that merging the partitions will be a good first step in the clean-up that is to follow. At one point I thought about reinstalling the OS from scratch but that would probably take longer than I have. – FrustratedWithFormsDesigner Feb 5 '19 at 21:11
  • Can you take the system off-line? then booting from a USB and simply copying things over and changing the boot flags would be easiest. – Fabby Feb 5 '19 at 21:19
  • @Fabby: I don't have physical access to this machine so that would probably be difficult. Getting someone else to do it would probably take too long (mostly because the people with access are busy and I would expect a certain minimum amount of red tape for that kind of request). – FrustratedWithFormsDesigner Feb 5 '19 at 21:21
  • 1
    Move / to /home using pivot_root, update fstab, delete the / after it successfully reboots an option then? Do you have a KVM console into the thing? or limited to ssh? – Fabby Feb 5 '19 at 21:27
4

Presuming you actually have free space on /opt, and it's a filesystem that supports at least offline shrinking, the safest bet would be:

  1. Since your home directory is on /opt, you can't be logged in to it — or you won't be able to unmount /opt. One way around this is to enable root login via ssh, using public keys. I don't have an Ubuntu box in front of me to be 100% sure of the steps, but it should just be editing /etc/ssh/sshd_config to change PermitRootLogin to prohibit-password (or without-password, for older versions of OpenSSH). Then put your public key in /root/.ssh/authorized_keys. An alternative (suggested by @bistoco) is to create a new user, with a home directory on the root filesystem, e.g.,: sudo mkdir /tmphome && sudo adduser --home /tmphome tmpuser && sudo adduser tmpuser sudo
  2. Make sure you can log in as root or the new user now. Do this from another terminal, do not log out your other session until you've logged in as root, either directly or via sudo from the new user (essential for recovery if, e.g., you accidentally broke sshd)
  3. Log in a second root session, just in case. You use this if you somehow break your first one.
  4. Finally log out your user session, and any others you have.
  5. Unmount /opt. If umount /opt gives an in use error, use fuser -vm /opt (or whatever) to see what is accessing it. You might also need to stop some services, or find another session to log out. (If you can't get /opt to unmount, go to step 10 to abort the process).
  6. Shrinking a volume often requires an fsck, and its a good idea anyway. You'll probably need to add -f to force fsck on a clean device. E.g., fsck -f /dev/mapper/VGNAME-home. This may take a while. (If fsck fails, stop. Check for typos. If it's really failing, something is wrong.)
  7. Reduce the volume: lvreduce -Ay -r -L 100G VGNAME/home. The -r tells it to reduce the filesystem first. The 100G is the new size; pick whatever you'd like (of course can't be smaller than the amount of data on /opt). This make take a long while, depending on how much data is on the volume. If this fails due to not supported, this isn't going to work. Proceed to 9 to abort. (If it fails complaining you asked it to shrink to much, pick a larger size and repeat the command).
  8. Enlarge the rootfs: lvextend -Ay -r -L 200G VGNAME/root. Again the 200G is the size, and can be whatever you need (up to all available space). The -r tells it to resize the filesystem as well (after enlarging the LV); typically this can be done on-line. If it can't... well, your system will still be accessible, but really you need to find a way to use a live CD.
  9. Regardless of if that worked, mount /opt.
  10. Make sure you can log in as your user again. Do not log out your root sessions until you've confirmed you can. If you're using SSH connection multiplexing, use ssh -o ControlPath=none user@host to make sure a cached connection is not fooling you.
  11. Start any services that you had to stop to unmount /opt. At least if you want them running.
  12. Change the ssh setting back to not allowing root login, if that's the option you pick and is the way it was before. Make sure you can log in a new session before logging out. Always do this when changing sshd config. Or, if you created a new user, remove it with e.g., deluser --remove-home tmpuser

PS: You do not need to grow / to occupy all the available space. You can always extend it again if you need to — it's often better to leave some space in a PV unallocated.

18
  • Will step 8 work with / mounted? i think not. – bistoco Feb 5 '19 at 22:37
  • 1
    @bistoco With most filesystems in current use, yes. You can enlarge them while mounted. ext4 supports it, for example. So do more recent ext3. And XFS, and btrfs, and... – derobert Feb 5 '19 at 22:37
  • I think it will be easier on point 1, to create a user with a custom home-folder path under VGNAME/root like sudo mkdir -p /tmphome/ && sudo useradd -m -d /tmphome/ USERNAME, and give it sudo access. Then login and follow the rest of the steps. No other config changes required. – bistoco Feb 5 '19 at 23:38
  • 1
    @FrustratedWithFormsDesigner yes, you can do that. I'd always leave a little bit of space free on the root partition - completely full might break. – derobert Feb 6 '19 at 17:30
  • 1
    @FrustratedWithFormsDesigner Glad to hear it worked. There really ought to be an automatic way to find "interesting" relocations like you ran in to — finding cross-device symlinks ought to do it. But I don't know of a tool that does that, might be worth a question. I'm mostly on Unix & Linux (where I'm pretty sure that question would be happily accepted), I imagine here is OK too but am less familiar with Ask Ubuntu. – derobert Feb 11 '19 at 18:30

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.