[OpenIndiana-discuss] How do I swiych from IDE to AHCI mode for my SATA disks, please vet my procedure!

Jim Klimov jimklimov at cos.ru
Mon Mar 18 18:02:31 UTC 2013


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



More information about the OpenIndiana-discuss mailing list