Bug 810040
| Summary: | F17/F18 xen/kvm/vmware/hyperv guest with no USB: gnome-shell fails to start if fprintd is present | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Michael Young <m.a.young> | ||||||||
| Component: | fprintd | Assignee: | Bastien Nocera <bnocera> | ||||||||
| Status: | CLOSED ERRATA | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||||||
| Severity: | unspecified | Docs Contact: | |||||||||
| Priority: | urgent | ||||||||||
| Version: | 17 | CC: | amit.shah, awilliam, bnocera, brilong, crobinso, dcharlespyle, jamie, johannbg, jreznik, jskladan, ketuzsezr, kparal, kwizart, martin.wilck, matt, maxamillion, mclasen, mfabian, mike_parlett, mikom3, nicoweb.contact, otaylor, pasik, robatino, rstrode, samkraju, samuel, satellitgo, stephent98, tflink, virt-maint, vvm, walters, yogu007 | ||||||||
| Target Milestone: | --- | ||||||||||
| Target Release: | --- | ||||||||||
| Hardware: | Unspecified | ||||||||||
| OS: | Unspecified | ||||||||||
| Whiteboard: | RejectedBlocker AcceptedNTH | ||||||||||
| Fixed In Version: | fprintd-0.4.1-3.fc17 | Doc Type: | Bug Fix | ||||||||
| Doc Text: | Story Points: | --- | |||||||||
| Clone Of: | Environment: | ||||||||||
| Last Closed: | 2013-01-10 22:28:37 UTC | Type: | Bug | ||||||||
| Regression: | --- | Mount Type: | --- | ||||||||
| Documentation: | --- | CRM: | |||||||||
| Verified Versions: | Category: | --- | |||||||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||||||
| Embargoed: | |||||||||||
| Bug Depends On: | |||||||||||
| Bug Blocks: | 752665 | ||||||||||
| Attachments: |
|
||||||||||
http://git.gnome.org/browse/gnome-shell/commit/?id=e333263fd646cee7b235e181db7dd96a6bf0735e Is the upstream commit with the workaround in gnome-shell I am hitting this with the F17 TC4 as well. (In reply to comment #1) > http://git.gnome.org/browse/gnome-shell/commit/ > ?id=e333263fd646cee7b235e181db7dd96a6bf0735e > > Is the upstream commit with the workaround in gnome-shell Yup. That fixes it. Can this patch be added in gnome-shell? I just hit this with a fresh install of the F17 release under kvm. At the very least it would be good to give this issue a keyword of CommonBugs so folks don't waste a lot of time trying to figure out why the very first thing they see on a fresh install is that abysmal "Oh no! Something has gone wrong." screen. Had same problem with vmware esx 4.0 Removing fprintd does solve the issue Fix needs to be in updates Same issue with Hyper-V. Removing fprintd also solved the issue. Owen, can the fix be put in gnome-shell for f17 so that people can update it at least after install? I can confirm this bug still exists in release version on VMWare ESXi 4.1 and the above workaround solves the issue. Since most of these hypervisors don't let you press Ctrl+Alt+F2 to see what's happened it is quite cumbersome. What a pain in the butt. I just experienced this on ESXi 5 with a fresh install of F17. :-( Why hasn't anyone picked up this bug and moved it to assigned instead of new? brian: Fedora doesn't always follow a really strict bug management process, you can't really infer much from a state of NEW as opposed to ASSIGNED. it's very much left up to the individual maintainer. it may be the case this is actually fixed in the current state of F17 gnome-shell, though I don't know either way; but even if it were, fresh installs from static media would still be affected. Note http://git.gnome.org/browse/gnome-shell/commit/?id=e333263fd646cee7b235e181db7dd96a6bf0735e was wrong, so would need http://git.gnome.org/browse/gnome-shell/commit/?id=638507caff2660891f768f583532f35eb55de0bf layered on top. gnome-shell-3.4.1-6.fc17 has been submitted as an update for Fedora 17. https://admin.fedoraproject.org/updates/gnome-shell-3.4.1-6.fc17 Package gnome-shell-3.4.1-6.fc17: * should fix your issue, * was pushed to the Fedora 17 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing gnome-shell-3.4.1-6.fc17' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2012-14307/gnome-shell-3.4.1-6.fc17 then log in and leave karma (feedback). Is it possible that this bug still exists on Fedora-18-Beta-TC1-x86_64-netinst.iso? When installing that in qemu-kvm, I still see the same problem and rpm -e fprintd-0.4.1-3.fc18.x86_64 fprintd-pam-0.4.1-3.fc18.x86_64 still helps. Gnome shell version on Fedora-18-Beta-TC1-x86_64-netinst.iso is: gnome-shell-3.6.0-1.fc18.x86_64 Same problem when using the Fedora-18-Nightly-20121003.08-x86_64-Live-desktop.iso image. First thing I see when booting this is the frowney screen. And then I can workaround this by switching to a virtual console and log in a root and then rpm -e fprintd fprintd-pam init 3 init 5 and then I can proceed. Mike: my guess would be that your VM has no USB bus, in which case you are seeing https://bugzilla.redhat.com/show_bug.cgi?id=828166 . Adam: 828166 a duplicate of this bug. This issue (810040) has always been that there is rarely a USB bus emulated in most virtual environments, and fprintd requiring one to work at all is a problem. thanks, jamie - ray, does that match with your reading? If I pass "-device piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2" to qemu then I can get F18 Live to boot to gdm without a frown. Perhaps it would be nice if qemu enabled usb by default? (In reply to comment #20) > If I pass "-device piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2" to > qemu then I can get F18 Live to boot to gdm without a frown. The above was copied from virt-manager's invocation of qemu-kvm but as already mentioned in bug 828166, the -usb option is sufficient. The F17 update was pushed stable at the beginning of this month - should this bug be closed, or moved elsewhere? (In reply to comment #20) > Perhaps it would be nice if qemu enabled usb by default? Thank you for finding this option, finally I don’t have to work around this anymore when installing in qemu. The qemu manpage seems to say that -usb will become the default: USB options: -usb Enable the USB driver (will be the default soon) did anyone verify that the update actually fixes the bug? I don't have an F17 VM to test, but a fully updated F18 alpha VM still has the bug. gnome-shell-3.4.1-6.fc17 does not fix the problem, after updating I re-installed fprintd on my vm, and it results in the abysmally lame "something has gone wrong" screen of shame. Removing fprintd results in being able to log in again. can you attach /var/log/gdm/:0-greeter.log ? *** Bug 828166 has been marked as a duplicate of this bug. *** Created attachment 633460 [details]
fprintd preventing login w/gnome-shell-3.4.1-6.fc17.x86_64
Just tested Fedora 18 TC6 on Windows 8 RTM (x86_64) Hyper-V and it still displays the same error while trying to boot the Live DVD (GNOME 3). (In reply to comment #20) > If I pass "-device piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2" to > qemu then I can get F18 Live to boot to gdm without a frown. > > Perhaps it would be nice if qemu enabled usb by default? The real solution would be for fprintd to not crash if it cannot find an USB device. Updating bug to also mention F18. Hi i had the same problem with gdm using virtualbox-4.1.22 and fedora 17. i started the vm in advanced/recovery mode and type the command su -c 'yum update --enablerepo=updates-testing gnome-shell-3.4.1-6.fc17' but it didnt change nothing then i continued to read this page and found that the bug came from the usb controller which wasnt activated on my vm config. in virtualbox i needed to type this command on the host to make the fedora 17 start :) VBoxManage modify vm my_vm_name usb on i didnt test on fedora 18 versions Proposing this as an beta blocker bug under the following alpha criteria "Following on from the previous criterion, after firstboot is completed and on subsequent boots, a system installed according to any of the above criteria (or the appropriate Beta or Final criteria, when applying this criterion to those releases) must boot to a working graphical environment without unintended user intervention. This includes correctly accessing any encrypted partitions when the correct passphrase is supplied" Since this affects from the looks of it running Fedora as an host on all virtualzation technologies hyperv/kvm/vbox/vmware/xen, including kvm/xen which probably is what "Fedora's current preferred virtualization technology" is supposed to cover... Created attachment 643647 [details]
fprintd: request name unconditionally at startup
the dbus activation machinery depends on daemons taking a name on
the bus to complete activation without timeouts.
fprintd fails prematurely if there is USB bus (as found in some
virtual machine setups).
This commit moves the bus-name-acquisition code to happen before
the fail-from-no-usb-bus code to keep callers from timing out
when activating fprintd.
Discussed at 2012-11-12 QA meeting acting as a blocker review meeting. Rejected as a blocker and NTH: " This only affects graphical installs in VMs without a USB bus. It seems uncommon enough to not warrant blocker or NTH status for F18 beta. Please re-propose as final NTH/blocker for reconsideration if this is not fixed otherwise by then." moving to fprintd, because I think the remaining issue is there. *** Bug 875537 has been marked as a duplicate of this bug. *** Created attachment 643659 [details]
updated patch
The previous patch didn't have some squashed fixes in it.
Confirmed this In VMworkstation running on Ubuntu : build custom VM with usb removed. Install Fedora-18-Beta-TC8-i386-netinst.iso with gnome default reboot/ Firstboot login "Oh NO" whale fail shutdown VM Add USB 2 to VM start /login /gnome3 starts (the patch has been committed upstream now) clearing 'blocks: F18Beta' (should have been done as part of secretaryization) After login to Gnome via VNC session I get this Alert backtrace_rating: 4 Package: gnome-shell-3.6.2-3.fc18 OS Release: Fedora release 18 (Spherical Cow) Logged in; found this error. backtrace_rating: 4 Package: gnome-shell-3.6.2-5.fc18 OS Release: Fedora release 18 (Spherical Cow) I've tested the upstream patch, and it worksforme on F18. Here's my steps: 1) Install F18 beta guest (w/ kvm + virt-manager), verify I can log into gnome shell, shutdown VM 2) Edit VM XML to disable USB: * virsh edit <vmname> * remove <input type='tablet' bus='usb'/> * change <controller type='usb' index='0'> to <controller type='usb' index='0' model='none'> * save and exit 3) start VM, verify you see the gnome shell fail screen 4) build local F18 fprintd rpm adding this patch: http://cgit.freedesktop.org/libfprint/fprintd/patch/?id=9577b6db03115c78f90bb644348ef765f00d95d9 5) yum update *.rpm 6) telinit 3; telinit 5; No gnome-shell error 7) Reboot VM and verify no gnome-shell error Now for KVM guests via libvirt, disabling USB is not something most people will do. However xen and other virt platforms don't seem to add a USB bus by default so this bug makes fedora and gnome look pretty bad. halfline, hadess, can someone spin up F17 and F18 updates? (In reply to comment #43) > * change <controller type='usb' index='0'> to <controller type='usb' > index='0' model='none'> Correction, you need to drop the entire <controller type='usb'... block and replace it with <controller type='usb' index='0' model='none'/> Somehow, I got this error and I am not running Fedora in a VM or even using KVM, xen or qemu at all. I have VirtualBox installed but am not using it at present. I'm seeing it in a fully updated F18 Beta as well, no VMs involved. you may have a real system with no USB bus, I guess. Such things are rare, but exist. No, I certainly have a USB bus. Whatever the cause, I can't log into the system until the fprint* programs are removed. Scratch build implementing #c43 http://koji.fedoraproject.org/koji/taskinfo?taskID=4850159 yum localinstall --nogpgcheck http://kojipkgs.fedoraproject.org//work/tasks/160/4850160/fprintd-0.4.1-4.fc18.x86_64.rpm http://kojipkgs.fedoraproject.org//work/tasks/160/4850160/fprintd-pam-0.4.1-4.fc18.x86_64.rpm Tested with Success on Hyper-V Server 2012 x86_64 (Fedora-18 x86_64 Guest) I was able to login with gnome3. Why this was not added into the repo more early? This bug should have been considered as a blocker IMHO. (or NTH at least). This affect the ability to have a usable system at the end of a graphical install in order to later make updates. fprintd-0.4.1-4.fc18 has been submitted as an update for Fedora 18. https://admin.fedoraproject.org/updates/fprintd-0.4.1-4.fc18 fprintd-0.4.1-3.fc17 has been submitted as an update for Fedora 17. https://admin.fedoraproject.org/updates/fprintd-0.4.1-3.fc17 Re proposing as final blocker/nth. This cant be fixed afterwards for an live spin so let's not release and deliver bad user experience for people that want to try and run Fedora in the hyporvisor of their choosing. It would be good to get developers feed back on how invasive they think pulling this fix would be into final. I'm -1 blocker/CommonBugs on this one for final. It's a long time problem (and sad it takes a long time to get possible fix), not a regression and the use case is quite uncommon (no USB for graphical hypervisor used on live cd). Well for example Xen PV domUs don't have USB as a default. Many people hit this issue when installing Fedora 17/18 domUs using pvfb. (In reply to comment #53) > I'm -1 blocker/CommonBugs on this one for final. It's a long time problem > (and sad it takes a long time to get possible fix), not a regression and the > use case is quite uncommon (no USB for graphical hypervisor used on live cd). This is a regression and affects all hyporvisor running Fedora VM's and cant be fixed via update ( for live spins ) (In reply to comment #53) > I'm -1 blocker/CommonBugs on this one for final. > the use case is quite uncommon >(no USB for graphical hypervisor used on live cd). is 100% common for _all_ users of MS Hyper-V -1 blocker, this seems to be enough of a corner case to not warrant a release blocker. Online installations won't be affected, if we push the update to stable updates, just offline installations. yum update will solve it then. It's unfortunate, but it seems to affect just a very limited audience and can be documented and worked around easily. Could any one that is CC and affected by this bug vote either +1 to blocker or +1 to nth since RH QA team seems not be able to comprehend how wide spread the problem is or in a rush pushing out F18 instead of delivering something usable in the hands of our end user base. Kamil Páral this is not some corner case like you are trying to state here. This fixes the number one problem users have had with running Fedora in VM including our own as is stated in comment 54 and thus violates these beta criteria. "The release must be able host virtual guest instances of the same release, using Fedora's current preferred virtualization technology The release must install and 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" The fix is here let's pull and put on the release spins +1 blocker Yeah, this has going on for way too long. +1 blocker. +1 blocker ^^^^^^^^^^^ if for solve problem not solved since 2012-04-04(!) need write this magic phrase -- Ok, Done +1 blocker - F18 does not work on Hyper-V and from what I can tell from other comments, it has issues on Vmware and Xen too. It would not consider that a corner case. +1. I don't see how this cannot be a blocker since it affects so many installs. This has been affecting me for over 6 months on Fedora graphical installs under VMware. Now you're telling me F18 won't fix it either? Come on guys. Respin F18 with this update please. if it was that fucking important why didn't someone fucking propose it at ANY TIME IN THE LAST SIX MONTHS? -1 blocker (as I'm absolutely with jreznik on this) Wasn't it proposed as a blocker by Jóhann B. Guðmundsson on 2012-11-11 ? No need to pull a Linus Torvalds here. (In reply to comment #66) > Wasn't it proposed as a blocker by Jóhann B. Guðmundsson on 2012-11-11 ? No > need to pull a Linus Torvalds here. As Beta blocker, not Final (see comment 34). it was proposed as a beta blocker and duly rejected. it could have been proposed as a final blocker at any time before or since then. seriously. guys. there have been stories in the media for three months about F18 being delayed. we have spun seven candidate builds for F18 final, with no-one at any point taking the trouble to fill out the one freaking Xen test case (though Konrad assured me when we added the Xen criterion that there was a community of users just champing at the bit to help out). QA, devel, anaconda team and release engineering have all been working our asses off to knock off the giant list of blocker bugs and get a releaseable build, we _finally_ get a build which apparently addresses all the blockers, and 4.5 hours before the go/no-go meeting is when you decide to starting making a fucking fuss about this and saying 'oh just respin it, that's no big deal rite'? That's _bullshit_ of the highest order. -1 blocker for similar reasons as jreznik. This bug doesn't have enough impact to justify taking as a blocker this late and accepting all the consequences that come along with that. If it had been proposed a month ago, this wouldn't be so much of an issue but I really can't justify slipping F18 again on account of just this bug. Granted, this is a small change but we're pretty much out of time before deciding to slip or not and there's no guarantee that the fprintd update won't cause issues - if it does cause issues, there is a very good chance that F18's release will slip again. This is not a regression, there are workarounds available (use USB, don't use livecd) and with the exception of the livecd case, this could be reasonably fixed with an update. Just FYI - blocker review is not about popularity contest but about what we are able to commit to fix it and the resources we have. Definitely it would be cool to fix all bugs ever in one release but in unlimited time with unlimited resources. Unfortunately we do not have such resources, team of very committed Fedora people is a small one (the same size team for the other OS vendor would write Fac*ebook app). Unfortunately respin is not only about including one package to the compose, but also a huge amount of work to verify the fix if it's not breaking something else (and you know that one bug fix leads to two regressions) and closer to release it means higher risk. And it's one thing that should be considered. This bug is not a regression (and again, I'm not happy we were not able to fix it earlier but again - see the resources part), it could be workarounded and preferred virtualization technology in our case is KVM. And we could use these free resources of Fedora QA, Jóhann is part of, to for example work on test automation to find out this sort of problems earlier. Just please consider these information before voting even I understand the bug fix is important for you. Thanks. -1 blocker here. +1 NTH if we need to respin for other reasons. I agree it's nasty, but there are workarounds and it doesn't directly hit any of our release critera, and it's way late in the day. (In reply to comment #68) > it was proposed as a beta blocker and duly rejected. it could have been > proposed as a final blocker at any time before or since then. Sure. Nobody did it thought. > > seriously. guys. there have been stories in the media for three months about > F18 being delayed. we have spun seven candidate builds for F18 final, with > no-one at any point taking the trouble to fill out the one freaking Xen test > case (though Konrad assured me when we added the Xen criterion that there > was a community of users just champing at the bit to help out). QA, devel, And I think the Virt day sometime in December showcases it, at which point it was put as Beta blocker and then was removed. Perhaps folks thought: "Oh well, they really don't care to fix this." and went on with the holiday shopping forgetting about the world of open-source. > anaconda team and release engineering have all been working our asses off to > knock off the giant list of blocker bugs and get a releaseable build, we > _finally_ get a build which apparently addresses all the blockers, and 4.5 > hours before the go/no-go meeting is when you decide to starting making a > fucking fuss about this and saying 'oh just respin it, that's no big deal > rite'? That's _bullshit_ of the highest order. This decision is up to you guys to figure out. It is a bit embarrassing in my mind that F17 and F18 do not work with various virtualization offerings (or even with KVM but with different configuration) b/c of a just one innocuous RPM out of the box. konrad: the note _in this bug_ about Beta blocker rejection explicitly states: "Please re-propose as final NTH/blocker for reconsideration if this is not fixed otherwise by then."" +1 NTH . I think it is too late to delay F18 just for this bug, but it should be fixed if there is a another respin. At least I'm blaming only myself. I was planning to test this already much earlier, but unfortunately didn't find the time :( Sorry for causing bad feelings with the +1 blocker stuff. I'll try to be more active earlier in the future! And thanks for all the hard work! It's appreciated. there will be a test build with the fprintd fix done available in around 1.5 hours from now. if people could be available to test it that would be useful. we are not committing to shipping it, just keeping our options open. I considered comments here and I vote for: -1 blocker/+1 NTH. (In reply to comment #76) > there will be a test build with the fprintd fix done available in around 1.5 > hours from now. if people could be available to test it that would be > useful. we are not committing to shipping it, just keeping our options open. > Thank you very much! I'll be able to test after 4 hours from now. (In reply to comment #78) > (In reply to comment #76) > > there will be a test build with the fprintd fix done available in around 1.5 > > hours from now. if people could be available to test it that would be > > useful. we are not committing to shipping it, just keeping our options open. > > > > Thank you very much! I'll be able to test after 4 hours from now. The Go/No-Go meeting starts in 1.5 hour but of course it could be prolonged if we will need it in case the blocker status will be granted as we would need not only to test if the fix actually makes the difference but mostly it does not break anything else + of course if the compose is ok as itself. (In reply to comment #79) > (In reply to comment #78) > > (In reply to comment #76) > > > there will be a test build with the fprintd fix done available in around 1.5 > > > hours from now. if people could be available to test it that would be > > > useful. we are not committing to shipping it, just keeping our options open. > > > > > > > Thank you very much! I'll be able to test after 4 hours from now. > > The Go/No-Go meeting starts in 1.5 hour but of course it could be prolonged > if we will need it in case the blocker status will be granted as we would > need not only to test if the fix actually makes the difference but mostly it > does not break anything else + of course if the compose is ok as itself. > In that case I'll postpone my 'offline time', so I'm able to test the build immediately when it is ready. Thanks. Some bureaucracy notes: Johann wrote "This fixes the number one problem users have had with running Fedora in VM including our own as is stated in comment 54 and thus violates these beta criteria. "The release must be able host virtual guest instances of the same release, using Fedora's current preferred virtualization technology" comment #54 refers to Xen. Xen is not our 'current preferred virtualization technology'; KVM is. The correct criteria under which this should be considered are: "The release must boot successfully as Xen DomU with releases providing a functional, supported Xen Dom0 and widely used cloud providers utilizing Xen. This does not include any issues limited to the release functioning as Xen Dom0" for the case of running as a Xen guest (it seems from the comments that Xen guests sometimes / always default to not having a USB controller), and/or: "Following on from the previous criterion, after firstboot is completed and on subsequent boots, a system installed according to any of the above criteria (or the appropriate Beta or Final criteria, when applying this criterion to those releases) must boot to a working graphical environment without unintended user intervention. This includes correctly accessing any encrypted partitions when the correct passphrase is supplied" For the couple of reported cases of this somehow affecting bare metal systems (comments #45 and #46). http://adamwill.fedorapeople.org/20130109-prerc3-x86_64.iso is an unofficial (built by me) live image with the fprintd update included, testing of that would be useful. The official RC4 build is still pending. sha256sum is c3188c7b73a02e71b9862852c85a2e9cc0f7055c5489499e6440592f41ac0063 . (In reply to comment #82) > http://adamwill.fedorapeople.org/20130109-prerc3-x86_64.iso is an unofficial > (built by me) live image with the fprintd update included, testing of that > would be useful. The official RC4 build is still pending. sha256sum is > c3188c7b73a02e71b9862852c85a2e9cc0f7055c5489499e6440592f41ac0063 . > Thanks! Downloading.. I'll let you know how the tests go. We can play the blame game why this was not re-proposed to the blocker bug list or why the maintainer had not pulled in the fix sooner etc. but the bottom line is without this fix this is what happens.. * If you take the "official" live spin fire it up in the hypervisor of your choosing, boot it BOOM FAIL WHALE ( And that will be the behaviour for the availability of that spins download time ) * If you do regular install and you boot it BOOM FAIL WHALE ( And that will be the behaviour for the availability of that spins download time ) * If you do an network install you boot it no fail whale once that fix has landed in stable All the above result in bad first impression from. bad review from reviewers etc. which have negative result on the project in whole. At the blocker bug meeting this could be accepted by conditions as in no other bug will be considered a blocker ( to prevent other blocker bugs piling in and or the temptation to pull in other fixes ) and if rc4 does not reveal any additional bugs we would ship it. We ( QA ) could only focus testing that might be affected by this change and release in time ( or with minimal delay ) if d. charles pyle and matt mossholder are reading this, it would be useful to know if the live image fixes their cases. like, *right now* it would be useful. tomorrow it might be irrelevant. Whoa this bug blew up :) Admittedly it didn't occur to me about the live media being permanently infected with this bug otherwise I'd have raised it as a blocker. But I'll defer to QA here: +1 NTH but not worth holding up the release on its own. (Can xen PV even do cdrom installs on linux? virt-manager doesn't think so) I disabled USB on my F18 KVM guest, reproduced the issue, pulled the fprintd build from koji and verified the fix. Downloading Adam's livecd now but it will take a while. (In reply to comment #83) > (In reply to comment #82) > > http://adamwill.fedorapeople.org/20130109-prerc3-x86_64.iso is an unofficial > > (built by me) live image with the fprintd update included, testing of that > > would be useful. The official RC4 build is still pending. sha256sum is > > c3188c7b73a02e71b9862852c85a2e9cc0f7055c5489499e6440592f41ac0063 . > > > > Thanks! Downloading.. I'll let you know how the tests go. > Replying here aswell.. so I can confirm "20130109-prerc3-x86_64.iso" fixed the fprintd bug! A summary of my tests: - F18-RC3 live-image has the fprintd bug. - 20130109-prerc3-x86_64.iso doesn't have the bug. - F18-RC4 live-image doesn't have the bug. Also F18-RC3 installed/worked OK on the following: - 32bit Xen PV domU installed using virt-install http install. - 64bit Xen PV domU installed using virt-install http install. - 64bit Xen HVM guest using the live-image. I'll test F18-RC4 aswell. I just finished testing F18-RC4: - 32bit F18-RC4 Xen PV domU installs and works OK using virt-install http install. - 64bit F18-RC4 Xen PV domU installs and works OK using virt-install http install. - 64bit F18-RC4-live Xen HVM guest works OK (booted from emulated CD-drive). I can confirm F18-RC4 fixes the fprintd bug. I get proper GDM login prompts on the F18-RC4 PV domU pvfb consoles after installation; F18-RC3 gave the sad face with "Oh no! Something went horribly wrong" text due to the fprintd bug. It would be good since we manage to squeeze it through to potentially release with this update if the reporters here could conduct the base install [1] and desktop install [2] ( with an emphasis on *dm )tests and write their results ( pass/fail ) on the relevant wiki page along with the hypervisor that was used Dont forget to give karma to the update Thanks 1.https://fedoraproject.org/wiki/Test_Results:Fedora_18_Final_RC4_Base 2.https://fedoraproject.org/wiki/Test_Results:Fedora_18_Final_RC4_Desktop 3.https://admin.fedoraproject.org/updates/fprintd-0.4.1-3.fc17 Discussed at the 2013-01-09 Fedora 18 go/no-go meeting [1]. While a nasty bug, it was judged too much of a corner case to block release of F18 so late in the release process (only a subset of xen VMs would hit this in certain install types) and was rejected as a release blocking bug for Fedora 18. However, a tested fix would be considered for F18 final after freeze. [1] http://meetbot.fedoraproject.org/fedora-meeting-2/2013-01-09/f18_final_gono-go_meeting.2013-01-09-19.00.txt Graphical logins on an f18 xen guest work again with https://admin.fedoraproject.org/updates/fprintd-0.4.1-4.fc18 . Karma given. Package fprintd-0.4.1-4.fc18: * should fix your issue, * was pushed to the Fedora 18 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing fprintd-0.4.1-4.fc18' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2013-0507/fprintd-0.4.1-4.fc18 then log in and leave karma (feedback). > 1.https://fedoraproject.org/wiki/Test_Results:Fedora_18_Final_RC4_Base Did those. Noticed a non-fprintd related issue where rngd service did not start. > 2.https://fedoraproject.org/wiki/Test_Results:Fedora_18_Final_RC4_Desktop Will do those later on today. "Noticed a non-fprintd related issue where rngd service did not start." - that one's known, it's pretty much what you'd expect on any system which doesn't actually have a hardware RNG (which is most). So I don't think it's really a problem. I can confirm this issue really affected VirtualBox, but only if you manually disabled the USB bus, which _enabled by default_ (even in the opensource version). So it concerned just a fraction of VirtualBox users. With RC4 the issue is fixed, LiveCD boots and GDM works even if you don't have an USB bus. I checked just i686 version, because x86_64 is unbearably slow for some weird reason. (In reply to comment #95) > I checked just i686 version, because x86_64 is unbearably > slow for some weird reason. So the solution is to use ICH9 chipset inside the VirtualBox VM and then x86_64 also works fast. Verified as well. (In reply to comment #87) > (In reply to comment #83) > (In reply to comment #82) >> >> http://adamwill.fedorapeople.org/20130109-prerc3-x86_64.iso is an unofficial >>(built by Adam Williamson ) live image with the fprintd update included >== >- 20130109-prerc3-x86_64.iso doesn't have the bug. >== I'm download this .iso and boot in LiveCD mode on Hyper-V Screeshoot of result You can see on http://social.technet.microsoft.com/Forums/en/linuxintegrationservices/thread/19d21642-dd11-4c30-bbb1-bf5982ee1c83 Or on http://vvm.blog.tut.by/2012/08/22/fedora-18-on-hyper-v/ IMHO, Fedora 18 behavior on Hyper-V look like normal P.S. About need or not need block Fedora 18 RTM : My current "magic phrase" = "in first impression, Bug 810040 look like fixed" P.P.S. To Adam Williamson: Thanks! Good job. (In reply to comment #97) >> (In reply to comment #87) >>> (In reply to comment #83) >>>> (In reply to comment #82) VVM> IMHO, Fedora 18 behavior on Hyper-V look like normal and for https://alt.fedoraproject.org/pub/alt/stage/18-RC4/Live/x86_64/Fedora-18-x86_64-Live-Desktop.iso Verified as fixed with 18-RC4 and qemu-kvm. I completed the following ad hoc test suite with qemu-kvm-1.0.1-2.fc17.x86_64: 1. Boot Live CD in VM, login, complete fresh, default install: qemu-kvm -m 2048 -hda f18-test-1.img -cdrom ~/xfr/fedora/F18/F18-Final/RC4/Fedora-18-x86_64-Live-Desktop.iso -vga qxl -boot menu=on #-usb -usbdevice mouse 2. Reboot to the newly installed system, complete firstboot, and login. 3. Reboot and login. 4. Create a new standard user, logout, login as new user. 5. Reboot, login as new user. A similar test was done using the DVD, with the exception that step 1 is modified to read: 1. Boot DVD in VM and complete fresh, default Gnome desktop install: qemu-kvm -m 2048 -hda f18-test-2.img -cdrom ~/xfr/fedora/F18/F18-Final/RC4/Fedora-18-x86_64-DVD.iso -vga qxl -boot menu=on #-usb -usbdevice mouse Results: All of the above succeed with 18-RC4 for x86_64. Notes: 1. I had been working around Bug 828166 by adding "-usb" to the qemu-kvm command line. The "-usb" option is commented out in step 1 to document this workaround. 2. With 18-RC3 Live, in step 1, login is not possible because the "Oh no! ..." message is displayed. 3. With 18-RC3 DVD, in step 2, after firstboot is completed, login is not possible because the "Oh no! ..." message is displayed. fprintd-0.4.1-4.fc18 has been pushed to the Fedora 18 stable repository. If problems still persist, please make note of it in this bug report. fprintd-0.4.1-3.fc17 has been pushed to the Fedora 17 stable repository. If problems still persist, please make note of it in this bug report. |
If I install an F17 xen guest (with graphical packages selected) and boot it afterwards I get the "an error has occurred" screen instead of a gdm login screen. The /var/log/gdm/:0-greeter.log file contains the error JS ERROR: !!! Exception was: Error: Error invoking Gio.init: Error calling StartServiceByName for net.reactivated.Fprint: GDBus.Error:org.freedesktop.DBus .Error.Spawn.ChildExited: Launch helper exited with unknown return code 157 JS ERROR: !!! lineNumber = '0' JS ERROR: !!! fileName = '"gjs_throw"' JS ERROR: !!! stack = '"("Error invoking Gio.init: Error calling StartSe rviceByName for net.reactivated.Fprint: GDBus.Error:org.freedesktop.DBus.Error.S pawn.ChildExited: Launch helper exited with unknown return code 157")@gjs_throw: 0 (null)@/usr/share/gjs-1.0/overrides/Gio.js:242 ([object _private_Gio_DBusConnection],"net.reactivated.Fprint","/net/reactivated /Fprint/Manager")@/usr/share/gjs-1.0/overrides/Gio.js:201 FprintManager()@/usr/share/gnome-shell/js/gdm/fingerprint.js:19 ()@/usr/share/gnome-shell/js/gdm/loginDialog.js:776 wrapper()@/usr/share/gjs-1.0/lang.js:167 ()@/usr/share/gjs-1.0/lang.js:194 _createGDMSession()@/usr/share/gnome-shell/js/ui/main.js:93 start()@/usr/share/gnome-shell/js/ui/main.js:214 @<main>:1 If I remove the fprintd and fprintd-pam packages then I do get a gdm login screen on boot.