Ticket #6134 (closed defect: invalid)

Opened 8 years ago

Last modified 8 years ago

With guest additions control-S can't be typed into guest: guest linux and host XP. 3.1.2 -> guest configuration issue

Reported by: zephyrus Owned by:
Priority: major Component: other
Version: VirtualBox 3.1.2 Keywords:
Cc: Guest type: Linux
Host type: Windows


I have had the same problem mentioned in bug 5832

But here is a twist.

In my case, I can't type control-S to the terminal window in guest linux somehow.

This makes it very difficult to use Emacs editor where control-S is used for incremental search and saving a buffer is control-X and control-S, etc..

I am attaching below the description of the problem I had before I realized bug 5832 posting.

The major problem was the stuck mouse, and then this failure to input control-S :-(


Strange failure of mouse/desktop integration during upgrade to 3.1.2

I experienced the following strange problem which was eventually cleared up more or less (except for control-S input problem to emacs). I am reporting it here so that others who experience something similar may be able to follow my lead to get out of the pit, so to speak.

Also, this may warn developers that something is fishy in the way the current tool distributed with 3.0.12 may handle mouse/desktop integration.

Symptom and Background:

I have used 3.0.10 for a while to run Debian linux under Win XP host. I recently downloaded 3.1.2 (three days ago.) and upgraded to it.

I ran guest linux inside the new 3.1.2 virtualbox, and noticed that the mouse integration (the feature to move mouse cursor over vbox and the underlying host window background without the need to "capture" or hit right-control to move in between these windows.) no longer works. I now had to hit right-control to release the mouse focus from virtualbox to move to other applications under XP host.

I figured that the virtual box support tool installed in guest linux must be outdated or incompatible with 3.1.2.

So I re-installed the NEW tool in the guest linux. (Caution: I vaguely recalled seeing that the installation process stated that the script didn't update xorg.conf since it believed the script was generated by virtualbox script, and no change was necessary. This may be the cause of the proble detailed below, but I am not sure.)

I rebooted the guest so that the new tool drivers, etc. will be effective to make the mouse integration work again.

*Now, the funny behavior.*

(*) I could enter username and password to gnome login box. Again, so fa, so good. (This is the correct working part which I found rather strange considering the later behavior.)

*BUT* once the gnome desktop appears, I can't click on the linux icons or desktop background to invoke programs. There was nothing I could do because I could not invoke any program at all using mouse clicks! (My initial desktop has no terminal open and so I could not type anything to it. Then I wonder if I could type something under this strange behavior anyway. But I digress.U)

Also, I noticed that the mouse movement was rather flakey. It seemed to move up and down mostly no matter how hard I tried to move it horizontally.

The only place where mouse button is recognized is when I move the cursor out of virtualbox window in the downward direction and trying moving it upward again into the gnome desktop shown inside virtual box [I forgot to metion that the newly installed toolbox now seemed to handle the resizing of the guest linux window, at least], and then somehow the virtual desktop switcher, which allows me to switch among four saved desktops offered to show the pop-up menu. But then again, I could not choose any of the menu items or mark on/off any of the check boxes therein.

So I could not do a thing.

I have seen strange behavior of mouse that rendered GUI useless when the mouse driver was not correct for the particular mouse used under X.

So I figured that maybe the newly installed virtualbox tool was to blame, since this type of pointing device error is often to blam on incorrect mouse driver, etc., I decided to remove the new tool.

I rebooted the guest OS : luckily, from the virtualbox menu, I could invoke ACPI power-off, which in turn started the guest linux OS shutdown in one minute. Otherwise, I was at a loss what to do.

Firstly, I downgraded virtual box to 3.0.10 to see if this helps.

No. Unfotunately, the strange symptom of inffective mouse handling continued now with the older 3.0.10, too.

So I really thought the new tool was to blame and decided to remove it. But without being able to interact with GUI, how do we manage removing the tool for the time being.

I shutdowned the linux guest by ACPI power-off again. When I booted the guest linux again, I entered into single user mode from grub menu, and once I log in as superuser, I removed /lib/modules/*my-linux-kernel-vesiond*/vbox*.ko

There were to such ko modules. I left the vfs-related modules since I needed file sharing between host XP and guest linux very much although I can live with non-integration of mouse.

Unfortunately, when I entered the multi-user mode, the lack of mouse integration also means that the we lack the auto resizing of desktop of guest linux to the virtualbox window under XP desktop. This is VERY inconvenient since I wanted to use the full screen occasionally from within guest linux, but this time when I enlarge virtualbox window, the gnome desktop in the linux guest remained in the original size and thus very small inside the enlarged virtualbox window.

So I need the working .ko for desktop integration.

I got stuck :-(

Then I recalled the message that stated /etc/X11/xorg.conf was not re-created during virtualbox tool install since the installation script thought xorg.conf was originally created by virtualbox tool installer.


So I thought of editing /etc/X11/xorg.conf, but found it contained very few lines. No way to edit it in a meaningful way to placate the misbehaving tool, I thought.

I got stuck again.

Well, then I did something drastic. I simply removed xorg.conf. (Actually, I renamed it.)

and decided to see how this would work out.

I hit control+alt+backspace which will restart X server only in guest linux.

I half expected the failure of X server. Instead, to my surprise, X started all right!

Although the integration didn't work (because I removed the applicable *.ko), somehow X was usable anyway. [I wonder where X server picked up the default and looked at /var/log/Xorg.0.log, etc. It seemd that X server used default built into the binary, etc. and managed to come up and work!]

After checking the behavior of shutting down and rebooting a few times, I decided to install toolkit again. This is because I sensed that the failure to replace xorg.conf during installation was possibly the cause of the failure

This time, the installation produced xorg.conf since there was no xorg.conf under /etc/X11/ to speak of. (this was under 3.0.10. Funny, though, I could not find the "old" image of toolkit presumably installed for 3.0.10, but I only could install the later toolkit possibly installed by 3.1.2).

After the tool installation, I shutdown X server only [C-ALT-BS] and saw that the integration now works and I could click on icons of Gnome desktop and invoke programs and type something into newly started terminal windows.

So now, I shut down guest linux and decided to upgrade to 3.1.2 again.

This time around, after a period of suspence, I saw that the mouse/desktop integration works correctly with virtualbox 3.1.2 EXCEPT for I can't type control-S to emacs window somehow!!!

I have no idea why.

This failure to pass contro-S to emacs is right now the only mouse/desktop integration problem that remains.

There can be still a lurking problem with the toolkit distributed with 3.1.2.


Change History

comment:1 Changed 8 years ago by zephyrus

OK, I downgraded to 3.1.0, still no luck as far as control-S was concerned.

This was really strange.

Running of xev from tty console showed that the key event for control-S was not recorded. Control key down was recorded. But no control-S. Other didn't have this problem. Control-Q was recorded for example.

I scratched my head.

On a hunch, I ran "stty -raw" on the tty console.

Then, lo and behold, "control-S" is recognized by xev: its event is recorded (exactly speaking, Control down event was recorded, and the subsequent 's' key down event was also recorded while the control was still down. Previously it was not recognized at all.)

Now control-S works in emacs, also.

However, I think there is something really strange going on.

From what I understand in emacs code, emacs specifically disables the special handling of "control-S" in the tty driver before it starts user interaction.

Has something changed in the 3.1.0 (and later) [and guest addition tools] and previous version of virtualbox and their addition tools?

It is possible I was using 3.0.10 (NOT 3.1.0) before. Sorry for the confusion!

comment:2 Changed 8 years ago by michael

  • Status changed from new to closed
  • Resolution set to invalid
  • Summary changed from With guest additions control-S can't be typed into guest: guest linux and host XP. 3.1.2 to With guest additions control-S can't be typed into guest: guest linux and host XP. 3.1.2 -> guest configuration issue

As mentioned in #5832, the Guest Additions from the 3.1.4 beta release fix the problem with the mouse integration (you can use those Additions with the 3.1.2 release without problems). As the Ctrl-S thing sounds more like a guest configuration issue than a VirtualBox issue to me I will close this ticket, but you can always re-open it if you disagree.

comment:3 Changed 8 years ago by zephyrus

Dear Michael,

I now have a feeling this is more of an issue of some upgrade procedure: After a few round of going back and forth between the previous 3.0.10 and 3.1.0, and 3.1.2, I now have Vbox 3.1.2, and 3.1.10 Guest addition running AND without the problem of control-S not being recognized. But I suppose if someone got stuck with a similar problem, then he/she can look at this bug report. I can't pin point the problem, but maybe 3.0.10 -> 3.1.2 (without going through 3.0.12, then 3.1) may be too radical an upgrade. I have not changed the guest OS setup at all as far as VBox is concerned except for the guest addtion. This is a production destkop and so I don't tinker with various setup without a reason. Emacs is somethihg I depend upon so much.

Regarding 3.1.4 beta Guest Addition. I tried it. But tt causes a serious kernel problem on shutdown and I am reporting it beta feedback forum. Guest Debian is at Linux debian-vbox-ci 2.6.26-2-686 #1 SMP Sat Dec 26 09:01:51 UTC 2009 i686 GNU/Linux

Maybe the kernel is too old for 3.1.4Beta, but Debian is very conservative and uses somewhat old and stable kernel all the time.

Note: See TracTickets for help on using tickets.
ContactPrivacy policyTerms of Use