on a x86_64 f13 host, using virt-manager/qemu-kvm , trying to test out Fedora-14-Beta-i686-Live-KDE.iso or Fedora-14-Beta-x86_64-Live-KDE.iso , booting these seems to hang, but others (adamw and poelcat) report that it's just very very slow. On this same box, testing prior live images, like those for f12-kde-live and f13-kde-live boot and function as expected.
I was doing Fedora 14 guests on Fedora 12 x86_64 bare metal that were working great until sometime after the Fedora 14 alpha. Now I can't boot a live CD and get to the login window. Should this bug be moved to Fedora 14?
Moving to version "14" and blocking final release. Per release criteria: "The release must boot successfully as a virtual guest in a situation where the virtual host is running the previous stable Fedora release (using Fedora's current preferred virtualization technology)
Re: comment 1 I have to concur, this seems to have happened sometime after F14-alpha for me too (the -alpha isos booted a-ok for me).
Update: running the latest Fedora 12 packages on my system, I can no longer boot the Fedora 14 as a KVM guest. It gets to the end of the boot process and appears to hang the guest. After waiting 5 minutes at 100% CPU on the hypervisor I kill the guest.
(In reply to comment #4) > Update: running the latest Fedora 12 packages on my system, I can no longer > boot the Fedora 14 as a KVM guest. It gets to the end of the boot process and > appears to hang the guest. After waiting 5 minutes at 100% CPU on the > hypervisor I kill the guest. Clarification--I can no longer boot the Fedora 14 ALPHA
John, your case is not covered under the criteria: "the previous stable Fedora release" means *one* release prior, not any prior supported release, so we only cover F14-on-F13. I can confirm this bug for the KDE image but not any other case. The Beta KDE image boots extremely slowly (well, the boot process is mostly fine, it's KDE initialization that takes forever) in qemu/kvm/virt-manager on an F14 host. KDE then performs equally sluggishly once it's finally done booting. The other three Beta images boot and perform just fine. I suspect this has something to do with KDE desktop rendering but I'm really not sure what.
As far as blocker status goes, we agreed we need more information and will review next week. We will try and test this with the 'vesa' driver, with ajax's fix for the use of vesa in KVMs.
Update: I updated my machine to Fedora 13 and the Fedora 14 virt guest experience is much improved with the Gnome LiveCD. I consider this NOTABUG now. This is no longer a blocker bug from my perspective.
Re-reviewing bug comments below it would appear the remaining issue here is KDE specific. Are KDE-only bugs considered final release blockers (I don't see anything in the release criteria)? If not, we should remove blocker status for this bug.
I have not been able to reproduce outside of the KDE disk Image I was given last week. I will look for a newer image and see if I can reproduce there, but standard F14 images are okay. One thought, is KDE forcing graphics capability that is pushing softgl since the hardware doesnt exist? If so, that is going to be insanely slow to virtualize.
"Are KDE-only bugs considered final release blockers (I don't see anything in the release criteria)? If not, we should remove blocker status for this bug." By precedent, yes. For many releases there's been a KDE Blocker bug which has blocked F14Blocker and we haven't challenged this in the blocker review process. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
adjusting summary and moving it to the KDE blocker. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
adding KDE folks to CC. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
Compositing and the desktop effects which require it are disabled by default in Fedora, I don't think KDE is attempting to use it at all. (And FWIW, even in upstream's default setup, compositing is only enabled by default on known-good graphics chipsets.)
(In reply to comment #14) > Compositing and the desktop effects which require it are disabled by default in > Fedora, I don't think KDE is attempting to use it at all. (And FWIW, even in > upstream's default setup, compositing is only enabled by default on known-good > graphics chipsets.) Thanks for the feedback. If I understand correctly, since this is not a default configuration, we shouldn't consider this a KDE release blocker for F14-Final? If so, is any additional confirmation needed from the KDE-SIG before we remove this from the list?
> If I understand correctly, since this is not a default configuration, we > shouldn't consider this a KDE release blocker for F14-Final? Unfortunately, you misunderstood. The problem shows up with the default configuration. In comment #10, it was suggested as a possible cause that KDE might be requiring OpenGL and getting some slow software emulation, but this cannot be the issue in the default configuration. So we still haven't found the cause of the slowness.
(In reply to comment #16) > > If I understand correctly, since this is not a default configuration, we > > shouldn't consider this a KDE release blocker for F14-Final? > > Unfortunately, you misunderstood. > > The problem shows up with the default configuration. In comment #10, it was > suggested as a possible cause that KDE might be requiring OpenGL and getting > some slow software emulation, but this cannot be the issue in the default > configuration. So we still haven't found the cause of the slowness. Thanks for the correction. We'll continue to monitor this issue for root cause. I don't think I need to reiterate the urgency of resolving this issue. If there are additional people or data needed to help move this forward, please don't hesitate to locate/request it.
It's not really clear to me what the status of this is... Is anyone actively trying to track down the issue? Have we made a determination on whether or not this bug should block the release? We're getting close to the wire here, and I want to make sure this bug gets the attention it deserves.
"Have we made a determination on whether or not this bug should block the release?" No. It's easy to tell this. If we did, it would either have the 'AcceptedBlocker' whiteboard field, or it would have the 'RejectedBlocker' whiteboard field and not be blocking a release-blocking bug any more. The fact that it is blocking a release-blocker bug but has no related whiteboard field means a final review of its blocker status has not yet been made. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
Tested a few fresh f14 images in kvm/qemu here on my f13 box, not much good to report, unfortunately. f14.tc1.1 live kde i686 : see grub , immediately after booting, see white screen where normally boot process/plymouth appears (seems to be some other unrelated plymouth-related problem?) f14.rc1.1 live kde x86_64 : gets further than i686, then exhibits similar as this bug, last thing I see is: Serial: 8250/16550 driver, 4 ports, IRQ sharing enabled though qemu isn't pegging the cpu on the host at this point. kde-i386-20101013.16.iso : white screen, same as f14.tc1.1 live kde i686 kde-x86_64-20101013.16.iso : white screen, same as f14.tc1.1 live kde i686
burned kde-i386-20101013.16.iso to cd, boots fine bare-metal. :(
This is odd because I am seeing great performance with kde-x86_64-20101012.15.iso in kvm. I am wondering, if you update to virt-preview packages for virt, does this fix things for you? Might be something in older qemu that doesnt exist in F14 hosts.
I've just tested Fedora-14-x86_64-Live-KDE.iso (TC1.1) and kde-x86_64-20101013.16.iso (both times I gave the guests 512MB ram) and they boot and work, at least for a few minutes. For reference the last nightly I tried before was kde-x86_64-20100928.17.iso which goes to a white screen while logging in but does boot to run level 3. Note: It looks like kde-x86_64-20101013.16.iso is actually built with i686 packages for some reason (the logs show that the preceding nightly was normal in this regard).
That may also be a difference, I give my guests considerably more memory than 512M, typically 2G, and never less than 1G. Do we have memory contention issues? Still doing a bit more testing, but this doesn't seem to be an issue with F14 qemu at least, so I am not sure that I would consider it a blocker. Seems odd to hold a release pending an update to a package in an older release unless it impacts upgrade.
Using f13 + virt-preview repo + reboot later, kde-i386-20101013.16.iso = works(*) kde-x86_64-20101013.16.iso = works(*) f14.tc1.1 live kde i686 = works(*) f14.tc1.1 live kde x86_64 = works(*), though I can confirm this isn't really x86_64 per comment #23 so looks like things are testable with qemu-kvm again, and resolved to my own satisfaction. (*) modulo the usual cirrus driver bug that makes the desktop look orange instead of blue, but that's not qemu's problem.
yeah, I tested a TC1 KDE live image boot on a similarly up-to-date F14 host and it works okay, though it does seem to slow down over time (I don't give my VMs much memory, though, which could explain it). -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
Desktop live Fedora-14-i686-Live-Desktop.iso is out today and taking over 10 minutes to boot on AMD Phenom(tm) 9600 Quad-Core Processor 4GB RAM, which ought to be fine. Tried various options, including qemu-kvm -hda fedo.qcow2 -cdrom Fed* -m 1024&
Uh, that's the GNOME image, the report is about the KDE one.
Oh wait, you're saying now the GNOME one is being slow… Maybe the same issue…
I don't think so. I had this issue with some KDE live images but never with the GNOME desktop, and both final KDE and final GNOME boot fine for me. I think it's something different, Henry, please file a new report. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
Works now, with the recent glib update. Carry on!