Hello Collinson, During the IBM Redbooks residency at the ITSO this month I had the opportunity to rewrite the kickstart section of the Virtualization Cookbook and I used the kickstart example file with RHEL6.4: #version=RHEL6.4 install reboot nfs --server=<ip_address> --dir=/var/nfs/rhel64 lang en_US.UTF-8
rootpw --iscrypted $6$jiFGqyU1FwxWWQ6t$7qnsOSsUsNOyGnjtIpR63z204RDjL1q6M//lxfA.E5SbQ.M2gNKCJpahQ.m07JCm.56y H3vKbxc5bVtvRERwd0 firewall --disabled authconfig --enableshadow --passalgo=sha512 --enablefingerprint selinux --enforcing timezone --utc America/New_York bootloader --location=mbr --driveorder=dasdb,dasdc,dasdd,dasde --append="crashkernel=auto" # The following is the partition information you requested # Note that any partitions you deleted are not expressed # here so unless you clear all partitions first, this is # not guaranteed to work zerombr clearpart --all --initlabel --drives=dasdb,dasdc,dasdd,dasde part / --fstype=ext4 --size=1024 part pv.094006 --grow --size=200 part pv.094009 --grow --size=200 part swap --grow --size=200 part swap --grow --size=200 volgroup system_vg --pesize=4096 pv.094006 pv.094009 logvol /opt --fstype=ext4 --name=opt_lv --vgname=system_vg --size=512 logvol /tmp --fstype=ext4 --name=tmp_lv --vgname=system_vg --size=512 logvol /usr --fstype=ext4 --name=usr_lv --vgname=system_vg --size=2048 logvol /var --fstype=ext4 --name=var_lv --vgname=system_vg --size=512 %packages @base %end Do you think you can send us the kickstart file you used just for reference ? Thank you, Kind Regards, Filipe Miranda On Jun 27, 2013, at 2:15 PM, "Collinson.Shannon" <[email protected]> wrote: > 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/ ---------------------------------------------------------------------- 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/
