Date: Sat, 19 Jun 1999 00:54:05 -0400 (EDT) From: "Crist J. Clark" <cjc@cc942873-a.ewndsr1.nj.home.com> To: dwhite@resnet.uoregon.edu (Doug White) Cc: holtor@yahoo.com, freebsd-questions@FreeBSD.ORG Subject: Re: Remote Format? Message-ID: <199906190454.AAA17230@cc942873-a.ewndsr1.nj.home.com> In-Reply-To: <Pine.BSF.4.10.9906181744590.34137-100000@resnet.uoregon.edu> from Doug White at "Jun 18, 99 05:45:34 pm"
next in thread | previous in thread | raw e-mail | index | archive | help
Doug White wrote, > On Wed, 16 Jun 1999, Holtor wrote: > > > I've got several machines up at a colocation. > > On one machine, I have 2 hd's. What I want to do. > > Is backup my second HD on the first one, format > > it, and slice it up into a 500 meg /tmp and the > > rest back to the second HD, then restore.. > > Since my machine is a colo, I've got no console > > access to it..would it be a wise idea to do this > > remotly? Please advise..i'd really like to split up > > this drive if possible into a /tmp. > > Probably not since it involves a reboot, Huh? It does? Not the way I read it. > and you could flub the partition > table setup and lock yourself out with 'No Operating System' sitting on > the console. :-) If he was mucking with the system partition or boot labels, I would agree. However, I don't think he is. And in that case, I don't see how local or remote would make much difference. Here're the steps I see (assuming the second disk is slice '1' and partition 'g' mounted at /usr/home), 1) Backup the second drive. I /assume/ you have enough space for the whole second drive in _one_ partition of the first? I'll assume that you are playing this risky and are tight for space, # dump -a0 -f - /usr/home | gzip > /usr/tmp/dump_da1.gz # umount /usr/home 2) OK, now, my preference is to edit a disklabel file, edit it, then read the edited version back in. (You might even make the new label as the first step in the whole process.) # disklabel -r da1 > da1.dsklbl # your-favorite-editor da1.dsklbl In the editor, make the new halved partitions. Let's call the new one 'h'. Double-check the new label is correct. Triple-check. Now write the label, # disklabel -R -r da1 da1.dsklbl 3) OK, kewl, you have a new label... BUT this next step is the destructive one from which there is no turning back! # newfs /dev/da1s1g # newfs /dev/da1s1h 4) Whoo! Shiny new partitions on drive 1! Now, let's restore the one that was there before, # mount /dev/da1s1g /usr/home # cd /usr/home # gunzip -c /usr/tmp/usr.home_da1.dmp | restore -rf - 5) OK, now the matter of your new /tmp. The current /tmp might have important files, and some disruption might be unavoidable if we move them. But a reboot is a big disruption too. # mv /tmp /oldtmp # mkdir tmp # mount /dev/da1s1h /tmp # cd /tmp # tar cf - -C /oldtmp . | tar xf - <check the move was OK, then...> # rm -rf /oldtmp 6) OK, almost done! Just add a line to the /etc/fstab to mount your new /tmp at startup. Oh, and we have that whole big backup of the old drive, 'rm /usr/tmp/usr.home_da1.dmp'. OK... Now I did not see a need to reboot anywhere in there. But as I mentioned, moving /tmp can break things that have open files there, a reboot might not be too bad of an idea depending on just what this box does and is running. Did I miss anything? And was that what you were asking? :) -- Crist J. Clark cjclark@home.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-questions" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199906190454.AAA17230>