[OpenIndiana-discuss] Disk re-labelling and zfs

[Jim Klimov]

26 января 2016 г. 13:44:49 CET, Jonathan Adams <t12nslookup at gmail.com> пишет:
>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
>>
>_______________________________________________
>openindiana-discuss mailing list
>openindiana-discuss at openindiana.org
>http://openindiana.org/mailman/listinfo/openindiana-discuss

Unless i'm missing something, your case is a simple one of the zfs rpools being bound to a saved device path. So grub does find your pool and boots up the kernel+miniroot (module) and passes the device path string from the chosen hdd to the kernel, but the solaris/illumos kernel can not validate this string and find a device by it, because the controller is different. Unlike other pools, the rpool does not seek by name, guid, etc.

You have to use a live image or firefly failsafe to simply import-export the rpool after you migrate to a new controller.

Jim
--
Typos courtesy of K-9 Mail on my Samsung Android