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.
