SVM V20z root mirror panic
One of the problems I have been working on recently has to
do with running Solaris Volume Manager on
V20z
and
V40z
servers. In general, SVM does not care what kinds of disks
it is layered on top of. It justs passes the I/O requests through
to the drivers for the underlying storage. However, we were seeing
problems on the V20z when it was configured for root mirroring.
With root mirroring, a common test is to pull the primary boot disk and reboot to verify that the system comes up properly on the other side of the mirror. What was happening was that Solaris would start to boot, then panic.
It turns out that we were hitting a limitation in the boot support for disks that are connected to the system with an mpt(7D) based HBA. The problematic code exists in bootconf.exe within the Device Configuration Assistant (DCA). The DCA is responsible for loading and starting the Solaris kernel. The problem is that the bootconf code was not failing over to the altbootpath device path, so Solaris would start to boot but then panic because the DCA was passing it the old bootpath device path. With the primary boot disk removed from the system, this was no longer the correct boot device path. You can see if this limitation might impact you by using the "prtconf -D" command and looking for the mpt driver.
We have some solutions for this limitation in the pipeline, but in the meantime, there is an easy workaround for this. You need to edit the /boot/solaris/bootenv.rc file and remove the entries for bootpath and altbootpath. At this point, the DCA should automatically detect the correct boot device path and pass it into the kernel.
There are a couple of limitations to this workaround. First, it only works for S10 and later. In S9, it won't automatically boot. Instead it will enter the DCA and you will have to manually choose the boot device. Also, it only works for systems where both disks in the root mirror are attached via the mpt HBA. This is a typical configuration for the V20z and V40z. We are working on better solutions to this limitation, but hopefully this workaround is useful in the meantime.
With root mirroring, a common test is to pull the primary boot disk and reboot to verify that the system comes up properly on the other side of the mirror. What was happening was that Solaris would start to boot, then panic.
It turns out that we were hitting a limitation in the boot support for disks that are connected to the system with an mpt(7D) based HBA. The problematic code exists in bootconf.exe within the Device Configuration Assistant (DCA). The DCA is responsible for loading and starting the Solaris kernel. The problem is that the bootconf code was not failing over to the altbootpath device path, so Solaris would start to boot but then panic because the DCA was passing it the old bootpath device path. With the primary boot disk removed from the system, this was no longer the correct boot device path. You can see if this limitation might impact you by using the "prtconf -D" command and looking for the mpt driver.
We have some solutions for this limitation in the pipeline, but in the meantime, there is an easy workaround for this. You need to edit the /boot/solaris/bootenv.rc file and remove the entries for bootpath and altbootpath. At this point, the DCA should automatically detect the correct boot device path and pass it into the kernel.
There are a couple of limitations to this workaround. First, it only works for S10 and later. In S9, it won't automatically boot. Instead it will enter the DCA and you will have to manually choose the boot device. Also, it only works for systems where both disks in the root mirror are attached via the mpt HBA. This is a typical configuration for the V20z and V40z. We are working on better solutions to this limitation, but hopefully this workaround is useful in the meantime.
I have a Solaris 10 on a v20z with all patches as of 10-05-2005 and wanted to mirror the drives but it looks like a gamble.
With your proposed workaround, I assume (since you can not just PULL a disk) I assume that you have PULL a disk and then PUT in a different disk (satisfies that two disks are attached to the mpt HBA).
The real downside is that it will never auto-boot once a mirror goes south.
Posted by Jon Strabala on October 05, 2005 at 03:52 PM PDT #
Posted by Jerry on October 07, 2005 at 08:01 AM PDT #
Posted by Ahmad Cheikh.Moussa on January 29, 2006 at 06:07 AM PST #
Posted by Ahmad Cheikh.Moussa on January 29, 2006 at 06:19 AM PST #
Posted by Jerry Jelinek on January 30, 2006 at 07:05 AM PST #
Posted by Ahmad Cheikh.Moussa on January 30, 2006 at 08:51 AM PST #
Posted by Jerry Jelinek on February 01, 2006 at 07:43 AM PST #
Posted by Ahmad Cheikh.Moussa on February 01, 2006 at 11:25 PM PST #
Posted by fdasfdsa on October 12, 2006 at 07:03 PM PDT #
With root mirroring, a common test is to pull the primary boot disk and reboot to verify
Posted by runescape money on November 10, 2007 at 12:51 AM PST #
Curious -- Infodoc 83605 tells us to do exactly the opposite, to have altboopath in there.
I really, really wish that running Solaris 10 on the x4?00 were less painful than running it on commodity legacy Microcult hardware. Perhaps my error is in not recognizing the former *as* the latter.
Posted by Anthony on January 04, 2008 at 01:04 PM PST #