Opened 15 years ago
Closed 15 years ago
#5760 closed defect (invalid)
X stays black in Gentoo guest on Kubuntu 9.10 host -> closed as obsolete
Reported by: | Rutger van Bergen | Owned by: | |
---|---|---|---|
Component: | GUI | Version: | VirtualBox 3.1.0 |
Keywords: | X black | Cc: | |
Guest type: | Linux | Host type: | Linux |
Description
I have a VirtualBox 3.1.0 machine running Gentoo (kernel 2.6.31) on a Kubuntu 9.10 host. I installed the guest additions that came with VirtualBox (that is, not the ones that are available as Gentoo packages), and fired up Xorg (1.6.5) after that. What happens then is that the virtual machine's window resizes but stays black, while the Xorg log file seems to indicate that X started successfully. It is possible to successfully switch to another tty (using Host + Fn), from which I can then kill X. When X is killed, the console does come back up normally.
I have tested this using a plain text console and a VESA framebuffer console (albeit in the opposite order), with the exact same result both times.
I'm attaching my Xorg.0.log and xorg.conf for your reference.
Attachments (5)
Change History (14)
by , 15 years ago
Attachment: | xorg.conf.txt added |
---|
comment:1 by , 15 years ago
The log file shows a server segfault (crash). Unfortunately there is no trace information available in the log file. When you say that you tested this with the VESA framebuffer, do you mean that you re-enabled the VESA driver? And what happens if you delete (or rename) the VBox mouse driver?
comment:2 by , 15 years ago
First off, I want to thank you for responding so quickly.
The "crash" you mentioned is caused by, or at least related to, me hitting Ctrl-C in the console that I started X in, with the purpose of killing it. The log you looked at was generated when the VESA framebuffer was disabled, but the results are exactly the same (even at a logging level) when it is enabled.
Anyway, in the meantime the plot has thickened further. I have installed (that is, emerged) KDE 4.3.3, and now the behavior is different. When I start kdm I *do* get the kdm login screen, but after entering my credentials, the screen turns and stays black again. With one relevant difference: this time there is a blinking (text console) cursor in the upper left corner of the screen, which was not there in the "bare X" scenario. In the area of logging there are also differences. In /var/log/messages, kdm is making the following complaints (vboxvideo related kernel messages included because of potential relevance):
Dec 15 10:20:03 vbox-gentoo kernel: [ 125.103993] pci 0000:00:02.0: PCI INT A -> Link[LNKB] -> GSI 11 (level, low) -> IRQ 11 Dec 15 10:20:03 vbox-gentoo kernel: [ 125.109579] [drm] Initialized vboxvideo 1.0.0 20090303 for 0000:00:02.0 on minor 0 Dec 15 10:20:12 vbox-gentoo kdm: :0[3585]: Cannot open ConsoleKit session: Unable to open session: Failed to execute program /usr/libexec/dbus-daemon-launch-helper: Success Dec 15 10:20:12 vbox-gentoo kdm: :0[3585]: Client start failed Dec 15 10:20:12 vbox-gentoo kdm: :0[3585]: Cannot close ConsoleKit session: Unable to close session: no session open Dec 15 10:20:13 vbox-gentoo kdm[3578]: X server for display :0 terminated unexpectedly Dec 15 10:20:13 vbox-gentoo kdm[3578]: Unable to fire up local display :0; disabling.
The Xorg.0.log file does now show a "spontaneous" crash. See the Xorg.0.log.kdm attachment that I will add in a minute. I will also attach my current xorg.conf (xorg.conf.kdm), in which I have commented out the Input section in which the keyboard module is explicitly loaded.
For purpose of completeness, I want to note that the logs have been created when the VESA framebuffer was disabled.
I have not yet tried to rename the VBox mouse driver, which I will try as soon as possible after finishing this addition to the ticket. I expect, but I admit that is not based on any knowledge of the inner structure or workings of the VBox drivers, that will not make much of a difference, considering the fact that the X backtrace does not mention the mouse, but instead the video driver.
Anyway, I will let you know what the results of that are, and perhaps the new attachments constitute a clue until then.
by , 15 years ago
Attachment: | xorg.conf.kdm added |
---|
Xorg.conf file, used when the Xorg.0.log.kdm file was generated
comment:3 by , 15 years ago
I have retested, this time with the VBox mouse driver renamed, with no functional difference. The only difference (which was expected) is that the Xorg log (Xorg.0.log.novboxmouse) now mentions that it can't find the vbox mouse driver.
by , 15 years ago
Attachment: | Xorg.0.log.novboxmouse added |
---|
Xorg server log file, with KDM, without the VBox mouse driver
comment:4 by , 15 years ago
This message is just to indicate that the issue still occurs in VirtualBox 3.1.2.
comment:5 by , 15 years ago
The crash in Xorg.0.log.kdm occurs inside a call to VBOXMapVidMem., and this issue looks similar to #5788, which was apparently a bug in X.Org Server. Might this be the same thing?
comment:6 by , 15 years ago
I certainly can't rule it out, because the highest stable xorg-server version in Gentoo is 1.6.5 (plus one round of patches), and the last comment of bug #5788 refers to a patched version of 1.7.4. If it is a bug in X.Org Server, would that mean that it is not possible to run Gentoo with X in VirtualBox until 1.7.4 (with the apparently necessary patches) is marked stable within Gentoo?
comment:7 by , 15 years ago
Maybe you could try the Gentoo X.Org maintainers? Sorry if I sound mean, but I really don't feel like setting up a Gentoo VM just now to investigate, especially not if there is a good chance that it is someone else's bug.
comment:8 by , 15 years ago
I wouldn't say it sounds mean, I would say it's fair enough. Anyway, I have actually moved away from running Gentoo in VirtualBox; instead I'm running it as the host OS now. Sorry if I sound mean ( ;-) ), but I do have to say that the "Gentoo version" of X.Org does run fine directly on the hardware, which seems to indicate that although the issue may be fixed by a modification in X.Org, it is the combination of X.Org and VirtualBox that makes the issue manifest itself. For the purpose of being complete: on the Gentoo host I am now running OpenSolaris within VirtualBox (on the Gentoo host), with X running perfectly both on Gentoo and OpenSolaris.
comment:9 by , 15 years ago
Resolution: | → invalid |
---|---|
Status: | new → closed |
Summary: | X stays black in Gentoo guest on Kubuntu 9.10 host → X stays black in Gentoo guest on Kubuntu 9.10 host -> closed as obsolete |
In that case I will close the ticket. Thanks for letting me know!
Xorg.conf file