Re: Moving to a bigger HD, is dump still the best way - dump problem
Bill wrote: ... Now here is what I did then... # cd /mnt/newr # ../oldr/sbin/dump 0af - /mnt/oldr | restore rf - (the old drive is also openbsd 3.8) This worked like a charm for the root fs Then I tried the var and I got a slew of errors about the disk being full. But its the /dev/rd* drive thats full. I am guessing its the - part of it. Is it because the restore is not grabbing it as fast as the dump is putting it there? ... I don't have time to verify the error that I'm pretty sure you are making, but you are deviating from the FAQ's instructions, in a way that I'm sure you think doesn't matter, but I'm pretty sure it does. Nick.
Re: Moving to a bigger HD, is dump still the best way - dump problem
Hello! On Mon, Jan 09, 2006 at 01:40:19AM -0500, Bill wrote: [...] Now here is what I did then... # cd /mnt/newr # ../oldr/sbin/dump 0af - /mnt/oldr | restore rf - (the old drive is also openbsd 3.8) This worked like a charm for the root fs Then I tried the var and I got a slew of errors about the disk being full. But its the /dev/rd* drive thats full. dump/restore need some space in /tmp. Just mount a mfs to /tmp so that that doesn't fill up the initial ramdisk. When I move to another disk, I boot from the old one to single user, mount the new one unter /mnt and do the dump/restore for all partitions. I just call mount /tmp manually, /etc/fstab has an entry for an mfs based /tmp on my boxen anyway. [...] Kind regards, Hannah.
Re: Moving to a bigger HD, is dump still the best way - dump problem
In message [EMAIL PROTECTED] so spake Hannah Schroeter (hannah): dump/restore need some space in /tmp. Just mount a mfs to /tmp so that that doesn't fill up the initial ramdisk. Or just point the TMPDIR environment variable to a mounted partition with enough space. - todd
Re: Moving to a bigger HD, is dump still the best way
I recently had to migrate my HD for another reason, and I wrote it all down: http://www.xs4all.nl/~hanb/documents/hd-migration # Han
Re: Moving to a bigger HD, is dump still the best way
Hi! On Mon, Jan 09, 2006 at 05:22:47PM +0059, Han Boetes wrote: I recently had to migrate my HD for another reason, and I wrote it all down: http://www.xs4all.nl/~hanb/documents/hd-migration I think async + softdep as mount option doesn't make sense. And I still think the dump/restore combo will be faster than any other way. And mounting -u the *old* filesystems noatime would make things faster if you still prefer or need to use pax/cpio/cp -R/... (e.g. if you have different partitioning, so that dump/restore won't work). Still, thanks for writing documents like this which might help people see how to combine the basic (and well-documented) tools of the OS for typical tasks. # Han Kind regards, Hannah.
Re: Moving to a bigger HD, is dump still the best way
On Sat, 07 Jan 2006 00:42:18 -0500 Nick Holland [EMAIL PROTECTED] spake: Bill wrote: I found one of my firewalls has a 4Gig drive. While it is still working fine, I am thinking maybe I should remove the 10 year old thing and maybe move it somewhere a little less stressed). I googled and faq'd and nothing recent came up, so I was wondering if this was the best way to move the stuff over. * Put in the new drive * Boot with cd / floppy * Partition new drive with the same layout, but bigger partitions Only do this if you really need it. Leaving much of your disk unallocated has lots of advantages. 4G is a lot for a firewall...look at all the people putting firewalls on 256M and 512M flash media. If you don't have something to put in them, making partitions bigger just makes it take longer to reboot after you trip over the power cord. If you leave a Big Empty at the end of the disk, you can always create a new partition there if something actually gets filled. There's just no reason to allocate every block of a 40G (or 80G, or 160G) disk to a partition in a firewall... Stick your Most Likely to Grow partition at the end of the disk, you can then use growfs to enlarge it, rather than copying the data. * For each, mount old and new and dump from one to the other (per faq) * Recreate devices * Remove old drive reboot Does this seem sane? +reinstall boot blocks. Just did this today on a system, myself. Saw your note, read it, and thought, ...and install boot block. Saw the reply reminding you to reinstall boot block. Did my upgrade, thinking, don't forget to install the boot blocks...of course, I then forgot to install the boot blocks. :-/ But yes, this process works. AFTER you remember to install the boot blocks. ON THE OTHER HAND, if all the machine is is a simple firewall, this is a really good time to simply re-install from scratch, just as you wanted it to be, copying over the config as needed. It will very possibly be faster to simply install OpenBSD on the new disk, enable PF, copy over pf.conf, and get to work, rather than manually copying over all the partitions, one at a time. Forgetting to install the boot blocks is annoying on some systems. :) Nick. What was that about boot blocks? :) I see the wisdom in much of what you are saying. I would like a bit more space, but I think your right and I will not use up all the space. Aside from the practice / experience of doing this under a non-panic solution I'd probably just do a full install - so I can see your point there also. Thanks for all for the comments, suggestions and OPPS to avoid Bill
Moving to a bigger HD, is dump still the best way
I found one of my firewalls has a 4Gig drive. While it is still working fine, I am thinking maybe I should remove the 10 year old thing and maybe move it somewhere a little less stressed). I googled and faq'd and nothing recent came up, so I was wondering if this was the best way to move the stuff over. * Put in the new drive * Boot with cd / floppy * Partition new drive with the same layout, but bigger partitions * For each, mount old and new and dump from one to the other (per faq) * Recreate devices * Remove old drive reboot Does this seem sane? Thanks -- Bill Chmura Director of Internet Technology Explosivo ITG Wolcott, CT p: 860.621.8693 e: [EMAIL PROTECTED] w. http://www.explosivo.com
Re: Moving to a bigger HD, is dump still the best way
On Fri, Jan 06, 2006 at 12:25:25PM -0500, Bill wrote: I found one of my firewalls has a 4Gig drive. While it is still working fine, I am thinking maybe I should remove the 10 year old thing and maybe move it somewhere a little less stressed). I googled and faq'd and nothing recent came up, so I was wondering if this was the best way to move the stuff over. I usually use dump for those kind of tasks. * Put in the new drive * Boot with cd / floppy * Partition new drive with the same layout, but bigger partitions * For each, mount old and new and dump from one to the other (per faq) * Recreate devices I can't imagine any devices that to be recreated. * dont forget to installboot(8) the new disk or else it wont boot. * Remove old drive reboot Does this seem sane? Thanks Janjaap van Velthooven -- / __/ /_/ __/ /_ __/ __/ /___ / / /_ __/___/_/_ /___ / / __/ /___ / / /___/_/_/_/_/_/_/___/_/_/
Re: Moving to a bigger HD, is dump still the best way
On 1/6/06, Bill [EMAIL PROTECTED] wrote: I found one of my firewalls has a 4Gig drive. While it is still working fine, I am thinking maybe I should remove the 10 year old thing and maybe move it somewhere a little less stressed). I googled and faq'd and nothing recent came up, so I was wondering if this was the best way to move the stuff over. * Put in the new drive * Boot with cd / floppy * Partition new drive with the same layout, but bigger partitions * For each, mount old and new and dump from one to the other (per faq) * Recreate devices * Remove old drive reboot Does this seem sane? Yes. Don't forget to add the boot block, and keep in mind the i386 BIOS limitations on the root partition. Kevin
Re: Moving to a bigger HD, is dump still the best way
On Fri, Jan 06, 2006 at 12:25:25PM -0500, Bill wrote: I found one of my firewalls has a 4Gig drive. While it is still working fine, I am thinking maybe I should remove the 10 year old thing and maybe move it somewhere a little less stressed). I googled and faq'd and nothing recent came up, so I was wondering if this was the best way to move the stuff over. * Put in the new drive * Boot with cd / floppy * Partition new drive with the same layout, but bigger partitions * For each, mount old and new and dump from one to the other (per faq) * Recreate devices * Remove old drive reboot Does this seem sane? Yes, but just softRAIDing with a second drive is pretty good too, and avoids having to test the new drive too extensively. (It should still be tested, as you don't want it smoking the entire machine, but it's more fault-tolerant. Especially if you use different busses...) Other than that, it works. Be sure to installboot(8), as pointed out by others. Joachim
