OMAP-L137 MV_PRO_5.0 kernel login

That is a bit unusual, you should only need root with no password, and it is unlikely that the /etc/passwd file was corrupted on its own, particularly since you are seeing a variety of other unusual messages. To get into this further, I would verify your permissions over the NFS mounted region on your host, as well as your NFS export settings and your boot arguments.

If you can post your /etc/exports file from your host Linux machine, and the output of printenv from U-Boot we might be able to uncover the root of the issue.

The host computer linux-lap host interface 169.254.2.2  running tftp nfsd dhcpd.  to the target 169.254.1.2

 linux-lap:/etc # cat exports
/home/mnolin/nfs        *(rw,no_root_squash,no_all_squash,sync) 169.254.1.1(rw) 169.254.1.2(rw)
/tftpboot/mnolin        169.254.1.1(ro) 169.254.1.2(ro) *(fsid=0,ro,root_squash,sync,no_subtree_check)

U-Boot > printenv
bootdelay=3
baudrate=115200
ethaddr=00:0e:99:02:f7:4a
filesize=2740C7
fileaddr=C1180000
serverip=169.254.2.2
nfshost=169.254.2.2
bootfile=uImage
bootcmd=dhcp;tftp;bootm
ipaddr=169.254.1.2
init=/sbin/init
rootpath=/home/mnolin/nfs
bootargs=console=ttyS2,115200n8 noinitrd rw ip=169.254.1.2 root=/dev/nfs nfsroot=169.254.2.2:/home/mnolin/nfs,nolock mem=32M
stdin=serial
stdout=serial
stderr=serial
ver=U-Boot 1.3.3 (Apr 23 2009 - 17:32:00)

Environment size: 438/16380 bytes

using 'chmod -R 777' on dev lib/modules and etc cleaned up many of the 'Permissions'  warnings and allowed for ssh_host_keys and modules.dep to be created.

'login: root'  no longer prompts for a password but returns 'Login incorrect'

unable to resolve "Cleaning /tmp /var/lock /var/run chgrp changing  group of /var/run/utmp': Operation not permitted.

That is one step forward, usually I don't see permissions problems with the target filesystem on the host, but it is possible. The most common problem I see is not untarring the filesystem as root since it needs to make symbolic links but it seems you don't have that particular problem. Just as a test you may want to give all permissions to the entire target filesystem to see if that changes at all how the board boots.

Michael Nolin said:

 linux-lap:/etc # cat exports
/home/mnolin/nfs        *(rw,no_root_squash,no_all_squash,sync) 169.254.1.1(rw) 169.254.1.2(rw)
/tftpboot/mnolin        169.254.1.1(ro) 169.254.1.2(ro) *(fsid=0,ro,root_squash,sync,no_subtree_check)

Usually I do not restrict the NFS mounts to specific address ranges in the /etc/exports for filesystems boards will be mounting (though in my case the board IP addresses tend to be DHCP assigned by a DHCP server I don't control). I am not sure I follow your first line for /home/mnolin/nfs, it seems like you have both the * for all accessors and ip addresses specifically, though if it was truly bad syntax you would be running into other issues. If it is acceptable to your network you might try something more open like just:

/home/mnolin/nfs        *(rw,no_root_squash,no_all_squash,sync)

That is the form I typically use for target NFS mount points.

I am also not certain why you are sharing the /tftpboot/mnolin region as a NFS mount point, it should not hurt anything, but it is not necessary for booting the board via TFTP/NFS.

The bootargs value in U-Boot looks ok.

Searching these forums for 'login'  I found a relevant discussion from 2009:

I have added this line in the inittab file:

1:2345:respawn:/bin/login -f root console

Minicom console now presents a "Welcome to Monta..."   and a prompt. ssh login works with no password prompt.