Created attachment 506079 [details] screenshot of the error msg Description of problem: The error msg that is recieved: Unable to read package metadata. This may be due to missing repodata directory. Please ensure that your install tree has been correctly generated. failure: repodata/7f0baa056a7062d97e7a721b02cb4a8722e8e2b0dbc62e0ef390dbaa96f1c378-primary.sqlite.bz2 from anaconda-InstallationRepo-201105131943.x86_64: [Errno 256] No more mirrors to try. [Exit installer] [Edit] [Retry] On the DVD media (Fedora-15-x86_64-DVD.iso) The file '/repodata/repomd.xml' specifies the following files on the DVD: 2837838aa7c648a3b6cd5eb754dee7b1df7b98bc42c58532937d9e4f397db7e8-Fedora-15-comps.xml 482363d08cce65e9862eef4f8389ae96c7114841032f97053b09b67fce1535c3-filelists.sqlite.bz2 5f9682212cf1ec3e67f0b98392bcdbfa575512cdaa0084bb70bbbec6c73f71fa-primary.xml.gz 7f0baa056a7062d97e7a721b02cb4a8722e8e2b0dbc62e0ef390dbaa96f1c378-primary.sqlite.bz2 a1e30d38bf8041a48d0a23ade3cdfe38e9c5b9873547d20e35d40466b27da0ca-filelists.xml.gz b12d93a30a89628e723469152807ac614d4bd93aacb1d7f4fdc04a6b373dedbb-other.sqlite.bz2 e67f6e07e869158b8ae94de833adf43fe14c4fdd90d8cf7c01fab221e9716684-Fedora-15-comps.xml.gz f40f58bd92219adf1a42e4b8914af33bf6c7e24ea419d5b8c812f9bbf451a944-other.xml.gz However, the actual filenames are missing the file extension: repodata/2837838aa7c648a3b6cd5eb754dee7b1df7b98bc42c58532937d9e4f397db7e8 repodata/482363d08cce65e9862eef4f8389ae96c7114841032f97053b09b67fce1535c3 repodata/5f9682212cf1ec3e67f0b98392bcdbfa575512cdaa0084bb70bbbec6c73f71fa repodata/7f0baa056a7062d97e7a721b02cb4a8722e8e2b0dbc62e0ef390dbaa96f1c378 repodata/a1e30d38bf8041a48d0a23ade3cdfe38e9c5b9873547d20e35d40466b27da0ca repodata/b12d93a30a89628e723469152807ac614d4bd93aacb1d7f4fdc04a6b373dedbb repodata/e67f6e07e869158b8ae94de833adf43fe14c4fdd90d8cf7c01fab221e9716684 repodata/f40f58bd92219adf1a42e4b8914af33bf6c7e24ea419d5b8c812f9bbf451a944 These are sha256 checksums of the files themselves, and I verified the checksum's are valid, just the file names are wrong. The situation with the file names causes a problem for anaconda when the boot options 'repo=' are used, and the repomd.xml file is parsed form the DVD or an extract of the DVD. For example: * booting from the DVD and specifying a NFS repo (a dvd extract). * booting from the DVD and specifying a CDROM repo (the dvd's /repodata). * PXE booting and specifying a NFS repo (a dvd extract). I uncovered this problem when creating an interactive network installation using PXE (syslinux), and then specifying repo=nfs. Here is my pxelinux.0 boot information: LABEL FC15i MENU LABEL ^Fedora 15 - x86_64 (interactive) IPAPPEND 2 KERNEL FC/15/x86_64/vmlinuz APPEND initrd=FC/15/x86_64/initrd.img ramdisk_size=5939 repo=nfs:192.168.1.234:/mnt/DroboFS/Shares/build/OS/FC/15/x86_64 ksdevice=p2p1 ip=dhcp lang=en_US.UTF-8 The above syslinux menu will launch anaconda from the initrd.img The problem was SOLVED when I rename the files according to how the repomd.xml file specifies (shown above). This is only possible if I have extracted the DVD to my NFS server for network installation, or by fixing the DVD iso. I have so far not attempted to fix the DVD iso, and was hoping somebody on the fedora DVD build team could do that? Version-Release number of selected component (if applicable): Fedora 15 How reproducible: Always - Use the repo= boot option. Steps to Reproduce: 1. boot via DVD 2. press [tab] to edit the boot options 3. specify boot options with repo= Actual results: Anaconda cannot find the files specified in /repodata/repomd.xml Expected results: Anaconda CAN find the files specified in /repodata/repomd.xml Additional info: I have examined Fedora going back as far as 14, 13, and 12. All of them have the issue specified in this alleged BUG. However, RHEL 6 update 1 is correct! When you extract the "rhel-server-6.1-x86_64-dvd.iso" DVD you will see the /repodata is setup correctly. Somebody inside Red Hat did the right thing, but for some reason the Fedora has been doing the wrong thing for years! Also I suspect Bugzilla: #703025 might be related to this problem.
Have been told that a tool named Pungi might be related to how the /repodata files are created. https://fedorahosted.org/pungi/wiki/ This is speculation, but it seems reasonable this bug might go one of two ways: 1. make Anaconda work with /repodata files that are missing the extension. * parse the repomd.xml, get the filename location, split the files on the hypen to exclude the part after the sha256sum. 2. Make the pungi build process do the right thing. Regardless, the files on the Fedora DVD are incorrect, and have been incorrect for some time. We may want to test this in future releases during the go/no-go process.
Perhaps something's wrong with you burn? I downloaded the F15 DVD and verified: clumens@exeter:/tmp$ ls /misc/repodata/ 2837838aa7c648a3b6cd5eb754dee7b1df7b98bc42c58532937d9e4f397db7e8-Fedora-15-comps.xml 482363d08cce65e9862eef4f8389ae96c7114841032f97053b09b67fce1535c3-filelists.sqlite.bz2 5f9682212cf1ec3e67f0b98392bcdbfa575512cdaa0084bb70bbbec6c73f71fa-primary.xml.gz 7f0baa056a7062d97e7a721b02cb4a8722e8e2b0dbc62e0ef390dbaa96f1c378-primary.sqlite.bz2 TRANS.TBL a1e30d38bf8041a48d0a23ade3cdfe38e9c5b9873547d20e35d40466b27da0ca-filelists.xml.gz b12d93a30a89628e723469152807ac614d4bd93aacb1d7f4fdc04a6b373dedbb-other.sqlite.bz2 e67f6e07e869158b8ae94de833adf43fe14c4fdd90d8cf7c01fab221e9716684-Fedora-15-comps.xml.gz f40f58bd92219adf1a42e4b8914af33bf6c7e24ea419d5b8c812f9bbf451a944-other.xml.gz repomd.xml
Nevermind! I found out that the problem was caused by incorrect DVD extract. The software 7zip truncated the file names to 64 characters during the extract, and since sha256sum's are 64 chars, that is why the appended stuff beyond the checksum failed. This became apparent in the /Packages dir when some files are 64+ chars. So the root cause has been found out, and I take back everything I wrote in the bug report. Now, to add one lasting msg for anybody who might be reading this far. Regardless of the root-cause, I figure some hardness could be added to the DVD by moving the checksum's into a CHECKSUM file, and keeping file names as short as possible. It would allow busted extraction software to continue to work. ;-)