Hi,
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: VMware-esx-drivers-scsi-aacraid_esx30-1.1.5.2vmw-64607.i386.rpm
3.5.0 Up1: VMware-esx-drivers-scsi-aacraid_esx30-350.1.1.5.2vmw-82663.i386 (the .rpm is missing)
and so on:
VMware-esx-drivers-scsi-lpfc_elx_v740-350.7.4.0.13.1-82663.i386
VMware-esx-drivers-scsi-mptscsi_2xx-350.2.6.48.13vmw-82663.i386
VMware-esx-drivers-scsi-qla2300-v707_vmw-350.7.8.32-82663.i386.r
Renaming them to the proper file name doesn't work though. Any chance for a 82663a build?
Did you run the MD5 hash? The website states md5sum:7b30e780044302ac893bc25d03e48959 but there have been other recent posts that state the website value may be incorrect.
Have your tried verifying the download using the MD5SUM? I am wondering if this could be the case...
--
Mark Mathson
It appears we hit Post Message at the same time.
--
Mark Mathson
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.
Is this for a new install or upgrade existing 3.5 server? You can also try the ZIP file instead of the ISO to see if you can upgrade the server.
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
media,
we will support customers in order to be able to upgrade.
However where customers respin the provided VMware ISO, then we don't
support this
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
address this.
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
Method Changes)
I am informed by engineering that this naming convention is here to
stay.
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
truncated.
" 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
avoid it.
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
decribed above,
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.
Hmm, so in the future, if I need to extract the files for a network deployment, I'm supposed to abuse an ESX server to get to the files? This is a Windows shop
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:
67% Complete
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.