Hi all, We have been updating our in-house AutomatedInstall environment for Solaris 10 (Update 1) and testing this release. The procedure I used on systems with SVM mirrored root disks (/, swap, ...) on Solaris 9 does not work on Solaris 10!
Under Solaris 9, I used the fact that SVM did not notice changes to underlying submirrors (actual the physical slice which the submirror is composed). So I reinstall the OS on Disk A, make the system aware of the metadevices (update md.conf and reboot) then simply dettach the submirrors on Disk B, invoke metaroot, update vfstab, reboot and attach the Disk B submirrors. The later stages of which are described in the attached script ( see the functions SimpleRecoveryStage 1 & 2 ). This was fine, as SVM (Solaris 9) still had all mirrors and submirrors in Okay state, and I knew which disk the OS was installed on and simply deattached the now invalid submirrors (located on Disk B) and reattached them when appropriate. If I install Solaris 10 or Solaris 10 Update 1 (SPARC on Sun Blade 1500), setup SVM for a mirrored system disk (all slices saved overlap). The system shows all metadevices are "Okay", and the system is fully functional (both before and after a reboot). Now, if you install a copy of the OS on Disk A (init 0 then boot net - install (S10U1) or boot cdrom (FCS)), and then after installation make the system aware of the MDDBs (update md.conf) and reboot, ALL mirrors and submirrors appear in "Need Maint" state. (Noting that, I'm currently not using the metadevices, just making the OS aware of them) At this point, I can't use my Solaris 9 SVM procedure, it will fail, as the metadetach can not detach the Disk B submirrors - metadetach fails on "Need Maint" mirror/submirror. metastat suggests I should resync the mirror as a way to remove the error condition, but I don't know which direction the resync would occur in and I'm not willing to let metaresync make a decision about which submirror is valid, it has them both in "Needs Maint" state. If I continue trying to reinstate SVM mirrors at this point, by clearing all existsing metadevices (metaclear -r d0, ...) and reconstructing the devices from scratch (see the newly developed BuildFromLHS* functions in the attached script), the OS reports that every thing is fine, metatstat has all the new metadevices in "Okay" state. If I now reboot the system to use the new metadevices (and attach the other half of the mirror), the system goes into an infinite early-in-boot panic (both S10FCS abd S10U1) - its similar in nature to the panic described in http://blogs.sun.com/roller/page/jerrysblog?entry=solaris_volume_manager_odds_and But I have not verified that nologging is the cause because I assumed that S10U1 would have the patch for this issue. Before responding, read all the PS/PPS/PPPS notes below. Q: What approach should be taken for S10 systems with respect to reinstallation of systems with mirrored root filesystems? (as the PS describes, I'll understand if partial/complete deconstruction of mirrors is _required_, as opposed to recommended) Noting: I'd prefer not to use any solution that involved destorying the MDDBs themselves, as some V240 we have mirror the other two available disks - and they have real and valuable data!! Many Thanks in Advance, Peter Sydney, Australia PS: I completely understand that the correct procedure is to detach the submirrors of partitions the install process will touch BEFORE attempting the re-installation of the OS, but the advantage with the Solaris 9 procedure I used was that if the installer did not remember this step (and even I have forgotten it once) that the procedure was robust enough to handle this situation (A REAL BONUS in my book) PPS: The functions BuildFromLHS* in the attached script, where my first attempts at Solaris 10 compatible procedures for this task. PPPS: The code is design to run in an environment with support for debugging, testing and logging of all actions, hence the "directives" likes Execute/Message/..., so the script would not run directly but I believe the simple nature of the script and its intents will be obvious to all. This message posted from opensolaris.org -------------- next part -------------- A non-text attachment was scrubbed... Name: SimpleMirroredInternalDisks Type: application/octet-stream Size: 11357 bytes Desc: not available URL: <http://mail.opensolaris.org/pipermail/lvm-discuss/attachments/20060315/95b7c8dc/attachment.obj>
