+++ This bug was initially created as a clone of Bug #740378 +++ Created attachment 524269 [details] Screenshot of vncviewer localhost:0 - none of the keys pressed are sent to anaconda. Description of problem: When I try to install F16 as DomU under Xen the installer (text) does not recognize any of the keys I am pressing. If I use the VNC F8 to send Ctrl-Alt-Del nothing happens. Version-Release number of selected component (if applicable): Whatever is in the F16-Alpha How reproducible: Steps to Reproduce: 1. cat > F16.xm kernel = "/tmp/vmlinuz" ramdisk="/tmp/initrd.img" #extra="askmethod" memory = 1024 name = "Fedora" vcpus=2 vif = [ 'mac=00:0F:4B:00:00:63,bridge=switch' ] disk = [ 'phy:/dev/vg_guest/FC16-64,xvda,w' ] vfb = [ 'vnc=1, vnclisten=0.0.0.0,vncunused=1'] 2. xm create -c F16.xm 3. vncviewer localhost:0 Actual results: No keyboard response. Expected results: Keyboard response Additional info: I did manage to install FC16 using workarounds. Mainly on the 'extra' line I added 'console=hvc0 test serial vnc' and I was able to hit keys in the text console (so the one provided by xm console), but still not in the VNC provided by the framebuffer. And the selection of the packages was done via vncviewer <guest-ip>:0. After the install was finished I poked around in the initrd and noticed that the xen-kbdfront was missing. But I couldn't figure out a way to insert the xen-kbfront during the install - either via unpacking the xz initrd img (tried the alpha version), nor disk images. Perhaps there is a link explaining how to create one? --- Additional comment from ketuzsezr on 2011-09-21 15:54:13 EDT --- Created attachment 524270 [details] Text output from 'xm console' with debug options. Screen output based off: #cat F16.xm kernel = "/tmp/vmlinuz" ramdisk="/tmp/initrd.img" extra="debug initcall_debug loglevel=10" memory = 1024 name = "Fedora" vcpus=2 vif = [ 'mac=00:0F:4B:00:00:63,bridge=switch' ] disk = [ 'phy:/dev/vg_guest/FC16-64,xvda,w' ] vfb = [ 'vnc=1, vnclisten=0.0.0.0,vncunused=1'] #xm create -c F16 --- Additional comment from ketuzsezr on 2011-09-21 16:03:21 EDT --- There is a workaround for this which is to do: extra="vnc lang=en_US.UTF-8 keymap=us" Anyhow, I am more than happy to test say, an kernel and initrd.img that have an xen-kbdfront injected in it... Does F16 use the old RHEL5 method of manually loading some specific modules? Or does it nowadays use the udev mechanism? --- Additional comment from ketuzsezr on 2011-09-27 14:15:24 EDT --- I am having a hard time actually finding this version (17.0) in the rawhide or F16 initrd.img. This URL http://fedora.mirror.ac.za/linux/development/rawhide/x86_64/os/Packages/ shows that lorax-16.4.2 is going in rawhide/f16. Sooo when will 17.0 be in? It is rather impossible to test this without using an initrd image, so I can't very well do 'yum update' during an install when I can't use the keyboard.
The fix is in 17.0 and it sounds like 17.0 will be used in F17. That is great! However this bug also affects F16. Without this fix, you can't install F16 under Xen - which means that it will affect Amazon EC2 customers at least. Please back-port this fix in F16. I am more than happy to test this patch.
proposing as a blocker for final so we can kick it around in a blocker review.
Discussed at 2011-09-30 blocker review. Agreed to punt again, as the Xen blocker criterion discussion didn't reach a clear resolution yet. We will try to kickstart that discussion and think more about e.g. the EC2 use case.
Discussed at 2011-10-07 blocker review. Again we didn't make a decision on the Xen criteria yet: we're going to take the discussion to devel@ and make a decision one way or the other by next week, then vote on this bug appropriately.
I built an x86_64 test image with the new lorax-16.4.5-1 and uploaded the initrd and kernel to: - http://tflink.fedorapeople.org/iso/20111007_loraxtest/initrd.img - http://tflink.fedorapeople.org/iso/20111007_loraxtest/vmlinuz
Tim, Thanks for building those ones. Sadly, it seems that the patch Martin backported still does not bundle the xen-kbdfront driver in the install image: sh-4.2# find /lib/modules/3.1.0-0.rc8.git0.1.fc16.x86_64/ -name xen-kbdfront sh-4.2# cd /lib/modules/3.1.0-0.rc8.git0.1.fc16.x86_64/ sh-4.2# cat modules.order |grep xen-kbd kernel/drivers/input/misc/xen-kbdfront.ko
I looked at the patch, and it is treating xen-kbdfront as a package (which it isn't) rather than a kernel module. Not surprisingly it doesn't work.
(In reply to comment #6) > Sadly, it seems that the patch Martin backported still does not bundle the > xen-kbdfront driver in the install image: Actually, that's my bad. There was a rather subtle error in my iso build process and it didn't actually use the new lorax build. I rebuilt the initrd and vmlinuz (double checking the lorax version) and uploaded them with a checksum this time. - http://tflink.fedorapeople.org/iso/20111007_loraxtest/initrd.img - http://tflink.fedorapeople.org/iso/20111007_loraxtest/vmlinuz - http://tflink.fedorapeople.org/iso/20111007_loraxtest/f16_loraxtest.sha256
Tim, I tested the one in comment #8, but as Michael Young mentioned - the patch in the lorax code is not sufficient - so it still is not working right :-(
Created attachment 526975 [details] add xen-kbdfront as a module, not a package I have done a scratch build of lorax with the attached patch at http://koji.fedoraproject.org/koji/taskinfo?taskID=3413155 which is more likely to work.
(In reply to comment #10) > Created attachment 526975 [details] > add xen-kbdfront as a module, not a package > > I have done a scratch build of lorax with the attached patch at > http://koji.fedoraproject.org/koji/taskinfo?taskID=3413155 > which is more likely to work. That did it! With that patch in place the newly created initrd img now accepts keyboard commands. With that, I can install F16 PV guests. Thanks
Discussed at 2011-10-14 blocker review meeting. Accepted as a blocker under the new Xen criterion "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". The criterion as written doesn't _technically_ precisely cover install issues, but we intended it to, and we may clarify this.
Can people please re-test this with Final TC2 and confirm it's fixed? The fix should be included.
It was in TC1 and I did a successful of that a few days ago where the keyboard worked.
great, let's close this then. thanks!