[OpenIndiana-discuss] Disk re-labelling and zfs

[Jonathan Adams]

I was hoping that someone else would reply to this, someone with more
knowledge of how it worked ...

The issue that I'm aware of is that the Grub system doesn't understand
about new devices and cannot find the root pool to import if the device it
is attached to has changed.

We had a system, a little while ago, that we wanted to replace the disk
controller on.  we put the 2 root drives on the new controller, got the
grub prompt and promptly reboot cycled.  We put the drives back on the
original and everything worked, so we knew it wasn't the drives ...

What we eventually did was drop one disk from the pool, move it to the new
controller, add it to the pool in mirror, grub-install on the "new" disk,
reboot, drop the second disk, move it to the new controller, add the disk
to the pool in mirror, grub-install and reboot.

My guess is that as long as you can keep the USB device booting, you would
be better off using the USB device as USB and then cloning it to the new
internal drive.

Jon

On 22 January 2016 at 08:08, Jim Klimov <jimklimov at cos.ru> wrote:

> Hello all,
>
> I'm migrating a laptop to a new hdd, and opened a can of worms. Would
> anyone share ideas on catching them? :)
>
> 1) Initially the new disk was in an USB cradle, so its 'type' in Solaris
> format saved that string. It is quite inconvenient when I've now swapped
> the disks and use the cradle for the old one, but the type is mis-assigned
> (says 'cradle id' for the system disk now internal, not for one actually in
> the cradle).
> This bit of info survives dualboots and failsafe/livecd boots.
>
> So I went to 'format / type / auto (0)' and again to apply this layout
> whose numeric fields looked exactly like the old one's - only the name
> changed.
>
> Then I went to partitions to redefine the rpool slice, and labeled the
> disk.
>
> However, 'zpool import (-D too)' no longer finds the rpool, and upon
> reboot grub fails (i guess it can not proceed to find the menu file);
> reinstalling grub from failsafe image did not help, so booting up is now
> again tricky ;)
>
> Any ideas if the zfs pool can be salvaged, or must be recreated?
>
> 2) i'm not too much opposed to recreation this time, because the WD SSHD
> disk said it had 512/512 byte sectors, but upon pool import it says that my
> block alignment sucks. I guess the ssd layer of the disk exposes some
> different sectors than what partdd saw and zpool used by default.
>
> Should tweaks in livecd/failsafe sd.conf, so I use e.g. 4kb sectors, fix
> it?
>
> 3) the old disk did have some issues and so even a zfs cksum error (in a
> copies=1 relatively disposable dataset). Despite failmode=continue, the old
> disk disappeared from under the running system as soon as 'zfs send' or
> 'rsync' got to reading the corrupt block. Given that this was the rpool
> disk, only reboots allowed to regain the system. Not warning about yanking
> the disk ever got into serial console logs nor terminal nor
> /var/adm/messages.
>
> This was uncool and required complicated workarounds to recreate the
> history (and clone-linking) of involved datasets on the new disk with rsync
> and zfs combined ;(
>
> Thanks in advance,
> Jim
> --
> Typos courtesy of K-9 Mail on my Samsung Android
>
> _______________________________________________
> openindiana-discuss mailing list
> openindiana-discuss at openindiana.org
> http://openindiana.org/mailman/listinfo/openindiana-discuss
>