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

Not only VC update was wrong now the ESX CD when burned with ordinary tools is corrupted. At least they should have warned people! I have no cd burner programs capable of handling this ISO we are mostly on windows and do not have any cd burners on our redhat boxes. I can extract files intact using WinImage but again gave no software to make a bootable CD of it. Why is it so difficult to use Juliette format?

Are there any disadvantages or extra complexities in installing from ZIP? Has anyone already done it? Did it go smoothly?

Thanks,

Alex

0 Kudos
Expert
Expert

Interesting... I downloaded the 3.5 Update1 ISO image, validated the MD5 sum. Then burned my ISO file with Nero Burning ROM 6.6.0.6 and 7.x.x.x Ultra Edition (different desktop off-site, so don't have the specific version at hand). But burns completed without issue and verification completed without issue. I downloaded the ISO file late Monday afternoon (April 14th), if that makes any difference?

0 Kudos
Contributor
Contributor

Thanks for the tip! I will try nero

0 Kudos
Contributor
Contributor

Maybe we should compose a list of burining and extracting software that says whether it works or not.

  • Nero 6.6.0.6 - Works

  • Nero 7 - Works

  • WinRar 3.71 - Doesn't work

  • MagicISO - Works

  • NTI DVD-Maker 7.7 - Doesn't work

  • WinDisk - Works

  • HP iLO - Doesn't work

  • Dell DRAC - Doesn't work

  • Alcohol 1.9.7 - Doesn't work

0 Kudos
Contributor
Contributor

Maybe we should compose a list of burining and extracting software that says whether it works or not.

  • Nero 6.6.0.6 - Works

  • Nero 7 - Works

  • WinRar 3.71 - Doesn't work

  • MagicISO - Works

Excellent Idea

NTI DVD-Maker 7.7 - Doesn't work

WinDisk - Works

0 Kudos
Contributor
Contributor

If anyone knows anything about software not mentioned here, post it, so we can expand the list.

0 Kudos
Enthusiast
Enthusiast

Here is the deal. We have HP 7000c enclosuse and HP BL460c blades. If we try to use ESX 3.5 update1 ISO and mount it in iLO as ISO file the result is that you get a message asking to insert ESX installation CD and cannot continue the install. This enclosure does not have CD-ROM, so iLO is the only option used. This is also a problem for remote installations in data centers.

I think VMware has to revise HCL and exclude mentioned hardware as you cannot install ESX 3.5 update 1 from ISO file provided as is unless HP will try to fix something in thier firmware.

0 Kudos
Contributor
Contributor

That's bad... does the iLO firmware version make any difference?

0 Kudos
Immortal
Immortal

I think that VM Ware blaming this on ISO standards and not supporting them is bogus. They provide the media, they must adhere to standards, period. Otherwise everything is a bust.

I am NOT going to switch software simply because one works and one doesn't, that's retarded, and if this is the case, when I come back off of vacation, I am lodging a formal complaint. This is getting WAY out of hand, and this is not tolerated.

I am using Alcohol 1.9.7 and it doesn't appear to work either.

I think it should ALSO be noted that Dell and HP's have a method to use an existing ISO via any location, and that's not working either. So now who does VM Ware have to blame? I am not buring the CD, it's built into the Remote Access Card, so what, Dell and HP need to re write their Remote Software for accessing ISO images, too? I don't think so.

0 Kudos
Immortal
Immortal

I agree with Eugene, we don't have HP, but we do have Dell, and they have a ILO equivalent method, called DRAC, Dell Remote Access Card. I can boot, but around 68% it bombs complaining a file is missing or corrupt...

And no the firmware doesn't make a difference. We haven't had an issue until ESX 3.5 Update 1.

0 Kudos
Immortal
Immortal

Are there any disadvantages or extra complexities in installing from ZIP? Has anyone already done it? Did it go smoothly?

The problem is, what if you are doing a NEW install? Upgrade or a ZIP isn't an option, there is no place to extract them to on the ESX host. Right now I have to revert to ESX 64607, then do a remediate, which is rediculous. I should be able to do a NEW install from update 1.

0 Kudos
Contributor
Contributor

So if Alcohol doesn't work, we can write off Daemon Tools as well.

0 Kudos
Enthusiast
Enthusiast

PLEASE FILE TICKETS WITH VM SUPPORT for all issues you have with the 3.50 Update 1 ISO image. This is a real problem, and I suspect they are just not seeing enough tickets on it to be pushed to action.

I assume that everyone here has filed support tickets with VMware on this issue. While the info I posted earlier basically left my special case "hung out to dry", the other cases being documented here, especially the ones on iLO and DRAC are critical, and based on the reply I received from the tech:

"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."

these issues should be addressed by them. They can't ignore major vendors not supporting VMwares uses of a non-standard Rock-Ridge format on the ISO's. They need to create the ISO in the standard format, not "joliet-long" style.

Here is the relevent section of mikisofs from the man page pertaining to the method they are using to "trick" the file system (I've bolded the important thing for them):

"-joliet-long

Allow Joliet filenames to be up to 103 Unicode characters. This breaks the Joliet specification - but appears to work. Use with caution. The number 103 is derived from: the maximum Directory Record Length (254), minus the

length of Directory Record (33), minus CD-ROM XA System Use Extension Information (14), divided by the UTF-16 character size (2)."

0 Kudos
Expert
Expert

Excellent, thanks. Yes, VMware should get hammered for this to a

degree.

Schor-

0 Kudos
Immortal
Immortal

> Excellent, thanks. Yes, VMware should get hammered for this to a degree.

TOTALLY!! nth degree.

0 Kudos
Contributor
Contributor

The VMware help desk and engineers should act on this matter ASAP to

resolve before their credibility is damaged. It should be a relatively

easy task to create a new ISO then test and publish it for use.

0 Kudos
Immortal
Immortal

I'm an engineer with VMware's Continuing Product Development (CPD) Team, and I've been recently apprised of the issues surrounding the truncated file names on the ESX 3.5 Update 1 CD. I think there are some mis-conceptions about the root of the problem, and I'd like to clarify them, as well as re-assure you that VMware is working on a solution.

Since the ISO9660 standard implies severe limits on the length of file names and which characters they may contain, VMware creates our CD images with both Rock Ridge and Joliet extensions. While it is not necessary to use both, it ensures that the correct (long) file names are available on a greater number of platforms. Specifically, while Linux (including the ESX installer environment and the Console OS) and Apple OS X support Rock Ridge, Microsoft Windows supports only Joliet.

Rock Ridge's limit for file name length is 255 characters. However, Joliet has a 64-character limit. This is part of the Joliet standard, and not a bug with the tools VMware uses to create the ISO images. The re-naming of some RPMs in the update 1 CD to address upgrade issues has caused some file names to exceed this 64-character limit. As a result, those file names are shortened to 64 characters in the Joliet records.

Since Windows systems will use the Joliet extensions, when extracting the contents of the CD or ISO using a Windows machine, the short file names will be used. Once the files have been copied off of the CD or ISO, they can simply be renamed, as the other file systems used by Windows (NTFS and FAT32) support file names up to 255 characters long.

OS X and Linux both default to using the Rock Ridge extensions, so those platforms do not encounter this issue.

It is important to note that when simply burning the ISO image to media, there is no need for the operating system or CD-burning software to understand the file system contained within the ISO image. Thus, one can use a CD-burning program like Nero on a Windows computer in order to create valid installation media. It is only when extracting or copying the contents of the ISO or CD, for example to add files to the CD or create a network installation source, will the truncation of Joliet file names cause a problem. (Whether or not one can restore the long file names when modifying the ISO image's contents will likely depend upon the CD-mastering software used.)

Similarly, the remote console applications provided by devices like the Dell Remote Assistant Card (DRAC), HP Integrated Lights-Out (iLO) and IBM Remote Supervisor Adapter (RSA) read the low-level CD media or ISO image. Since they also do not need to understand the file system contained on the image or media, the truncated Joliet file names should not impact the use of these devices to install or upgrade ESX (provided that the ISO image has not been modified).

VMware did not, of course, intend to break the ability of Windows users to properly read the CD. We are investigating several ways to mitigate this problem in future releases, such as re-naming the affected files or using non-standard long file name support for Joliet (e.g., the -joliet-long option to mkisofs), and I'm confident that we'll have a solution before the next release.

-Richard

Richard Shaffer

0 Kudos
Hot Shot
Hot Shot

I've seen similiar installation failures using DRAC virtual media. For some reason, virtual device I/O does not keep the idle timeout from expiring. When it does, the DRAC breaks the virtual device connection, but leaves the console session running.

I've gotten around the problem by setting the idle timeout to its max value.

0 Kudos
Enthusiast
Enthusiast

rshaffer, your response is appreciated. However, let me note a few key things which I can't fit into your explanation of the situation:

  • we can't install ESX 3.5 Update 1 when downloaded ISO image is burned with Nero 7 and from management windows desktop attached to HP Blade via iLO. "Insert ESX Installation CD" error comes up after bootloader is trying to read CD to continue installation.

  • same result if attaching the ISO image to HP Blade via iLO from the same desktop.

Do you have answer for this? We have no problem using ESX 3.5 RTM ISO image.

Best regards,

Eugene

0 Kudos
Immortal
Immortal

Hi Eugene,

There are several problems that could be occuring:

1. The installer may be unable to find the CD-ROM device on your system. I think this would be relatively rare, since remote console cards usually emulate them as generic IDE or USB devices.

2. The installer may be unable to mount the file system on the CD, possibly because it is in some way corrupt.

3. The installer may have determined that the CD is not a valid ESX installation source, because it cannot find the .discinfo or stage2.img files.

4. The installer was unable to mount the stage2.img.

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.

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?

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.

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.

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.)

Please let me know if you have any questions regarding the additional information.

Thanks,

-Richard

0 Kudos