Date: Thu, 4 Mar 2010 12:21:30 +1030 From: Malcolm Kay <malcolm.kay@internode.on.net> To: krad <kraduk@googlemail.com> Cc: freebsd-questions@freebsd.org Subject: Re: / slice too small Message-ID: <201003041221.30263.malcolm.kay@internode.on.net> In-Reply-To: <d36406631003030814x6774ba65i6ad655b2d1416d3c@mail.gmail.com> References: <20100228132654.GA2796@orange.esperance-linux.co.uk> <201003040053.40894.malcolm.kay@internode.on.net> <d36406631003030814x6774ba65i6ad655b2d1416d3c@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 4 Mar 2010 02:44 am, krad wrote: > On 3 March 2010 14:23, Malcolm Kay <malcolm.kay@internode.on.net> wrote: > > On Mon, 1 Mar 2010 08:44 am, krad wrote: > > > On 28 February 2010 15:42, Elias Chrysocheris > > > > <eliaschr@cha.forthnet.gr>wrote: > > > > On Sunday 28 of February 2010 15:26:54 Frank Shute wrote: > > > > > I've got a machine here running 7.2 which I want to > > > > > upgrade to 8.0 but looking at the root slice it is > > > > > woefully small: > > > > > > > > > > $ df -h > > > > > Filesystem Size Used Avail Capacity Mounted > > > > > on /dev/ad4s2 190M 146M 29M 84% / > > > > > devfs 1.0K 1.0K 0B 100% /dev > > > > > /dev/ad4s4 129G 15G 104G 12% /usr > > > > > devfs 1.0K 1.0K 0B 100% > > > > > /var/named/dev > > > > > > > > > > I've got a CD/DVD writer on that machine along with a > > > > > 100MB ethernet connection to my desktop. > > > > > > > > > > How do I go about upgrading it? Dump/restore and > > > > > change the partition table? > > > > > > > > > > Any suggestions gratefully received. > > > > > > > > > > > > > > > Regards, > > > > > > > > Yes. The dump/restore should do the trick as long as you > > > > have another medium > > > > to store the dumps (such as another hard disk). You will > > > > store the images of > > > > your slices to the new medium using dump(8). You can > > > > then use FixIt console to > > > > re-partition and re-slice your hard disk and then > > > > restore(8) your images in the newly sliced hard disk. > > > > Actually, if you have another hard disk device, you can > > > > use piped dump/restore to copy the whole system from one > > > > disk to the other and make the second one your bootable > > > > disk. Of course you must have sliced the second device > > > > first. > > > > I've done this many times. The first was to remove an > > > > openSUSE partition I had, > > > > living in the same hard disk as my FreeBSD. The second > > > > time was to move my FreeBSD to another hard disk > > > > (physical device). The new disk became my boot disk. > > > > The third time was to move my system to another bigger > > > > hard disk device and at > > > > the same time be formated as ZFS. > > > > Now my system boots from this third hard disk device, > > > > having ZFS and the operating system is the same as that > > > > I first installed (of cource updated...) > > > > > > > > Elias > > > > _______________________________________________ > > > > freebsd-questions@freebsd.org mailing list > > > > http://lists.freebsd.org/mailman/listinfo/freebsd-questi > > > >ons To unsubscribe, send any mail to " > > > > freebsd-questions-unsubscribe@freebsd.org" > > > > > > You might well find it easier to use rsync rather than > > > dump. Just make sure you use the following flags > > > > > > rsync -aHP --numeric-ids > > > > This is a bit questionable for copying live fs. Probably OK > > if you use snapshots. Leaves you in very similar situation > > as doing backups with tar. These schemes also alter the > > access times on files (which I guess doesn't usually matter > > too much). > > > > But dump/restore is no more complex to use than rsync and > > manages snapshots for you, so why mess about with > > questionable schemes. > > I understand what you mean about live file systems, but in > this case its not a problem as he will be in single user mode. I'm not sure that single user mode avoids this problem. > > Also using the "a" flag means the modification times are > intact. I did not mention modification times but access times which I admit are seldom put to any use. It is very difficult for any utility to avoid altering these -- dump is the only exception I know of. > > I use rsync at work over 100s of systems and it is very > effective, and the noc find it far easier to recover small > numbers of files than having to go digging into dump files. > I've not found this too difficult even when working with compressed dumps. > The way we have got everything setup on a zfs backend mean we > can do incremental forever, as well which is much more > efficient than having to do regular level 0 dumps. Yes, rsync is great for updating incremental changes but this is quite irrelevant to the OP's problem. For backup it seems this also somewhat reduces the effectiveness. For example when you are asked to recover the original of a file that was changed before the lastest backup. Many of us think it desirable to regularly archive complete backups. But each to his own; backup methods and strategies have always been something of a controverial issues. > > > Malcolm Kay > > > > > I use it in our backup setup at work, and have restored > > > countless freebsd boxes. > > > > > > When you repartition the drive remember to add the boot > > > blocks > > > > > > eg > > > > > > fdisk -B ad0 > > > bsdlabel -B ad0s1 > > > _______________________________________________ > > > freebsd-questions@freebsd.org mailing list > > > http://lists.freebsd.org/mailman/listinfo/freebsd-question > > >s To unsubscribe, send any mail to > > > "freebsd-questions-unsubscribe@freebsd.org" > > > > _______________________________________________ > > freebsd-questions@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-questions > > To unsubscribe, send any mail to " > > freebsd-questions-unsubscribe@freebsd.org"
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201003041221.30263.malcolm.kay>