Re: / slice too small

2010-03-04 Thread krad
2010/3/4 Malcolm Kay malcolm@internode.on.net

 On Thu, 4 Mar 2010 02:44 am, krad wrote:
  On 3 March 2010 14:23, Malcolm Kay
 malcolm@internode.on.net wrote:
   On Mon, 1 Mar 2010 08:44 am, krad wrote:
On 28 February 2010 15:42, Elias Chrysocheris
  
   elias...@cha.forthnet.grwrote:
 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
  FilesystemSizeUsed   Avail Capacity  Mounted
  on /dev/ad4s2190M146M 29M84%/
  devfs 1.0K1.0K  0B   100%/dev
  /dev/ad4s4129G 15G104G12%/usr
  devfs 1.0K1.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-unsubscr...@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.

 Sorry i misread


  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.


This is not a problem in our scenario as the backend storage is zfs and all
underpinned with snapshots. This enables us to retrieve and file from any
day for the last x days dependent on the retention period.



 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
___

Re: / slice too small

2010-03-04 Thread Malcolm Kay
On Thu, 4 Mar 2010 08:23 pm, krad wrote:
 2010/3/4 Malcolm Kay malcolm@internode.on.net

  On Thu, 4 Mar 2010 02:44 am, krad wrote:
   On 3 March 2010 14:23, Malcolm Kay
 
  malcolm@internode.on.net wrote:
On Mon, 1 Mar 2010 08:44 am, krad wrote:
 On 28 February 2010 15:42, Elias Chrysocheris
   
elias...@cha.forthnet.grwrote:


 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.
 
  Sorry i misread
 
   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.

 This is not a problem in our scenario as the backend storage
 is zfs and all underpinned with snapshots. This enables us to
 retrieve and file from any day for the last x days dependent
 on the retention period.

Sounds good. I have no experience with zfs. But I suggest that 
'x' needs to be quite large.

Anyway I think we (or rather I) have done the subject to death,
and it is time for me to keep quiet.

Regards,
Malcolm


___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org


Re: / slice too small

2010-03-03 Thread Malcolm Kay
On Mon, 1 Mar 2010 08:44 am, krad wrote:
 On 28 February 2010 15:42, Elias Chrysocheris 
elias...@cha.forthnet.grwrote:
  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
   FilesystemSizeUsed   Avail Capacity  Mounted on
   /dev/ad4s2190M146M 29M84%/
   devfs 1.0K1.0K  0B   100%/dev
   /dev/ad4s4129G 15G104G12%/usr
   devfs 1.0K1.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-questions
  To unsubscribe, send any mail to 
  freebsd-questions-unsubscr...@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.

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-questions
 To unsubscribe, send any mail to
 freebsd-questions-unsubscr...@freebsd.org
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org


Re: / slice too small

2010-03-03 Thread krad
On 3 March 2010 14:23, Malcolm Kay malcolm@internode.on.net wrote:

 On Mon, 1 Mar 2010 08:44 am, krad wrote:
  On 28 February 2010 15:42, Elias Chrysocheris
 elias...@cha.forthnet.grwrote:
   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
FilesystemSizeUsed   Avail Capacity  Mounted on
/dev/ad4s2190M146M 29M84%/
devfs 1.0K1.0K  0B   100%/dev
/dev/ad4s4129G 15G104G12%/usr
devfs 1.0K1.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-questions
   To unsubscribe, send any mail to 
   freebsd-questions-unsubscr...@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.

Also using the a flag means the modification times are intact.

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.

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.



 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-questions
  To unsubscribe, send any mail to
  freebsd-questions-unsubscr...@freebsd.org
 ___
 freebsd-questions@freebsd.org mailing list
 http://lists.freebsd.org/mailman/listinfo/freebsd-questions
 To unsubscribe, send any mail to 
 freebsd-questions-unsubscr...@freebsd.org

___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org


Re: / slice too small

