Hi,
I finally got xen to work properly by creating initrd by hand, so thanks to all the people who helped me out last time. Now I have another issue. The centos guest is hanging just before the login prompt comes up, and I also notice that udev is failing initially itself. I am using the images from jailtime.org.
I created the mkinitrd by using the command below. Is there anything I should add?
mkinitrd -f --with=xennet --builtin=aic7xxx --builtin=serverworks --preload=xenblk --omit-raid-modules --omit-lvm-modules --fstab=myfstab /boot/lxxen-initrd.img 2.6.19-1.2895.fc6xen"
Thanks.
Update on this:
I was able to login to the domU using sshd, and found that it was the nash-hotplugd that's using 99% of the cpu, and I think this is what's interfering with the udevd and also making the mingetty not appear on the console. So how do I turn off nash-hotplugd in the initrd?
thanks.
Hello:
It seems
------------------ - scrub another possible error message from dmraid output * Mon Feb 13 2006 Bill Nottingham <notting(at)redhat.com> 8.28-1 - kill nash-hotplug before starting udev (<pjones(at)redhat.com>) ------------------
It appears you need to kill nash-hotplug before you start udev, but I think the kill is failing and the something is screwing up nash-hotplug to consume a lot of cpu. So how do I kill nash-hotplug before starting udev?
Thanks.
Allright, I think I got the issue. I am trying to boot a centos 4.1 on a fc6. Now fc6 initrd, even the custom created one, has nash-hotplugd, which has to be killed before starting udev, but this logic is not there in the initscripts of centos-4.1. So I have to basically hand craft an initrd that will kill off this nash-hotplug in the initrd itself, if it has to work with all the older distros.
This is too much work, to tell the truth. I will test with fc6 guest on fc6 and report back.
On Fri, 2 Feb 2007, K T Ligesh wrote:
Allright, I think I got the issue. I am trying to boot a centos 4.1 on a fc6. Now fc6 initrd, even the custom created one, has nash-hotplugd, which has to be killed before starting udev, but this logic is not there in the initscripts of centos-4.1. So I have to basically hand craft an initrd that will kill off this nash-hotplug in the initrd itself, if it has to work with all the older distros.
I don't think that is the reason for not getting a login prompt. The nash-hotplug can be annoying. I've had to kill it in the past too. I infact disable hotplay/udev on those older images, and just use a MAKEDEV and create the devices I need,
To fix your login problem do this:
mount -o loop centosfs dir cd dir
(or login via ssh to the running centos box)
cd dev ; /dev/MAKEDEV null zero random urandom console tty pty hda xvd loop (this uses the MAKEDEV script in the /dev/ of dom0 to create nodes in the /dev of the guest image)
mknod dev/xvc0 c 25 187 (cause there is some confusion about which major/minor to use)
edit inittab and change the mingetty for tty2 to xvc0, eg:
2:2345:respawn:/sbin/mingetty xvc0
(change tty2 not tty1 because in a normal "working" situation, tty1 will be mapped to the xen virtual console already, you do not want to break that)
And do:
echo "xvc0" >> etc/securetty (to allow root logins)
I also made a xenU ramdisk for my images, on dom0:
mkinitrd /boot/initrd-2.6.18-1.2849.fc6xenU.img --with=xennet --preload=xenblk
(again note to redhat: PLEASE include xennet/xenblk in the xen ramdisk, even if the dom0 strictly does not need it. It will allow everyone to re-use the same initrd when not using pygrub with disk images, but kernel=/ramdisk= statements with a rootfs)
Paul
On Fri, Feb 02, 2007 at 02:10:24AM +0100, Paul Wouters wrote:
On Fri, 2 Feb 2007, K T Ligesh wrote:
Allright, I think I got the issue. I am trying to boot a centos 4.1 on a fc6. Now fc6 initrd, even the custom created one, has nash-hotplugd, which has to be killed before starting udev, but this logic is not there in the initscripts of centos-4.1. So I have to basically hand craft an initrd that will kill off this nash-hotplug in the initrd itself, if it has to work with all the older distros.
(or login via ssh to the running centos box)
cd dev ; /dev/MAKEDEV null zero random urandom console tty pty hda xvd loop (this uses the MAKEDEV script in the /dev/ of dom0 to create nodes in the /dev of the guest image)
mknod dev/xvc0 c 25 187 (cause there is some confusion about which major/minor to use)
edit inittab and change the mingetty for tty2 to xvc0, eg:
2:2345:respawn:/sbin/mingetty xvc0
(change tty2 not tty1 because in a normal "working" situation, tty1 will be mapped to the xen virtual console already, you do not want to break that)
And do:
echo "xvc0" >> etc/securetty (to allow root logins)
I also made a xenU ramdisk for my images, on dom0:
mkinitrd /boot/initrd-2.6.18-1.2849.fc6xenU.img --with=xennet --preload=xenblk
(again note to redhat: PLEASE include xennet/xenblk in the xen ramdisk, even if the dom0 strictly does not need it. It will allow everyone to re-use the same initrd when not using pygrub with disk images, but kernel=/ramdisk= statements with a rootfs)
Yeah, I did that. So now xen uses xvc0 and not the ttyS0? That's actually good news, since that means that the tty is now freed up?
Thanks.