|
xen-users
Re: [Xen-users] VNC console access in paravirtualized domUs
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Am 19.06.2008 um 09:54 schrieb Ray Barnes:
Per my last post in this thread, I came to the same conclusion you
did (that Etch wouldn't have the framebuffer stuff in the kernel)
so I subsequently tried Lenny and Sid. I found that the modules
for something called "vfb" in Sid, but they won't load. Adding
"video=xenfb" to the kernel parameters is of none effect either; I
still get "XENBUS: Device with no driver: device/vfb/0" in the
kernel messages (and no /dev/fb0 either). Ubuntu Hardy is a little
different story. It generates the /dev/fb0 and seems to act right,
it just won't send anything to VNC. Even with "console=xvc
console=tty" in the kernel args, I get a black VNC screen that's
sized appropriately, but no text. Still trying to ascertain what,
if anything, this has to do with Xorg.
I'm hoping someone will fix this; it sure would be nice to have.
-Ray
The vfb.ko module has nothing to do with Xen as far as I know. That
is only a dummy module, used for development and testing. What you
need is the Xen framebuffer, you can check which Xen components are
in your DomU's kernel by simply using: "grep 'XEN' /boot/config-$
(uname -r)". You'll want to look for XEN_FRAMEBUFFER in this
particular case (I think that was it).
For your Hardy DomU, the only thing I can tell you is that this has
nothing to do with Xorg, since it isn't even installed. It is simply
a matter of the kernel not sending the console data to the
appropriate device, though I can't tell you why or how to make it
work. The best thing would probably be to compare the boot cycle
(kernel, patches, kernel options, modules, /etc/modu*, etc.) to a
system where it works. You could also try to play with the vga
command line option (if it's supported by the kernel), because I
think the default Hardy Server kernel doesn't use the framebuffer at
all. Thats just a hunch though, no clue if I'm right there, since I'm
pretty new to Xen myself.
Paul.
- --
Paul Schulze
avlex@xxxxxxx
Public Key: http://solaris-net.dyndns.org/keys/key_avlex.asc
"Making mistakes is human,
but to really fuck things up you need Computers"
On Wed, Jun 18, 2008 at 10:15 AM, Mike Lovell <mike@xxxxxxxxxxxx>
wrote:
I have seen this problem on a setup that I did with debian etch.
Unfortunately, I didn't spend enough time with it to see if this
is a solution since I didn't need a graphical console anyways.
Are you using the xen kernel that is available in the debian etch
repositories? If so, that might be your problem. The kernel there
(2.6.18-4-xen-686) is one that was build with xen 3.0.3 which did
not have the vfb capabilities. The 3.0.4 release did. So the
kernel doesn't have a way to do a graphical console. I would try
building the linux kernel with the 3.2.0 patch set and using that
for the domu. (http://bits.xensource.com/oss-xen/release/3.2.0/
linux-2.6.18-xen-3.2.0.tar.gz). I started to try that on my set up
but didn't have enough time to fully explore the possibility.
I might be completely off on this since I am definitely not a xen
expert but it seems like a logical explanation.
Mike
_______________________________________________
Xen-users mailing list
Xen-users@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-users
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (Darwin)
iD8DBQFIWmcvYDWOGtiChoARAhiaAJ4qcytGd6jDNWyHoDNCDWhnU/iPuQCeKMQp
cY8lV+8sGiuFZELvEwpPdYw=
=4aBQ
-----END PGP SIGNATURE-----
_______________________________________________
Xen-users mailing list
Xen-users@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-users
|
|
|
Home