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....
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?
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.
Hmm.. I'am going to test my scripted installation today. Hopefully i have a beter result. Do you deploy your ESX Servers with UDA?
Good luck,....
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.
Thanks..
De scripted installation with UDA works fine. So take a look at UDA
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...
Nice, good job.
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
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.
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.
"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.
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
You are right,... we found this out the hard way....
Fortunately this lun was empty....
thanks for the tip anyway...