[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-users] OpenSuse 11 hvm domU: screen resolution up to 640x480
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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |