Contributor
Contributor

VMware 3.5.0 Update1 ISO corrupt?

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?

0 Kudos
73 Replies
Expert
Expert

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.

0 Kudos
Contributor
Contributor

Have your tried verifying the download using the MD5SUM? I am wondering if this could be the case...

--

Mark Mathson

0 Kudos
Contributor
Contributor

It appears we hit Post Message at the same time. Smiley Happy

--

Mark Mathson

0 Kudos
Contributor
Contributor

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.

0 Kudos
Expert
Expert

Don't know if you have read this thread or not but there are some issues with the 3.5 update.

0 Kudos
Contributor
Contributor

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.

0 Kudos
Immortal
Immortal

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.

0 Kudos
Immortal
Immortal

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.

0 Kudos
Contributor
Contributor

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?

0 Kudos
Immortal
Immortal

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.

0 Kudos
Contributor
Contributor

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.

0 Kudos
Enthusiast
Enthusiast

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.

0 Kudos
Contributor
Contributor

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 Smiley Wink

0 Kudos
Enthusiast
Enthusiast

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.

0 Kudos
Expert
Expert

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?

0 Kudos
Contributor
Contributor

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?

0 Kudos
Expert
Expert

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.

0 Kudos
Enthusiast
Enthusiast

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.

0 Kudos
Expert
Expert

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.

0 Kudos