migrating /var "the directory" to /var "a filesystem"

Latest response

I need to migrate the contents of my /var directory to a filesystem because of a security requirement.  I have created a filesystem, and mounted it to /mnt.  In single user mode I used the following command to migrate the contents of /var to the new filesystem:


huron : /var # find . -print | cpio -Bpdumv /mnt


I then modified the fstab to mount the new filesystem to /var at boot time.  When I reboot the system the boot process hangs at "Starting system logging".  I even ran an fsck on the new filesystem and it still didn't work.  Does anyone have a better way to accomplish my task than what I have already tried?  I have not deleted the contents of /var the directory, so all i have to do is replace fstab with the original fstab, boot up, and I'm fine.






Morning Andrew!


Moving /var will be difficult as there will be files still in place and you will just overlay the new filesystem over it. So if space becomes an issue you will need to clean it out as best you can. Having the system in single user mode, if possible, will make it easier since little will be happening on the system.


I tend to just use "cp -Rp" for moving filesystems. It has worked for me in exactly the situations you are talking about now. The steps are pretty much like you said:


1. Make the new filesystem and mount it somewhere temporarily.

2. Copy things over.

3. Unmount the filesystem.

4. Edit /etc/fstab.

5. Mount the new filesystem.



Some possible issues may be the options you put in /etc/fstab. When you have it mounted in the temporary place, see what it says in /etc/mtab. That might give you some ideas.



Don't forget to clean old /var once you verify that everything works as expected. If you don't clean it and a new admin later compares the output of "df" and "du" on /, he will have a hard time to figure out where the difference comes from.

You could also try booting the installation media in rescue mode, and move the files from here. At least you'll be 100% sure that no process is accessing the filesystem.

I wonder if SElinux is causing some issues - as I am not sure if cpio is SElinux-aware.  /var is obviously a very important filesystem to have functioning correctly and I potentially see how it could cause a box to either hang for quite some time, or not boot at all.

If I was in this situation I would disable SElinux to see if the problem goes away.  


The following command would reapply the appropriate "standard" or "default" context(s) to the files (but would take quite a while, most likely).  NOTE: you will need your new filesystem mounted as /var for this to work.


# df -h /var 

# restorecon -RFvv /var


If you wanted to be extremely scientific about the issue..

you could boot off rescue media and compare the filesystem vs the "legacy" files using

# ls -lZ

to compare the applied context to the flie


For ensuring the transfer of extended filesystem attributes (SELinux contexts, ACLs, etc.) tools like dump/restore  or even `dd`can prove more reliable than higher-level tools like cp/mv/tar/cpio. Ensuring that you've transfered the extended attributes can save you the time of relabeling.

"cp --archive" is an option as well.

Don't use cp -p. It won't preserve everything (e.g. extended attributes like SELinux contexts).

Instead use either cp -a or rsync -aX.

With your original command you're making this way more complicated than it has to be.

  1. Boot into single user mode (init 1).
  2. Shutdown anything that's somehow still accessing /var (use lsof +D /var or fuser -vm /var to inspect).
  3. Use rsync -aXv /var/ /mnt/var/ -- assuming you mounted the new var filesystem at /mnt/var.
  4. mv /var /var.bak
  5. Unmount the new var from /mnt or wherever and mount it up to /var.
  6. Back into multiuser mode