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?

-- 
Stan Larson
I/S Manager
Freedom Sales & Marketing
P: [phone]
F: [phone]
stan(a)freedomics.com
www.freedomics.com

[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.
>
> 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?
>
> --
> Stan Larson
> I/S Manager
> Freedom Sales & Marketing
> P: [phone]
> F: [phone]
> stan(a)freedomics.com
> www.freedomics.com
>
> --
> Fedora-xen mailing list
> Fedora-xen(a)redhat.com
> 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.
>  >
>  >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. 
Regards,
Dan.
-- 
|=- Red Hat, Engineering, Emerging Technologies, Boston.  [phone] -=|
|=-           Perl modules: http://search.cpan.org/~danberr/              -=|
|=-               Projects: http://freshmeat.net/~danielpb/               -=|
|=-  GnuPG: 7D3B9505   F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505  -=|

[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.
-- 
|=- Red Hat, Engineering, Emerging Technologies, Boston.  [phone] -=|
|=-           Perl modules: http://search.cpan.org/~danberr/              -=|
|=-               Projects: http://freshmeat.net/~danielpb/               -=|
|=-  GnuPG: 7D3B9505   F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505  -=|