Kickstart scripted instal for esx 3

[shen73]

Hi everyone,

I'm trying to run the simplest scripted install for esx 3. i've gone out to a previously installed esx3 host and ran through the scripted installer and saved a ks.cfg. threw it on a floppy and went to another host to do the scripted install. used esx ks=floppy method=cdrom and the install runs through no problem. only problem is when the reboot comes, the server loads into grub and not into esx3. Is there a switch i need to include in the bootloader section to point it to esx3? linux is definately not a forte of mine. Thanks!

here is the kickstart i'm using

\# Auto-Generated Scripted Install Configuration file.

\# This file is used for VMware ESX Server Scripted Install Deployment

\# Installation Method

cdrom

\# root Password

rootpw --iscrypted $1$V0yNyYeH$UItLlTW1RPArL0ySAOKmc.

\# Authconfig

auth --enableshadow --enablemd5

\# BootLoader ( The user has to use grub by default )

bootloader --location=mbr

\# Timezone

timezone America/Los_Angeles

\# X windowing System

skipx

\# Install or Upgrade

install

\# Text Mode

text

\# Network install type

network --bootproto static --ip xx.xx.xxx.xxx --netmask 255.255.255.0 --gateway xxx.xxx.xxx.xxx --nameserver xxx.xxx.xxx.xxx --hostname vhost-006 --addvmportgroup=1 --vlanid=0

\# Language

lang en_US

\# Langauge Support

langsupport --default en_US

\# Keyboard

keyboard us

\# Mouse

mouse none

\# Reboot after install ?

reboot

\# Firewall settings

firewall --disabled

\# Clear Partitions

clearpart --all --initlabel --drives=cciss/c0d0

\# Partitioning

part /boot --fstype ext3 --size 102 --ondisk cciss/c0d0

part / --fstype ext3 --size 4997 --ondisk cciss/c0d0

part swap --size 1600 --ondisk cciss/c0d0

part None --fstype vmfs3 --size 10000 --grow --ondisk cciss/c0d0

part None --fstype vmkcore --size 94 --ondisk cciss/c0d0

part /var/log --fstype ext3 --size 1992 --ondisk cciss/c0d0

\# VMware Specific Commands

vmaccepteula

%packages

@base

@ everything

%post

[shen73]

i ran across another post with a link that describes redhat's options for kickstart. i edited the bootloader section to state

bootloader --location=mbr --driveorder=cciss/c0d0

and tried the script again. it worked.

here's the link i used for anyone else who may need it.

http://www.red-hat.com/docs/manuals/enterprise/RHEL-3-Manual/sysadmin-guide/s1-kickstart2-options.ht...

[SrTim]

Correct! I have used the --driveorder= option as well. Needing to do so means that you are likely attached to a SAN and have LUNs visible to the host during install.

[mgranzow]

thank you guys!!! you hit it right on the head!

[Jasemccarty]

As an FYI, you probably don't want to do an install with SAN LUNs attached.

It makes things much easier if you disconnect the SAN LUNs first.

Regardless, good tip!

[ktwebb68]

Or you can do like I do and just remove the HBA. Bit of a pain but my SAN guys stay pretty busy so typically it's easier to just remove the fiber card, install, and replace it. Well, quicker anyway

[JDLangdon]

You mean it is easier to remove the fiber card from the server then it is to disconnect the fiber cables from the card?

Jason

[ktwebb68]

It'd be nice if I could do that. Bladecenter. So unless you want to remove SAN connectivity for multiple blades, you wouldn't be pulling fiber out of their ports.

[dconvery]

I don't know much about the IBM blades, but if it is a standard fabric switch...You could just disable the switch port or the zone during deployment.

[ktwebb68]

If you wanted to either disable other blade HBA's, or get the SAN team involved then yes. That's correct. As my original post says, sometimes it's just easier to pull out the blade and pop the hba. Besides actually having to walk to the chassis, it takes all of a minute. If I had access and knowledge of the masking and zoning of the hba itself no question that's how I would manage it. Since I don't, and our SAN guys are back and forth between the data center we will be moving to in the next year, typically the method I am talking about is quicker.

[DFATAnt]

Having used IBM Bladecenters in the past, you can telnet to the FC switch module and disable the port that the blade is using. This will saving you going anywhere near the chassis to do any physical work. After the ESX install, you telnet in to the FC switch module again and enable the port (given that the SAN guys allow you access in to the FC switch module).

Although having said all that, when I used IBM Bladecenters, we used a boot from SAN setup which meant we had to have the ports enabled...

[ktwebb68]

Yep, we boot from SAN drives. No local storage.

[ktwebb68]

I'd probably do it from the GUI myself if I was installing to the local drive and did want to go that route. Personally I'd still probably pop the blade out and remove the card. At least if I was at the rack anyway and until I get my kickstart server going, and as long as the CD pops out at the end of the previous install, I would be.