Solved System won't boot after moving to a different disk?

At work I have a 10.3/AMD64 system that currently has root on a UFS2 file system on a single disk, and I'd like to ultimately move it to ZFS on mirrored disks. However, as I'd like to use the existing disk as one of the two mirror disks, my first step was to clone the contents of the current disk to a temporary drive (still UFS2), boot from that drive, then use the original system disk and another to create the mirror.

To create the temporary disk, I mostly followed the instructions for GPT disks on Warren Block's Disk Setup On FreeBSD site, only adapting it to my existing disk partitions and dev node names. To copy the existing data, I opted for rsync over dump/ restore, as UFS2 now uses 32 KB blocks by default instead of the legacy 16 KB blocks on the existing system drive, and I wasn't sure if that would cause issues or not. As such, the temporary disk shows slightly larger usage in df due to more wasted space.

The problem comes when trying to boot from the new, temporary disk after moving the content over. Initially, everything seems to be working, but then it hangs right before I would normally see ZFS related messages on the console. The system has two ZFS pools on it already, most notably /home, which makes me suspect that it's somehow related to ZFS and the existing pools. Do they need to be exported before trying to boot from the new disk?

I also tried to replicate the problem in a VM, without success, even when not exporting the pools. However, there's more than a few variables that are different between the VM and the real physical system (e.g. no block size mismatch, I think the existing system disk is MBR and not GPT, whereas in the VM they were both GPT, etc.), so that doesn't surprise me. Any idea on where to go from here, or how to troubleshoot?
 
I think the existing system disk is MBR and not GPT
Yet you followed a guide for a GPT setup ... so it is very unclear what you have done.

Any idea on where to go from here, or how to troubleshoot?
may be posting some factual information ?

Code:
gpart show -p /dev/xxx   # where xxx is your original-source disk
gpart show -p /dev/yyy   # where yyy is your destination-temporary disk
cat /etc/fstab   # from source disk
cat /etc/fstab   # from destination disk
also, which rsync command(s) you used exactly ?
 
Yet you followed a guide for a GPT setup ... so it is very unclear what you have done.
Sorry I wasn't clear. Where the guide says gpart create -s gpt da0 I would type the same thing, as in this particular case, da0 was the drive I was using as the temporary drive. The only parts I differed from the guide was in the partition area where I adapted it to this machine, which has only a single root partition (e.g. /tmp is not on a separate file system as his guide shows).

may be posting some factual information ?
There's no need for the attitude as everything I posted was factual.

As for the command output (note that ad4 is a symlink for ada0, as this machine was set up pre-cam):
Code:
# gpart show -p ada0
=>       63  312581745    ada0  MBR  (149G)
         63  312581745  ada0s1  freebsd  [active]  (149G)

# gpart show -p da0
=>       34  156249933    da0  GPT  (75G)
         34          6         - free -  (3.0K)
         40       1024  da0p1  freebsd-boot  (512K)
       1064        984         - free -  (492K)
       2048  156247919  da0p2  freebsd-ufs  (75G)
Yes, the temporary drive is smaller, but as I'm still well shy of the 75G limit it's not an issue. And the fstabs:

Code:
# Device                Mountpoint      FStype  Options         Dump    Pass#
# Original disk fstab
/dev/ad4s1a             /               ufs     rw              1       1
/dev/acd0               /cdrom          cd9660  ro,noauto       0       0

# Temporary disk fstab
/dev/ad0p2              /               ufs     rw              1       1
/dev/acd0               /cdrom          cd9660  ro,noauto       0       0
And finally, the command I used to sync the disks (after mounting the temp disk to /mnt): rsync -axHAXSv --delete --numeric-ids --exclude=/tmp/* / /mnt

Edit: Nevermind, looking through my own post I just realized I had "ad0p2" instead of "da0p2". I'll test tonight, but I'm almost sure that's the (only) problem. Mea culpa.
 
Just to report back it did boot after the fix. I then created the ZFS pool, copied everything back, and it's now exclusively a ZFS system (aside from the boot loaders, of course).
 
Back
Top