Lars Noodin wrote: > Nick Holland wrote: >> ... >> In general, it seems to be bad to drastically change the disklabel on a >> running system (i.e., changing the beginning and ending points of a >> currently mounted partition). >> >> HOWEVER, if you can do it from bsd.rd, it should be no problem. > > I was booting from a live CD on the target system and running various > commands via SSH against the source. I could copy fine (using dd, tar, > rsync and dump), but lack the knowledge about how to zap the > disklabels/partitions/repartition all at once.
well, from a live CD, that's easy, then. Your fdisk partition table is the very first sector of the disk. Your OpenBSD disklabel is in the beginning of the 'a' partition. By the time you copy the first 100 sectors of the disk, you have replaced both. Just keep going until you run out of disk. dd if=/dev/wd0c of=/some/place/on/wd1/disk.img will get your entire disk put on a file. (through a bs= on there. I did a little testing recently. On the system I was working with, "bs=64k" was about optimal, definitely faster than "bs=512k" and much faster than no "bs=" line. Bigger is better to a very finite limit) >> The one-line part is just a dangerous stunt, really. Make one error, >> and it goes bad quickly. > > That's the fun of it. :O something like this: dd if=/dev/wd0c |ssh [EMAIL PROTECTED] "dd of=/dev/wd1c/" As I never get things like that right the first time, and in this case, I'm not consulting anything other than my non-parity checked, non-ECC memory, if you tell me that worked, I'll be amazed. But..."something like that". I actually did something like that Friday to migrate a 40G disk to a 500G disk, dd'ing each partition over its new, resized partition on the new disk. Worked pretty well, on my third or fourth try. :) (important tips: if you 'dd' over rwd0a, you will blow away your disklabel. Don't do that. You want to dd over 'wd0a', not the "raw" device. On the other hand, your OTHER partitions, you probably want the "raw" device, as it goes about ten times as fast). After the partitions are migrated, 'growfs' them to "fluff" them back out to their new size. I developed this process on a system that dump and tar just wouldn't cut it for (rsync backup system, massive numbers of hard links, tar couldn't handle the depth, dump ran out of memory after running for many, many hours). dd worked fine and fast. 'course, by last Friday, I forgot all my lessons from the last time and had to learn 'em all over again. :) Nick.
