moving /var

On Wed, Dec 20, 2006 at 10:01:35PM -0000, wrote:
> On Wed, Dec 20, 2006 at 01:41:11PM -0500, Greg Folkert wrote:
>
> > On Wed, 2006-12-20 at 14:36 +0000, wrote:
> > > I recently tried to move /var to a new partition. Booted from some
> > > live cd, moved it and edited /etc/fstab to suit. Broke the machine
> > > as it wouldn't boot afterwards (in fact I recollect it booted but with

[...]
> > >
> > > What should I have done?
> >
> > I have done it many times from LiveCD, also from Single user mode. I had
> > to turn off some logging and other things even in single user mode.
> >
> > Effectively you have to make sure you get everything. If you are running
> > Ubuntu there are additional items you need to make sure are taken care
> > of. (Make sure /var/run and /var/lock are on the root partition for
> > tmpfs filesystems)

[...]
> >
> > So, what did you do to move it? (list of commands used, would be good)
>
> Hmm, it's a couple of weeks ago now. I usually use cp -a for things
> like this and then rename the directory and make a new one to mount to,
> but in this case I think I used mv. I don't think there are any critical
> symlinks. The old /var directory was definitely empty after the move,
> because I checked. Anyway cp -a back again put everything into place
> and the system booted as normal afterwards.

when I've done it in the past, I have tar'd the whole directory, cp'd
and untar'd it in the new location, change fstab and reboot. done. I
don't see why cp -a wouldn't work too... hmmm... maybe you've got some
other problem and this is just a symptom.

>
> The implication of your comments is that you don't think there was any
> problem with initrd. In fact, I am sure I have done this before with no
> problems. I was surprised when there was a problem. I did also move
> /usr (to another partition) which was of course trouble-free. Perhaps I
> shall try again when I get back to that box ( am in the wrong country at
> the moment).
>
> Really, I asked two questions mixed up together. The other is how to
> run makeinitrd, or anything else such as lilo or grub-install (or
> whatever the command is) in a chroot, when chrooting cuts you off from
> the /dev and /proc filesystems so that none of these commands will run.

mount proc -t proc /mnt/chroot/proc

check the debian install manual, there is information on installing
from another unix system and included there is how to install kernels
from the chroot. should be applicable here.

A

richard@the-place.net :
> On Wed, Dec 20, 2006 at 01:41:11PM -0500, Greg Folkert wrote:
>
> > On Wed, 2006-12-20 at 14:36 +0000, wrote:
> > > I recently tried to move /var to a new partition. Booted from some
> > > live cd, moved it and edited /etc/fstab to suit. Broke the machine
> >
> > So, what did you do to move it? (list of commands used, would be good)
>
> Hmm, it's a couple of weeks ago now. I usually use cp -a for things
> like this and then rename the directory and make a new one to mount to,
> but in this case I think I used mv. I don't think there are any critical

Note mv doesn't work between filesystems. cp -a or tar/untar (or any
other archiver) is the right way.

> symlinks. The old /var directory was definitely empty after the move,
> because I checked. Anyway cp -a back again put everything into place
> and the system booted as normal afterwards.

I don't understand how.

--
Any technology distinguishable from magic is insufficiently advanced.
(*) http://www.spots.ab.ca/~keeling Linux Counter #80292
- - http://www.faqs.org/rfcs/rfc1855.html Please, don't Cc: me.
Spammers! http://www.spots.ab.ca/~keeling/emails.html

--

On Wed, Dec 20, 2006 at 10:01:35PM -0000, wrote:

> Really, I asked two questions mixed up together. The other is how to
> run makeinitrd, or anything else such as lilo or grub-install (or
> whatever the command is) in a chroot, when chrooting cuts you off from
> the /dev and /proc filesystems so that none of these commands will run.

I've done this several times over the years as needs change and I've
never had a problem. Here's how I do it:

from single-user mode
format the new partition
mount it on e.g. /newvar
use mc and copy /var to /newvar (keeping same attributes)
shutdown -Fr now
boot the install disk and:
rename /newvar to /oldvar
edit /etc/fstab to point /var to the new partition,
and mount the old var partition on /oldvar
for my friend Justin Case.
reboot to single user mode, and ensure all is well,
reboot to standard mode.
if all looks good, unmount /oldvar and delete the partition or
otherwise reclaim that space.

As far as running a command from within the partition (e.g. chroot) from
a rescue, I note that the Etch installer has this on the rescue-mode
menu (including installing grub or lilo), I would just do that if need
be.

YMMV, good luck.

Doug.

--

On Sat, Dec 23, 2006 at 04:55:00PM +0100, Michelle Konzack wrote:
> Am 2006-12-20 13:41:11, schrieb Greg Folkert:
> > Effectively you have to make sure you get everything. If you are running
> > Ubuntu there are additional items you need to make sure are taken care
> > of. (Make sure /var/run and /var/lock are on the root partition for
> > tmpfs filesystems)

while I don't think the above is true, as most of my /var's are not on /
partition, I also don't think that:

>
> /var/run and var/lock must NOT be on the root partition.
>

is true too. I have at least one /var that is not mounted on a
seperate partition making it definitely ON the / partitions.

A

On Sat, 2006-12-23 at 16:55 +0100, Michelle Konzack wrote:
> Am 2006-12-20 13:41:11, schrieb Greg Folkert:
> > Effectively you have to make sure you get everything. If you are running
> > Ubuntu there are additional items you need to make sure are taken care
> > of. (Make sure /var/run and /var/lock are on the root partition for
> > tmpfs filesystems)
>
> /var/run and var/lock must NOT be on the root partition.
[...snip...]

As of right NOW, Ubuntu uses a "different" way of booting.

*IF* /var/run and /var/lock are NOT on the initial root (/) filesystem
before the other filesystems are mounted then it fails to boot properly.

In fact "/etc/init.d/mountvirtfs" executed early (S01) in the boot
process has the initial mounting of the tmpfs stuff in it here it is:

# Mount standard /proc filesystem
TYPE=
case "$KERNEL" in
Linux|GNU)
TYPE=proc
;;
*FreeBSD)
TYPE=linprocfs
;;
*)
TYPE=procfs
;;
esac

# Mount standard /proc and /sys.
domount $TYPE /proc
domount sysfs /sys

# Mount /var/run and /var/lock as tmpfs.
# /var may be on another drive so create /var/run if we need to
domount tmpfs /var/run "-o mode=0755"
domount tmpfs /var/lock "-o mode=1777"

# Mount /proc/bus/usb -- though all software should be modified to
# use /dev/bus/usb instead now
domount usbfs /proc/bus/usb

Then later in the boot process, it "remounts" the dirs to a "safe
location" for saving later... then once /var is properly mounted it
remounts them where they properly need to be. Done in mtab (S22) then in
mountall (S35)

I KNOW this is the way it is in Ubuntu, I had a server I setup for a
customer. After I did initial setup, I had to add a real Raid Array
(2.2TB) to various filesystems of which one was /var (before /var was on
root). During the re-deploy I missed making the /var/run and /var/lock
directories as *I* would NEVER have done that normally. This caused
failing to reboot properly, not bringing up the NICs and periodically
falling off the network as well.

I "got" to make a 2 hour each way and 3-5 hour troubleshooting "Gratis"
travel call each time this thing failed. (4 times)

It was tracked down to there NOT being /var/run and /var/lock on the
root(/) filesystem

So, please DO NOT tell me what NOT to do. I specified this was on Ubuntu
on the off chance the person was using Ubuntu.

I'll bet the Lenny (Etch+1) has this.
--
greg,

The technology that is
Stronger, better, faster: Linux