I'm having difficulties installing 3.5.0 Update 1 using the ISO I downloaded from vmware.com. It appears that a couple of driver RPMs have truncated filenames, e.g.:
3.5.0 Up1: VMware-esx-drivers-scsi-aacraid_esx30-322.214.171.124.2vmw-82663.i386 (the .rpm is missing)
and so on:
Renaming them to the proper file name doesn't work though. Any chance for a 82663a build?
>> Inline comments is what I have at this moment and the rest I have requested from our client who will provide other the details like firmware versions and actual error.
Unfortunately, I'm unable to find an error with the text "Insert ESX Installation CD." Is this the exact text of the error message? If not, providing the exact text of the error or prompt may help to narrow its cause. >> actual screen shot is requested from the client
Knowing where in the installation process you see this error message would help as well. For example, are you prompted with the "CD Media Test" dialog?
>> Yes, right after this dialog we are getting error asking to provide ESX installation CD
In addition, knowing the model of your blade chassis and the version of the iLO firmware that it's using may enable me to reproduce the problem. We do have iLO systems here, and the update 1 CD works on them. However, it may be that the error only occurs with your specific hardware environment.
>> This is understood, I have requested this details, however just to remind you that we have not problem with 3.5 RTM ISO image. I have comfirmed MD5 hash of Update 1 ISO it matches.
Also, does the CD boot into the graphical installation on any other system? This may help determine whether the problem is with the CD media or ISO format, or whether it's a hardware compatibility issue.
>> have not tried other systems. Blade center used for the install is at remote location so we can't have access to it.
Finally, when you get this error message, pressing AltF3 will show some status messages printed by the installer, and AltF4 will show the system log output (mostly from the kernel). Do either of these screens show an error message that may help indicate the cause of the problem? (Note: When using iLO, you may have to configure a hot key, otherwise Alt+F4 tends to do unwanted things on your Windows machine.) >> This information is requested for you
Please let me know if you have any questions regarding the additional information. >> Why RTM ISO CD works and not Update 1? I think this is a key question. We know we have correct ISO image and you can see that there are many others who have issue with it never been heard before with RTM release. If you need any other details please let me know.
The problem that I've been experiencing is during the ESX Update
installation, it quits right at the 68% complete then posts a message
that either the CD media is bad or there are missing files.
Any ideas on this type of problem?
I am using Sonic DigitalMedia Plus v7.0 to create CD's from ISO images.
Have you done "Test CD" option when you boot to ESX install?
Also you can switch with AltF4 and AltF3 to see actual error when process stops at 68%. I had same problem with ESX 3.0.2. Turned out it was bad CD media.
Yes I did and the report was the CD was bad. This is what lead to the
ISO corrupt chain of email. How can we create a usable CD from what I
say is a bad ISO image. I've never had so much trouble pulling down ISO
images as this one. The VMWare tech support needs to investigate and
correct it. If not then they should post caveats on what troubles have
been identified and workaround solutions. Even better, mail installation
media to customers.
Not only DRAC, but IBM RSA/aMM, and HP iLO/iLO2 have at times issues with ESX 3.5 Update ISO images. We have had various issues with ESX 3.5 Update 1 media as well. And, I don't care that VMware says 'Don't Use' HP iLO. DRAC, RSA, etc. The fact is, they should support them, and people in real life use them. VMware should also support USB drive boot and build officially. I know this a bit off topic, but NO ONE seriously stands in front of a server with physical media these days. And of course ESXi adaption rate at enteprise level is NOT going to be fast, so media image builds are going to be around for 18 months or 2+ years if you look at ESXi development roadmap is considered from a rationale perspective.
Another thought came to mind? Did VMware change their web site infrastructure from physical to virtual? From running on hardware to VMs? Does that explain why the community forums seem slower than in the past, and the downloads are not as stable? NAH... That just does not make sense... Never mind. Of course the VMware entire websphere runs on VMs... ah...well... they do? right?
This could indicate that the CD wasn't burned correctly, or the media was scratched or faulty. It may help to burn the media at a slower speed. (I've experienced this problem with the bargain-priced 100-pack type of CD-Rs when burning at high speed.) Have you tried running the media check when prompted? (Nevermind: I've read your subsequent post, and it appears that the media test failed in your case. Unfortunately, the Tech Support Engineer was correct: This indicates that the media could be read, but the bits were simply wrong.) You can also calculate an MD5 hash of the media itself, and compare this with the one on VMware's download page. On Linux (or the ESX Console OS), you can do this by inserting the CD in the drive and running "md5sum /dev/cdrom".
If you're installing over iLO or a similar device, it may be that the virtual media is being disconnected. Unfortunately, each device handles this differently, as does each operating system. For the installer's part, in most cases it does not seem to handle a disconnection and subsequent reconnection gracefully. This is partly due to the devices themselves, partly due to the way the installer's Linux kernel handles these devices, and partly due to the way the installer recovers (or doesn't) from an error reading the media. We should take a look at this latter issue, and see if there is something we can do better to recover from this scenario.
Some remote console devices enable you to adjust a timeout for virtual media. Setting this value to the maximum may help. However, this is not configurable on all devices.
We have been testing 3.5 Update 1 ISO media on IBM RSA(aMM for BladeCenter), Dell RAC, and HP iLO/iLO2. We have seen some very odd issues lately with ESX 3.5 Update 1 media that we never saw previously. We have not narrowed down the specifics in all cases, but we know we have valid ISO images, in that they burn fine at any speed we have tried, as I noted before, using Nero 6.x and 7.x with no issues. We always validate the MD5 sums as well. Updates to follow, as we learn more.
know this a bit off topic, but NO ONE seriously stands in front of a server with physical media these days.
No, this is not at all off topic. The main reason I started this thread is that we had problems extracting the ISO image to a directory on our Altiris server, which is a Windows box. That means I'll probably use Windows tools to validate and extract the ISO.
Now, how many VMware customers will deploy their enterprise-class virtualization product with an enterprise class deployment tool like Altiris (or HP RDP)? One? Ten? Thousands? How many will have spent a couple of hours troubleshooting their deployment system, before realizing the extracted files are not exactly what they should be?
Those are all excellent points made with rational reasons to believe
that an ISO file should work with most CD/DVD writer software. It should
not be the case where the customer has to download/pay for alternate
You'll find that many company's insist on controlling computer
environments by approved software.
We had the same problem.
We copied the iso file to our local FTP site and did the installation via the FTP, so we could rename the files during the installation.
After a while we got the same message we renamed the files and everything was Ok.
We renamed "VMware-esx-drivers-scsi-qla2300-v707_vmw-3126.96.36.199-82663.i386.r" to "VMware-esx-drivers-scsi-qla2300-v707_vmw-3188.8.131.52-82663.rpm"
and "VMware-esx-drivers-scsi-aacraid_esx30-184.108.40.206vmw-64607.i386.rpm" to "VMware-esx-drivers-scsi-aacraid_esx30-220.127.116.11vmw-64607.rpm"
We did it with every file that showed op with a error, after that the installation was a SUCCES.
I need to know more details on the steps undertaken.
1. Download the ISO image from VMWare to your ftp site.
2. Create CD using what product from the VMWare ISO image.
3. Test CD to validate to issues exist, missing files etc.
I downloaded the iso 2 days ago (Latest Version: 3.5 Update 1 | 4/10/2008 | Build: 82663)
First we tried to install it via the cd-rom, but we got the errors above.
So i put the cd in my notebook an copied the entire content to our FTP server (wich is located in the same network as the ESX server).
During the installation of ESX 3.5 update 1 you can choose where the installation files are located ( CD / HTTP / FTP ), we choose FTP site, just enter the ipnumber of our ftp server and the name of the map (we also had to enter the root folder name (michiel\install\esx3.5) and entered the username and password (i dont know why but the the password cant have capital letters).
The installation continious and after a while we got the error, i got behind my laptop and browsed to the ftp map, i renamed the files so they all ended with .rpm.
I hit Ok in the error screen on the ESX server (retry), and the installation went further.
I assume you can also edit the iso files and burn it back to a new cd......
I hope this information will help.
I understand the parts about creating CD's from the ISO file. What
application/program did you use for this part of the process?
We are using Sonic v7.0 windows based application.
The next part of your process sounds as though you run the
installation/setup.exe off the CD and target the FTP site as the
destination, is this correct? At this point does the installation fail
then you begin renaming the files with extensions of RPM?
This sounds like a tremendous amount of effort on your part to correct
problems contained within the way the ISO image was built. I still stand
by my original comments that the vendor should take the initiative to
make corrections and create a standardized ISO image then publish it to
I found 4 files that needed to be renamed with the rpm extension and then the install worked fine. These are under the VMware\RPMS directory. I am using HP RDP to delpoy the OS.
Sorry I just noticed michiel.peeters already posted this.
Message was edited by: snowbird
It is nice to know with exact files need to be renamed, i didn't write them down. Now we can rename the files and create a new bootable cd.
Because we didnt know wich files needed to be renamed, we choose the FTP method, so we could rename the files during the installation.
"The next part of your process sounds as though you run the
installation/setup.exe off the CD and target the FTP site as the
destination, is this correct?"
Let me try to explain,
1. we downloaded the iso image file from the website
2. we burned the iso to a cd
4. we copied the entire content of the cd to a map on our local ftp server
5. we boot the new ESX server with the cd, after a while you can choose where the source files are located, we selected FTP
6. when the error came up, we renamed the file wich was "bad", en pressed enter on the ESX server, we repeat this step with all the errors.
i hope its al little clearer now.
This thread is getting so long. Hopefully VMware now understands how violating standards is a bad idea. Let's clear up a couple things though.
The 4 file names have been known from the beginning, posted in the very first message of this thread even.
As to the idea of renaming them and burning a new bootable CD... well it just won't work. The issue isn't that the ISO vmware provided is bad, but rather non-standard. They elected to exceed the maximum filename length (64) of the Joliet file system. Using some special parameters on a Linux host you can create a disc with filenames up to 103 characters. However, Windows CD driver does not handle the long names. Linux seems to not have the problem reading the kludged disc.
Even the manual for the Linux iso builder application (mkisofs) says that using the long filenames is a very BAD idea. The problems we've been experiencing is proof that the authors of that manual were telling the truth.
Bottom line is that we cannot fix this ourselves really. It is up to VMware to resolve it. Our role is to apply pressure on them to force the right decision out of them.
Until they change this, touching the ISO using Windows poses a likelihood of creating this truncation issue. You don't know how much this pains me to say, but this time the problem isn't a MS Windows flaw.
File support tickets with VM support for every instance where this affects you.
I agree the problem is totally in the VMWare production's hands. Their
help desk needs to elevate this matter to upper management for
resolution. To expect the customer to come up with solutions could
introduce other unforeseeable problems. To ignore this as a high
priority can damage the VMWare Company's reputation to say the least.
We have all wasted precious man hours trying to come up with solutions
on a problem that is clearly a lack of VMWare using standard practices.
I see this file listed when the installation/upgrade stalls. I searched
the media and located the RPM file.
The only difference is the one on the CD has extended the name
Did anyone else see the same problem?