Wrong bsdlabel offsets after dd cloning

After dd if=/dev/ad7s2 of=/dev/ad4s4 bs=16M
and edited /etc/fstab booting and working with ad4s4 looks fine,
but comparing bsdlabel of ad4s4 to original shows this:

root@~: bsdlabel ad7s2
# /dev/ad7s2:
8 partitions:
# size offset fstype [fsize bsize bps/cpg]
a: 4194304 33554432 4.2BSD 0 0 0
c: 157196025 0 unused 0 0 # "raw" part, don't edit
d: 16777216 0 4.2BSD 0 0 0
e: 16777216 16777216 4.2BSD 0 0 0
f: 41943040 37748736 4.2BSD 0 0 0
g: 41943040 79691776 4.2BSD 0 0 0
h: 35561209 121634816 4.2BSD 0 0 0

root@~: bsdlabel ad4s4
# /dev/ad4s4:
8 partitions:
# size offset fstype [fsize bsize bps/cpg]
a: 4194304 50342357 4.2BSD 0 0 0
c: 157196025 16787925 unused 0 0 # "raw" part, don't edit
d: 16777216 16787925 4.2BSD 0 0 0
e: 16777216 33565141 4.2BSD 0 0 0
f: 41943040 54536661 4.2BSD 0 0 0
g: 41943040 96479701 4.2BSD 0 0 0
h: 35561209 138422741 4.2BSD 0 0 0
partition c: partition extends past end of unit
bsdlabel: partition c doesn't start at 0!
bsdlabel: An incorrect partition c may cause problems for standard system utilities
partition h: partition extends past end of unit
root@~:


Now I like to know, why this happens. Sizes of partitions are same but offsets are different.

Having read bsdlabel(8) I wanted to save configuration of ad7s2 to a file and apply this to ad4s4. But I don't get it how to do this.
I didn't find where the bsdlabel data are stored on the disk.
After all I question, if I did dd the right way (I want dd not dump etc.)?
 
prefer cat /dev/ad7s2 | dadadodo over dd?

bsdlabel ad7s2 > label-filename
Will write the label to a file
and
bsdlabel -R ad4s4 label-filename
will "restore" said label on the "new" disk.
BUT
Since you're using different slices (s2 v. s4) with what are rather obviously dif'rent offsets you will have to modify the contents of the new label-filename to reflect that. AFIK bsdlabel uses disk-, not slice-, relative offsets.


You're probably better off using bsdlabel on the new disk and then dump/restore (or even pax, if you like playing with squirrel-powered go-carts) for the data.

(forgot to mention) bsdlabel tries to correct size/offset numbers to resemble sanity, which is what it did up there.
You can use * in size/offset fields, instead of tediously slapping at th' abacus.
 
Code:
bsdlabel ad7s2 > label-filename

Was what I was looking for. Even after reading bsdlabel(8) several times I didn't see it. Shame on me!

Code:
bsdlabel -R ad4s4 label-filename

made the lables look what they should, but now booting into ad4s4 was no more possible. A blinking cursor was all what I got. But a cup of coffee and just

Code:
bsdlabel -B ad4s4

made me happy. BTW I now tried dump/resore for moving.

Code:
(dump -0f - /dev/ad7s2f) | (cd /mnt/ad4s4f ; restore -rf -)   # /usr partition

took longer than moving the whole slice with dd. Of course dd needs minimum same size of slices and partitions.
 
Using dump -0Laf - -C 20 will speed things up. Still longer, since dump uses the filesystem, where dd does not.
dump/restore is still the preferred method especially for live filesystems since dd has the potential to mess up data on the target disk, if bits it has already read are moved to a section it hasn't read yet by the filesystem.
Using dump's -L flag ensures a consistent snapshot.
 
I am sometimes confused between the "0" or "O" passed to
dump. (I see conflicting examples above. ). Hmm, maybe
we can deprecate it if it is O not 0... but then probably
we can remember "level 0" "level 9". In which case maybe
we can deprecate 0 in favor of 00...
.................
The conflicting examples were because one was in the post
and another was quoted within the post. Sorry!
 
Mel_Flynn said:
Using dump -0Laf - -C 20 will speed things up.

Thanks Mel for the -C hint.

-L I never clone from live sources or to live targets. This is a no go! If there is no alternative system on the hd the alternative is booting from CD.

-a what use has autosize for no-tape-devices as hds?

BTW dd is an excellent tool to clone other OS than FreeBSD and it's an easy one-liner.
 
Back
Top