inittab is not executing after my Linux box boots up

[premdas.prajosh@gmail.com (Prajosh Premdas)]

Hi

I have copied the generated rsa key and placed it in my nfs root filesystem.
I find the problem still persists

Please see the last leg of the logs below

*eth0: link up (100/Full)*
*VFS: Mounted root (nfs filesystem) on device 0:12.*
*Freeing init memory: 128K*
*Starting network...*
*ip: RTNETLINK answers: File exists*
*Starting dropbear sshd: OK*
*
*
I feel the already generated key has been detected. And still the
initab doesn't execute. Please advice

On Tue, Jun 21, 2011 at 11:15 AM, Vladimir Murzin <murzin.v@gmail.com>wrote:

> On Mon, Jun 20, 2011 at 10:24 AM, Prajosh Premdas
> <premdas.prajosh@gmail.com> wrote:
> > Hi Dave and Mulyadi
> > Can you tell me where to place the previously generated RSA key. I even
> > suspected this but this line
> > Starting dropbear sshd: generating rsa key... generating dsa key... OK
> >
> > and the OK pulled me off the track. One more thing can you tell me  what
> > does the OK mean there...
> > My mask is mask=255.0.0.0 so it is able to get the NFS server location
> > I typed a wrong command after changing the commands i find no difference
> > On Sun, Jun 19, 2011 at 11:22 PM, Dave Hylands <dhylands@gmail.com>
> wrote:
> >>
> >> Hi Projish,
> >>
> >> On Sun, Jun 19, 2011 at 8:24 AM, Prajosh Premdas
> >> <premdas.prajosh@gmail.com> wrote:
> >> > Hi
> >> > Please find the entire boot sequence here
> >> > RomBOOT
> >> ...snip...
> >> > TCP cubic registered
> >> > NET: Registered protocol family 17
> >> > rtc-at91sam9 at91_rtt.0: hctosys: unable to read the hardware clock
> >> > IP-Config: Guessing netmask 255.0.0.0
> >> > IP-Config: Complete:
> >> >      device=eth0, addr=10.220.4.200, mask=255.0.0.0, gw=10.220.4.35,
> >> >      host=10.220.4.200, domain=, nis-domain=(none),
> >> >      bootserver=255.255.255.255, rootserver=10.0.0.1, rootpath=
> >> > eth0: link up (100/Full)
> >> > VFS: Mounted root (nfs filesystem) on device 0:12.
> >>
> >> So it looks like your root file system was mounted successfully.
> >>
> >> > Freeing init memory: 128K
> >>
> >> All message from this point onwards come from init.
> >>
> >> > Starting network...
> >> > ip: RTNETLINK answers: File exists
> >> > Starting dropbear sshd: generating rsa key... generating dsa key... OK
> >>
> >> And since sshd is starting, it's actually processing stuff from your
> >> root file system.
> >>
> >> You may want to try disabling ssh. Generating the rsa key can take
> >> several minutes, depending on how fast your target is. So it may look
> >> like the system is hung, but it will actually continue to boot.
> >>
> >> You may want save away the generated RSA key and include it in your
> >> generated image so that this step is faster. For a given filesystem,
> >> it only happens the first time, and once the generated key is stored,
> >> ssh will just use the previously generated key. But if you're
> >> constantly rebuilding your filesystem without any generated keys then
> >> the first time you boot the new filesystem you'lll gget a long delay.
> >>
> >> --
> >> Dave Hylands
> >> Shuswap, BC, Canada
> >> http://www.davehylands.com
> >
> >
> >
> > --
> > Regards,
> >
> > Prajosh Premdas
> >
> > _______________________________________________
> > Kernelnewbies mailing list
> > Kernelnewbies at kernelnewbies.org
> > http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
> >
> >
>
> Hi Prajosh,
>
> I believe, that generating keys by sshd involve blocked operation on
> /dev/random.
> It's strict requirement to use /dev/random instead of /dev/urandom in such
> case.
>
> Actually, it's well-known problem in embedded world to fill up entropy
> pool, because of
> lack random events into some solutions.
>
> I've heard it's  possible to save and restore entropy pool, but it's
> not safe, I think.
> In my opinion, Dave's suggestion about saving keys into image is quite
> suitable, as
> soon as you aren't intend to distribute you solution on the market.
>
> P.S. Sorry for my English.
>



-- 
Regards,

Prajosh Premdas



-- 
Regards,

Prajosh Premdas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20110621/6fcfa7f3/attachment.html