Re: / slice too small
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
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
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
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
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
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
/ slice too small
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, -- Frank Contact info: http://www.shute.org.uk/misc/contact.html ___ 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
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]
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
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
