On Tue, Jul 05, 2011 at 09:03:50AM -0400, Edward Ned Harvey wrote: > > I suspect the problem is because I changed to AHCI. > > This is normal, no matter what OS you have. It's the hardware.
That is simply false. > If you start using a disk in non-AHCI mode, you must always continue to use > it in non-AHCI mode. If you switch, it will make the old data inaccessible. Utterly not true. Even in this case, the problem is not access to the data. The problem is with booting from the device / mounting as root, because solaris (and windows) embed device name/path information into configuration data critical for booting. Even these OS's will be able to access data disks via either controller mode/type if the boot time issue is removed. Other operating systems that don't depend on embedded device path information in the boot sequence can switch easily between IDE/AHCI modes for boot disks, or indeed between other controller types (different scsi controllers, booting native vs as a VM, moving disks between boxes, etc). The fact that Solaris fails to tolerate this is a bug. In addition to other problems, this bug manifests when trying to use removable usb sticks as boot media/rpool, because usb device names are constructed based on port and topology in some cases. I have also been bitten by it in the past when rearranging controllers into different slots. > Just change it back in BIOS and you'll have your data back. Then backup > your data, change to AHCI mode (because it's supposed to perform better) and > restore your data. In this case, the recorded device path has probably been mangled, and will need to be repaired before the pool is bootable again. The pool should, however, be accessible as data from an independent boot. -- Dan.
pgpiQdSFcRMcp.pgp
Description: PGP signature
_______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
