On Mon November 14 2011, 12:02:13 AM, Flavio wrote:
> > As a test, try doing
> > 'rcSuSEfirewall2 stop', and see if that helps.
>
> nope. I've already tried that and it doesn't help. I think it is all related
> to those kernel modules that are missing.
>
> > If it does, we can play with
> > the firewall config to allow all traffic on your 192.168.1 subnet. If
> > one hvm domu works, and the other doesn't. it could be that one kernel
> > doesn't have a kernel module that the firewall needs, so it is
> > defaulting to lockdown.
> It's not due to the firewall because if I boot with the default 2.6.37
> kernel that
> comes with the installation, the network works. Changing the kernel
> with the 3.1.0
> it doesn't.
>
> > If none of this works, you may have to break out tcpdump on the tap
> > interface. I'm no expert with it,
>
> so am I.
>
> > but I'd look for some kind of restriction on the kind
> > of traffic that's getting out of the interface - just arp and udp, but
> > no tcp, or communication in one direction, but not the other.
>
> I repeat. I think it's due to the kernel configuration. I have no idea of
> what could the problem be. I prefer to find an alternate solution. By the
> way, I couldn't
> setup the PV guest at the end.
Ok - As I said, so long as the 3.1 domu config has
CONFIG_XEN_NETDEV_FRONTEND=y (builtin) the network should theoretically work.
Particularly since your Gentoo dom0 is also 3.1. The fact that your 2.6.37
domu network works, and 2.6.37 is the old xenlinux style, as opposed to the
newer 3.1 pvops style, shows that qemu-dm is capable of hiding the
differences. The fact that /etc/sysconfig/kernel asks for the old xennet,
xenblk names shouldn't matter with the newer xen-netfront as a builtin. And
again, your eth0 got an ipv4 address from the network - I assume you get
addresses from dhcp?
None the less. post your dmesg for 3.1, and I'll compare it to the dmesg for
2.6.37 you previously posted. (Yeah, I remember - no network. Redirect it:
dmesg > ~/something-in-your-homedir.)
> >> cirrusfb 32579 0
> >
> > Ok, now I'm confused again. Have I got this right - your compiled
> > kernel, 3.1, has no network, and your 2.6.37 has the resolution
> > problem?
>
> Both have the resolution problem. 2.6.37 is OK for the network. 3.1.0 is not
> OK.
Ok - that's clearer.
> > Because at one
> > point, you said you tried to install the kernel-xen package from suse
> > (2.6.37.6-0.9), and you got an 'Invalid or unsupported executable
> > format'
> > error.
>
> Yes, the kernel-xen doesn't work to me. Anyway, I don't think it is a good
> thing, to install a domU kernel if it won't run on a PV guest.
>
> > Which 2.6.37 kernel are you talking about now, that's (mostly) working?
>
> 2.6.37 is the kernel that comes with the distribution setup (suse 11.4).
> It's not a xen capable kernel, or even better it's a "normal" kernel.
> 3.1.0 is a kernel that has been compiled by myself.
> kernel-xen, has been installed with zypper, the suse package manager.
>
> > Ok - I just looked at your dmesg, and your booting suse's 2.6.37.1-1.2-
> > desktop. Let's look at the file formats:
> > [...]
> >
> > So suse's desktop flavor of the kernel (which has no xen features for a
> > pv domain) is a bzimage format, which is standard, and an hvm domain
> > should have no problems with it, and your (earlier version)
> > 2.6.37.1-1.2-desktop kernel does in deed boot. The 2.6.37.6-0.9-xen
> > kernel(s) are ELF formats, as required by a pv domain. Don't know why
> > you are getting the bad executable error, but you can try substituting
> > vmlinux (with an x) for vmlinuz (with a z), and see if your pv domain
> > will boot now.
>
> It's not pv, but hvm. Anyway, I can't substitute a z with a x. The
> file is called
> vmlinuz. Or maybe I didn't understand exactly what you mean.
Look in /boot after you install kernel-xen (actually, any suse kernel, which
is 2.6.37 in this case). Eg:
-rw-r--r-- 1 root root 4359289 Oct 26 11:57 vmlinux-2.6.37.6-0.9-xen.gz
lrwxrwxrwx 1 root root 28 Nov 8 20:34 vmlinuz -> vmlinuz-2.6.37.6-0.9-
default
-rw-r--r-- 1 root root 4016864 Oct 26 11:37 vmlinuz-2.6.37.6-0.9-default
-rw-r--r-- 1 root root 3709170 Oct 26 11:39 vmlinuz-2.6.37.6-0.9-xen
lrwxrwxrwx 1 root root 24 Nov 13 18:51 vmlinuz-xen ->
vmlinuz-2.6.37.6-0.
See - there is a vmlinux *and* a vmlinuz xen kernel. You could try either
spelling in your menu.lst. This goes back to when you were trying to boot
kernel-xen as a pv domu. Your menu.lst stanza had no xen.gz entry - only
'kernel vmlinuz...' and 'initrd initrd...' lines. I was just suggesting
testing whether the vmlinux has a more compatible executable format than the
vmlinuz. (Although, since they are both ELF formats, there probably won't be
any difference.)
> > So my question remains: the 3.1 kernel is the one without a network, and
> > the 2.6.37.1-1.2-desktop is the one with the resolution problems,
> > right?
> Right. As I've written above, both have the resolution problem, otherwise,
> the resolution problem would be solved now, and we would talk about a
> networking problem!
On to the resolution problem.
> > This is showing that vesa is builtin, and cirrusfb is a module, as on my
> > systems.
> >
> >> > ls -alF /sys/bus/pci/devices/0000:00:02.0 (your video device)
> >>
> >> lrwxrwxrwx 1 root root 0 Nov 13 09:57
> >> /sys/bus/pci/devices/0000:00:02.0 ->
> >> ../../../devices/pci0000:00/0000:00:02.0/
> >
> > Sorry - I forgot about the soft link. I meant ls -alF
> > /sys/bus/pci/devices/0000:00:02.0/ (with a trailing slash). Pls repost.
>
> # ls -alF /sys/bus/pci/devices/0000:00:02.0/
> total 0
> drwxr-xr-x 3 root root 0 Nov 13 23:49 ./
> drwxr-xr-x 12 root root 0 Nov 13 23:49 ../
> -r--r--r-- 1 root root 4096 Nov 13 23:49 boot_vga
> -rw-r--r-- 1 root root 4096 Nov 13 23:52 broken_parity_status
> -r--r--r-- 1 root root 4096 Nov 13 23:51 class
> -rw-r--r-- 1 root root 256 Nov 13 23:49 config
> -r--r--r-- 1 root root 4096 Nov 13 23:52 consistent_dma_mask_bits
> -r--r--r-- 1 root root 4096 Nov 13 23:52 device
> -r--r--r-- 1 root root 4096 Nov 13 23:52 dma_mask_bits
> -rw------- 1 root root 4096 Nov 13 23:52 enable
> -r--r--r-- 1 root root 4096 Nov 13 23:52 irq
> -r--r--r-- 1 root root 4096 Nov 13 23:52 local_cpulist
> -r--r--r-- 1 root root 4096 Nov 13 23:52 local_cpus
> -r--r--r-- 1 root root 4096 Nov 13 23:52 modalias
> -rw-r--r-- 1 root root 4096 Nov 13 23:52 msi_bus
> -r--r--r-- 1 root root 4096 Nov 13 23:52 numa_node
> drwxr-xr-x 2 root root 0 Nov 13 23:52 power/
> --w--w---- 1 root root 4096 Nov 13 23:52 remove
> --w--w---- 1 root root 4096 Nov 13 23:52 rescan
> -r--r--r-- 1 root root 4096 Nov 13 23:49 resource
> -rw------- 1 root root 33554432 Nov 13 23:52 resource0
> -rw------- 1 root root 33554432 Nov 13 23:49 resource0_wc
> -rw------- 1 root root 4096 Nov 13 23:49 resource1
> -r-------- 1 root root 131072 Nov 13 23:52 rom
> lrwxrwxrwx 1 root root 0 Nov 13 23:49 subsystem -> ../../../bus/pci/
> -r--r--r-- 1 root root 4096 Nov 13 23:52 subsystem_device
> -r--r--r-- 1 root root 4096 Nov 13 23:52 subsystem_vendor
> -rw-r--r-- 1 root root 4096 Nov 13 23:49 uevent
> -r--r--r-- 1 root root 4096 Nov 13 23:52 vendor
>
Again, there is no directory entry for a soft link called 'driver' pointing
to a kernel module, such as cirrusfb, so vesa is probably still in charge. See
if anything interesting comes from 'cat
/sys/bus/pci/devices/0000:00:02.0/uevent'.
> > So the drivers listing, and lsmod are showing that cirrusfb is loaded,
> > but lspci -vvv is not? Contradictory - again, is this the domu with the
> > resolution problem?
>
> Yes it is. I have the resolution problem in any case.
>
> > Yeah - the BAR error bothers me. Something is preventing the cirrusfb
> > from initializing. Normally you get a handoff from the builtin vesa
> > driver to the installed card driver. This is from my baremetal suse
> > system:
> >
> > fb: conflicting fb hw usage radeondrmfb vs VESA VGA - removing generic
> > driver
> >
> > BAR errors are not something I have experience with. I'm going to repost
> > this section of your post, and see if Fajar has something to say.
>
> OK
>
> On 13 November 2011 18:57, jim burns <jim_burn@xxxxxxxxxxxxx> wrote:
> > If you are installing from a modern install disk, the xorg driver evdev
> > should configure your mouse correctly. Check your Xorg.0.log for evdev.
> I am using the latest DVD release. No errors reported in the Xorg.0.log file
> in the dom0.
No, I mean do you see lines that evdev loaded? 'grep evdev
/var/log/Xorg.0.log'
> > This is kind of old. You say the install worked,
>
> It started... but as I've already said, it blocked.
I don't know what you mean by blocked. Did the installer load, and you got a
menu, but you couldn't get it to start installing packages? Your link to the
setup procedure mentioned setting up Apache to mount your cdrom. You could
just as easily have used an nfs mount of the cdrom. The problem is you can get
your dom0 to load a cd in a pv install, but once the installer is handed
control, an inherent limitation of a pv domu or install, is it doesn't know
about cd devices.
> It is really frustrating that there is not any guide to setup
> a OpenSuse PV domU.
Yes it is. In fact, every distro has some utility to install a pv domu of its
own kind, but limited ability to read install disks from a different distro.
For instance, it is trivial to install an opensuse pv domu using Yast in an
opensuse dom0. Of course, your dom0 is gentoo.
> Anyway, the config file I use to start the installation is a little
> bit different:
> name="OpenSuse11"
> memory=2048
> disk =
> ['phy:/dev/loop0,hdc:cdrom,r','file:/mnt/xen/vmstore/opensuse11/opensuse11.
> img,xvda,w' ]
> vif = [ 'type=ioemu, mac=00:16:3e:00:00:21, bridge=xenbr0' ]
> vfb = [ "type=vnc,vncunused=1,vnclisten=0.0.0.0,keymap=it" ]
> kernel = "/mnt/xen/kernel/opensuse/vmlinuz-xen"
> ramdisk = "/mnt/xen/kernel/opensuse/initrd-xen"
> vcpus=1
> on_reboot = 'restart'
> on_crash = 'restart'
>
Looks ok.
> > even though the config is
> > using hdc/hda instead of xvdc/xvda. I'm assuming you changed
> > bridge=eth0, and kernel= and ramdisk= to the names on your system.
>
> Of course.
>
> > How is this method working out for you? Network and resolution ok?
>
> You already know the answer now..
>
> > Keep answers for this install separate from the hvm problems we are
> > working on. This gets confusing enough to keep track of as is.
>
> Of course. Just in case, I will open another discussion on that.
Good idea.
_______________________________________________
Xen-users mailing list
Xen-users@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-users
|
Home