Has anyone else run into this? We were running RHEL 6.2 on s390x (z/VM 6.2, actually) with no problems, but the same kickstart modified to point to the RHEL 6.4 ISO seems to ignore the "clearpart --initlabel --all/zerombr" lines. We have a standard (small) "zlinux build" that was defined in the kickstart (minidisks specified with the by-path names), but would also have a variable number of extra minidisks added to the application volume group depending on the needs of the app that requested the server. Some could live with the 20G default "datavg", but most need extra minidisks added to that volume group to stand up their software.
So, we had the 2 minidisks that made up the default 20G specified by name in the command section of the kickstart, but added a %post section to discover any additional disks and add them in as well. All's perfect in RHEL 6.4 for a brand-new server, but when we are asked to rebuild an existing server, the kickstart fails, saying the "datavg" volume group was already found. If I manually zero-out the extra disks, or use DIRMAINT to recreate them, the rebuild works fine, but clearpart or zerombr no longer seems to work against every disk accessible to the kickstart (just every disk specified by name). I tried adding in a %pre section to whack those extra disks, but from what I can see, that's happening after partitioning as well, and it's during the partitioning (when it hits the creation of datavg for the 2 minidisks every server has) that it fails. Oddly, in RHEL 6.2, this worked perfectly. I could rebuild servers at the click of a button. RedHat is saying they can't recreate my problem, but my guy (probably low-level) also can't find a mainframe to play with--he's doing everything with x86, and I'm wondering if this isn't an s390-specific issue. Has anyone else encountered this? Am I expecting too much from the kickstart, and was just exploiting some closed loophole with RHEL 6.2? It's not a show-stopper (since we don't rebuild that often and the DIRMAINT re-create works fine), but I just find it weird. Thanks for any help with this! Shannon Collinson, AVP, Mainframe Engineering SunTrust Bank Office: 404.827.6070 | Mobile: 404.642.1280 | Mail Code GA-MT-1750 | 245 Peachtree Center Ave Suite 1700 | Atlanta, GA 30303 How Can We Help You Shine Today? LEGAL DISCLAIMER The information transmitted is intended solely for the individual or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of or taking action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you have received this email in error please contact the sender and delete the material from any computer. By replying to this e-mail, you consent to SunTrust's monitoring activities of all communication that occurs on SunTrust's systems. SunTrust is a federally registered service mark of SunTrust Banks, Inc. [ST:XCL] ---------------------------------------------------------------------- For LINUX-390 subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 ---------------------------------------------------------------------- For more information on Linux on System z, visit http://wiki.linuxvm.org/
