If you are interested in replying, pls CC: me, as I am not subscribed to the
list.
Since upgrading to F15, I have been unable to start my hvm winxp guest.
The default kernel after a yum update is 2.6.38.6-27.fc15.x86_64. 2.6.38 would
not be expected to start a guest, since it has no net and block backends.
However, I found that the boot process hung around the time that the desktop
was about to be started. Adding either '3' or 'nomodeset' to the end of the
'module' line for the kernel in grub.conf allows booting to complete. However,
I find that '3' is preferable to 'nomodeset', as the console blanks, and
becomes unusable with 'nomodeset'. '3' of course doesn't even try to start the
desktop, but doesn't affect the fedora 'vncserver' service.
Once started up, as expected, starting my winxp guest resulted in a complaint
about not being able to start a block device. (Yeah, I saw Fajar's tip about
using http://git.kernel.org/?p=linux/kernel/git/konrad/xen.git in the '[Xen-
users] kernel-2.6.39' thread this month. Thanx.)
I have been using xen on fedora since f7; first with their xenified kernels
even into f9, then with jeremy's git, then settling on myoung's prebuilt dom0,
which has been stuck on 2.6.32 for some time now. That isn't a problem for
device drivers for me, but presents major headaches with using fedora's new
replacement for init/upstart, called systemd, which relies heavily on cgroups.
Apparently, myoung's 2.6.32 doesn't setup cgroups the way 2.6.38 does, if at
all.
Systemd starts all service required sockets first, then automatically starts a
service when the socket receives input. It also starts all 'chkconfig'
configured services for your runlevel in parallel, with appropriate
dependencies so that a service doesn't start till the services it depends on
have started. This means that services may not start up in exactly the same
order that you are used to on previous fedoras based on their rc.d priority
numbers. That makes debugging what went wrong when your boot hangs difficult.
I tried disabling the last few services that printed on the console, and it
always seemed to hang at something beyond the last service that printed on the
console. After a long time, you would get messages about avahi failing, then
the network service itself, which wouldn't make for a very usable system even
if it had finished booting. Apparently systemd's dependency based service
starting was hanging somewhere, and no amount of placing debug msgs in various
services was helping.
I also noticed under 2.6.38 that /var/log/messages was not being logged to.
Only the console was getting the syslog, which at least in runlevel 3 was not
being obscured by a desktop. Finally, in annoyance, I reverted to using the
previous logger on my system, rsyslog, with 'chkconfig rsyslog on'. This,
interestingly enough, passed the request to systemd, and converted the request
to 'rm'-ing the existing logging service in /etc/systemd, and copying the ones
for rsyslog from /lib/systemd to /etc/systemd. (I believe the way to revert to
the default behavior is 'systemctl enable systemd-kmsg-syslogd.service', but
I haven't had an opportunity to try it yet.)
Lo and behold, the next boot into 2.6.32 completed successfully, and without
having to disable runlevel 5. You get a bunch of errors in dmesg(1) about
systemd-{kmsg-syslogd,logger}.service not starting, and a bunch of errors on
the boot console corresponding to the time those services don't start
referring to cgroups. (Things go by much more quickly on the boot console with
systemd than you may be used to!) Apparently, those services are more
sensitive to cgroups not being setup by 2.6.32. Systemd itself is still
running, starting and stopping services dynamically as needed.
Now, tho', I still can't start my winxp vm. Qemu-dm-winxp.log complains,
sometimes repeatedly, about:
xen be: console-0: xen be: console-0: initialise() failed
initialise() failed
and xend.log simply informs me that the domain rebooted, and restarting has
been disabled to prevent loops.
F15 updates xen to 4.1.0.
Some other minor irritants: For some reason, the tun kernel module is not
being loaded automatically. Nothing in /etc/{udev,modprobe.d} would suggest
why. I just load it in /etc/rc.modules. And don't even get me started on
selinux - it's gong crazy. It's like they ripped all the rules for xen out of
selinux. This is the first fedora release that is actively hostile to xen, as
opposed to indifferent to it, since F9. (Get to know audit2allow / checkmodule
/ semodule_package / semodule - they are your friends!)
I hate major upgrades! When I upgraded my suse system to openSuSE 11.4, my
iscsi target stopped working, and I had to learn the new way of setting it up.
Of course, that target is where my winxp disk lives!
Oh well, hope this helps people to know what to expect on F15, and maybe
someone will come up with a workaround, or myoung will update his
configuration to run on F15.
_______________________________________________
Xen-users mailing list
Xen-users@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-users
|
Home