2010-03-03 Thread Malcolm Kay
On Thu, 4 Mar 2010 02:44 am, krad wrote:
 On 3 March 2010 14:23, Malcolm Kay 
malcolm@internode.on.net wrote:
  On Mon, 1 Mar 2010 08:44 am, krad wrote:
   On 28 February 2010 15:42, Elias Chrysocheris
 
  elias...@cha.forthnet.grwrote:
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
 FilesystemSizeUsed   Avail Capacity  Mounted
 on /dev/ad4s2190M146M 29M84%/
 devfs 1.0K1.0K  0B   100%/dev
 /dev/ad4s4129G 15G104G12%/usr
 devfs 1.0K1.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-unsubscr...@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-unsubscr...@freebsd.org
 
  ___
  freebsd-questions@freebsd.org mailing list
  http://lists.freebsd.org/mailman/listinfo/freebsd-questions
  To unsubscribe, send any mail to 
  

Re: / slice too small

2010-03-03 Thread Malcolm Kay
On Mon, 1 Mar 2010 08:44 am, krad wrote:
 On 28 February 2010 15:42, Elias Chrysocheris 
elias...@cha.forthnet.grwrote:
  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
   FilesystemSizeUsed   Avail Capacity  Mounted on
   /dev/ad4s2190M146M 29M84%/
   devfs 1.0K1.0K  0B   100%/dev
   /dev/ad4s4129G 15G104G12%/usr
   devfs 1.0K1.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-questions
  To unsubscribe, send any mail to 
  freebsd-questions-unsubscr...@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

To preserve extended flags set with chflags you also need
  --fileflags
and the fileflags patch enabled on installing rsync.
For example look at:
#ls -lo /var
and note flag on empty. 

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-questions
 To unsubscribe, send any mail to
 freebsd-questions-unsubscr...@freebsd.org
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org


Re: / slice too small

2010-02-28 Thread Elias Chrysocheris
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
 FilesystemSizeUsed   Avail Capacity  Mounted on
 /dev/ad4s2190M146M 29M84%/
 devfs 1.0K1.0K  0B   100%/dev
 /dev/ad4s4129G 15G104G12%/usr
 devfs 1.0K1.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-questions
To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org


[Fwd: Re: / slice too small]

2010-02-28 Thread Peter Ulrich Kruppa
Sorry, I forgot to include the list!

Uli.



 Weitergeleitete Nachricht 
 Von: Peter Ulrich Kruppa ulr...@pukruppa.net
 An: Frank Shute fr...@shute.org.uk
 Betreff: Re: / slice too small
 Datum: Sun, 28 Feb 2010 15:52:05 +0100
 
 Am Sonntag, den 28.02.2010, 13:26 + schrieb Frank Shute:
  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
  FilesystemSizeUsed   Avail Capacity  Mounted on
  /dev/ad4s2190M146M 29M84%/
  devfs 1.0K1.0K  0B   100%/dev
  /dev/ad4s4129G 15G104G12%/usr
  devfs 1.0K1.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?
 Check if your /boot/kernel directory *much* bigger than let's say about 45 MB.
 Then you probably have built your kernel with debugging symbols which
 will make it too big for your root partition.
 In /etc/make.conf add the line
   INSTALL_NODEBUG=yes
 and rebuild your kernel.
 
 Good luck
   
 Uli. 
 
  Any suggestions gratefully received.
  
  
  Regards,
  
 

___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org


Re: / slice too small

2010-02-28 Thread krad
On 28 February 2010 15:42, Elias Chrysocheris elias...@cha.forthnet.grwrote:

 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
  FilesystemSizeUsed   Avail Capacity  Mounted on
  /dev/ad4s2190M146M 29M84%/
  devfs 1.0K1.0K  0B   100%/dev
  /dev/ad4s4129G 15G104G12%/usr
  devfs 1.0K1.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-questions
 To unsubscribe, send any mail to 
 freebsd-questions-unsubscr...@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

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-questions
To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org