This service will be undergoing maintenance at 03:30 UTC, 2016-05-27. It is expected to last about 2 hours
Bug 623126 - mediacheck and install fail in KVM guest when swapping in a disc bigger than the one originally booted from
mediacheck and install fail in KVM guest when swapping in a disc bigger than ...
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: qemu (Show other bugs)
14
All Linux
low Severity medium
: ---
: ---
Assigned To: Fedora Virtualization Maintainers
Fedora Extras Quality Assurance
RejectedBlocker
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2010-08-11 08:06 EDT by Andre Robatino
Modified: 2013-01-10 01:08 EST (History)
26 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2012-05-21 07:41:47 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
anaconda.log (10.41 KB, text/plain)
2010-08-12 14:57 EDT, Andre Robatino
no flags Details
syslog (49.18 KB, text/plain)
2010-08-12 14:57 EDT, Andre Robatino
no flags Details
program.log (19.86 KB, text/plain)
2010-08-12 14:58 EDT, Andre Robatino
no flags Details

  None (edit)
Description Andre Robatino 2010-08-11 08:06:33 EDT
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.
Comment 1 Chris Lumens 2010-08-11 10:54:12 EDT
Please attach /tmp/anaconda.log, /tmp/syslog, and /tmp/program.log.
Comment 2 James Laska 2010-08-11 11:43:38 EDT
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?
Comment 3 Bill Nottingham 2010-08-11 11:59:52 EDT
Did you ensure the new iso gets 'reattached' correctly?
Comment 4 Andre Robatino 2010-08-11 12:32:10 EDT
(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?
Comment 5 Andre Robatino 2010-08-11 12:37:44 EDT
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.
Comment 6 Andre Robatino 2010-08-11 21:40:46 EDT
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?
Comment 7 Andre Robatino 2010-08-12 14:57:14 EDT
Created attachment 438505 [details]
anaconda.log
Comment 8 Andre Robatino 2010-08-12 14:57:53 EDT
Created attachment 438506 [details]
syslog
Comment 9 Andre Robatino 2010-08-12 14:58:21 EDT
Created attachment 438507 [details]
program.log
Comment 10 Andre Robatino 2010-08-13 02:15:02 EDT
The above attachments are for RC3 i386.  RC4 i386 does exactly the same thing when installing using virt-manager.
Comment 11 Chris Lumens 2010-08-16 11:48:36 EDT
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).
Comment 12 Andre Robatino 2010-08-16 12:29:03 EDT
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.
Comment 13 Andre Robatino 2010-08-16 12:34:58 EDT
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.
Comment 14 Chris Lumens 2010-08-16 13:25:23 EDT
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.
Comment 15 Andre Robatino 2010-08-16 13:31:00 EDT
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.
Comment 16 Andre Robatino 2010-08-16 13:39:50 EDT
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.
Comment 17 Andre Robatino 2010-08-16 14:20:48 EDT
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).
Comment 18 Andre Robatino 2010-08-16 14:36:32 EDT
Doing the same mediacheck inside a VirtualBox 3.2.8 guest, all 6 discs pass.
Comment 19 Chuck Ebbert 2010-08-17 07:08:17 EDT
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.)
Comment 20 Andre Robatino 2010-08-17 07:25:23 EDT
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.
Comment 21 Andre Robatino 2010-08-17 07:54:18 EDT
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
Comment 22 Andre Robatino 2010-08-17 09:04:28 EDT
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.
Comment 23 Bill Nottingham 2010-08-17 10:20:04 EDT
Moving to qemu, this seems like a virt bug. Please readjust the Fedora version to match whatever your host is.
Comment 24 Andre Robatino 2010-08-17 10:24:24 EDT
Host is F13 x86_64.  Changing the Version to 13, leaving the Platform as "All Linux" for now.
Comment 25 Andre Robatino 2010-08-18 04:58:13 EDT
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.
Comment 26 Andre Robatino 2010-08-23 13:07:51 EDT
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.
Comment 27 Andre Robatino 2010-08-25 03:23:01 EDT
Running a guest inside a guest (which is _very_ slow), I verified that the bug exists with a F14 "host".
Comment 28 Adam Williamson 2010-08-27 12:42:13 EDT
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
Comment 29 Justin M. Forbes 2010-09-02 12:26:03 EDT
This is being looked at, though is somewhat lower priority for the above reasons.
Comment 30 Andre Robatino 2010-09-28 07:36:57 EDT
(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.)
Comment 31 Andre Robatino 2010-09-28 07:57:26 EDT
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.
Comment 32 Andre Robatino 2010-09-28 08:06:29 EDT
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.
Comment 33 Adam Williamson 2010-09-28 11:29:09 EDT
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
Comment 34 Bill Nottingham 2010-10-15 10:38:12 EDT
*** Bug 642951 has been marked as a duplicate of this bug. ***
Comment 35 Cole Robinson 2012-05-21 07:41:47 EDT
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.

Note You need to log in before you can comment on or make changes to this bug.