Fedora xen - Oct 2006 - Console Hang On Boot Using 2.6.18-1.2200.fc5xenU

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: (727) 835-1150
F: (727) 835-1151
stan@freedomics.com
www.freedomics.com

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: (727) 835-1150
>F: (727) 835-1151
>stan@freedomics.com
>www.freedomics.com
>
>--
>Fedora-xen mailing list
>Fedora-xen@redhat.com
>https://www.redhat.com/mailman/listinfo/fedora-xen

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.  +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  -=|

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

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.

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  -=|