Which distro/version? Apparently this was a known problem with RHEL5, but might have been fixed by now.
-----Original Message----- From: Linux on 390 Port [mailto:linux-...@vm.marist.edu] On Behalf Of Scott Rohling Sent: Wednesday, June 10, 2009 9:09 AM To: LINUX-390@VM.MARIST.EDU Subject: Re: [LINUX-390] To kick or to clone ... that is the question I haven't experienced that myself -- in fact, we would kickstart a server over and over again doing testing, and it always had an existing Linux system on it when we did the kickstart <shrug> I guess YMMV. Scott On Wed, Jun 10, 2009 at 6:59 AM, Hall, Ken (GTS) <ken_h...@ml.com> wrote: > And you're almost stuck with letting kickstart format the disks. There are > conditions that will cause kickstart to hang if the disks have anything that > looks Linux-like on them, so the safest thing is to CP format them first. > > -----Original Message----- > From: Linux on 390 Port [mailto:linux-...@vm.marist.edu] On Behalf Of > Scott Rohling > Sent: Wednesday, June 10, 2009 8:56 AM > To: LINUX-390@VM.MARIST.EDU > Subject: Re: [LINUX-390] To kick or to clone ... that is the question > > Hi Doug -- Yep, we sure had some fun kicking Linux servers! > > Not sure how Linux not doing restarting itself is an IBM issue... but that > 'is' a nasty downside to kickstarting -- ending up at a 'You may safely > reboot' screen doesn't help automation. > > And we should add that kickstarting is faster than cloning 'if' the DASD is > already Linux formatted.. if not, the kickstart does the formatting, adding > time to the install. > > Scot > > On Tue, Jun 9, 2009 at 11:39 PM, WILLIAM CARROLL <v...@smgvbest.com> > wrote: > > > Hi Scott, > > > > I'll jump on your bandwagon but then again you already know I perfer > > Kickstarting over cloning > > you should also mention that unless you have Flashcopy for your DASD > > Kickstarting is actually faster than cloning. > > unless your clone master is very small. > > > > as you recall ours was on a mod3 (lots of required garbage) and cloning > > that mod3 was slower than kickstarting > > also after the kickstart was done the server was ready, no additional > > steps > > to change IP's or anything. > > > > if only redhat would fix that re-ipl after the reboot. > > they say it's an IBM issue not thiers > > > > Doug Carroll > > > > > > > > ----- Original Message ----- > > From: "Scott Rohling" <scott.rohl...@gmail.com> > > To: <LINUX-390@VM.MARIST.EDU> > > Sent: Wednesday, June 10, 2009 12:00 AM > > Subject: To kick or to clone ... that is the question > > > > > > This is a blatant request for discussion about the pros and cons of > using > >> an > >> automated installation (e.g. RH kickstart - Suse autoyast (though maybe > >> this > >> has changed - I'm not current on Suse) - vs cloning a system from a > >> 'golden > >> image'... and I should say: on zSeries. > >> > >> I'm a fan of kickstart - and I'll list my reasons in approximate order > of > >> importantance to me (most to least): > >> > >> - kickstart forces a scripted and recreatable installation. You > specify > >> the rpm's and can do some limited scripting within the kickstart file > >> itself > >> to end up with (hopefully) a working Linux system that requires no > manual > >> tweaking (at least - if you do it 'right'). The alternative is a cloned > >> system that the Linux SA's have been on, and perhaps several other teams > - > >> all performing manual tasks to end up with the final product - all sorts > >> of > >> shoeprints and no good detectives. Whereas a kickstart config is > >> self-documenting - a clone is not. With good scripting and good use of > >> rpm > >> packaging for your 'local' or even 'vendor' products - you can end up > with > >> a > >> very KISS config file that might even go multiplatform. (e.g. > arch=`uname > >> -m` ) > >> > >> - with a proper building of conf and parm files on z/VM - a guest can be > >> kicked already configured with a working network -- no need for some > >> outside > >> scripting or manual config. > >> > >> - you can have different kickstart files for different server 'types' > >> (web, > >> app, db, etc) - these can even be built dynamically and requested via a > >> URL > >> to to the kickstart ( e.g. > >> http://mykicker/kick.web&ip=xx.xx.xx.xx+etc+etc.....) > >> > >> - The size of the DASD can be flexible.. cloning requires copying the > >> same > >> size DASD as the source.. > >> > >> - The latest fixes can be applied by keeping the repository the > kickstart > >> uses current - rather than updating a clone source. (of course - > testing > >> is > >> still required and would require kickstarting a guest to truly do any > >> testing - a good thing imo) > >> > >> - It encourages packing by rpm rather than manual 'tarball' methods.. > >> this > >> is in line with a 'recreatable' install. Yes, you can still do 'tar' > >> commands in the kickstart file itself.. but specifying an rpm package > is > >> oh > >> so much easier. > >> > >> - Servers start 'clean' - ie no old log files from the clone source and > >> no > >> need to try and script a 'cleanup' > >> > >> - No worrying about whether a clone source is 'up' when a new server is > >> clone and possibly clone a live system > >> > >> > >> There are downsides.. but I'll leave those to the rest of you to > expound > >> on, since I'm taking a position of 'kickstart good, Jane' > >> > >> Thanks and hope this is valuable to some .. > >> > >> Scott > >> > http://www.marist.edu/htbin/wlvindex?LINUX-390 > > -------------------------------------------------------------------------- > This message w/attachments (message) may be privileged, confidential or > proprietary, and if you are not an intended recipient, please notify the > sender, do not use or share it and delete it. Unless specifically indicated, > this message is not an offer to sell or a solicitation of any investment > products or other financial product or service, an official confirmation of > any transaction, or an official statement of Merrill Lynch. Subject to > applicable law, Merrill Lynch may monitor, review and retain > e-communications (EC) traveling through its networks/systems. The laws of > the country of each sender/recipient may impact the handling of EC, and EC > may be archived, supervised and produced in countries other than the country > in which you are located. This message cannot be guaranteed to be secure or > error-free. References to "Merrill Lynch" are references to any company in > the Merrill Lynch & Co., Inc. group of companies, which are wholly-owned by > Bank of America Corporation. Securities and Insurance Products: * Are Not > FDIC Insured * Are Not Bank Guaranteed * May Lose Value * Are Not a Bank > Deposit * Are Not a Condition to Any Banking Service or Activity * Are Not > Insured by Any Federal Government Agency. Attachments that are part of this > E-communication may have additional important disclosures and disclaimers, > which you should read. This message is subject to terms available at the > following link: http://www.ml.com/e-communications_terms/. By messaging > with Merrill Lynch you consent to the foregoing. > -------------------------------------------------------------------------- > > ---------------------------------------------------------------------- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -------------------------------------------------------------------------- This message w/attachments (message) may be privileged, confidential or proprietary, and if you are not an intended recipient, please notify the sender, do not use or share it and delete it. Unless specifically indicated, this message is not an offer to sell or a solicitation of any investment products or other financial product or service, an official confirmation of any transaction, or an official statement of Merrill Lynch. Subject to applicable law, Merrill Lynch may monitor, review and retain e-communications (EC) traveling through its networks/systems. The laws of the country of each sender/recipient may impact the handling of EC, and EC may be archived, supervised and produced in countries other than the country in which you are located. This message cannot be guaranteed to be secure or error-free. References to "Merrill Lynch" are references to any company in the Merrill Lynch & Co., Inc. group of companies, which are wholly-owned by Bank of America Corporation. Securities and Insurance Products: * Are Not FDIC Insured * Are Not Bank Guaranteed * May Lose Value * Are Not a Bank Deposit * Are Not a Condition to Any Banking Service or Activity * Are Not Insured by Any Federal Government Agency. Attachments that are part of this E-communication may have additional important disclosures and disclaimers, which you should read. This message is subject to terms available at the following link: http://www.ml.com/e-communications_terms/. By messaging with Merrill Lynch you consent to the foregoing. --------------------------------------------------------------------------
