Re: [Xen-users] OpenSuse 11 hvm domU: screen resolution up to 640x480

[jim burns <jim_burn@xxxxxxxxxxxxx>]

On Wed December 7 2011, 5:54:34 PM, Flavio wrote:
> On 7 December 2011 07:15, jim burns <jim_burn@xxxxxxxxxxxxx> wrote:
> > Ok -  I got curious about your pv install method, and tried it myself.
> > It actually did work, but you may not be aware of it.
> > 
> > First, given your config, it looks like all you did was an 'xl create
> > ...' to start your install.
> 
> Yes, I actually did xl create opensuse11.cfg && xl vncviewer `xl domid
> OpenSuse11`

The syntax on xl vncviewer is unnecessary, despite what xl help says. 'xl 
vncviewer OpenSuse11' works also.

> Then in the vnc viewer at a certain point, a message appears and it
> says to enter the
> domU via ssh. So performing the following command, the graphical setup
> starts: ssh -X root@<domU_IP> and then start yast (see screenshots below).

I didn't use any of your extra= lines in my install, so I never had Yast in a 
ssh -X window. Convenient though, since you ended up being able to use the 
mouse, instead of using the Alt-keystroke method I was using in vnc.

> Finally the Automatic Configuration starts and I can finish the
> installation process.
> After that, the boot continues in the vnc viewer and I can proceed
> with the login.
> Of course the boot process continues on the domU console too (where
> the pygrub started).
> In this case, the mouse doesn't work for me too! :(
> Let's investigate if some option is missing in the configuration file.
> The pointer doesn't move but click works.
> See this:
> http://xen.1045712.n5.nabble.com/OpenSuse-11-PV-domU-installation-problem-t
> he-mouse-pointer-doesn-t-move-but-click-works-td4998460.html

Doesn't help much if you can't move the cursor around to click on something. 
:-(

> I had this problem in the installation process before. The strange fact is
> that the mouse works with yast but not with vnc.

Right - because you are using the mouse, keyboard, and video on your client 
where you typed 'ssh -X ...', not the drivers in the domu. That's why I said 
using the extra= line with ssh was convenient.

> Something tells me that it is a OpenSuse 11.4 issue, so I'm going to
> download the
> 12.1 version of the DVD and to try a new PV setup (now that I know how
> to complete
> the setup!!!).

Interesting. I haven't even had time to upgrade my suse 11.4 bare-metal system 
yet.

> > Anyway, that's what I did, with this config patterned after the one you
> > posted, with local differences, and hvm directives removed (and by the
> > way,
> > 'vcpus' was misspelled):
> Was it misspelled? I've checked. I didn't notice that. Anyway...

Sorry - I was editing and comparing several config files at the time. It was 
one of my old configs that had the misspell.

> > That kernel & initrd started the install, and then I had to pick
> > one of the Network install methods, after clicking on 'Back' to get to a
> > menu. (Yes - it is a *pain* not having the mouse work. Fortunately,
> > each option on each screen in Yast has an underlined letter. That
> > letter, held down with the Alt key, selects that option.)
> 
> Yes, but not in the first screen! http://goo.gl/6EymS in wich I don't
> know how to press close!

See the dotted lines around 'openSUSE Build Service'? That's where the 
'cursor' is. Hit Tab several times until 'CLOSE' has the box, then hit return. 
(Just thought of something - since click works, you should be able to 'right 
click' on that screen, and arrow key down to 'close'. On most keyboards, there 
is a 'mouse click' key on the bottom right side, between the Alt & Ctrl keys.)
 
> > After the install finished, I changed the config file - un-comment the
> > bootloader= line, and comment out the kernel= & ramdisk= lines. I then
> > did an 'xm create ... -c' to be sure that grub was setup right, and
> > then exited the domu's console, and did an 'xm vncviewer ...', and I am
> > now staring at the KDE desktop.
> 
> Well, thanks to your tip above, I was able to go ahead with the setup
> where I was
> blocked. Now, I've noticed that I could start KDE as root but not as a
> normal user.
> Maybe it is due to a permission issue, or a missing group membership. I have
> to investigate also on it.

This may have something to do with your other extra= line. I had no trouble 
getting a desktop as an ordinary user, until I added extra='xencons=tty ...'. 
This interferes with the creation of /dev/tty0, which I'm guessing xorg needs.

> > This is the menu.lst it installed. Notice it has kernel-desktop, and
> > kernel-xen installed, with the kernel-xen as the default menu item, so
> > the 'xm create' with the '-c' option was not necessary. I could have
> > gone straight into a vncviewer. (I don't think menu.lst will be setup
> > until you are past the Automatic Configuration step, so I didn't switch
> > comments on bootloader and kernel / ramdisk till after then.)
> 
> This is pretty good. Actually I think it detects that it is a PV domU
> and it installs
> also the kernel-xen setting it as the default kernel. Good!

Correct. It wouldn't be very useful for a virtual install routine to install a 
kernel that was not domu capable. :-)

> > Unfortunately, the desktop I'm looking at is 800x600, so we are back to
> > one of the original problems. I'll try putting 'vga=0x31a' in menu.lst,
> > or Fajar's suggestions about setting resolution in a pv domu, in the
> > next day or two, and tell you what I come up with.
> 
> So, no higher resolution than 800x600 with some xorg.conf trick? Bad...
> Anyway, the first problem to solve now is the mouse pointer. This has the
> highest priority now.
> 
> On 7 December 2011 11:08, jim burns <jim_burn@xxxxxxxxxxxxx> wrote:
> > Well, this is fairly useless. The mouse doesn't work at all, so the
> > desktop is unusable. I have to 'xm console ...' in to give commands. I
> > turned on sshd, and changed the SuSEfirewall rules so I can use ssh as
> > well.
> 
> I really don't understand why the mouse doesn't work. I'm really frustrated.
> > The resolution is unchangeable. The hvm tricks that worked - vga=0x31a,
> > or defining an xorg.conf don't work.
> :
> :-(
> :
> > And Fajar's xen-fbfront.video=32,1280,1024
> > option in menu.lst didn't either. I wouldn't be surprised if suse
> > renamed the module, though, like it renamed xennet and xenblk. However,
> > since XEN_FRAMEBUFFER is builtin, I can't find the name of the module
> > to modify it's options.
> 
> Maybe one solution is to recompile the kernel and put it as module.
> We should try. The problem is that it is a very long process if we use
> the config file provided by the distro.

That would be useful. I won't do it - compile times on my system are bad, too. 
And I have several other projects stacked up.

> Pheraps we could try an "external" domU kernel, and not using pygrub
> but something
> like the following line in the configuration file:
> kernel = "/mnt/xen/kernel/vmlinuz-xen-3.1.0-domU"
> I use that kernel to start a gentoo pv domU and it works.

The problem with that approach is you have to copy over the whole 
/lib/modules/<kernel version> tree to your domu, or you won't be able to load 
any kernel modules that are not in your initrd. And you won't be able to keep 
the modules updated with new versions of the kernel from within the domu. 
You'd have to update them on the source computer, then copy the modules over 
to the domu again. It would be useful for quick testing, though. If it's an 
.rpm file, though, you can install it directly in your domu, if there are no 
dependency problems.

_______________________________________________
Xen-users mailing list
Xen-users@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-users