On 10 November 2011 00:15, jim burns <jim_burn@xxxxxxxxxxxxx> wrote:
> You probably want BALLOON set. In a dom0,
> you would have various BACKENDs set (not shown, probably because the names are
> different in 2.6.37), and you would also want EVTCHN & GNTDEV set.
Yes, and they are actually compiled in the dom0 kernel. balloon is compiled too.
> You can
> probably get away without these in a domu. Not sure about PLATFORM_PCI -
> definitely required in a pv domu for pci passthrough to work. Not sure what an
> hvm domu needs for passthrough.
Don't worry about that, becouse I cannot do so much with the passthrough.
>
> Your modprobe errors for xennet and xenblk are probably because opensuse
> expects those names (xenlinux) instead of the newer names (pvops). They can be
> ignored if your FRONTENDS are builtin.
As a matter of fact, I don't know if I can, because the network
doesn't work. Or, even
better, the IP address is going to be assigned during the boot but I
can't ping the two
hosts (domU and dom0) each other.
> Look in /etc/sysconfig/kernel, on the
> line with the variable DOMU_INITRD_MODULES. Another interesting file is
> /etc/sysconfig/bootloader, where you set defaults for menu.lst.
Yes, I've seen.
> Interesting - otherwise, it's exactly the same as what Fajar posted. Try this
> - edit /etc/init.d/boot.local, and add the line 'modprobe cirrusfb', and
> reboot. That will execute before any of the services start up.
Yes, the module is loaded, but the lspci result is still the same. No
driver mentioned.
>> 2) if I delete the kernel line and I leave only the two following
>> (i.e. the kernel and the
>> initrd lines) the domU doesn't start.
>
> I'm assuming you changed 'module vmlinuz...' to 'kernel vmlinuz...', and
> 'module initrd.../initramfs...' to 'initrd initrd.../initramfs...'.
Yes.
> (Systems
> that use dracut to run the boot process use initramfs instead of initrd.
> Opensuse 11.4 (where 2.6.37 came from) doesn't use dracut.) In other words,
> with opensuse's habit of providing the symlinks vmlinuz and initrd pointing to
> the actual binaries in /boot, your grub entry would be similar to:
>
> title openSUSE
> root (hd0,1)
> kernel /vmlinuz root=/dev/system/root resume=/dev/system/swap showopts
> vga=0x31a CPUFREQ=no
> initrd /initrd
>
> if you use lvm. Since you don't, replace /dev/system/... with /dev/sda,
> /dev/sdb, etc. as appropriate. And make sure the first 'root' option is right.
> '(hd0,1)' as shown would be /dev/sda2, where /boot lives. If /boot is not on a
> separate partition from /, then '/vmlinuz' becomes '/boot/vmlinuz', etc.
OK.
Then, what I have done now is:
1) install again kernel-xen package.
I noticed a strange fact: the new entry that has been created in the
menu.lst is the
following:
title Xen -- openSUSE 11.4 - 2.6.37.6-0.9
root (hd0,1)
kernel /boot/vmlinuz-2.6.37.6-0.9-xen
root=/dev/disk/by-id/ata-QEMU_HARDDISK_QM00001-part2
resume=/dev/disk/by-id/ata-QEMU_HARDDISK_QM00001-part1 splash=silent
quiet showopts vga=0x314
initrd /boot/initrd-2.6.37.6-0.9-xen
The last time I installed kernel-xen, there was also the xen.gz entry.
2) I tried to reboot with this new xen kernel but, after selecting the
kernel above Grub says:
Error 13: Invalid or unsupported executable format
And that is the same error I got previously when I made the change
described in a
previous e-mail, as regard the menu.lst file.
3) I booted again with the previous working kernel and made the
modification you
suggested to me, making the new grub xen entry like the following:
title Xen -- openSUSE 11.4 - 2.6.37.6-0.9
root (hd0,1)
kernel /boot/vmlinuz-2.6.37.6-0.9-xen root=/dev/sda2
resume=/dev/sda2 splash=silent quiet showopts vga=0x314
initrd /boot/initrd-2.6.37.6-0.9-xen
4) reboot with the kernel above and I get the same error at point 2.
> Interesting - you definitely get the cirrus xorg module being selected, along
> with the other candidates fbdev and vesa. After the card is initialized, fbdev
> and vesa are unloaded, in favor of the better candidate cirrus. What surprises
> me if that the 'lspci' output you posted didn't have the *kernel* module
> driver cirrusfb. I didn't think the xorg module cirrus would work without the
> kernel module driver cirrusfb.
Maybe it works thanks to the vesa generic driver.
> Also, Xorg.0.log is clearly only supporting
> 800x600 and 640x480, as opposed to the extra resolution Fajar posted -
> 1024x768. Hopefully, the modprobe I asked you to put in /etc/init.d/boot.local
> will sort this out. Post 'lspci -vvv -s 00:02.0' after you make that change.
OK, I answered to this, before...
>
>> In conclusion, I am aware that what I am doing is not properly
>> correct, and I would
>> simply be able to install a rpm kernel without compiling a new one
>> every time, because
>> it is something insane.
>> I've found this: http://forum.3tera.com/showthread.php?t=2161
>
> Yeah - that's pretty old.
And the downloads are no longer available :(
Thanks a lot,
--
Flavio
_______________________________________________
Xen-users mailing list
Xen-users@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-users
|
Home