Console Hang On Boot Using 2.6.18-1.2200.fc5xenU

[Stan Larson]

Sorry if this is a repeat.  I haven't found searchable archives for this 
forum yet.

1.  I installed FC5 + xen on a base system and performed "yum -y upgrade".
2.  I then created and booted a DomU using the original FC5 disk.  So 
far, so good.
3.  In the DomU, I performed "yum -y upgrade" and rebooted the DomU 
using the new kernel, 2.6.18-1.2200.fc5xenU.

The DomU boots OK, but returns control or starts a shell.  The console 
starts all services and then just hangs.  I can ssh into the domain  
from another window and all is well.  If I break from the console using 
CRTL-] and then return using xm console, I'm still stuck.  If I boot to 
the old kernel (the one provided by the FC5 install disk, aka 
2.6.15-1.2054_FC5xenU) the problem doesn't occur.

Any suggestions?

[Mike Freemon]

Was there any responses on this email from 10/17?  I'm seeing the same 
problem on my system:

# uname -a
Linux grids1 2.6.18-1.2200.fc5xen0 #1 SMP Sat Oct 14 17:49:47 EDT 2006 i686 
i686 i386 GNU/Linux

# rpm -qa|grep xen
kernel-xenU-2.6.18-1.2200.fc5
xen-3.0.3-1.fc5
kernel-xen0-devel-2.6.18-1.2200.fc5
kernel-xenU-devel-2.6.18-1.2200.fc5
kernel-xen0-2.6.18-1.2200.fc5

- Mike

At 10/17/2006 10:14 AM  Tuesday, Stan Larson wrote:
> Sorry if this is a repeat.  I haven't found searchable archives for this 
> forum yet.
> I installed FC5 + xen on a base system and performed "yum -y upgrade".
> I then created and booted a DomU using the original FC5 disk.  So far,
>
> so good.
> 3.  In the DomU, I performed "yum -y upgrade" and rebooted the DomU using 
> the new kernel, 2.6.18-1.2200.fc5xenU.
>
> The DomU boots OK, but returns control or starts a shell.  The console 
> starts all services and then just hangs.  I can ssh into the domain
> from another window and all is well.  If I break from the console using 
> CRTL-] and then return using xm console, I'm still stuck.  If I boot to 
> the old kernel (the one provided by the FC5 install disk, aka 
> 2.6.15-1.2054_FC5xenU) the problem doesn't occur.
>
> Any suggestions?
>
> --
> Stan Larson
> I/S Manager
> Freedom Sales & Marketing
> P: [phone]
> F: [phone]
> [e-mail]
> www.freedomics.com
>
> --
> Fedora-xen mailing list
> [e-mail]
> https://www.redhat.com/mailman/listinfo/fedora-xen

[Daniel P. Berrange]

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.
> # uname -a
> Linux grids1 2.6.18-1.2200.fc5xen0 #1 SMP Sat Oct 14 17:49:47 EDT 2006 i686 
> i686 i386 GNU/Linux
>
> # rpm -qa|grep xen
> kernel-xenU-2.6.18-1.2200.fc5
> xen-3.0.3-1.fc5
> kernel-xen0-devel-2.6.18-1.2200.fc5
> kernel-xenU-devel-2.6.18-1.2200.fc5
> kernel-xen0-2.6.18-1.2200.fc5
>
> At 10/17/2006 10:14 AM  Tuesday, Stan Larson wrote:
> > Sorry if this is a repeat.  I haven't found searchable archives for this 
> > forum yet.
> > I installed FC5 + xen on a base system and performed "yum -y upgrade".
> > I then created and booted a DomU using the original FC5 disk.  So far,
> >
> > so good.
> > 3.  In the DomU, I performed "yum -y upgrade" and rebooted the DomU using 
> > the new kernel, 2.6.18-1.2200.fc5xenU.
> >
> > The DomU boots OK, but returns control or starts a shell.  The console 
> > starts all services and then just hangs.  I can ssh into the domain
> > from another window and all is well.  If I break from the console using 
> > CRTL-] and then return using xm console, I'm still stuck.  If I boot to 
> > the old kernel (the one provided by the FC5 install disk, aka 
> > 2.6.15-1.2054_FC5xenU) the problem doesn't occur.

Regards,
Dan.

[Adrian Chadd]

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.

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.

michelle:~# uname -a
Linux michelle 2.6.18-1.2200.fc5xenU #1 SMP Sat Oct 14 18:06:38 EDT 2006 i686 GNU/Linux
michelle:~# cat /etc/debian_version
3.1
michelle:~#

Adrian

[Robin Bowes]

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.

[Daniel P. Berrange]

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.