File names truncated in repodata - official bin DVD

[mbrijun]

Hello fellow Centos users,

yesterday I downloaded the official Centos 6.0 binary DVD with MD5 of "d7e57d6edaca1556d5bad2fa88602309". As my linux machine does not have a DVD, I extracted the ISO onto a Windows machine with Winrar and started the network install. Soon I got an error message "Unable to read package metadata. This may be due to a missing repodata directory". Upon closer inspection I realised that all the file names within the "repodata" folder are truncated to 64 characters. To doublecheck the theory I also burnt a DVD. It had the same problem.

Either I have downloaded an outdated DVD from http://mirrors.dedipower.com/centos/6.0/isos/i386/CentOS-6.0-i386-bin-DVD.torrent or the DVD image needs to be rereleased.

I was able to complete my installation by rsyncing the extracted ISO with one of the mirrors.

Please advise.

[pschaff]

The problem was likely not with the ISO but with WinRAR which mangled the file names. If you burned a DVD from the extracted directory, or extracted files from a DVD burned from the good ISO image, but with the same WinRAR tool, you just replicated the problem again.

Sounds like you found a suitable work-around, but there are other Windows tools that can handle the job properly. Others have [url=https://www.centos.org/modules/newbb/viewtopic.php?topic_id=32279&forum=55&post_id=138289#forumpost138289]reported success with WinRAR[/url] so it may be a matter of the version or options used.

[mbrijun]

Hi Phil,

thanks for your reply. Yes, I had a doubt about Winrar, although it had never previously let me down. I burnt a DVD as well. The DVD also had the file names truncated. I am rather sure at this point it is an issue with the ISO. The checksums of the ISO are correct.

Martynas

[pschaff]

I can assure you that a valid ISO image works, without mangled filenames, when downloaded, verified via checksum, burned directly to appropriate media, and used as intended - as a bootable installation source. Both QA testing and extensive installation experience by others confirm this. It is not clear from the information supplied how you are seeing truncated filenames, but it would have been noticed before now if there was such a basic issue with the ISO images.

[mbrijun]

Hi Phil,

I have re-read my original post. It is obvious that I did not include the CPU arch in the post.

Arch: i386
Name: CentOS-6.0-i386-bin-DVD.iso
MD5sum: d7e57d6edaca1556d5bad2fa88602309

Probably not many people use the i386 media these days, let alone use network install to install it. Again, I could be wrong.

I have also found a bug which could be relevant: http://bugs.centos.org/view.php?id=4947

Please see the the included screenshot:

https://docs.google.com/leaf?id=0B1qVFQzoUCmoNTI5Mjk5ZDUtMjcyOS00M2Y4LWE0MGQtMTBmZDFlMWY4Y2Zi&hl=en_GB

[pschaff]

That bug was about a repository sync issue.
[code]# mkdir /tmp/mnt
# mount -ro loop /share/CentOS/6/isos/i386/CentOS-6.0-i386-bin-DVD.iso /tmp/mnt
# ls /tmp/mnt/repodata/
2b014e1fcde80ec1cc69d6a048f260f712b1ae2d83d1fc04d3b3c00ade817ec9-primary.sqlite.bz2
509e08f6113733097d575739730e47783b85f94fe8cf449767364b8b8c7aba7b-other.xml.gz
67e74ebb80b8882defa7712a4a7192a65bd68d33894f6013fca41f4954845aa1-c6-i386-comps.xml.gz
73a3b7e0741eba6cafa8d5404b02565060e7f2293caab10657074186c48e713b-c6-i386-comps.xml
b4ccc345fa1c924fa1ab3841913be2c37507dc448b91f33f95e041c00b4bacfa-filelists.xml.gz
bc37813e8d9a5dd92784ba8149dc2995db7be4624207d56fe841bbf14187180f-primary.xml.gz
c639bc18e11e6e620b30b80fa43f69d830c08a1c1890b0dc5afed0028704ddc8-other.sqlite.bz2
d15a7119737517aa5f5a330d9da13336e537845f861a9757e0d211249e193836-filelists.sqlite.bz2
repomd.xml
TRANS.TBL
# md5sum /share/CentOS/6/isos/i386/CentOS-6.0-i386-bin-DVD.iso
d7e57d6edaca1556d5bad2fa88602309 /share/CentOS/6/isos/i386/CentOS-6.0-i386-bin-DVD.iso
[/code]
QED :-)

[mbrijun]

Hi Phil,

I think I understand what has happened here. I fired up a virtual machine by using the ISO downloaded. I am happy to report that the file names are indeed displayed in full:

[quote]
[mbrijun@spark repodata]$ ls
2b014e1fcde80ec1cc69d6a048f260f712b1ae2d83d1fc04d3b3c00ade817ec9-primary.sqlite.bz2
509e08f6113733097d575739730e47783b85f94fe8cf449767364b8b8c7aba7b-other.xml.gz
67e74ebb80b8882defa7712a4a7192a65bd68d33894f6013fca41f4954845aa1-c6-i386-comps.xml.gz
73a3b7e0741eba6cafa8d5404b02565060e7f2293caab10657074186c48e713b-c6-i386-comps.xml
b4ccc345fa1c924fa1ab3841913be2c37507dc448b91f33f95e041c00b4bacfa-filelists.xml.gz
bc37813e8d9a5dd92784ba8149dc2995db7be4624207d56fe841bbf14187180f-primary.xml.gz
c639bc18e11e6e620b30b80fa43f69d830c08a1c1890b0dc5afed0028704ddc8-other.sqlite.bz2
d15a7119737517aa5f5a330d9da13336e537845f861a9757e0d211249e193836-filelists.sqlite.bz2
repomd.xml
TRANS.TBL
[/quote]

Which means that the problem lies somewhere else. The only thing that I can think of now is the Joliet vs Rock Ridge extensions. A quick search on the internet reveals that Joliet only supports file names up to 64 unicode characters long. Rock Ridge supports longer file names. I think Windows only uses Joliet.

[pschaff]

[url=http://en.wikipedia.org/wiki/ISO_9660#Operating_system_support]Wikipedia[/url] agrees with you about the Windows limitation.