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
Contributor
Contributor

The following are captures of information during attempts to run upgrade from VMware 3.0.2.

Below are the final messages at which time the installation/upgrade stalls due to missing files or corrupt media.

Package Installation

Name: VMware-esx-drivers-net-e100-2.3.40-64607

Size: 204K

Summary: VMware ESX Driver

Packages

Total: 232

Complete: 192

Remaining: 40

Then this message gets displayed.

The package

VMware-esx-drivers-net-e100-2.3.40-64607 cannot be opened. This is due to a missing file or perhaps a corrupt package. If you installing from CD media this usually means the CD drive is unable to read the media.

Press to try again

-


I then ran the media self test which fails.

Medial Check Result

The image which was just tested has errors. This could be due to a corrupt download or a bad disc.

0 Kudos
Contributor
Contributor

So, to sum up:

1. When copying ISO contents in order to customize installation (scripted, etc), don't use Windows. Rather, mount a valid CD in a ESX / Linux host and extract from there.

2. Once repackaged, the ISO will need to be burned to CD on a Linux box.

Is this correct?

0 Kudos
Immortal
Immortal

Hi astrolab,

Number 1 is correct. Number 2 is not: It shouldn't matter what OS you

use to burn the ISO image.

-Richard

0 Kudos
Contributor
Contributor

Not really. Both depend on the software you use to extract the files or burn the image. Some burning software appears to be 'recompiling' the ISO image in the process. Some Windows-based ISO extraction programs just work. See .

0 Kudos
Leadership
Leadership

Thread moved to the VI: ESX 3.5 forum

Tom Howarth

VMware Communities User Moderator

Tom Howarth VCP / VCAP / vExpert
VMware Communities User Moderator
Blog: http://www.planetvm.net
Contributing author on VMware vSphere and Virtual Infrastructure Security: Securing ESX and the Virtual Environment
Contributing author on VCP VMware Certified Professional on VSphere 4 Study Guide: Exam VCP-410
0 Kudos
Contributor
Contributor

Richard,

Thanks. I am still unsuccessful in ISOing ESX 3.5 Update 1 after I repackaged it with kickstart files. I don't have problems with builds prior to 3.5 update 1. Using ISOrecorder or Easy CD Creator 10.

0 Kudos
Contributor
Contributor

All,

That is a valid point to make, why are the earlier ISO versions 3.0.2

working with no flaws and this version requires a frustrating amount of

effort with no successful result? What changed from previous version to

this release? I used Windows Easy CD Creator with success and now I see

from the flood of discussions that everyone has their approach but none

are using default settings of applications e.g. Easy CD Creator or Roxio

by Sonic.

The VMWare engineer team need to fix this.

0 Kudos
Enthusiast
Enthusiast

I think VMWare does not want to accept the problem as is and they are trying to convince us we all do it wrong and everything is perfectly working. This only creates frustration for all IT engineers spending long hours trying to make this working. This damages VMware products reputation and the company image because nobody want to spend time because of a product issue.

Regards,

Eugene

0 Kudos
Enthusiast
Enthusiast

The reason it is broken, is that they "fixed" a problem they created with the release of 3.5 where certain patch names were in conflict with 3.0. To address the problem, they inserted more version info into the file names at 3.5U1 (happened as part of the patch process pre-update 1 actually), but this pushed the filename length over the Joliet file system limit. To work around the latter problem, they use a documented kludge in the mkisofs (--joliet-long) program that uses a portion of the directory name space for the file name. However, the mkisofs man page warns that this could break things and may or may not work. And, Windows has no understanding of the kludge, nor do many Windows third party burner apps. Windows is truncating filenames due to VMware choosing to not follow the Joliet file specification. Doing the builds and burns in Linux does not have the issue, only Windows.

I agree that failing to recognize this as a problem is a black eye for VMware. They should realize that it's never a good idea to work outside the bounds of the specification, especially when dealing with heterogeneous environments.

Keep submitting tickets to vmware support. It's the only way they know how big of a problem this is.

0 Kudos
Immortal
Immortal

Hi astrolab,

I'm not sure what you mean by "unsuccessful." Is it that the CD you create doesn't boot properly, or that the file names are still shortened?

I'm assuming that the files you copied to the hard drive on your Windows machine have been properly re-named before creating an ISO from them. In that case, as long as your software supports Rock Ridge extensions, this should work fine. However, the file names will still show up truncated on Windows systems, since they rely on Joliet instead of Rock Ridge support.

If it's an issue with booting, it may be that your CD-authoring software doesn't understand how to create a bootable CD using the isolinux image. (I have neither ISOrecorder nor Easy CD Creator, so I'm not sure what options these support.) With isolinux, there should be no "disk emulation" to simulate a hard drive or floppy. If you have mkisofs, the proper options for creating a CD would be:

mkisofs -J -r -T -b isolinux/isolinux.bin -c isolinux/boot.cat -no-emul-boot -boot-load-size 4 -boot-info-table -o output_file_name.iso source_dir

This page has links to download pre-compiled Windows binaries of the cdrtools package, which contains mkisofs.

Hopefully, you'll be able to get this to do what you want it to.

-Richard

0 Kudos
Contributor
Contributor

Thanks for the reply.

I do everything from an ESX host, via mkisofs, using exactly what you indicated. THen I transfer the ISO to a Vista workstation for the burning. It's the burning process that "breaks" the installation truncating the RPM names, I assume it's strictly dependent on the ISO burning software. Never had this issue with builds from 3.5 64607 down. Sorry if I created confusion, are you successful in creating an installation CD from a Windows workstation? I assume if I burn the ISO from a Linux VMWARE Workstation guest in a Windows workstation, it will still conflict with the Joliet standards as it's proxyed to Windows for the actual access to the CD?

0 Kudos
Immortal
Immortal

Hi Astrolab,

Can you detail which burning software you're using and the steps you're

taking to burn the image? I'll try to duplicate your problem if I'm

able.

-Richard

0 Kudos
Contributor
Contributor

rshaffer, let's go through the steps, live from my office: Smiley Happy

1- mount ESX 3.5 CD from CD-ROM drive of ESX host, copy everything to /tmp/esxcd

2-Unpackage, add KS file, repackage using :

mkisofs -J -r -T -b isolinux/isolinux.bin -c isolinux/boot.cat -no-emul-boot -boot-load-size 4 -boot-info-table -o output_file_name.iso source_dir

3- SCP to a Windows workstation

Now, mount the ISO as a CD-ROM using Virtual Clone DRive. All RPMs look as they should, no truncation.

4- Ok, to the burning now....

Using, say, ISOrecorder.

5- Off to try....... Boots OK, as expected. Transfer image, all very well....BINGO

It's working. I guess I just need to mount the CDROM directly into a Linux / ESX host, not on a Windows box and then transfer it.

Thanks Richard.

0 Kudos
Contributor
Contributor

BTW, encountered the same problem with the Update 2 ISO. Attempted to install via iLO. Failed. MD5 checked OK. Self tests failed most of the time. Even when they passed, the installation failed.

To get around it: I used the two ISOs which I downloaded (thinking the first one was bad). Whenever an error popped up during the upgrade, unmount the ISO, remount the other one, retry and continue .. repeat until completed. For whatever reason mounting and unmounting the same ISO did not work, but using two files worked .. not sure why, woodoo? Smiley Happy

Good luck.

miji2

0 Kudos