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.