Adrian Chadd wrote: > On Thu, Nov 02, 2006, Daniel P. Berrange wrote: >> On Thu, Nov 02, 2006 at 05:15:56PM -0600, Mike Freemon wrote: >>> Was there any responses on this email from 10/17? I'm seeing the same >>> problem on my system: >> I posted a reply to the same problem reported in another thread - I mised >> this thread originally. The solution is to install new kudzu in the DomU >> from updates-testing. This new kudzu ensures that the agetty process gets >> spawned on the xvc0 console as well as the paravirt framebuffer. What version is this? I don't see any upgrades available for kudzu on updates-testing: # rpm -q kudzu kudzu-1.2.34.5-1 # yum --enablerepo=updates-testing upgrade kudzu ... Could not find update match for kudzu No Packages marked for Update/Obsoletion > If you're like me and run non-Redhat guests under FC5 + redhat xen kernels > you'll have to do it maunally: > > /etc/inittab: (assuming you're using getty and not already using 'co' > in your inittab) > > co:2345:respawn:/sbin/getty 38400 xvc0 > > and add xvc0 to /etc/securetty so you can login as root on the console. /etc/inittab contains: # Run gettys in standard runlevels co:2345:respawn:/sbin/agetty xvc0 9600 vt100-nav xvc0 is in /etc/securetty I see this in the console: Starting HAL daemon: [ OK ] INIT: Id "co" respawning too fast: disabled for 5 minutes INIT: no more processes left in this runlevel INIT: Id "co" respawning too fast: disabled for 5 minutes INIT: Id "co" respawning too fast: disabled for 5 minutes Ah, this looks like an SELinux issue: # audit2allow -i /var/log/audit/audit.log -l allow getty_t device_t:chr_file getattr; This fixes it: chcon --reference=/dev/tty0 /dev/xvc0 or chcon -t tty_device_t /dev/xvc0 R. -- Fedora-xen mailing list Fedora-xen@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-xen
