Re: moving /var
Mr G wrote: Why can't you just #mount --rebind /var /newvar Because that won't copy the data into the new filesystem. To do that you do actually need to copy the data as described in the previous messages. (I prefer 'rsync -a' over 'cp -a' because rsync can be restarted efficiently.) Then once copied it needs to be swapped into place. Bob signature.asc Description: Digital signature
moving /var
Hi, I read in book about Linux file systems and at the end of chapter there was one example in which author wanted to create dedicated volume for /var coz it was mounted on root partition. Lets skip some steps and assume we have prepared partition on disk - /dev/sdb1so he did it this way: [root@server ~]# mkdir /new_var [root@server ~]# mount /dev/sdb1 /new_var [root@server ~]# cp -vrp /var/* /new_var/ [root@server ~]# mv /var /old_var [root@server ~]# mkdir /var [root@server ~]# mount --bind /new_var/ /var and what is really bothering me most is that cp command, wouldn't it possibly create inconsistency ? What would be better way to do it ? Is it even possible to do such change on running system without worries to lose some data ? Thanks. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAGQ+rPHqoL3OaHdY_USkCTvHbVEh20w+brHaiEoN4GL6w=a...@mail.gmail.com
Re: moving /var
On 3/1/13 10:41 AM, Maroš Žilka wrote: What would be better way to do it ? Is it even possible to do such change on running system without worries to lose some data ? I wouldn't do it on a running system. Better to boot from a live CD or similar and do it from there. About a different way, the way I have done it is with tar using the -p option. I'm not sure if that's inherently better, but it is another way. Regards, /Lars -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/51306c93.8050...@gmail.com
Re: moving /var
Hi, Dňa 1. 3. 2013 9:41 Maroš Žilka wrote / napísal(a): and what is really bothering me most is that cp command, wouldn't it possibly create inconsistency ? What would be better way to do it ? Is it even possible to do such change on running system without worries to lose some data ? some time ago i wrote the article (in Slovak) about moving partitions/data. It is not exactly about your moving, but perhaps it will help: http://slavino.sk/linux/linux-vseobecne/167-zmena-rozdelenia-disku regards -- Slavko http://slavino.sk -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/51306e01.60...@slavino.sk
Re: moving /var
Dear Maroš, Maroš Žilka wrote: [root@server ~]# mkdir /new_var [root@server ~]# mount /dev/sdb1 /new_var [root@server ~]# cp -vrp /var/* /new_var/ [root@server ~]# mv /var /old_var [root@server ~]# mkdir /var [root@server ~]# mount --bind /new_var/ /var and what is really bothering me most is that cp command, wouldn't it possibly create inconsistency ? What would be better way to do it ? Is it even possible to do such change on running system without worries to lose some data ? Yes - if someone writes to /var after the file was copied, this change will be lost. You can make the window where such a change would be lost smaller by running rsync twice: # rsync -av /var/* /new_var # rsync -av /var/* /new_var where the second command should only take a few seconds (rather than very long, if, for example, /var/www is large). It might furthermore be helpful to remound /var read-only before the procedure and shut down as many services as possible – if nothing writes to /var, no data will be lost :) Best, Claudius -- Please don’t CC me. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130301084955.662d1...@ares.home.chubig.net
Re: moving /var
Hello List, On 01/03/13 09:53, Lars Noodén wrote: On 3/1/13 10:41 AM, Maroš Žilka wrote: What would be better way to do it ? Is it even possible to do such change on running system without worries to lose some data ? I wouldn't do it on a running system. Better to boot from a live CD or similar and do it from there. A simple live CD is sufficient: Debian netinst minimal CD in rescue mode is sufficient to do so. Do not forget to update the /etc/fstab configuration file with respect to the change; to clean up the /var (and let an empty one) in the `/' (root) partition. Jerome About a different way, the way I have done it is with tar using the -p option. I'm not sure if that's inherently better, but it is another way. Regards, /Lars -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/51306fd3.5030...@rezozer.net
Re: moving /var
Hello List, On 01/03/13 09:53, Lars Noodén wrote: On 3/1/13 10:41 AM, Maro ilka wrote: What would be better way to do it ? Is it even possible to do such change on running system without worries to lose some data ? I wouldn't do it on a running system. Better to boot from a live CD or similar and do it from there. A simple live CD is sufficient: Debian netinst minimal CD in rescue mode is sufficient to do so. Do not forget to update the /etc/fstab configuration file with respect to the change; to clean up the /var (and let an empty one) in the `/' (root) partition. It is simpler to move the partition in single user mode. Just issue the command (as root) # shutdown now (not 'shutdown -h now' or 'shutdown -r now'), wait the system go down and enter the root password when asked. You will have just a root shell running. An even more secure way (in case single user leaves some program running) is to reboot and pass the argument init=/bin/sh to the kernel by editing the kernel command line in grub. You will start a system with only a running shell as pid 1 and the root mounted read-only. Then remount the root read-write: # mount -o remount,rw / and do the dirty work. When you finish, unmount all partition other than the root, remount the root read only with # mount -o remount,ro / and reset the computer (shutdown will do nothing). João Luis. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/786369acf5452f17b53938245b229476.squir...@nonada.if.usp.br
Re: moving /var
On 3/1/13 1:06 PM, Joao Luis Meloni Assirati wrote: It is simpler to move the partition in single user mode. Just issue the command (as root) # shutdown now Thanks. Single user mode is for things just like that. The answer was in front of us the whole time. Regards, /Lars -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/51309300.8020...@gmail.com
Re: moving /var
Hello, On 01/03/13 12:06, Joao Luis Meloni Assirati wrote: Hello List, On 01/03/13 09:53, Lars Noodén wrote: On 3/1/13 10:41 AM, Maroš Žilka wrote: What would be better way to do it ? Is it even possible to do such change on running system without worries to lose some data ? I wouldn't do it on a running system. Better to boot from a live CD or similar and do it from there. A simple live CD is sufficient: Debian netinst minimal CD in rescue mode is sufficient to do so. Do not forget to update the /etc/fstab configuration file with respect to the change; to clean up the /var (and let an empty one) in the `/' (root) partition. It is simpler to move the partition in single user mode. Just issue the command (as root) Indeed. I will think about it next time. # shutdown now (not 'shutdown -h now' or 'shutdown -r now'), wait the system go down and enter the root password when asked. You will have just a root shell running. An even more secure way (in case single user leaves some program running) is to reboot and pass the argument init=/bin/sh to the kernel by editing the kernel command line in grub. You will start a system with only a running shell as pid 1 and the root mounted read-only. Then remount the root read-write: # mount -o remount,rw / and do the dirty work. When you finish, unmount all partition other than the root, remount the root read only with # mount -o remount,ro / and reset the computer (shutdown will do nothing). João Luis. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/5130947b@rezozer.net
RE: moving /var
Hi, A simple live CD is sufficient: Debian netinst minimal CD in rescue mode is sufficient to do so. Do not forget to update the /etc/fstab configuration file with respect to the change; to clean up the /var (and let an empty one) in the `/' (root) partition. It is simpler to move the partition in single user mode. Just issue the command (as root) # shutdown now Hmm, I have always used the init command to change runlevels. So I would have gone for: # init 1 And indeed single user lever is the way to go for lots of stuff like this. Bonno Bloksma -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/89d1798a7351d040b4e74e0a043c69d73529a...@hglexch-01.tio.nl
Re: moving /var
On 01/03/2013 09:41, Maroš Žilka wrote: Hi, I read in book about Linux file systems and at the end of chapter there was one example in which author wanted to create dedicated volume for /var coz it was mounted on root partition. Lets skip some steps and assume we have prepared partition on disk - /dev/sdb1so he did it this way: [root@server ~]# mkdir /new_var [root@server ~]# mount /dev/sdb1 /new_var [root@server ~]# cp -vrp /var/* /new_var/ [root@server ~]# mv /var /old_var [root@server ~]# mkdir /var [root@server ~]# mount --bind /new_var/ /var and what is really bothering me most is that cp command, wouldn't it possibly create inconsistency ? What would be better way to do it ? Is it even possible to do such change on running system without worries to lose some data ? Thanks. I think it's not a good thing to do it on a running system. Even with a LVM snapshot on the running /var, you'll end up with two /var volumes to sync while apps are still reading/writing to one and then the other. Or an option would be to stop every services (say mysql, apache, etc.), then =mount -o remount,ro /var=, then copying it and swapping volumes I'm not sure if this is robust enough. Nicolas -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/5130ac78.4060...@yahoo.fr
Re: moving /var
Bonno Bloksma wrote: A simple live CD is sufficient: Debian netinst minimal CD in rescue mode is sufficient to do so. Do not forget to update the /etc/fstab configuration file with respect to the change; to clean up the /var (and let an empty one) in the `/' (root) partition. It is simpler to move the partition in single user mode. Just issue the command (as root) +1 for single user mode. No need to boot other media. The system is designed to be self-sufficient. # shutdown now Hmm, I have always used the init command to change runlevels. So I would have gone for: # init 1 The documented interface is 'telinit' to tell init to change runlevels. But in practice telinit is linked to init. Therefore it works both ways. lrwxrwxrwx 1 root root 4 Jun 7 2012 /sbin/telinit - init And indeed single user lever is the way to go for lots of stuff like this. Agreed. Bob signature.asc Description: Digital signature
Re: moving /var
Why can't you just #mount --rebind /var /newvar B G On Mar 1, 2013 4:00 PM, Bob Proulx b...@proulx.com wrote: Bonno Bloksma wrote: A simple live CD is sufficient: Debian netinst minimal CD in rescue mode is sufficient to do so. Do not forget to update the /etc/fstab configuration file with respect to the change; to clean up the /var (and let an empty one) in the `/' (root) partition. It is simpler to move the partition in single user mode. Just issue the command (as root) +1 for single user mode. No need to boot other media. The system is designed to be self-sufficient. # shutdown now Hmm, I have always used the init command to change runlevels. So I would have gone for: # init 1 The documented interface is 'telinit' to tell init to change runlevels. But in practice telinit is linked to init. Therefore it works both ways. lrwxrwxrwx 1 root root 4 Jun 7 2012 /sbin/telinit - init And indeed single user lever is the way to go for lots of stuff like this. Agreed. Bob
Re: moving /var
On Wed, Dec 20, 2006 at 10:01:35PM -, [EMAIL PROTECTED] 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. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: moving /var
On Sat, Dec 23, 2006 at 02:25:51PM -0500, Greg Folkert wrote: On Sat, 2006-12-23 at 16:55 +0100, Michelle Konzack wrote: [..] /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. Aha! This may explain it. No, it wasn't ubuntu installed but the original setup came from knoppix (just might have been mepis, which is definitely ubuntuish, but I am pretty sure it was knoppix). Probably, then a similar issue. I'll try to take the box to somewhere with adsl and do a full dist-upgrade to etch, including a latest kernel and see if things are more regular afterwards. There are still a stack of packages lingering minor numbers behind etch as a result of the lack of available bandwidth for upgrading. Thanks again to everybody for the insights. -- richard -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: moving /var
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. I have: 8-- # /etc/fstab: static file system information. # # file systemmount pointtype options dump pass proc/proc procdefaults0 0 usbdevfs/proc/bus/usb usbdevfs defaults 0 0 /dev/hda2 noneswapsw 0 0 /dev/hda1 / ext3defaults,errors=remount-ro 0 1 /dev/hda3 /tmpext3defaults0 2 /dev/hda5 /usrext3defaults0 2 /dev/hda6 /varext3defaults0 2 /dev/hda7 /var/logext3defaults0 2 8-- and it works since Debian 2.1/Slink Thanks, Greetings and nice Day Michelle Konzack Systemadministrator Tamay Dogan Network Debian GNU/Linux Consultant -- Linux-User #280138 with the Linux Counter, http://counter.li.org/ # Debian GNU/Linux Consultant # Michelle Konzack Apt. 917 ICQ #328449886 50, rue de Soultz MSM LinuxMichi 0033/6/6192519367100 Strasbourg/France IRC #Debian (irc.icq.com) signature.pgp Description: Digital signature
Re: moving /var
Am 2006-12-20 15:20:33, schrieb Andrew Sackville-West: mount proc -t proc /mnt/chroot/proc Ehm, -- mount -t none /proc /mnt/chroot/proc -o bind would work a little bit better and is the right way to go. Thanks, Greetings and nice Day Michelle Konzack Systemadministrator Tamay Dogan Network Debian GNU/Linux Consultant -- Linux-User #280138 with the Linux Counter, http://counter.li.org/ # Debian GNU/Linux Consultant # Michelle Konzack Apt. 917 ICQ #328449886 50, rue de Soultz MSM LinuxMichi 0033/6/6192519367100 Strasbourg/France IRC #Debian (irc.icq.com) signature.pgp Description: Digital signature
Re: moving /var
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 signature.asc Description: Digital signature
Re: moving /var
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, [EMAIL PROTECTED] The technology that is Stronger, better, faster: Linux signature.asc Description: This is a digitally signed message part
Re: moving /var
On Sat, 2006-12-23 at 09:04 -0800, Andrew Sackville-West wrote: 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. Please see my response to Michelle. -- greg, [EMAIL PROTECTED] The technology that is Stronger, better, faster: Linux signature.asc Description: This is a digitally signed message part
Re: moving /var
On Sat, Dec 23, 2006 at 03:42:49PM -0500, Greg Folkert wrote: On Sat, 2006-12-23 at 09:04 -0800, Andrew Sackville-West wrote: 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. Please see my response to Michelle. doh. there it is right there... sorry I missed that. I was responding to Michelle and missed the context. happy holidays A signature.asc Description: Digital signature
Re: moving /var
celejar [EMAIL PROTECTED]: On 12/21/06, s. keeling [EMAIL PROTECTED] wrote: Note mv doesn't work between filesystems. cp -a or tar/untar (or any other archiver) is the right way. Are you sure this is true? I think I use mv to do that all the time. I stand corrected. It was that way prior to v. 4.0 of coreutils. See info coreutils mv -- Any technology distinguishable from magic is insufficiently advanced. (*)http://www.spots.ab.ca/~keeling Linux Counter #80292 - -http://www.faqs.org/rfcs/rfc1855.htmlPlease, don't Cc: me. Spammers! http://www.spots.ab.ca/~keeling/emails.html -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: moving /var
On Wed, Dec 20, 2006 at 02:36:16PM +, [EMAIL PROTECTED] 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 no keyboard. Anyway it was unusable.) I thought it might be an initrd problem, and had a half-baked memory that chrooting into the root partition and running makeinitrd or somesuch would solve it. But as usual I got errors from nonexistant /dev and /proc filesystems in the chroot and so could not build a new initrd. So I copied /dev back where it came from and reverted fstab and all was well. I might have been more persistent but had a slow (and expensive) i'net connection so it was easier to give up. What should I have done? TIA Hi richard, most of the time /var/cache/apt/archives gets filled as it is where your debs are downloaded. About .5-1.5 GB should be ok to hold a few updates. Use 'clean' or 'autoclean' with aptitude when needed. This is an untested example of how to solve this: a) create /dev/hdb1 (new partition) with cfdisk b) mkfs.ext3 /dev/hdb1 # format new partition c) mount -t /dev/hdb1 /mnt # mount the new partition on a temporary # mount point d) mv /var/cache/apt/archives/* /mnt# move the files to the # temporary mount point e) umount /mnt # unmount temporary mount point f) add this to /etc/fstab: # add new partition to fstab /dev/hdb1 /var/cache/apt/archivesext3 defaults0 1 g) mount -a # make mount command add the new # mount point h) check if all is ok with 'mount' # check if /var/hdb1 and # /var/cache/apt/archives are listed done. Next reboot will do this automatically. Cheers, Kev -- | .''`. == Debian GNU/Linux == | my web site: | | : :' : The Universal | debian.home.pipeline.com | | `. `' Operating System| go to counter.li.org and | | `-http://www.debian.org/ |be counted! #238656 | | my keysever: pgp.mit.edu | my NPO: cfsg.org | signature.asc Description: Digital signature
Re: moving /var
On Wed, Dec 20, 2006 at 03:20:33PM -0800, Andrew Sackville-West wrote: On Wed, Dec 20, 2006 at 10:01:35PM -, [EMAIL PROTECTED] wrote: On Wed, Dec 20, 2006 at 01:41:11PM -0500, Greg Folkert wrote: On Wed, 2006-12-20 at 14:36 +, [EMAIL PROTECTED] 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 [...] Effectively you have to make sure you get everything. I [...] So, what did you do to move it? (list of commands used, would be good) but in this case I think I used mv [...] 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. Yes, I think you must be right. I'll try it again when I get back to that machine, and see if I can learn more. [...] 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. Thanks to all for the various comments and advice on these two unconnected issues -- richard -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: moving /var
[EMAIL PROTECTED] [EMAIL PROTECTED]: On Wed, Dec 20, 2006 at 01:41:11PM -0500, Greg Folkert wrote: On Wed, 2006-12-20 at 14:36 +, [EMAIL PROTECTED] 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.htmlPlease, don't Cc: me. Spammers! http://www.spots.ab.ca/~keeling/emails.html -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: moving /var
On 12/21/06, s. keeling [EMAIL PROTECTED] wrote: Note mv doesn't work between filesystems. cp -a or tar/untar (or any other archiver) is the right way. Are you sure this is true? I think I use mv to do that all the time. Celejar -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
moving /var
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 no keyboard. Anyway it was unusable.) I thought it might be an initrd problem, and had a half-baked memory that chrooting into the root partition and running makeinitrd or somesuch would solve it. But as usual I got errors from nonexistant /dev and /proc filesystems in the chroot and so could not build a new initrd. So I copied /dev back where it came from and reverted fstab and all was well. I might have been more persistent but had a slow (and expensive) i'net connection so it was easier to give up. What should I have done? TIA -- richard -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: moving /var
On Wed, Dec 20, 2006 at 02:36:16PM -, [EMAIL PROTECTED] 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 no keyboard. Anyway it was unusable.) I thought it might be an initrd problem, and had a half-baked memory that chrooting into the root partition and running makeinitrd or somesuch would solve it. But as usual I got errors from nonexistant /dev and /proc filesystems in the chroot and so could not build a new initrd. So I copied /dev back where it came from and reverted fstab and all was well. I might have been more persistent but had a slow (and expensive) i'net connection so it was easier to give up. What should I have done? How did you move it. What sequence of commands did you use? Regards, -Roberto -- Roberto C. Sanchez http://people.connexer.com/~roberto http://www.connexer.com signature.asc Description: Digital signature
Re: moving /var
[EMAIL PROTECTED] wrote: rtpn I recently tried to move /var to a new partition. Booted from some rtpn What should I have done? are you moving it because root is getting full? i've always moved /usr without problem - it's larger, anyhow. lishi've got truth [EMAIL PROTECTED] in times of fiction. -hr -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: moving /var
On Wed, 2006-12-20 at 14:36 +, [EMAIL PROTECTED] 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 no keyboard. Anyway it was unusable.) I thought it might be an initrd problem, and had a half-baked memory that chrooting into the root partition and running makeinitrd or somesuch would solve it. But as usual I got errors from nonexistant /dev and /proc filesystems in the chroot and so could not build a new initrd. So I copied /dev back where it came from and reverted fstab and all was well. I might have been more persistent but had a slow (and expensive) i'net connection so it was easier to give up. 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) But like I said, I have done it multiple times... heck even once accidentally reformatted the /var filesystem AND deleted all backups before the retore, having to recreate it from scratch on the new filesystem. So, what did you do to move it? (list of commands used, would be good) -- greg, [EMAIL PROTECTED] The technology that is Stronger, better, faster: Linux signature.asc Description: This is a digitally signed message part
Re: moving /var
On Wed, Dec 20, 2006 at 01:41:11PM -0500, Greg Folkert wrote: On Wed, 2006-12-20 at 14:36 +, [EMAIL PROTECTED] 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 no keyboard. Anyway it was unusable.) I thought it might be an initrd problem, and had a half-baked memory that chrooting into the root partition and running makeinitrd or somesuch would solve it. But as usual I got errors from nonexistant /dev and /proc filesystems in the chroot and so could not build a new initrd. So I copied /dev back where it came from and reverted fstab and all was well. I might have been more persistent but had a slow (and expensive) i'net connection so it was easier to give up. 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) But like I said, I have done it multiple times... heck even once accidentally reformatted the /var filesystem AND deleted all backups before the retore, having to recreate it from scratch on the new filesystem. 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. 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. -- richard -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: moving /var
On Wed, Dec 20, 2006 at 10:01:35PM -, [EMAIL PROTECTED] wrote: On Wed, Dec 20, 2006 at 01:41:11PM -0500, Greg Folkert wrote: On Wed, 2006-12-20 at 14:36 +, [EMAIL PROTECTED] 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 signature.asc Description: Digital signature
moving var
I'd recommend using rsync for this kind of thing. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Moving /var to another drive
On 12 Mar 2002, Shri Shrikumar wrote: On Tue, 2002-03-12 at 15:42, Franηois Chenais wrote: And what happens if the /var/log and /var/run dirs that can change during the tar ? Franηois Go into single user mode telinit 1 and then tar. I actually use cp -a which seems to preserve all the required attributes. Point taken guys, thanks. So go into single-user mode before doing the tar. Of course there are about a million ways of transferring filesystems (cp, tar, cpio, dd, rsync, dump...). That's the joy of UNIX, but you can get fancy above and beyond the call of duty. One guy I learnt a lot of UNIX from told me to do, for example to transfer /var (command line incomplete and probably full of mistakes as I can't really remember all the correct minutiae): find /var --print | cpio -pdum (plus other cpio syntax) Needless to say, that had me running for the tar manpage in no time at all... ;) In my humble opinion, the choice of transfer method in a case as simple as that posed by Andrew must be down to personal taste/habit/familiarity/convenience rather than any technological consideration. Best regards, | George Karaolides Linustech Advanced Solutions, | | tel: +357 22 55 61 29 86 Ifigenias Street, 3rd Floor, | | web: www.linustech.com.cy Strovolos, Nicosia CY 2003, | | email: [EMAIL PROTECTED] Republic of Cyprus. |
Moving /var to another drive
Hi My /var and /usr partitions have just run out of space and I was wondering what is the best way to copy them to a new drive that has just been installed. Any suggestions would be greatly appreciated. Regards, Andrew
Re: Moving /var to another drive
Hi Andrew, You need to be root on your machine to do this. Make two partitions on the new drive using cfdisk /dev/drive Then make a filesystem on each partition. Stick to the tried-and-tested ext2, or go for one of the new journalling ones like ext3 or reiserfs, if you're running a kernel recent enough to support them or can compile one that does. E.g. mke2fs /dev/partition Then mount the first partition e.g. under /mnt mount /dev/partition /mnt And transfer the data using tar: tar cplf - -C / var | tar xvf - -C /mnt Unmount the partition umount /mnt Mount the other one and do the same thing for /usr: mount /dev/partition tar cplf - -C / usr | tar xvf - -C /mnt umount /mnt Make sure you type the tar commands exactly as above, you don't want to go dropping the entire copnmtents of /var or /usr (or even / if you v=get it wrong) in the wrong place! Edit /etc/fstab and either add lines for /usr and /var, or change existing ones, to mount your new filesystems instead of the old ones. Here's an example: --- fstab excerpt --- /dev/sdb6 /usr ext2 rw 0 2 /dev/sdb7 /var ext2 rw 0 2 --- end fstab excerpt --- Then go to single user mode: telinit S Unmount /usr and /var: umount /usr umount /var Mount all partitions using your new fstab: mount -a Check that everything is mounted where it should be: mount And go back to your usual runlevel (usually 2 on Debian): telinit 2 That's it. Note that if /usr and /var were originally part of your root filesystem, the data will still be there but the new filesystem will be mounted on the top level directory so you won't see it. After you've successfully transferred /usr and /var out of the root filesystem, you can reclaim the space by going to single user mode, unmounting /usr and /var, and doing the following: rm -rvf /var rm -rvf /usr mkdir /var mkdir /usr Be VERY careful that /usr and /var are NOT mounted when you do this! Also note, a space or a slash in the wrong place in either of the above commands can wreck your system completely! Good luck, | George Karaolides Linustech Advanced Solutions, | | tel: +357 22 55 61 29 86 Ifigenias Street, 3rd Floor, | | web: www.linustech.com.cy Strovolos, Nicosia CY 2003, | | email: [EMAIL PROTECTED] Republic of Cyprus. | On Tue, 12 Mar 2002, Andrew Stephen wrote: Hi My /var and /usr partitions have just run out of space and I was wondering what is the best way to copy them to a new drive that has just been installed. Any suggestions would be greatly appreciated. Regards, Andrew -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Moving /var to another drive
And what happens if the /var/log and /var/run dirs that can change during the tar ? François On Tue, 12 Mar 2002 15:33:55 +0200 (EET) George Karaolides [EMAIL PROTECTED] wrote: Hi Andrew, You need to be root on your machine to do this. Make two partitions on the new drive using cfdisk /dev/drive Then make a filesystem on each partition. Stick to the tried-and-tested ext2, or go for one of the new journalling ones like ext3 or reiserfs, if you're running a kernel recent enough to support them or can compile one that does. E.g. mke2fs /dev/partition Then mount the first partition e.g. under /mnt mount /dev/partition /mnt And transfer the data using tar: tar cplf - -C / var | tar xvf - -C /mnt Unmount the partition umount /mnt Mount the other one and do the same thing for /usr: mount /dev/partition tar cplf - -C / usr | tar xvf - -C /mnt umount /mnt Make sure you type the tar commands exactly as above, you don't want to go dropping the entire copnmtents of /var or /usr (or even / if you v=get it wrong) in the wrong place! Edit /etc/fstab and either add lines for /usr and /var, or change existing ones, to mount your new filesystems instead of the old ones. Here's an example: --- fstab excerpt --- /dev/sdb6 /usr ext2 rw0 2 /dev/sdb7 /var ext2 rw0 2 --- end fstab excerpt --- Then go to single user mode: telinit S Unmount /usr and /var: umount /usr umount /var Mount all partitions using your new fstab: mount -a Check that everything is mounted where it should be: mount And go back to your usual runlevel (usually 2 on Debian): telinit 2 That's it. Note that if /usr and /var were originally part of your root filesystem, the data will still be there but the new filesystem will be mounted on the top level directory so you won't see it. After you've successfully transferred /usr and /var out of the root filesystem, you can reclaim the space by going to single user mode, unmounting /usr and /var, and doing the following: rm -rvf /var rm -rvf /usr mkdir /var mkdir /usr Be VERY careful that /usr and /var are NOT mounted when you do this! Also note, a space or a slash in the wrong place in either of the above commands can wreck your system completely! Good luck, | George Karaolides Linustech Advanced Solutions, | | tel: +357 22 55 61 29 86 Ifigenias Street, 3rd Floor, | | web: www.linustech.com.cy Strovolos, Nicosia CY 2003, | | email: [EMAIL PROTECTED] Republic of Cyprus. | On Tue, 12 Mar 2002, Andrew Stephen wrote: Hi My /var and /usr partitions have just run out of space and I was wondering what is the best way to copy them to a new drive that has just been installed. Any suggestions would be greatly appreciated. Regards, Andrew -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Moving /var to another drive
On Tue, 2002-03-12 at 08:33, George Karaolides wrote: snip And transfer the data using tar: tar cplf - -C / var | tar xvf - -C /mnt I would use rsync for this. It is faster and just all around better(IMHO). Unmount the partition umount /mnt Mount the other one and do the same thing for /usr: mount /dev/partition tar cplf - -C / usr | tar xvf - -C /mnt umount /mnt snip -- -Peace kid Scott Henson [EMAIL PROTECTED] God's the ultimate playa, so naturally He's going to have some haters, rapper Ice Cube said. But these haters need to realize that if you mess with the man upstairs, you will get your ass smote. True dat.
Re: Moving /var to another drive
On Tue, 2002-03-12 at 15:42, François Chenais wrote: And what happens if the /var/log and /var/run dirs that can change during the tar ? François Go into single user mode telinit 1 and then tar. I actually use cp -a which seems to preserve all the required attributes. I have done this process before. %telinit 1 %mkdir mnt/var %mkdir mnt/usr %mount /dev/whatever 4 new var /mnt/var %mount /dev/whatever 4 new usr /mnt/usr %cp -a /usr/* /mnt/var %cp -a /var/* /mnt/usr %umount /mnt/var %umount /mnt/usr %rm -r /mnt/var %rm -r /mnt/usr %umount /var %umount /usr %mv /var /var.old %mv /usr /usr.old %mkdir /var %mkdir /usr %mkdir /dev/whatever 4 new var /var %mkdir /dev/whatever 4 new usr /usr update /etc/fstab to reflect new changes %telinit 2 to come back to multiuser Please note that above steps are from memory - no guarantees - it worked for me atleast three times. make backups blah blah. Good luck Shri On Tue, 12 Mar 2002 15:33:55 +0200 (EET) George Karaolides [EMAIL PROTECTED] wrote: Hi Andrew, You need to be root on your machine to do this. Make two partitions on the new drive using cfdisk /dev/drive Then make a filesystem on each partition. Stick to the tried-and-tested ext2, or go for one of the new journalling ones like ext3 or reiserfs, if you're running a kernel recent enough to support them or can compile one that does. E.g. mke2fs /dev/partition Then mount the first partition e.g. under /mnt mount /dev/partition /mnt And transfer the data using tar: tar cplf - -C / var | tar xvf - -C /mnt Unmount the partition umount /mnt Mount the other one and do the same thing for /usr: mount /dev/partition tar cplf - -C / usr | tar xvf - -C /mnt umount /mnt Make sure you type the tar commands exactly as above, you don't want to go dropping the entire copnmtents of /var or /usr (or even / if you v=get it wrong) in the wrong place! Edit /etc/fstab and either add lines for /usr and /var, or change existing ones, to mount your new filesystems instead of the old ones. Here's an example: --- fstab excerpt --- /dev/sdb6 /usr ext2 rw 0 2 /dev/sdb7 /var ext2 rw 0 2 --- end fstab excerpt --- Then go to single user mode: telinit S Unmount /usr and /var: umount /usr umount /var Mount all partitions using your new fstab: mount -a Check that everything is mounted where it should be: mount And go back to your usual runlevel (usually 2 on Debian): telinit 2 That's it. Note that if /usr and /var were originally part of your root filesystem, the data will still be there but the new filesystem will be mounted on the top level directory so you won't see it. After you've successfully transferred /usr and /var out of the root filesystem, you can reclaim the space by going to single user mode, unmounting /usr and /var, and doing the following: rm -rvf /var rm -rvf /usr mkdir /var mkdir /usr Be VERY careful that /usr and /var are NOT mounted when you do this! Also note, a space or a slash in the wrong place in either of the above commands can wreck your system completely! Good luck, | George Karaolides Linustech Advanced Solutions, | | tel: +357 22 55 61 29 86 Ifigenias Street, 3rd Floor, | | web: www.linustech.com.cy Strovolos, Nicosia CY 2003, | | email: [EMAIL PROTECTED] Republic of Cyprus. | On Tue, 12 Mar 2002, Andrew Stephen wrote: Hi My /var and /usr partitions have just run out of space and I was wondering what is the best way to copy them to a new drive that has just been installed. Any suggestions would be greatly appreciated. Regards, Andrew -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Moving /var to another drive
On Tue, Mar 12, 2002 at 04:42:37PM +0100, François Chenais wrote: And what happens if the /var/log and /var/run dirs that can change during the tar ? That's my main disagreement with George's instructions. Go to single-user mode _before_ you copy /var and /usr to the new drive instead of after copying them. This will shut down all the various daemons that might be modifying data while you work. (The lesser disagreement is that I would use cpio instead of tar, but that's really just a matter of taste.) So, how I do it: 1. Shut down machine[1] 2. Install new drive 3. Boot to single-user mode 4. cfdisk /dev/hdnew 5. mount /dev/hdnewvar /mnt 6. cd /var 7. find . -xdev -print0 | cpio -pvdm0 /mnt 8. umount /mnt 9. Repeat steps 5-8 for /usr 10. Update /etc/fstab 11. Reboot or 11. umount /var umount /usr mount -a init 2 [1] I'm assuming that the box is not hot-swap capable, so you have to power down to install the new drive. If it is hot-swappable, just plug the drive in and use `init 1` to get to single-user mode. -- When we reduce our own liberties to stop terrorism, the terrorists have already won. - reverius Innocence is no protection when governments go bad. - Tom Swiss
Re: Moving /var to another drive
On Tue, Mar 12, 2002 at 03:33:55PM +0200, George Karaolides wrote: That's it. Note that if /usr and /var were originally part of your root filesystem, the data will still be there but the new filesystem will be mounted on the top level directory so you won't see it. After you've successfully transferred /usr and /var out of the root filesystem, you can reclaim the space by going to single user mode, unmounting /usr and /var, and doing the following: rm -rvf /var rm -rvf /usr mkdir /var mkdir /usr Be VERY careful that /usr and /var are NOT mounted when you do this! Also note, a space or a slash in the wrong place in either of the above commands can wreck your system completely! Good warnings. I would also recommend doing a `ls -ld /usr /var /tmp/perms` before deleting the old directories, then double-checking that the ownership and permissions on them are correct after creating and mounting the new ones. -- When we reduce our own liberties to stop terrorism, the terrorists have already won. - reverius Innocence is no protection when governments go bad. - Tom Swiss
Re: Moving /var to another drive
* François Chenais ([EMAIL PROTECTED]) spake thusly: And what happens if the /var/log and /var/run dirs that can change during the tar ? You may end up with a slightly b0rked system (but you knew that already). If your /var was on the root drive, you'll have to delete its contents before mounting new /var -- otherwise nfs-mounted /var will mask the old one, and contents of old /var will still be there, using up disk space. Of course you'd better stop the daemons whose log and run files you're deleting. So you'll do that in a single-user mode, with all daemons stopped anyway, and then /var/run and /var/log won't change during tar. Dima -- We're sysadmins. Sanity happens to other people. -- Chris King
Re: Moving /var to another drive
George Karaolides [EMAIL PROTECTED] wrote: Hi Andrew, snip And transfer the data using tar: tar cplf - -C / var | tar xvf - -C /mnt snip I recently did something similar, moving my personal files to a new HD so that I can mount the entire drive (partitioned as one big drive) to /home/nl for my personal files. Interestingly, because I now have an entire ext2fs file system mounted as my home directory, I now have a lost+found directory in my home directory. Not, obviously, a big problem, just something to keep in mind. One thing I wondered about, though. You are using the technique of taring up the entire directory tree and then untaring it into the target partition. Why not just use cp -a source target instead? N
Re: Moving /var to another drive
* Neal Lippman ([EMAIL PROTECTED]) spake thusly: ... One thing I wondered about, though. You are using the technique of taring up the entire directory tree and then untaring it into the target partition. Why not just use cp -a source target instead? Tradition, portability. cp -a is a GNUism, there was no cp -a back when, and there is no cp -a on many systems now. It doesn't matter if you are not going to use a Real Unix(tm), ever; those who do prefer to learn portable ways of doing things. Dima -- Q276304 - Error Message: Your Password Must Be at Least 18770 Characters and Cannot Repeat Any of Your Previous 30689 Passwords -- RISKS 21.37
Re: Moving /var
on Mon, Aug 27, 2001 at 08:33:04PM -0700, Eric G. Miller (egm2@jps.net) wrote: On Mon, Aug 27, 2001 at 08:09:15PM -0700, Jason Majors wrote: I currently have /var on hdc, but want to move it to sda. I've tried mounting the new partition as var2, copying the files, changing fstab, then rebooting, but lots of programs complain. I'd guess it has something to do with the state of var at the time of the copy, vs at the time of shutdown/boot. That method works well for home, usr, etc. Is there a good way to do this for var? other than reinstalling? Thanks. Jason Definitely go into single user mode first (telint 1). You don't want processes writing to log files, spool files, etc... while you do the migration. When you're finished, your new partition should be mounted as /var /dev/sda? or programs will certainly complain. 1. Go Single User 2. mount -t ext2 /mnt /dev/sdaX I would add at this point: mount -o remount,ro /var ...which ensures that your existing /var is readonly. If anything's actively trying to write at that point, you'll know about it. 3. Copy files via your favorite method (cp -a /var /mnt should work). 4. umount /mnt 5. umount /var 6. Edit fstab to point /var at /dev/sdaX 7. mount /var (now on the new disk) 8. exit (go back to multi-user mode) -- Karsten M. Self kmself@ix.netcom.com http://kmself.home.netcom.com/ What part of Gestalt don't you understand? There is no K5 cabal http://gestalt-system.sourceforge.net/ http://www.kuro5hin.org Free Dmitry! Boycott Adobe! Repeal the DMCA!http://www.freesklyarov.org Geek for Hirehttp://kmself.home.netcom.com/resume.html pgpE37kQaGHRs.pgp Description: PGP signature
Moving /var
I currently have /var on hdc, but want to move it to sda. I've tried mounting the new partition as var2, copying the files, changing fstab, then rebooting, but lots of programs complain. I'd guess it has something to do with the state of var at the time of the copy, vs at the time of shutdown/boot. That method works well for home, usr, etc. Is there a good way to do this for var? other than reinstalling? Thanks. Jason
Re: Moving /var
On Mon, Aug 27, 2001 at 08:09:15PM -0700, Jason Majors wrote: I currently have /var on hdc, but want to move it to sda. I've tried mounting the new partition as var2, copying the files, changing fstab, then rebooting, but lots of programs complain. I'd guess it has something to do with the state of var at the time of the copy, vs at the time of shutdown/boot. That method works well for home, usr, etc. Is there a good way to do this for var? other than reinstalling? Thanks. Jason Definitely go into single user mode first (telint 1). You don't want processes writing to log files, spool files, etc... while you do the migration. When you're finished, your new partition should be mounted as /var /dev/sda? or programs will certainly complain. 1. Go Single User 2. mount -t ext2 /mnt /dev/sdaX 3. Copy files via your favorite method (cp -a /var /mnt should work). 4. umount /mnt 5. umount /var 6. Edit fstab to point /var at /dev/sdaX 7. mount /var (now on the new disk) 8. exit (go back to multi-user mode) When moving partitions it's important to use a method that preserves permissions. Otherwise all hell can break loose... When your comfortable with the transfer, reclaim the original /var for some other use. -- Eric G. Miller egm2@jps.net
Re: Troubles with moving /var
On Mon, Dec 20, 1999 at 09:58:51PM -0500, Brian Servis wrote *- On 20 Dec, Ethan Benson wrote about Re: Troubles with moving /var On 20/12/99 aphro wrote: cp -a doesn't work on more obscure platforms like irix..there is a tar command..that acts like cp -a i saw it posted in a magazine(Maximum Linux) but i forgot what it was, if its linux its safe to use cp -a probably something like (cd / ; tar -cvpf - var) | (cd /home ; tar -xvpf -) quite a bit more obnoxious then cp -a for sure, but iirc it seemed to deal with symlinks a bit better. there is a cpio way too but i'll leave that to someone else. the key is when using tar use the -p switch !! :-) cd /var; find . -mount | cpio -dumpv /home/var has done the trick for me several times. I use # cd /source/dir/ ; find . -xdev | afio -p /dest/dir/ afio is the only one (of tar, afio and cpio) that has successfully done everything asked of it. Any of the following may not get copied correctly with one or another version of the other two: special files (block character devices) sockets named pipes sparse files long pathnames symlinks hard links I'm sure it's not perfect, but it hasn't failed me yet. John P. -- [EMAIL PROTECTED] [EMAIL PROTECTED] Oh - I - you know - my job is to fear everything. - Bill Gates in Denmark
Re: Troubles with moving /var
On 20/12/99 aphro wrote: cp -a doesn't work on more obscure platforms like irix..there is a tar command..that acts like cp -a i saw it posted in a magazine(Maximum Linux) but i forgot what it was, if its linux its safe to use cp -a probably something like (cd / ; tar -cvpf - var) | (cd /home ; tar -xvpf -) quite a bit more obnoxious then cp -a for sure, but iirc it seemed to deal with symlinks a bit better. there is a cpio way too but i'll leave that to someone else. the key is when using tar use the -p switch !! :-) -- Ethan Benson To obtain my PGP key: http://www.alaska.net/~erbenson/pgp/
Re: Troubles with moving /var
*- On 20 Dec, Ethan Benson wrote about Re: Troubles with moving /var On 20/12/99 aphro wrote: cp -a doesn't work on more obscure platforms like irix..there is a tar command..that acts like cp -a i saw it posted in a magazine(Maximum Linux) but i forgot what it was, if its linux its safe to use cp -a probably something like (cd / ; tar -cvpf - var) | (cd /home ; tar -xvpf -) quite a bit more obnoxious then cp -a for sure, but iirc it seemed to deal with symlinks a bit better. there is a cpio way too but i'll leave that to someone else. the key is when using tar use the -p switch !! :-) cd /var; find . -mount | cpio -dumpv /home/var has done the trick for me several times. -- Brian Servis -- Mechanical Engineering | Never criticize anybody until you Purdue University | have walked a mile in their shoes, [EMAIL PROTECTED] | because by that time you will be a http://www.ecn.purdue.edu/~servis | mile away and have their shoes.
Re: Troubles with moving /var
Ciao Alberto Bigazzi, I actually did it by hand, by tar-ing /var, copying it under /home and untaring it there. Then deleting /var and symlinking /home/var to /var. But I guess this is something VERY BAD as I ended up with lots of problems with PERMISSIONS. Now normal users CANNOT write into directories under /var, like /var/log or /var/lock, so I get lots of troubles of any kind... I have done the same things, with the same errors... :-) I think that the problems are all that daemons that don't want to recognize the changes. shutdown now should fix all (or stop restart all daemons). Ciao -- Paolo Pedaletti, Como, ITALYa paolo . pedaletti @ flashnet . it
Troubles with moving /var
The / partition on my home PC is fairly small and sometimes gets filled up because ov /var, so I've decided to migrate /var somewhere else. I have /usr and /home as separate partitions and would like to leave /usr alone, thus putting /var under /home, which is quite large and nearly unused (it's just a home PC, and use it to connect to the 'real' one at work). Q: Which is the correct way to do this? === I actually did it by hand, by tar-ing /var, copying it under /home and untaring it there. Then deleting /var and symlinking /home/var to /var. But I guess this is something VERY BAD as I ended up with lots of problems with PERMISSIONS. Now normal users CANNOT write into directories under /var, like /var/log or /var/lock, so I get lots of troubles of any kind... Alberto.
Re: Troubles with moving /var
On 20/12/99 Alberto Bigazzi wrote: I actually did it by hand, by tar-ing /var, copying it under /home and untaring it there. Then deleting /var and symlinking /home/var to /var. But I guess this is something VERY BAD as I ended up with lots of problems with PERMISSIONS. Now normal users CANNOT write into directories under /var, like /var/log or /var/lock, so I get lots of troubles of any kind... sounds like you forgot the -p switch to tar, which preserves the permissions, without it everything gets set according to your (probably root's) umask, if you have already nuked the real /var then your in for a bunch of chmoding i suppose.. I am not sure the best way to find out what the permissions are supposed to be other then have someone send you a recursive ls -l of their /var hierarchy. I am not aware of any quick way to restore the permissions to the proper values other then manually at this point, perhaps someone else has some ideas? just a couple i can tell you now, /var/lock is mode 1777, /var/log is mode 755 (users should not be able to write there), /var/spool/mail is mode 2775 those are the most important `special' directories i can think of right now, but there are several daemons with special directories under /var that have different owners/modes to allow them to run non-root. always mv the old directory out of the way and test your change before rm -rfing it ! :-) -- Ethan Benson To obtain my PGP key: http://www.alaska.net/~erbenson/pgp/
Re: Troubles with moving /var
i moved /var /home /usr with the command cp -a which preserves everything, i did it on 2 main servers and have nbot had a single problem so i bet its a safe way of doing it(the servers have been online since april) cp -a doesn't work on more obscure platforms like irix..there is a tar command..that acts like cp -a i saw it posted in a magazine(Maximum Linux) but i forgot what it was, if its linux its safe to use cp -a nate On Mon, 20 Dec 1999, Alberto Bigazzi wrote: albbig albbig The / partition on my home PC is fairly small and sometimes gets filled albbig up because ov /var, so I've decided to migrate /var somewhere else. albbig albbig I have /usr and /home as separate partitions and would like to leave /usr albbig alone, thus putting /var under /home, which is quite large and nearly albbig unused (it's just a home PC, and use it to connect to the 'real' one at albbig work). albbig albbig Q: Which is the correct way to do this? albbig === albbig albbig I actually did it by hand, by tar-ing /var, copying it under /home and albbig untaring it there. Then deleting /var and symlinking /home/var to /var. albbig albbig But I guess this is something VERY BAD as I ended up with lots of problems albbig with PERMISSIONS. Now normal users CANNOT write into directories under albbig /var, like /var/log or /var/lock, so I get lots of troubles of any albbig kind... albbig albbig Alberto. albbig albbig albbig albbig albbig -- albbig Unsubscribe? mail -s unsubscribe [EMAIL PROTECTED] /dev/null albbig [mailto:[EMAIL PROTECTED] ]-- Vice President Network Operations http://www.firetrail.com/ Firetrail Internet Services Limited http://www.aphroland.org/ Everett, WA 425-348-7336http://www.linuxpowered.net/ Powered By:http://comedy.aphroland.org/ Debian 2.1 Linux 2.0.36 SMPhttp://yahoo.aphroland.org/ -[mailto:[EMAIL PROTECTED] ]-- 7:23am up 122 days, 19:13, 2 users, load average: 0.42, 0.33, 0.30
moving /var to another partition??
Hi, I'm setting up to upgrade my system to potato (while I sleep :) and know that there's not enough room in /var/cache/apt/archives/. I've got another partition to work with and could either symlink that dir to the new partition, or move /var over (it's on it's own part. now). Question is... which is likely best? Or should I go into mtab and mount the new partition at /var/cache/apt/archives/ (if that's possible)? And am I correst in thinking that a cp -aR /var/* /newpartition followed by mtab changes is correct for shifting partitions? I seem to recall this as the MO for such stuff. Does apt go outside of /var/cache/apt/archives/ for unpacking? I.e. could I run into space problems elsewhere? /tmp is on a partition with ~70 Mb free. Thanks! Kenward Vaughan
Re: moving /var to another partition??
On Wed, 1 Sep 1999 [EMAIL PROTECTED] wrote: Question is... which is likely best? Or should I go into mtab and mount the new partition at /var/cache/apt/archives/ (if that's possible)? You're on the right track. The correct solution is: mount -text2 /dev/whatever /var/cache/apt/archives You should never edit mtab yourself. It is maintained by the mount and umount commands and editing it will cause bad things to happen.
RE: moving /var to another partition??
On 01-Sep-99 [EMAIL PROTECTED] wrote: Hi, I'm setting up to upgrade my system to potato (while I sleep :) and know that there's not enough room in /var/cache/apt/archives/. I've got another partition to work with and could either symlink that dir to the new partition, or move /var over (it's on it's own part. now). Question is... which is likely best? Or should I go into mtab and mount the new partition at /var/cache/apt/archives/ (if that's possible)? *slap* mtab is a run time created file by the working system, do not change it, do not touch it. Even if you do change it -- nothing happens. Change /etc/fstab. And am I correst in thinking that a cp -aR /var/* /newpartition followed by mtab changes is correct for shifting partitions? I seem to recall this as the MO for such stuff. Yes, move the data over than place a mount /dev/??? /var in fstab.
Re: moving /var to another partition??
On Wed, 1 Sep 1999 [EMAIL PROTECTED] wrote: : Hi, : : I'm setting up to upgrade my system to potato (while I sleep :) and know : that there's not enough room in /var/cache/apt/archives/. I've got another : partition to work with and could either symlink that dir to the new : partition, or move /var over (it's on it's own part. now). : : Question is... which is likely best? Or should I go into mtab and mount the : new partition at /var/cache/apt/archives/ (if that's possible)? Don't touch /etc/mtab; use /etc/fstab instead. You could mount your new filesystem on /var/cache/apt/archives/ if you like. : And am I correst in thinking that a :cp -aR /var/* /newpartition : followed by mtab changes is correct for shifting partitions? I seem to : recall this as the MO for such stuff. I prefer this: cd /var; find . -xdev -print | cpio -padm /target Replace var with the source dir, /target with the mountpoint of the new fs (usually /mnt around here) Again, you want to change /etc/fstab, not /etc/mtab. It's generally best to go to single-user (init 1) if you're going to move filesystems around. -- Nathan Norman MidcoNet 410 South Phillips Avenue Sioux Falls, SD mailto:[EMAIL PROTECTED] http://www.midco.net finger [EMAIL PROTECTED] for PGP Key: (0xA33B86E9)
Re: moving /var to another partition??
On Wed, Sep 01, 1999 at 12:54:31PM -0700, Sean 'Shaleh' Perry wrote: On 01-Sep-99 [EMAIL PROTECTED] wrote: [...] Question is... which is likely best? Or should I go into mtab and mount th new partition at /var/cache/apt/archives/ (if that's possible)? *slap* mtab is a run time created file by the working system, do not change it, do n touch it. Even if you do change it -- nothing happens. Change /etc/fstab. @#$%^!! Sorry, forget my V8 today. Duh. Thanks to you and the others about this. Kenward
