here it is. Note that the only difference between this and the RHEL6.2
kickstart (that works fine) is the ISO I point to and the %pre section I tried
to add to manually clear the disks out (which doesn't work either). In 6.2,
the zerombr and clearpart commands wipe any "extra" disks added to the server
without me having to do anything. The first "extra" disk is 0.0.0232 (and by
extra, I mean not mentioned in the bootloader by name). The install fails when
it hits the "volgroup datavg" statement on a rebuilt server, since it
apparently senses that 232 (and any other disks) are already in a volume group
called datavg. At least, that's my guess--if I use DIRMAINT to recreate 232
(et all) from scratch, the rebuild works fine.
# kickstart file for initial build of base zlinux servers-RHEL6
# version=RHEL64
install
reboot
nfs --server=<server name> --dir=/nfs/common/RHEL64ISO
lang en_US
rootpw lxinst
firewall --disabled
auth --useshadow --enablemd5
selinux --disabled
services --enabled netfs --disabled
sendmail,acpid,anacron,cron,auditd,autofs,avahi-daemon,bluetooth,cups,gpm,hidd,ip6tables,isdn,setroubleshoot,smartd,rhnsd
timezone --utc America/New_York
bootloader --location=mbr
--driveorder=/dev/disk/by-path/ccw-0.0.0200,/dev/disk/by-path/ccw-0.0.0203,/dev/disk/by-path/ccw-0.0.0204,/dev/disk/by-path/ccw-0.0.0210,/dev/disk/by-path/ccw-0.0.0211,/dev/disk/by-path/ccw-0.0.0220,/dev/disk/by-path/ccw-0.0.0230,/dev/disk/by-path/ccw-0.0.0231
--append="rhgb quiet"
# partitioning (specific to setup on zSeries)
clearpart --initlabel --all
zerombr
part /boot --ondisk=/dev/disk/by-path/ccw-0.0.0200 --fstype=ext4 --grow
--size=200
part swap --ondisk=/dev/disk/by-path/ccw-0.0.0201 --grow --size=200
part swap --ondisk=/dev/disk/by-path/ccw-0.0.0202 --grow --size=200
part pv.sys203 --ondisk=/dev/disk/by-path/ccw-0.0.0203 --grow --size=200
part pv.sys204 --ondisk=/dev/disk/by-path/ccw-0.0.0204 --grow --size=200
part pv.tls210 --ondisk=/dev/disk/by-path/ccw-0.0.0210 --grow --size=200
part pv.tls211 --ondisk=/dev/disk/by-path/ccw-0.0.0211 --grow --size=200
part pv.itm220 --ondisk=/dev/disk/by-path/ccw-0.0.0220 --grow --size=200
part pv.dat230 --ondisk=/dev/disk/by-path/ccw-0.0.0230 --grow --size=200
part pv.dat231 --ondisk=/dev/disk/by-path/ccw-0.0.0231 --grow --size=200
volgroup systemvg --pesize=4096 pv.sys203 pv.sys204
logvol / --fstype=ext4 --name=rootlv --vgname=systemvg --size=4096
logvol /home --fstype=ext4 --name=homelv --vgname=systemvg --size=1024
logvol /var --fstype=ext4 --name=varlv --vgname=systemvg --size=4096
logvol /tmp --fstype=ext4 --name=tmplv --vgname=systemvg --size=6144
logvol swap --fstype=swap --name=swaplv --vgname=systemvg --size=2048
volgroup toolsvg --pesize=4096 pv.tls210 pv.tls211
...logical volumes of our system tools...
volgroup itmvg --pesize=4096 pv.itm220
..logical volume for monitoring...
volgroup datavg --pesize=4096 pv.dat230 pv.dat231
...nothing here--it's empty, ready for the apps to use it once the server's
built...
%packages --ignoremissing
...tons of stuff added or removed...
%end
#
# PRE
#
%pre --interpreter /bin/sh --log=/tmp/pre-install.log
# zero out all disks
for x in `lsdasd | grep dasd | awk {'print $3'}`; do
dd if=/dev/zero of=$x bs=512 count=1
done
%end
#
# POST
#
%post
( # Note that we run the entire %post section as a subshell for logging.
...
# Add any extra tools volumes to toolsvg
ls -1 /dev/disk/by-path/ccw-0.0.021*-part1 | egrep -ve "210|211" >extratools
if [[ -s extratools ]]; then
echo "Adding the following volumes to toolsvg:"
cat extratools
pvcreate $(cat extratools)
vgextend toolsvg $(cat extratools)
echo " "
fi
rm extratools
# Add any extra data volumes to datavg (23x, 24x, 25x)
ls -1 /dev/disk/by-path/ccw-0.0.02[345]*-part1 | egrep -ve "230|231" >extradata
if [[ -s extradata ]]; then
echo "Adding the following volumes to datavg:"
cat extradata
pvcreate $(cat extradata)
vgextend datavg $(cat extradata)
echo " "
fi
rm extradata
...
) 1>/root/post_install.log 2>&1
%end
-----Original Message-----
From: Linux on 390 Port [mailto:[email protected]] On Behalf Of Filipe
Miranda
Sent: Friday, June 28, 2013 7:54 AM
To: [email protected]
Subject: Re: RHEL 6.4 kickstart no longer seems to clear all the partitions
with clearpart --all
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/
----------------------------------------------------------------------
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/
