User-Agent: Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; WOW64; Trident/5.0) Build Identifier: Fedora-18-Beta-x86_64-netinst.iso not include hid-hyperv.ko ( "Microsoft Vmbus HID-compliant Mouse") Reproducible: Always Steps to Reproduce: Run lsmod | grep hyperv Expected Results: hid_hyperv 9999 9
Not rygel, likely kernel?
Peter Robinson> Not rygel, likely kernel? Yes . . . Sorry: I'm select "rygel" ( not special) in process create bug report :-(
The Fedora kernel builds and provides those modules, but they aren't included in the initramfs. If they should be (and I have no idea), then dracut probably needs to include them.
JB> The Fedora kernel builds and provides those modules, JB> but they aren't included in the initramfs. Yes JB> If they should be (and I have no idea), JB>then dracut probably needs to include them. Do not worry :-) , they should be include => dracut needs to include them P.S. De-facto Bug 883005 is well-known problem Mouse Integration in Linux guest -- Sub-problem N1 mouse work in Linux Guest without "MS Vmbus HID-compliant Mouse", if connect to it from Windows _directly_ http://vvm.blog.tut.by/2011/02/22/hyper-v_mouse_in_linux/ == . . . Without "Microsoft Vmbus HID-compliant Mouse" , mouse work in {Linux Guest without hid_hyperv} if connect to it from {Windows physical workstation} _directly_ . . . == -- and imm. after solve N1, we look Sub-problem N2 i.e. CTRL + ALT + Left Arrow to release the mouse http://blog.allanglesit.com/2010/05/ubuntu-and-hyper-v-the-paths-to-enlightenment/ == Mouse Integration When a user uses Hyper-V Management Console or System Center Virtual Machine Manager to connect to a VM [ with Linux without "MS Vmbus HID-compliant Mouse" ] and they begin to interact with the desktop via the mouse, they find themselves in an interesting situation where they are unable to reclaim their mouse pointer from the VM without entering a somewhat cryptic keystroke ctrl + alt + left arrow. == P.P.S. Users and administrators of Hyper-V get a bad first impression about Fedora 18 , when see problem with mouse, even on install step This problem already solved in OpenSUSE, Ubuntu, Debian , etc.
(In reply to comment #4) > JB> The Fedora kernel builds and provides those modules, > JB> but they aren't included in the initramfs. > > Yes > > > JB> If they should be (and I have no idea), > JB>then dracut probably needs to include them. > > > Do not worry :-) , they should be include Why ? I'm using Server2012 Eval x86_64 and at the end of the install, I have: # lsmod | grep hyperv hid_hyperv 13059 0 hv_vmbus 33752 4 hv_netvsc,hid_hyperv,hv_utils,hv_storvsc Despite thoses are not included in the initramfs, they are probably not useful during the boot phase? (maybe hv_storvsc should be made available thought). Now I have another issue with gnome3 and a vesa xorg driver producing the "something went bad" message. Seems unrelated to this report.
FYI my issue was #810040
>(In reply to comment #5) >> (In reply to comment #4) JB>>> The Fedora kernel builds and provides those modules, JB>>> but they aren't included in the initramfs. VVM>> Yes JB>>> If they should be (and I have no idea), JB>>>then dracut probably needs to include them. VVM>> Do not worry :-) , they should be include N.Ch.> Why ? N.Ch.> I'm using Server2012 Eval x86_64 and at the end of the install, I have: { == # lsmod | grep hyperv hid_hyperv 13059 0 hv_vmbus 33752 4 hv_netvsc,hid_hyperv,hv_utils,hv_storvsc == VVM 2013-01-09: It self this state of loading kernel is fine, but see later "at end of the install" -- is to late, need "at begin of the install" } N.Ch.> Despite thoses are not included in the initramfs, N.Ch.>they are probably not useful during the boot phase? N.Ch.>(maybe hv_storvsc should be made available thought). Because my answer on 2013-01-09 countain some critics, and this critics may be true ( but may be not 100% true) and because bugzilla.redhat.com not allow edit posts, see full text of answer and screenshots at http://vvm.blog.tut.by/2012/08/22/fedora-18-on-hyper-v/ == . . . "at end of the install" -- is to late, need "at begin of the install" . . . ==
Does this report still hold ? To me the hid_hyperv.ko is present in the Fedora-18-x86_64-netinst.iso It might not be present in the initramfs built in a generic way (So dracut -f -H might bundle it). But it might be loaded at before the installation goes interactive.
Nicolas (kwizart)> Does this still apply with Fedora-18-x86_64.iso or netinst.iso from the Final version ? (not Beta) 2) in *LiveCD*.iso mouse work as need Tested with Fedora-18-x86_64-Live-XFCE.iso SHA256 = 95a75c334ce82b33f1a5d81eab196600e40c7933fd5f7bfa8e6ed9534529dd6e 1) With Fedora-18-x86_64-netinst.iso RTM ( SHA256 = df219f559311d255f7de7bff0bc8102e57b5352f3f6ecbeb8d583c2f780be449) nothing new: on step imm. after "the installation goes interactive" we again not have loaded "Microsoft Vmbus HID-compliant Mouse" : -- Reproducible: Always Steps to Reproduce: Run lsmod | grep hyperv Results: == {Blank Screen} == Expected Results: == # lsmod | grep hyperv hid_hyperv 99999 9 hv_vmbus 33752 4 hv_netvsc,hid_hyperv,hv_utils,hv_storvsc == -- hid_hyperv.ko must "be loaded at before the installation goes interactive" How exactly this implement -- is not important for Hyper-V sysadmins. P.S. And for RHEL v5.9 *netinst.iso hid_hyperv.ko must "be loaded at before the installation goes interactive", but not be loaded . . . Create another bug? Or?
> 2) in *LiveCD*.iso mouse work as need > > Tested with > Fedora-18-x86_64-Live-XFCE.iso > SHA256 = 95a75c334ce82b33f1a5d81eab196600e40c7933fd5f7bfa8e6ed9534529dd6e > > 1) > With Fedora-18-x86_64-netinst.iso RTM ( SHA256 = > df219f559311d255f7de7bff0bc8102e57b5352f3f6ecbeb8d583c2f780be449) > nothing new: on step imm. after "the installation goes interactive" we > again not have loaded "Microsoft Vmbus HID-compliant Mouse" : > > -- > Reproducible: Always > > Steps to Reproduce: > Run > lsmod | grep hyperv > Results: > == > {Blank Screen} > == > This has to be fixed in pungi to include hid_hyperv and hv_vmbus
This message is a reminder that Fedora 18 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 18. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '18'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 18's end of life. Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 18 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior to Fedora 18's end of life. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
This bug is fixed in Fedora 20 But: -- not fixed in Fedora 19
Thanks. Fedora doesn't respin install media so we'll have to settle for the f20 fix.