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?
Yup. The md5sum of the ISO on my hard drive is 7b30e780044302ac893bc25d03e48959... My colleague who discovered the file differences downloaded the ISO from home last night, same problem.
Yes, I've read that thread, but now, the md5sum appears correct.
I downloaded my ISO three days ago, and it's the same one as my colleague has. As if they fixed the md5sum instead of the ISO.
If your colleague has their ISO working, have them send you a burned CD with the ISO, maybe it's not the ISO but your burning software. I had trouble with some images, even though everything was fine, and it turned out to be the disks I was using. I had to make 4 attempts before it worked, but the ISO was fine.
Also not sure what kind of machines you use, but some have remote cards you can use to install the ISO from the network. Drop the ISO on a network someplace, and install from the ISO rather than a CD.
No, the ISO I have is exactly the same as my colleague's.
Anyway, your second suggestion made sense, so I tried another way of accessing the contents, and extracted all files with both WinRAR and MagicISO. Lo and behold, there was no file name corruption when I extracted with MagicISO (WinRAR did come up with truncated file names). As we're deploying through Altiris, this is good, I need the extracted files anyway. I'll try tomorrow morning (it's almost 7pm here) and post the results.
Either way, shouldn't an ISO image produce the same results, no matter what burning software you use?
Yes, but for some reason, the ISO doesn't always work. I don't know why that is either. In my case I used the same CD rom software (Alcohol) every time, the disks were different, I used some cheap OEM brand CD rom 3 times until I finally used Memorex and it worked perfect, so I knew the ISO was fine.
I finally used the ISO on another machine via the Remote Access and it worked, so the ISO wasn't the issue.
Ok, but using software to extract the files takes media quality out of the equation, doesn't it?
Oh well, as long as the problem is solved tomorrow. Thanks y'all for your input.
I filed a ticket with support yesterday morning and they got right back to me.
The official answer is that it's a feature not a bug, I'll post the VM tech's thread at the bottom of this. Anyway, they've made a decision to rename some rpm's to avoid a version conflict, but in doing so, have exceeded the 64 character filename limit for the Rock Ridge format. There is a kludge to use -juliet-long within mkisofs (the linux command that builds ISO's), but it is not standard and is highly unrecommended by the authors of mkisofs.
Basically, I copy off the files to a directory, then I went in and manually renamed the truncated files. That done, I altered the mkisofs command to use -juliet-long.
I think it's a bad idea on their part to rely on a kludge to the Rock Ridge standard. Many applications and OS's (including Windows) it seems do not understand the kludge, resulting in the truncation of the filenames.
We add files to the disc, including the HP Insight tools, and some kickstart info, so we can build consistent servers offsite/offline. This change, doesn't completely break the process, but it is very confusing.
Here is the tech's message:
To answer your questions:
From a VMware perspective, we provide and support the ESX
installation media e.g. ISO,
so that if this is burned onto a CD and customers will be able to
install their ESX software.
Then if customers have issues during the install using the downloaded
we will support customers in order to be able to upgrade.
However where customers respin the provided VMware ISO, then we don't
as we have no control over the resultant ISO.
" Please correct this and reissue corrected media as soon as possible.
If not planning to immediately fix, what is the correct command line to
rebuild the disk, hopefully using the "mkisofs" command."
I had to check this with engineering. No there are no plans to
This is actually a fix that was introduced to address an upgrade
issue from ESX3.0.2 to ESX 3.5
and is necessary in order to fix a critical versioning/upgrade issue.
I think the related patch was (ESX350-200803213-UG Driver Versioning
I am informed by engineering that this naming convention is here to
Notice that if you view the iso files via windows e.g. winrar you can
see the truncated filenames,
however on a linux box (e.g. the ESX) if you loopback mount the iso
file and then navigate through the directories,
you will see that the filenames appear correctly and are not
" For the time being, I manually went in and repaired the truncated name on
harddisk, then used the following command to create the new iso:
mkisofs -J -joliet-long -R -r -T -o ../ESX350UP1_KS.iso -b isolinux/isolinux.bin -c isolinux/boot.cat -no-emul-boot -boot-load-size 4 -boot-info-table .
This appears to work now. Before, we did not need to use "-joliet-long" to
get a good build, and since it is non-standard to use it, we'd prefer to
The following line:
mkisofs -J -l -R -r -T -o ../ESX350UP1_KS.iso -b isolinux/isolinux.bin -c isolinux/boot.cat -no-emul-boot -boot-load-size 4 -boot-info-table .
worked through version 3.5 with no problem. The problem is that this line
which builds a very standard iso image causes failure messages when used with
the truncated filenames. "
The command looks okay, however as it is not a supported activity as
it is up to the customers to experiment and test out what are the
proper arguments of the mkisofs (or genisofs etc...) command.
I hope that this answers your query, eventhough that you may not necessarily
agree with it
and having to use an additional step that was not necessary before in ESX3.5.
FYI, ESX doesn't have mkisofs in it, so you need another Linux box. No need to abuse the ESX server<g>.
I have an Ubuntu server in a vm that I use to do the build with mkisofs. I guess you could put a request into Micro$oft and the iso tools vendors to change how they handle kludged up CD's. I've slowly been migrating off Windows as much as possible anyway. Funny thing is how VMware treats linux as a third class citizen when it comes to not having VIC and requiring an MS server for VCMS, yet they tell me that if I look at the disk in Linux it works fine. Double standards at their best.
what version of mkisofs? I extracted files from ISO, they look correct, I added the additional command-line switch, but mkisofs still grips about non-standard names during generation of new ISO, and when I open new ISO, the long file names are there, but I still get the error when anaconda runs saying I have invalid media. I wonder if my mkfsiso version is different?
I am seeing the following error:
Error installing package,
There was an error installing VMware-esx-tools-3.5.0-64607
This can indicate media failure, lack of disk space, and/or hardware problems. This is a fatal error
and your install will be aborted.
I've tried downloading the ISO file several times and each attempt to create and install from it fail. Anyone else seeing this problem and what was the fix?
My original download of the OEM ISO yesterday is good, I have burned it and tested it. Did the MD5 sum match? It is the customized ISO image I create, that is driving me nuts, like others have commented on in this same thread.
I'm using Ubuntu, and the version of mkisofs is: 4.2.01+01a014ubuntu6. Please note, I've never used the "Test Media" as I've not figured out how it calculates the checks. The error I was having was at about 60% it said it couldn't read one of the truncated files.
Turns out my mkisofs version is current, the issue was that -l option conflicts with --joliet-long option, once I removed the -l option, things started working as expected, but I am still testing.