On 2013-03-18 18:14, Hans J. Albertsson wrote:
Status: I have a server with two SATA disks carrying a root pool 2 way
mirror.
The motherboard is in IDE mode for SATA.
This must now change, since I need to be able to accomodate disks of the
512e ilk, i e disks that lie about their blocksize, which really is 4k.
I think I should do the following:
Actually, your procedure is a bit over-complicated. While rpool is some
special case for import during boot (its label-embedded device paths are
trusted too much, which is the sole cause for problems with such driver
changes like SATA/IDE/vHDD/whatever), I don't remember needing the extra
steps you do with /device nodes. Just importing and cleanly exporting
the rpool while booted from a LiveDVD and having the controller in the
mode you want should suffice. At this moment the rpool is processed by
generic routines like any other pool, with detection of component disks
as needed, so it is found on other controllers than recorded in the
label. These paths are further saved into rpool labels, allowing its
import during further boot.
All this said, my laptop can only boot from USB as an alternate media,
and this shifts its known storage controller numbering. When I boot
from the HDD, it searches for SATA disks at improper device paths.
So my laptop is stuck with IDE mode until someone gets around to fix
or relax the rpool import procedure (i.e. instead of failing, try the
usual search for pools first).
On the running host, I make sure either disk can be booted, by doing the
installgrub things.
This rarely hurts ;)
Then I reboot the machine on a live DVD. On the way up, I set the Bios
to use AHCI mode for the SATA disks, and boot the Live DVD.
From the live cd I do, I hope this is correct! Please vet!
-------
zpool import -f rpool
( The -f is because I didn't export it on the running system, because I
couldn't, but I know it isn't active, I'm running off a DVD, see. But
how does "zpool" find rpool???)
See above ;)
This block is likely not needed - only if your hardware is somehow
non-standard and not detectable by bootup procedures.
In this case you might want to add the driver names, etc. into the
/boot/solaris/filelist.ramdisk text file which controls the contents
of the boot archive, and maybe add a forceload in /etc/system.
touch /a
zfs set -o canmount=on,mountpoint=/a root/ROOT/OI-151a7
zfs mount rpool/ROOT/OI-151a7
devfsadm -r /a -Cv
bootadm update-archive -R /a
If you changed the dataset properties above, you'd be wise to return
them to original values. You did record them, right? ;)
zpool export rpool
reboot
--------
After the reboot, if everything is OK I'm fine, but what can I do to
recover in IDE mode if all this breaks for some dumb mistake or error??
Either keep the other disk disconnected until you can just re-add it
into the mirror you are satisfied with, or change the BIOS settings
for HDDs to IDE and redo the LiveDVD trickery ;)
I'd like to ensure that disk number two remains unchanged until I know
AHCI mode works, so that I can either attach and resilver disk 2 if all
is OK or else reboot the Live DVD and recreate the IDE rpool from disk 2.
An alternative to devfsadm would be to erase the dev and devices trees
embedded in the rpool and copy the Live DVD /dev and /devices in.
This would likely break numbering of your multi-instance devices
(HBA controllers/HDDs, NICs) which may be unfortunate for monitoring
and configurations. Also, the LiveDVD has a limited set of drivers
and might not include/install device nodes for unknown things.
And I suppose a new installgrub would have to be performed somewhere
after the dev/devices revamp and and before the bootadm
I don't think the two are interconnected, or that another installgrub
is warranted. It itself has little notion of the connection type, just
using the BIOS-level access to a provided block device, AFAIK.
HTH,
//Jim Klimov
_______________________________________________
OpenIndiana-discuss mailing list
OpenIndiana-discuss@openindiana.org
http://openindiana.org/mailman/listinfo/openindiana-discuss
