Description of problem: Fedora 16-x86_64 TC2 xen Dom0 hangs on reboot with black screen. Issue seems to be related to xenconsoled since when the service is stopped manually with 'service xenconsoled stop' system reboots fine Version-Release number of selected component (if applicable): kernel-3.1.0-0.rc6.git0.3.fc16.x86_64 xen-4.1.1-3.fc16.x86_64 xen-runtime-4.1.1-3.fc16.x86_64 How reproducible: Steps to Reproduce: 1. Install Fedora 16-x86_64 TC2 2. Install and boot xen 3. ensure xend/xenstored/xenconsoled running 4. reboot Actual results: Black screen If start switching consoles I can see this message on the first console: rpcbind terminating on signal. Restarting with "rpcbind -w" System not responding Expected results: Sending SIGTERM to remaining processes.... REBOOT Additional info: All packages are updated after installation.
The system will shut down if you wait long enough (several minutes). The problem is that the xen and libvirt (if you have it installed) processes need to be shut down in the right order, for example xenstored needs to be running to allow both xenconsoled and libvirt-guests to be shut down, though I think there are further dependencies. Currently systemd doesn't know about these dependencies, so doesn't shut down the processes down in the right order, and therefore hangs at various stages until each times out. You can fix the xenstored/xenconsoled dependency by editing /etc/rc.d/init.d/xenconsoled and replacing the line # Required-Stop: $syslog $remote_fs with # Required-Stop: $syslog $remote_fs xenstored
Though it didn't work for me the exact way you mentioned (system still didn't reboot properly with xenstored in Required-Stop list). But I've found that using xencommons instead of xenstored/xenconsoled solved the issue. So the proper way to fix this in my case was: chkconfig --add xencommnos (btw this service isn't initially in chkconfig) chkconfig xenconsoled off chkconfig xenstored off
I hope this has been fixed from xen-4.1.1-6 and onwards (without enabling the xencommons script). Are you still seeing the problem?
This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component.
As in comment 4 this should now be fixed.