dd copy of FreeBSD-7.2 won't boot

[jflowers]

I have a remote server that was dd copied from one hard drive to another -
essentially the same size.  The disk device name (ad4) is the same but the
geometry for the new drive has a CHS of 969021/16/63

On booting it hangs at:

F1        FreeBSD
Boot:     F1

I copied the MBR with 'boot0cfg -B -opacket ad4' just to be sure but no joy.  
fbsd fdisk reports start 63, with CHS beg: 0/1/1 end: 1023/15/63.

Any help on direction to solve this?

Thanks.

--
Jim Flowers <jflowers@...>

_______________________________________________
freebsd-hackers@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@..."

[Daniel O'Connor-3]

On Tue, 23 Jun 2009, Jim Flowers wrote:

> I have a remote server that was dd copied from one hard drive to
> another - essentially the same size.  The disk device name (ad4) is
> the same but the geometry for the new drive has a CHS of 969021/16/63
>
> On booting it hangs at:
>
> F1        FreeBSD
> Boot:     F1
>
> I copied the MBR with 'boot0cfg -B -opacket ad4' just to be sure but
> no joy. fbsd fdisk reports start 63, with CHS beg: 0/1/1 end:
> 1023/15/63.
>
> Any help on direction to solve this?

I would have thought that boot0cfg would DTRT.

You could also try running fdisk -BI on your new disk to reinit the MBR,
then running boot0cfg on it.

--
Daniel O'Connor software and network engineer
for Genesis Software - http://www.gsoft.com.au
"The nice thing about standards is that there
are so many of them to choose from."
  -- Andrew Tanenbaum
GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C

[Wojciech Puchar-5]

> I have a remote server that was dd copied from one hard drive to another -
> essentially the same size.  The disk device name (ad4) is the same but the
> geometry for the new drive has a CHS of 969021/16/63
>
> On booting it hangs at:
>
> F1        FreeBSD
> Boot:     F1
>
> I copied the MBR with 'boot0cfg -B -opacket ad4' just to be sure but no joy.
> fbsd fdisk reports start 63, with CHS beg: 0/1/1 end: 1023/15/63.
>
> Any help on direction to solve this?
>

try fdisk -B /dev/ad0

but even better next time don't make slices, only disklabel. It just make
life simpler. I still don't understand why sysinstall by default create
them. It should be only used when windoze has to be run from the same disk
_______________________________________________
freebsd-hackers@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@..."

[Daniel O'Connor-3]

On Tue, 23 Jun 2009, Wojciech Puchar wrote:
> > Any help on direction to solve this?
>
> try fdisk -B /dev/ad0
>
> but even better next time don't make slices, only disklabel. It just
> make life simpler. I still don't understand why sysinstall by default
> create them. It should be only used when windoze has to be run from
> the same disk

There are plenty of BIOSen which will puke on a dangerously dedicated
disk.

Next time he should partition, label & newfs the disk, then copy it over
with dump | store.

Unless the disk is chock full it will be significantly faster.
 

--
Daniel O'Connor software and network engineer
for Genesis Software - http://www.gsoft.com.au
"The nice thing about standards is that there
are so many of them to choose from."
  -- Andrew Tanenbaum
GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C

[krad-2]

Personally id stay away from dd. Create the partitions and file systems
manually, and install the boot loader, then rsync the data across. It will
be a lot faster in most cases, as unlike dd you wont be copying unused
space. Something like this should do the job

Rsync -aPH --exclude=/mnt/** / /mnt

I'm assuming you weren't migrating due to a bad disk

-----Original Message-----
From: owner-freebsd-hackers@...
[mailto:owner-freebsd-hackers@...] On Behalf Of Jim Flowers
Sent: 23 June 2009 05:55
To: freebsd-hackers@...
Subject: dd copy of FreeBSD-7.2 won't boot

I have a remote server that was dd copied from one hard drive to another -
essentially the same size.  The disk device name (ad4) is the same but the
geometry for the new drive has a CHS of 969021/16/63

On booting it hangs at:

F1        FreeBSD
Boot:     F1

I copied the MBR with 'boot0cfg -B -opacket ad4' just to be sure but no joy.

fbsd fdisk reports start 63, with CHS beg: 0/1/1 end: 1023/15/63.

Any help on direction to solve this?

Thanks.

--
Jim Flowers <jflowers@...>

_______________________________________________
freebsd-hackers@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@..."

_______________________________________________
freebsd-hackers@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@..."

[Rick C. Petty-5]

On Wed, Jun 24, 2009 at 11:11:21PM +0100, krad wrote:
> Personally id stay away from dd. Create the partitions and file systems
> manually, and install the boot loader, then rsync the data across. It will
> be a lot faster in most cases, as unlike dd you wont be copying unused
> space. Something like this should do the job

I wouldn't say rsync is faster than dd, unless you have a lot of empty
space or are migrating across a network.  The nice thing about rsync is it
if you restart it, it picks up where it left off so to speak.  With dd you
have to add two arguments.

> Rsync -aPH --exclude=/mnt/** / /mnt
  ^

I often use:

        rsync -avHSPx / /mnt

The "x" means don't cross file system boundaries, which is generally what
you want when migrating file systems.

> I'm assuming you weren't migrating due to a bad disk

Actually using rsync to migrate a bad disk is preferrable over dd
(presuming you have no backup), since rsync will skip and warn you aboud
bad files, but "dd conv=noerror" could leave you in a bad situation if it
skips over critical metadata blocks.  I always try rsync first, with the
source filesystem mounted read-only, and if that fails I'll fall back to
dd.  Actually if you have the space and it was a bad disk, I'd probably dd
to a new disk or file, then mount that disk or file read-only, and then use
rsync.

-- Rick C. Petty
_______________________________________________
freebsd-hackers@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@..."

[jflowers]

I wound up using kraduk's suggestion except for using a snapshot instead of a
live file system.  Because the source disk had suffered DMA errors and a few
files lost to SOFT UPDATE errors, I built a full system first and then let
rsync merge the two.

mount -u -o snapshot /snapshot/snap1 /
mdconfig -a -t vnode -f /snapshot/snap1 -u 4
mount -r /dev/md4 /mnt
mount /dev/ad4s1a /mnt_t
rsync -aPH --exclude=usr/dumps/** /mnt/* /mnt_t
umount /mnt
mdconfig -d -u 4
umount /mnt_t

repeated for all partitions (/ /tmp /var /usr).

Also had to edit transferred fstab to reflect new device name (ad4) and
install a new boot0.

mount /dev/ad4s1a /mnt_t
vi /mnt_t/etc/fstab
umount /mnt_t

fdisk -B -b /boot/boot0 /dev/ad4

18 GB took about 20 minutes to complete snapshots and another 25 minutes to
transfer via rsync.

Thanks for all the help.

On Thu, 25 Jun 2009 10:49:50 -0500, Rick C. Petty wrote

> On Wed, Jun 24, 2009 at 11:11:21PM +0100, krad wrote:
> > Personally id stay away from dd. Create the partitions and file systems
> > manually, and install the boot loader, then rsync the data across. It will
> > be a lot faster in most cases, as unlike dd you wont be copying unused
> > space. Something like this should do the job
>
> I wouldn't say rsync is faster than dd, unless you have a lot of
> empty space or are migrating across a network.  The nice thing about
> rsync is it if you restart it, it picks up where it left off so to
> speak.  With dd you have to add two arguments.
>
> > Rsync -aPH --exclude=/mnt/** / /mnt
>   ^
>
> I often use:
>
> rsync -avHSPx / /mnt
>
> The "x" means don't cross file system boundaries, which is generally
> what you want when migrating file systems.
>
> > I'm assuming you weren't migrating due to a bad disk
>
> Actually using rsync to migrate a bad disk is preferrable over dd
>
> (presuming you have no backup), since rsync will skip and warn you aboud
> bad files, but "dd conv=noerror" could leave you in a bad situation
> if it skips over critical metadata blocks.  I always try rsync first,
>  with the source filesystem mounted read-only, and if that fails
> I'll fall back to dd.  Actually if you have the space and it was a
> bad disk, I'd probably dd to a new disk or file, then mount that
> disk or file read-only, and then use rsync.
>
> -- Rick C. Petty
>
> --
> This message has been scanned for viruses and
> dangerous content by MailScanner, and is
> believed to be clean.

--
Jim Flowers <jflowers@...>

_______________________________________________
freebsd-hackers@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@..."