On Sun, Nov 05, 2006 at 07:06:07PM +0000, Robin Bowes wrote:
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.
[snip]
# 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
If you want it to reliably persist across reboots then the semanage tool
is very handy:
# ls -lZ /dev/xvc0
crw--w---- root tty root:object_r:device_t /dev/xvc0
# semanage fcontext -a -t tty_device_t -f -c /dev/xvc0
# restorecon /dev/xvc0
# ls -lZ /dev/xvc0
crw--w---- root tty system_u:object_r:tty_device_t /dev/xvc0
I opened a bug about the SELinux policy problem - bz 213277
Regards,
Dan.
--
|=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=|
|=- Perl modules:
http://search.cpan.org/~danberr/ -=|
|=- Projects:
http://freshmeat.net/~danielpb/ -=|
|=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=|