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.
Please attach /tmp/anaconda.log, /tmp/syslog, and /tmp/program.log.
Tested on bare metal system, and it appears to install without error on x86_64. I wonder if this is related to a known issue with disc swaps in libvirt?
Did you ensure the new iso gets 'reattached' correctly?
(In reply to comment #1) > Please attach /tmp/anaconda.log, /tmp/syslog, and /tmp/program.log. Not being highly familiar with virt-manager, how do i copy these files to the host system?
Sorry, I'm very tired right now and may not respond for a while. This should be 100% reproducible by anyone using virt-manager, though.
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?
Created attachment 438505 [details] anaconda.log
Created attachment 438506 [details] syslog
Created attachment 438507 [details] program.log
The above attachments are for RC3 i386. RC4 i386 does exactly the same thing when installing using virt-manager.
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.
Looking more carefully at your syslog, I also see a bunch of media read errors. Looks like you've either got a bad image or there's a problem with reading them at a lower level than anaconda.
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.
Just ran the mediacheck on all 6 i386 CD ISOs in the guest. According to that, discs 2, 4, and 5 are bad (despite the fact that all 6 ISOs have good checksums on the host).
Doing the same mediacheck inside a VirtualBox 3.2.8 guest, all 6 discs pass.
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.
Moving to qemu, this seems like a virt bug. Please readjust the Fedora version to match whatever your host is.
Host is F13 x86_64. Changing the Version to 13, leaving the Platform as "All Linux" for now.
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.
To continue to be a F14 Beta blocker, this should have a Version of at least F14. Unfortunately, I don't have any F14 or Rawhide hosts, so I can't check - someone else will have to do this.
Running a guest inside a guest (which is _very_ slow), I verified that the bug exists with a F14 "host".
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
This is being looked at, though is somewhat lower priority for the above reasons.
(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.
Actually, from my own records, it was the Fedora Unity 20090414 F10 PPC respin. The two discs were 4584099840 and 66877440 bytes. The corresponding i386 and x86_64 respins were non-split.
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
*** Bug 642951 has been marked as a duplicate of this bug. ***
F14 is no longer supported. If anyone is still affected by this bug with newer qemu versions (fedora 16 or 17), please reopen this report.