2

My first question here on server fault. In my haste, I set up a local server with Centos 6.2 and let the Centos installer handle the partitions.

Big mistake, I know.

Anyway, the only problem I have with it is that the majority of the hard drive space was allocated to the /home mount point. We're not going to be using that... we're going to be using /var. I tried changing the mount point of the partition mounted to /home to mount to /var... but, as I'm sure you're already laughing to yourself, yes, it prevented my system from booting up. Turns out /var is important ;)

Now, I'm not a total imbecile, so I was able to boot to a recovery console and change it back. Now, that is why I have come to you guys.

How can I change the mount point to /var but still retain a functioning system? I presume I need to copy the contents of /var to /home somehow, but I'm not sure where to start.

Brendan
  • 145
  • 2
  • 10
  • Letting CentOS (or any OS) handle the partitions isn't _that_ bad - it's just that every admin I've ever seen always wants to set things up differently... – Mei Feb 17 '12 at 16:24
  • Well, unless you didn't already invested a lot of more work into the server configuration, why not just redo it and create a partition style you want this time? This will take about 20 minutes or something like that. That said, fixing the major problem on your current installation is also possible and actually quite easy, as David describes below. – Sven Feb 17 '12 at 16:28
  • Well, I've gone to great lengths to set up NGINX, PHP-FPM, etc. I suppose I can redo all of that. I wanted to avoid it if possible. – Brendan Feb 17 '12 at 16:45

1 Answers1

3

Your description is a little bit confusing - but it sounds like you have a /var partition and a /home partition.

You want to preserve the permissions when you copy - this is critical!

If want you want is simply to be able to mount /home as /var, then I would do this in the original environment:

# rsync -Wav /var/ /home

This will recreate directories like /var/lib, /var/tmp, and others in /home. After this is done, /home will look something like this (faking up output example):

# ls -m /home
agentx, backups, cache, charlie, crash, lib, local, lock, log, louie, mail, opt,
run, spool, tina, tmp, www

Note the three (faked up) home directories present: /home/charlie /home/louie /home/tina.

You should be able to delete all the home directories without serious problem, unless there is a daemon that expects a real home directory. In any case, to preserve them (just in case), I'd do this before copying /var:

# cd /home
# mkdir .sav
# mv charlie tina louie .sav

This will move the selected home directories out of the way but preserve them for later.

Also, when you move /home to /var that means that /home will now have to be created on / (root). After you boot with the new set up (with /home moved to /var) then do this:

# mkdir /home
# chmod 755 /home

Make sure to create any /home directories you need - or copy them from /var/.sav directory. To do the latter, do this in your new environment:

# rsync -Wav /var/.sav/ /home

Also note that the original /var will still be there. If it is in a mounted filesystem, then it will be hidden but will still take up space.

UPDATE: In response to the questions below, here are some thoughts on recovering space from /var:

You probably should not delete the files until you have run with the changed environment for a while and nothing has been required of the old environment. This is just for safety's sake.

Also for safety's sake, you probably should do two things. In the old environment, do this:

# touch /var/var.old
# touch /home/var.new

This will allow you to see two almost identical mounts but discern which is which at a glance.

To actually delete the data, you need to be able to access the data in the old /var. This data will not be directly accessible under /var once you've mounted your new partition.

There are two ways to do this:

  1. In original environment, create a hard link to /var (ln /var /var.old) and then in the new environment do rm -rf /var.old/*. I've not tried this, but with a hard link you should still access the old /var and not the new. Verify by looking for var.old (if you see var.new then it didn't work).

  2. In a recovery shell, do mkdir /var.old ; mv /var/* /var.old. Once done booting into the new environment, access data under /var.old.

Note that both of these preserve the /var directory which is needed for mounting.

Mei
  • 4,560
  • 8
  • 44
  • 53
  • Thank you. This worked great. Is there any way I can recover the space from /var/ or should I just "live with it"? (it's not taking up THAT much space, maybe 2GB) – Brendan Feb 17 '12 at 16:31
  • Ok, I may have been a bit hasty. The system hangs in the same spot as before -- right at "Starting System Logger:" Not sure what to do at this point other than reverse all the changes. – Brendan Feb 17 '12 at 16:38
  • David's procedure looks good. The only thing possibly missing is dealing with SELinux ... I think you'll need to run a relabel to fix up the security contexts. Look into the `restorecon` and/or `fixfiles` commands. – Steven Monday Feb 17 '12 at 17:43
  • I actually stumbled upon the `fixfiles relabel` command. That fixed my hanging System Logger. Thanks everyone! – Brendan Feb 17 '12 at 18:12
  • `fixfiles` and `restorecon` appear to be Red Hat-specific; at least, they exist on RHEL 5.7 but not Ubuntu Server 10.04. – Mei Feb 17 '12 at 20:22
  • @David: `fixfiles` and `restorecon` are SELinux-specific utilities. Centos6 installs SELinux by default, whereas Ubuntu (AFAIK) does not. – Steven Monday Feb 17 '12 at 21:22