VMware Cloud Community
Ferry1
Enthusiast
Enthusiast
Jump to solution

Scripted install fails on ESX 3.0.2

Hi,

We are doing an scripted install of ESX 3.0.2. At the end the script reboots the server and we end up at a nice screen saying:

Grub....

The server wont boot at all.... Smiley Sad

We used the same script on an ESX 3.0.1 source and it did work fine.

Anybody already any idea how to fix this issue?

0 Kudos
1 Solution

Accepted Solutions
Hrrflck
Contributor
Contributor
Jump to solution

Solved it. I noticed that my new KS config had a different bootloader section.

\[old]

bootloader --location=mbr

\[new]

bootloader --location=mbr --driveorder=sda

So I went back to the old cciss/c0d0 and also added it to the bootloader section \[bootloader --location=mbr --driveorder=cciss/c0d0].

After this change grub not longer just sits there, and the KS also does what it is supposed to do.

View solution in original post

0 Kudos
11 Replies
ICT-Freak
Enthusiast
Enthusiast
Jump to solution

Hmm.. I'am going to test my scripted installation today. Hopefully i have a beter result. Do you deploy your ESX Servers with UDA?

0 Kudos
Ferry1
Enthusiast
Enthusiast
Jump to solution

Good luck,.... Smiley Wink

To answer your question : No, we don't use UDA.

We just did a clean install and toke a script of this server. With this script we try to install the other servers.

0 Kudos
ICT-Freak
Enthusiast
Enthusiast
Jump to solution

Thanks..

De scripted installation with UDA works fine. So take a look at UDA Smiley Wink

0 Kudos
Ferry1
Enthusiast
Enthusiast
Jump to solution

Lol,... we found out the problem..

We are using HP Proliant Dl380 servers. At the ESX 3.0.1 we had to use the --ondisk cciss/s0d0[/i] option at the part[/i] command line.

At ESX 3.0.2 you dont have to and just can use --ondisk sda[/i].

We changed it and the scripted install works fine now!..

Thanks anyway... Smiley Wink

0 Kudos
ICT-Freak
Enthusiast
Enthusiast
Jump to solution

Nice, good job.

0 Kudos
marvinthebassma
Contributor
Contributor
Jump to solution

Hi guys,

I tried the scripted install this evening and I still have to use --ondisk=cciss/c0d0

at the "part" statements.

I tried using --ondisk=sda but it didn't work. Anaconda died with an exception.

Via ALT F2 I took a look in the anaconda debug file under /tmp and I showed an error for sda ... unknown disk or something like that.

Now at the moment the installation runs fine.

We use HP Proliant DL385 G1.

Marvin

0 Kudos
Hrrflck
Contributor
Contributor
Jump to solution

After solving the partitioning problem, another one crops up. The KS installation finishes without errors, but after the reboot the host is just named localhost and all the post processing is not performed. The KS script specifies the hostname and ip config but it just doesn't apply it.

I tried commenting out the IP config in the KS script and provide the details manually, but even then the host ends up as localhost.

All of this worked fine with 3.0.1

Thanks for your tip on UDA, it's a lot easier to manage then my manual PXE/TFTP/FTP/NFS homebrew.

0 Kudos
Hrrflck
Contributor
Contributor
Jump to solution

Solved it. I noticed that my new KS config had a different bootloader section.

\[old]

bootloader --location=mbr

\[new]

bootloader --location=mbr --driveorder=sda

So I went back to the old cciss/c0d0 and also added it to the bootloader section \[bootloader --location=mbr --driveorder=cciss/c0d0].

After this change grub not longer just sits there, and the KS also does what it is supposed to do.

0 Kudos
jwmarrott
Contributor
Contributor
Jump to solution

"At ESX 3.0.2 you dont have to and just can use --ondisk sda . "

This is not necessarily true! If you are attached to a SAN, the first LUN shows up as "sda." So if you specify "--ondisk sda" it will wipe the LUN and install to the SAN.

admin
Immortal
Immortal
Jump to solution

Had this today also, just provided a brand new shiney USB key 3.0.2 build + #post customizations on a few DL585 G2's.

I modified the ks.cfg to have -

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

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

\# Clear Partitions

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

\# Partitioning

part /boot --fstype ext3 --size 200 --ondisk cciss/c0d0 --asprimary

part / --fstype ext3 --size 4096 --ondisk cciss/c0d0 --asprimary

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

part /opt --fstype ext3 --size 2048 --ondisk cciss/c0d0

part /var --fstype ext3 --size 2048 --ondisk cciss/c0d0

part /tmp --fstype ext3 --size 2048 --ondisk cciss/c0d0

part /vmimages --fstype ext3 --size 10240 --ondisk cciss/c0d0

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

and all now is fine and dandy.......plus no patches to deploy, just in time saves me esxupdating over 200 patches --phew

I also created an iso with a menu so they can select which server they are building, not that they will...coz vmware doesn't seem to want to crash for me --yippee

peace out dudes Smiley Happy

0 Kudos
Ferry1
Enthusiast
Enthusiast
Jump to solution

You are right,... we found this out the hard way.... Smiley Wink

Fortunately this lun was empty.... Smiley Happy

thanks for the tip anyway...

0 Kudos