VirtualBox

Custom Query (16363 matches)

Filters
 
Or
 
  
 
Columns

Show under each result:


Results (82 - 84 of 16363)

Ticket Resolution Summary Owner Reporter
#4951 fixed VBoxGuestAdditions.iso not found after an upgrade. (Vbox refuses to continue with a saved image) ci-zephyurus
Description

Host: Win/XP 32bit Guest: Debian/GNU Linux 32 bit VirtualBox: 3.0.6

I noticed the availability of 3.0.6 and saved a running image of linux 32 bit version, and also saved a running version of solaris10 (64 bit).

Please not that I have not shutdown the OS images, but rather simply quit the Vbox and let it save the current states.

After the upgrade, when I tried to run linux 32 bit version, Vbox reported that one of the CD/DVD images are no longer accessible and refused to restart the image.

When I checked, VBox was looking for VBoxGuestAddtions.iso. (Which I think is a natural. I mean all running instances will mount it implicitly.)

Now, I checked the windows C drive where VBox installed to see if I messed up the upgrade. Well, the iso image was right there.

C:\Program Files\Sun\VirtualBox\VBoxGuestAdditions.iso

Then why VBox refused to continue with my saved image?

I scratched my head a few times, then I noticed the following.

VBox recorded the full pathname of the ISO file using partially DOS-style 8.3 name, thusly. c:\Program Files\Sun\XVMVIR~1\... The last part is omitted.

That is "VirtualBox" was recorded as old-fashined DOS 8.3 name, which I am afraid has changed to a different one during the upgrade.

So hoping to continue with the saved image, which contained rather up-to-date edit of a few files, I created "XVMVR~1" directory and copied the iso file there.

Voila, VBox now let me run / continue with my previously saved linux image.

My two cents worth for anyone troubled with a similar bug/problem/feature on Windows/XP host.

PS: Solaris 64 image could not be restarted any more, due to a strange kernel trap in 3.0.6 for now. What a pain. (see ticket # 4947 reported by someone else first.)

#5543 obsolete Japanese KB Hankaku key on linux guest (keycode = 49) is repeated incessantly ! ci-zephyurus
Description

On a linux guest under XP host, with a Japanese KB, a key called Hankaku key (actually hankaku/zenkaku swap key or whatever) is handled somewhat in a buggy manner.

When we press the key, sometimes the key is repeated continuously for no apparent reason, and we have to hit the key or other keys to stop this repeating. Well if lucky, that is. I had to close the window system in one or two instances when I first hit this bug.

This is really annoying and the only sane countermeasure for this buggy behavior is to disable key repeat for this particular key.

xset -r 49

49 is because the key code is reported as 49 under linux for this keyboard.

I checked VirtualBox ticket and there is Ticket #2847 which mentions the handling of this particular key "hankaku" on solaris. But then I notice something fishy there. The keycode reported in ticket #2847 is different from the above 49.

The exact X event generated when the key autorepeats itself for no apparent reason is as follows: captured by xev.

KeyRelease event, serial 33, synthetic NO, window 0x3a00001,

root 0x48, subw 0x0, time 635847596, (777,131), root:(781,181), state 0x0, keycode 49 (keysym 0x60, grave), same_screen YES, XLookupString gives 1 bytes: (60) "`" XFilterEvent returns: False

KeyPress event, serial 33, synthetic NO, window 0x3a00001,

root 0x48, subw 0x0, time 635847596, (777,131), root:(781,181), state 0x0, keycode 49 (keysym 0x60, grave), same_screen YES, XLookupString gives 1 bytes: (60) "`" XmbLookupString gives 1 bytes: (60) "`" XFilterEvent returns: False

KeyRelease event, serial 33, synthetic NO, window 0x3a00001,

root 0x48, subw 0x0, time 635847629, (777,131), root:(781,181), state 0x0, keycode 49 (keysym 0x60, grave), same_screen YES, XLookupString gives 1 bytes: (60) "`" XFilterEvent returns: False

I have found out this flakey behavior earlier this year, and thought it was only my keyboard. But then I experienced on other PC with different keyboard, and figured out it is NOT only my keyboard. And sure enough, when I searched similar problems using google, I found out there ARE MANY perplexed Japanese users (linux guest mostly since I am a user of linux host and interested in such users. It seems that only linux guest users get bitten by this bug.)

Anyway, one of the blog pages I found mentioned this crude kludge of

xset -r 49

and it works for me now. (Of course, no auto-repeating for this particular is available now.)

I think there must be something wrong in the keyboard handler of VirtualBox or guest utility for linux which may need fixing.

TIA

PS: Oh, I now noticed that the key actually is considered accent grave. How interesting.

PPS: I mention the version is 3.0.10, but many users experience this problem (maybe unique to Japanese KB?) since last year it seems so it affects 2.x and even 1.y etc. as well although the cursory check lists 2.4 users being affected by this bug last year.

PPS: Someone mentioned that XP IME (A frontend to input Japanese characters) may steal key up event(?) for this particular key before virtual box has time to see it. Right, accent grave is used to control the Japanese character input handling coupled with ALT key on an English keyboard. [But I am not sure if this stealing of key up event before virtualbox sees it is true or not. I am not sure I saw the same key-repeating problem under vmware. I need to check.] So this is a rumor until substantiated. PPPS: Anyway, this is a major nuisance. Many ubuntu BBS in Japan mention to disable this key for ubuntu-guest under virtualbox as one of the first thing to do after installation from what I gather.

#6134 invalid With guest additions control-S can't be typed into guest: guest linux and host XP. 3.1.2 -> guest configuration issue ci-zephyurus
Description

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.

Hmm.

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.

TIA

Batch Modify
Note: See TracBatchModify for help on using batch modify.
Note: See TracQuery for help on using queries.

© 2024 Oracle Support Privacy / Do Not Sell My Info Terms of Use Trademark Policy