Crond Appears To Hang In Xen

I recently decided to spend the money to buy a home server. (I got an Atom 330 and a 64GB SSD in case you were wondering.) In the name of security I decided to use Xen to separate the applications that would be running on it. So I installed OpenSSH to control it remotely. Then, I installed Xen. Finally, I initialized a new block device and installed an operating system to act as the first guest OS on the machine.
I booted up the guest OS and everything was working fine. That is, until after crond (the equivalent of the task scheduler if you only know Windows) started up. I saw the crond boot message and that was the last of it. Nothing after that. Not even the login prompt. While the reason to this seems obvious to me now, I became quite confused at that time.
So I asked Google to find a solution for me. It would appear that quite a number of people had the same problem. I read a few questions about it on forums but not many responses gave a working solution. I then found a couple of blog posts that did work, but I don’t quite understand how they worked.

http://www.nulynx.com/xen-boot-hangs-at-crond/
http://shell.burgas.org/2009/06/debian-xen-domu-hangs-at-crond/

For a default installation of Debian 5, placing

extra = ‘console=hvc0 xencons=tty

into the guest’s configuration file worked. Then it broke when I wanted to use a custom configured kernel. When I changed the kernel, I was back to the original problem.
That whole day I worked my brain to figure out what was wrong while I was at work. Why did the default installation not work? Why did that configuration change make it work? Why did it not work when I used a different kernel? I realized the simple truth is that the console you see in xm is not tty1. The Xen console it not a tty at all. It’s a separate device called hvc0. The reason why I did not see a login prompt is because getty is only setup to for ttys, and my custom kernel must be interpreting those arguments in a dissimilar manner.
So the solution was to simply get getty to start up on the hvc0 device. That was something I knew how to do from experience. Edit the inittab file! Add this line:

hvc:2345:respawn:/sbin/getty 38400 hvc0

That’s the same line as is used for tty1 with the id and device name changed.
Now the system is setup explicitly to startup getty on the xen console, and no need for any hackish kernel arguments. The ttys are actually devoted to interacting with the virtualized frame buffer. If you are not using the vfb you may as well comment out the tty getty lines, but leave them in there if you do intend to use the vfb.

Advertisements

~ by lunaticexperimentalist on August 28, 2009.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

 
%d bloggers like this: