Description of problem:
When attempting the test
https://fedoraproject.org/wiki/QA/TestCases/InstallSourceCdrom
there is a fatal error immediately after swapping in CD 2. In i386, the error is
The file xdg-user-dirs-gtk-0.8-5.fc13.i686.rpm cannot be opened. This is due to a missing file, a corrupt package or corrupt media. Please verify your installation source.
If you exit, your system will be left in an inconsistent state that will likely require reinstallation.
In x86_64, the error is
The file xsane-gimp-0.997-10.fc14.x86_64.rpm cannot be opened. This is due to a missing file, a corrupt package or corrupt media. Please verify your installation source.
If you exit, your system will be left in an inconsistent state that will likely require reinstallation.
Testing using virt-manager attached to ISO files, which have verified checksums.

I tried forcing the system off, then booting in rescue mode, but the files in /tmp (which were there before powering off) are no longer there. Since the problem is 100% reproducible, I can just do the install again, but how would I copy these files to the host system?

Yeah, this could definitely be the reattaching problem once again.
Andre - when you hit this, can you please verify (1) that there's something mounted on /mnt/source? anaconda definitely tried to mount something there, but I guess it could have failed without reporting somehow. (2) does whichever package it's reporting in the error dialog exist in /mnt/source/Packages? I'm trying to determine whether what's mounted really is the second disc or still the first (or the first again).

Tested again on RC4 i386. When the error happens, something is in fact mounted on /mnt/source/, and xdg-user-dirs-gtk-0.8-5.fc13.i686.rpm (the package in the error message) is located in /mnt/source/Packages. Loop mounting the CD #2 ISO on the host and comparing contents shows that this is in fact the same ISO mounted on the guest.

In VT2 in the guest, going into /mnt/source/Packages/ and running
rpm -Kv xdg-user-dirs-gtk-0.8-5.fc13.i686.rpm
it says
error: not an rpm package
but if I try the same thing on several other RPM files in the same directory, I get normal output. Running
md5sum xdg-user-dirs-gtk-0.8-5.fc13.i686.rpm
I get
md5sum: xdg-user-dirs-gtk-0.8-5.fc13.i686.rpm: Input/output error
but trying it on several other files in the same directory gives normal output.

There's nothing wrong with the media. I've verified the checksums on the ISO files multiple times, and did it again just now. This is 100% reproducible, so if you download CDs 1 and 2 (either i386 or x86_64), you should see exactly the same thing.

Also, if I loop mount CD #2 on the host, I have no trouble accessing the contents of xdg-user-dirs-gtk-0.8-5.fc13.i686.rpm (both rpm -Kv and md5sum work fine). The only access problems are in the guest.

Can you go to the console while disc 1 is mounted and look at
/sys/block/sr0/size
then see if the size changes after the second disk gets mounted? (You can mount them on the host to see what the correct sizes are.)

I suspect that this is not the correct device name for an attached ISO file - can you confirm that it is? I am not using physical media at all. When loop mounting either disc1 or disc2 on the host, or even if nothing is loop mounted, I always get 8925568. Currently, on the guest, while disc1 is mounted, I get 1402440. I'll check again when the first disc is finished whether it changes at all when the second disc is mounted, or if nothing is mounted.

When the second disc is mounted in the guest, the size is still 1402440. The value of /sys/block/sr0/size doesn't seem to have anything to do with what's mounted in the guest, or loop mounted on the host.
Googling for "/sys/block/sr0/size", I see what you're getting at - the sizes of the i386 CD ISOs are
disc1: 718049280
disc2: 728748032
disc3: 647405568
disc4: 725524480
disc5: 721870848
disc6: 77307904
and discs 2, 4, and 5 are bigger than disc 1. Doing the guest mediacheck using the x86_64 discs, after booting from the x86_64 disc 1, it says that discs 2, 3, and 4 are bad, which is as expected given that the x86_64 CD ISO sizes are
disc1: 720662528
disc2: 727154688
disc3: 725409792
disc4: 725485568
disc5: 650772480

I have all 15 install discs (8 for i386 and 7 for x86_64) and 6 of these are bootable (disc1, DVD and netinst for both arches). Checking all 6*15=90 combinations, mediacheck fails in every case if and only if the disc being checked is bigger than the one booted from.

The behavior is different on the command line. Running
qemu-kvm -m 1G -cdrom /tmp/F14-Alpha.RC4/i386/Fedora-14-Alpha-i386-disc1.iso
on the same host, and swapping ISOs using QEMU Monitor during mediacheck, the only one of the i386 ISOs which fails is the DVD image. Checked the ISO file checksums again to make sure they were actually all good.
BTW, there is a typo in virt-manager - in Step 2 of 5 of "Create a new virtual machine", it says "Choose an operating systen type and version". Should replace systen -> system.

Discussed at the blocker review meeting today. Since this affects only a case with no real use - using the split media inside a KVM, which no-one would ever really want to do in practice - and the split media apparently work fine on real discs on bare metal, we agreed this wasn't a blocker. It could potentially be considered one under '# Bug hinders execution of required Beta test plans or dramatically reduces test coverage', but we agreed that the impact to the test plans isn't sufficient to render the bug a blocker - it's not that hard to test this on bare metal instead of in a KVM.
--
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers

(In reply to comment #28)
> Discussed at the blocker review meeting today. Since this affects only a case
> with no real use - using the split media inside a KVM, which no-one would ever
> really want to do in practice - and the split media apparently work fine on
> real discs on bare metal, we agreed this wasn't a blocker. It could potentially
> be considered one under '# Bug hinders execution of required Beta test plans
> or dramatically reduces test coverage', but we agreed that the impact to the
> test plans isn't sufficient to render the bug a blocker - it's not that hard to
> test this on bare metal instead of in a KVM.
I've wondered if there's any policy that non-split media will always be made available. I realize it's not an issue for at least a few more releases - until the DVD splits - but it hasn't always been true for Fedora. FC1 was only available as split CDs - the DVD didn't appear until FC2. CentOS 5.5 x86_64 currently has no non-split media that I'm aware of - there's just CDs and a 2-DVD set. (The 2nd DVD is very small which is the excuse for not providing a single large image.)

Also, the Fedora Unity DVD has split in the past. I think it was PPC, probably a F10 respin. Unfortunately, they don't believe in keeping archives (or even old checksum files), so there's no way to check.

It's implied in our release criteria that DVD media at least will always be available. The question of split DVDs is an interesting one but it won't be the case for F14 and is unlikely to occur any time soon, there's a spare 1GB or so on the DVD image at present. If any of these theoretical cases were to occur for a future release and this bug were still present we could of course re-consider it as a blocker, but it doesn't appear to be an issue for F14.
--
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers