Re: [SSI-devel] Problems booting 2nd node for the first time

[Brian J. W. <Bri...@hp...>]

Goetzman, Dan wrote:

>>Hello SSI developers,
>>
>> You all may have seen my posting yesterday about booting my SSI cluster
>>(using CFS) on the second node directly from the shared storage and not
>>etherboot. Well, today I decided to go ahead and just boot as the install
>>docs show, using etherboot. I might try the GFS option after I have my CFS
>>based cluster booted and running.
>>
>> I followed the docs and setup a etherboot floppy. When I booted it failed
>>on the tftp part. A quick look revealed;
>>
>> 1) No /tftpboot dir
>> 2) No /tftpboot/vmlinuz
>>
>> I created the /tftpboot. I had to look around a bit and read up on
>>etherboot before I finally figured out that I needed to create a network
>>boot image via mknbi-linux. Looks like maybe "cluster_lilo" would do this
>>had I run it? The install docs only described running the regular old
>>lilo. Hmm...
>>
The addnode command should run cluster_lilo for you.

The reason the docs only say to run lilo in the beginning is because 
you're still running on a non-SSI kernel at that time. The cluster_lilo 
command depends on process migration.


>> Name server registered with clms
>> ipcname_read complete
>> Mounting root in linuxrc
>> Unmounting /proc
>> Attempting pivot_root
>> Running post-root cluster initialization
>> Starting init
>>
>> And it HANGS there forever...
>>    
>>

Can you give us a kernel backtrace? Enter kdb by pressing the Break key 
on a physical console (Ctrl-A on a serial console). Get the backtrace 
for init by entering the following:

kdb> btp 1

If init is blocking on a wait() call, see what children it has:

kdb> ps

See what the children's backtraces are with btp:

kdb> btp <pid>

When you're done, you can reboot:

kdb> reboot

Hope this helps,

Brian