Unable to get Guest / DomU Login Screen on XEN

From WBITT's Cooker!

Revision as of 10:21, 14 March 2011 by Kamran (Talk | contribs)
Jump to: navigation, search

There was a strange problem I faced, while creating a custom CD out of CENTOS 5.5 32 bit and 64 bit distributions. The problem was, that any VM installed using those distributions, failed to show a login prompt when accessed through "virsh console guest" or "xm console guest" commands. After spending significant time searching for the mysterious reason, both the cause and the solution was found. Thanks to the links mentioned in the references section.

The symptoms and the problem

The problem was experienced when a guest OS is installed using command line tools such as "virt-install", without using any graphics or vnc console, in pure headless mode. The installation completes without a problem, interacting with the user completely/fully through the CLI/text interface. When the system reboots, the console shows the system boot up of the virtual machine, and stops right after the last service is started (sometimes SSH, or crond), and stops without displaying a login prompt. When the virtual machine is tried to be accessed through "virsh console guest" or "xm console guest" commands, the login prompt does not show up. The system seems to be stuck. However, the same system (virtual machine) is accessible through SSH. (One can find the IP of the newly installed machine from the /var/log/messages of the physical host, or the dhcp server). Any other services on this VM are perfectly accessible through it's IP. This proves that the only problem is with the login prompt.

This link helped me obtain a login prompt on the virtual machine, manually.

The login prompt was not showing up, because the files /etc/inittab and /etc/securetty were not updated. The /etc/inittab was supposed to have the following line in it:

co:2345:respawn:/sbin/agetty xvc0 9600 vt100-nav

The xvc0 console (XEN Virtual Console) should also be listed in /etc/securetty file.

xvc0
. . . 
. . . 

dmesg revealed that xvc0 is installed correctly as the system console in this VM. Here is what dmesg reveals, when executed on the VM:

vm1 ~]# dmesg | grep console
netconsole: not configured, aborting
Xen virtual console successfully installed as xvc0
XENBUS: Device with no driver: device/console/0

So what prevented/stopped these lines to be appearing in these files? Or, in other words, what is the process which must run, so these lines can appear in /etc/inittab and /etc/securetty?

It turned out that kudzu was not installed on this VM. The VM in question here was installed using a custom CD. This CD did not include kudzu rpm in it. In-turn kudzu did not get installed on this VM, nor did it get started at the VM's system startup. It was later found and solved from this link:

.... Kudzu automatically adds an entry for xvc0 to /etc/inittab if /dev/console and /dev/xvc0 represent the same device (which is the case if xvc0 is the primary or only console device). If you use a virtual framebuffer device, this will not be the case, and an xvc0 entry will not be added to /etc/inittab....

The Solution

As noted above, the problem occurs in the absence of kudzu rpm and the kudzu service, on the virtual machine. When kudzu rpm is installed on the VM, along with it's dependencies, it updates the /etc/inittab and /etc/securetty files.

References

Personal tools