NFS root woes: No init found

NFS root woes: No init found

[Brian Waite]

Hi,
	I am attempting to boot up a custom PPC board and having problems with the
NFS Root. the board has a single 74xx PPC and Galileo memory controller. What
happens is everything looks good until I attempt to read init from the NFS
root. Then I get the message No init found. I have tried the obvious things
such as changing init for a staticly linked executable, to no avail. I have
enabled NFS debug and it looks like I have mounted the remote fs just fine.
In fact, I can remove /dev/console and watch console_init() throw a warning.
Has anyne seen problems with the Galileo's mii ports or any other boards
booting an NFS root filesystem? I am attaching the end of my log below.
Thanks
Brian


NET4: Linux TCP/IP 1.0 for NET4.0
IP Protocols: ICMP, UDP, TCP
IP: routing cache hash table of 8192 buckets, 64Kbytes
TCP: Hash tables configured (established 262144 bind 65536)
gt64260_eth_open : Assigned IRQ 32 to gt64260_eth0
eth0:  link state:
  GT: 100: Link:FD:nFC
 mii:100: Link:FD:nFC ANnc:Manual
Sending DHCP requests ., OK
IP-Config: Got DHCP answer from 192.9.200.220, my address is 192.9.200.246
IP-Config: Complete:
      device=eth0, addr=192.9.200.246, mask=255.255.255.0, gw=255.255.255.255,
     host=seblade2, domain=, nis-domain=(none),
     bootserver=192.9.200.220, rootserver=192.9.200.220, rootpath=/home/ppc
NET4: Unix domain sockets 1.0/SMP for Linux NET4.0.
Root-NFS: Mounting /home/ppc on server 192.9.200.220 as root
Root-NFS:     rsize = 4096, wsize = 4096, timeo = 7, retrans = 3
Root-NFS:     acreg (min,max) = (3,60), acdir (min,max) = (30,60)
Root-NFS:     nfsd port = -1, mountd port = 0, flags = 00000200
Looking up port of RPC 100003/2 on 192.9.200.220
Root-NFS: Portmapper on server returned 2049 as nfsd port
Looking up port of RPC 100005/1 on 192.9.200.220
Root-NFS: mountd port is 32771
NFS:      nfs_mount(c009c8dc:/home/ppc)
VFS: Mounted root (nfs filesystem).
Freeing unused kernel memory: 188k init
Kernel panic: No init found.  Try passing init= option to kernel.
 <0>Rebooting in 180 seconds..

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: NFS root woes: No init found

[Dan Malek]

Brian Waite wrote:

> ...Then I get the message No init found.

First, try using something simple like /bin/bash as your init program.
Trying to start up the init program relies on lots of things being
present in the file system.  If the program starts, and then exits,
you still get this message.

Just use a trivial, simple file system to get started.  A shell,
couple of commands and minimal libraries are easier to debug.

Good luck :-)

	-- Dan


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: NFS root woes: No init found

[Brian Waite]

I did this. I tried to start a staticly linked ash shell to no avail. No libs
are better than any libs :)
Thanks
Brian
On Wednesday 04 December 2002 4:48 pm, Dan Malek wrote:
> Brian Waite wrote:
> > ...Then I get the message No init found.
>
> First, try using something simple like /bin/bash as your init program.
> Trying to start up the init program relies on lots of things being
> present in the file system.  If the program starts, and then exits,
> you still get this message.
>
> Just use a trivial, simple file system to get started.  A shell,
> couple of commands and minimal libraries are easier to debug.
>
> Good luck :-)
>
> 	-- Dan


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: NFS root woes: No init found

[Wolfgang Grandegger]

Hello,

if you get to the bash prompt you could try to start the init program
manually. This should result in more useful error messages.

Hope it helps,

Wolfgang.


On 12/04/2002 11:11 PM Brian Waite wrote:
> I did this. I tried to start a staticly linked ash shell to no avail. No libs
> are better than any libs :)
> Thanks
> Brian
> On Wednesday 04 December 2002 4:48 pm, Dan Malek wrote:
>> Brian Waite wrote:
>> > ...Then I get the message No init found.
>>
>> First, try using something simple like /bin/bash as your init program.
>> Trying to start up the init program relies on lots of things being
>> present in the file system.  If the program starts, and then exits,
>> you still get this message.
>>
>> Just use a trivial, simple file system to get started.  A shell,
>> couple of commands and minimal libraries are easier to debug.
>>
>> Good luck :-)
>>
>> 	-- Dan
>
>
>
>


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: NFS root woes: No init found

[Brian Waite]

I tried loading the ash shell statically linked., along with a dynamically
linked bash. No executables seem to load. I have traced the execve call and
it progresses as far as walking the format list to determine what format the
file is in. After walking all the available formats, it can't find one and
fails. I have the floowing formats in my kernel:
CONFIG_KCORE_ELF=y
CONFIG_BINFMT_ELF=y
CONFIG_KERNEL_ELF=y

and the ash executale is an elf:
ash.static: ELF 32-bit MSB executable, PowerPC or cisco 4500, version 1,
statically linked, stripped

Any thoughts? I see the packets getting revieved by the gt64260_eth driver and
passed up to the higher layers. I also look at the various MIB counters and
see no errant packets so I can't why NFS is so cranky.

Thanks
Brian

On Wednesday 04 December 2002 5:20 pm, you wrote:
> Hello,
>
> if you get to the bash prompt you could try to start the init program
> manually. This should result in more useful error messages.
>
> Hope it helps,
>
> Wolfgang.
>
> On 12/04/2002 11:11 PM Brian Waite wrote:
> > I did this. I tried to start a staticly linked ash shell to no avail. No
> > libs are better than any libs :)
> > Thanks
> > Brian
> >
> > On Wednesday 04 December 2002 4:48 pm, Dan Malek wrote:
> >> Brian Waite wrote:
> >> > ...Then I get the message No init found.
> >>
> >> First, try using something simple like /bin/bash as your init program.
> >> Trying to start up the init program relies on lots of things being
> >> present in the file system.  If the program starts, and then exits,
> >> you still get this message.
> >>
> >> Just use a trivial, simple file system to get started.  A shell,
> >> couple of commands and minimal libraries are easier to debug.
> >>
> >> Good luck :-)
> >>
> >> 	-- Dan
> >


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: NFS root woes: No init found

[Jerry Van Baren]

Thoughts...

Does your mount command
* use the defaults options (-o defaults) or equivalent?
   - includes read/write and execute privileges

Does your host
* have "no_root_squash" (may not be necessary)?
* allow write access to the remote host?

gvb


At 05:30 PM 12/4/2002 -0500, Brian Waite wrote:

>I tried loading the ash shell statically linked., along with a dynamically
>linked bash. No executables seem to load. I have traced the execve call and
>it progresses as far as walking the format list to determine what format the
>file is in. After walking all the available formats, it can't find one and
>fails. I have the floowing formats in my kernel:
>CONFIG_KCORE_ELF=y
>CONFIG_BINFMT_ELF=y
>CONFIG_KERNEL_ELF=y
>
>and the ash executale is an elf:
>ash.static: ELF 32-bit MSB executable, PowerPC or cisco 4500, version 1,
>statically linked, stripped
>
>Any thoughts? I see the packets getting revieved by the gt64260_eth driver and
>passed up to the higher layers. I also look at the various MIB counters and
>see no errant packets so I can't why NFS is so cranky.
>
>Thanks
>Brian
>
>On Wednesday 04 December 2002 5:20 pm, you wrote:
> > Hello,
> >
> > if you get to the bash prompt you could try to start the init program
> > manually. This should result in more useful error messages.
> >
> > Hope it helps,
> >
> > Wolfgang.
> >
> > On 12/04/2002 11:11 PM Brian Waite wrote:
> > > I did this. I tried to start a staticly linked ash shell to no avail. No
> > > libs are better than any libs :)
> > > Thanks
> > > Brian
> > >
> > > On Wednesday 04 December 2002 4:48 pm, Dan Malek wrote:
> > >> Brian Waite wrote:
> > >> > ...Then I get the message No init found.
> > >>
> > >> First, try using something simple like /bin/bash as your init program.
> > >> Trying to start up the init program relies on lots of things being
> > >> present in the file system.  If the program starts, and then exits,
> > >> you still get this message.
> > >>
> > >> Just use a trivial, simple file system to get started.  A shell,
> > >> couple of commands and minimal libraries are easier to debug.
> > >>
> > >> Good luck :-)
> > >>
> > >>    -- Dan
> > >
>
>


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: NFS root woes: No init found

[Brian Waite]

Here is my /etc/exports:
/home   *(rw,insecure,no_root_squash)

That should be sufficent I think .

Thanks
Brian

On Wednesday 04 December 2002 5:47 pm, Jerry Van Baren wrote:
> Thoughts...
>
> Does your mount command
> * use the defaults options (-o defaults) or equivalent?
>    - includes read/write and execute privileges
>
> Does your host
> * have "no_root_squash" (may not be necessary)?
> * allow write access to the remote host?
>
> gvb
>
> At 05:30 PM 12/4/2002 -0500, Brian Waite wrote:
> >I tried loading the ash shell statically linked., along with a dynamically
> >linked bash. No executables seem to load. I have traced the execve call
> > and it progresses as far as walking the format list to determine what
> > format the file is in. After walking all the available formats, it can't
> > find one and fails. I have the floowing formats in my kernel:
> >CONFIG_KCORE_ELF=y
> >CONFIG_BINFMT_ELF=y
> >CONFIG_KERNEL_ELF=y
> >
> >and the ash executale is an elf:
> >ash.static: ELF 32-bit MSB executable, PowerPC or cisco 4500, version 1,
> >statically linked, stripped
> >
> >Any thoughts? I see the packets getting revieved by the gt64260_eth driver
> > and passed up to the higher layers. I also look at the various MIB
> > counters and see no errant packets so I can't why NFS is so cranky.
> >
> >Thanks
> >Brian
> >
> >On Wednesday 04 December 2002 5:20 pm, you wrote:
> > > Hello,
> > >
> > > if you get to the bash prompt you could try to start the init program
> > > manually. This should result in more useful error messages.
> > >
> > > Hope it helps,
> > >
> > > Wolfgang.
> > >
> > > On 12/04/2002 11:11 PM Brian Waite wrote:
> > > > I did this. I tried to start a staticly linked ash shell to no avail.
> > > > No libs are better than any libs :)
> > > > Thanks
> > > > Brian
> > > >
> > > > On Wednesday 04 December 2002 4:48 pm, Dan Malek wrote:
> > > >> Brian Waite wrote:
> > > >> > ...Then I get the message No init found.
> > > >>
> > > >> First, try using something simple like /bin/bash as your init
> > > >> program. Trying to start up the init program relies on lots of
> > > >> things being present in the file system.  If the program starts, and
> > > >> then exits, you still get this message.
> > > >>
> > > >> Just use a trivial, simple file system to get started.  A shell,
> > > >> couple of commands and minimal libraries are easier to debug.
> > > >>
> > > >> Good luck :-)
> > > >>
> > > >>    -- Dan
>


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: NFS root woes: No init found

[Roland Dreier]

>>>>> "Brian" == Brian Waite <waite@skycomputers.com> writes:

    Brian> I tried loading the ash shell statically linked., along
    Brian> with a dynamically linked bash. No executables seem to
    Brian> load. I have traced the execve call and it progresses as
    Brian> far as walking the format list to determine what format the
    Brian> file is in. After walking all the available formats, it
    Brian> can't find one and fails.

    Brian> Any thoughts? I see the packets getting revieved by the
    Brian> gt64260_eth driver and passed up to the higher layers. I
    Brian> also look at the various MIB counters and see no errant
    Brian> packets so I can't why NFS is so cranky.

This is just a wild guess, but maybe there is a data corruption
problem somewhere.  (Maybe cache-coherency?  I know the 74xx/gt64260
is a cache-coherent platform but maybe the snooping isn't wired up or
set up correctly??)

You could try printing out the data the kernel thinks it read for init
and compare it with what's actually on the disk.  (It seems likely it
will be different, since the kernel can't tell that it's an ELF file)

Just as a data point, we have had good success running Linux with NFS
root on both the Galileo Discovery eval board and our own custom board
(both used the Galileo internal ethernet).

Best,
  Roland

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: NFS root woes: No init found

[Brian Waite]

Oh I like the thought! I too have had good luch wit the eval board, but now
our custom is biting me. Lets have a looksie at the data.
Thanks for the idea.
Brian

> This is just a wild guess, but maybe there is a data corruption
> problem somewhere.  (Maybe cache-coherency?  I know the 74xx/gt64260
> is a cache-coherent platform but maybe the snooping isn't wired up or
> set up correctly??)
>
> You could try printing out the data the kernel thinks it read for init
> and compare it with what's actually on the disk.  (It seems likely it
> will be different, since the kernel can't tell that it's an ELF file)
>
> Just as a data point, we have had good success running Linux with NFS
> root on both the Galileo Discovery eval board and our own custom board
> (both used the Galileo internal ethernet).
>
> Best,
>   Roland


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: NFS root woes: No init found

[Roland Dreier]

>>>>> "Brian" == Brian Waite <waite@skycomputers.com> writes:

    Brian> Hi, I am attempting to boot up a custom PPC board and
    Brian> having problems with the NFS Root. the board has a single
    Brian> 74xx PPC and Galileo memory controller. What happens is
    Brian> everything looks good until I attempt to read init from the
    Brian> NFS root. Then I get the message No init found. I have
    Brian> tried the obvious things such as changing init for a
    Brian> staticly linked executable, to no avail. I have enabled NFS
    Brian> debug and it looks like I have mounted the remote fs just
    Brian> fine.

One thing that sometimes helps in debugging these problems is to use
an ethernet sniffer to see what your target is really getting from the
NFS server.  You can use something like "tcpdump -vvv -s 1500", or
something fancier like ethereal.  Then you can see whether the target
ever even tries to read the init file, etc.

Best,
  Roland

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: NFS root woes: No init found

[Brian Waite]

I tried that but things look pretty happy. Here is the output I get with
tcpdump -vvv -s 1500 host seblade2

I know this NFS root is set up because other PPC boxes use it for NFS root. I
am pretty stumped.

17:32:19.528377 seblade2.800 > dayton.sunrpc:  [udp sum ok] udp 56 (DF) (ttl
64, id 0, len 84)
17:32:19.528732 dayton.sunrpc > seblade2.800:  [udp sum ok] udp 28 (DF) (ttl
64, id 0, len 56)
17:32:19.559211 seblade2.800 > dayton.sunrpc:  [udp sum ok] udp 56 (DF) (ttl
64, id 0, len 84)
17:32:19.559469 dayton.sunrpc > seblade2.800:  [udp sum ok] udp 28 (DF) (ttl
64, id 0, len 56)
17:32:19.579903 seblade2.800 > dayton.32771:  [udp sum ok] udp 56 (DF) (ttl
64, id 0, len 84)
17:32:19.585120 dayton.32771 > seblade2.800:  [udp sum ok] udp 60 (DF) (ttl
64, id 0, len 88)
17:32:19.585790 seblade2.159747 > dayton.nfs: 100 getattr fh Unknown/1 (DF)
(ttl 64, id 0, len 128)
17:32:19.585865 dayton.nfs > seblade2.159747: reply ok 96 getattr DIR 40755
ids 0/0 sz 4096  (DF) (ttl 64, id 0, len 124)
17:32:19.586681 seblade2.159748 > dayton.nfs: 100 fsstat fh Unknown/1 (DF)
(ttl 64, id 0, len 128)
17:32:19.586781 dayton.nfs > seblade2.159748: reply ok 48 fsstat [|nfs] (DF)
(ttl 64, id 0, len 76)
17:32:19.615317 seblade2.159749 > dayton.nfs: 108 lookup fh Unknown/1 "dev"
(DF) (ttl 64, id 0, len 136)
17:32:19.615396 dayton.nfs > seblade2.159749: reply ok 128 lookup fh Unknown/1
DIR 40755 ids 0/0 sz 77824 nlink 17 rdev ffffffff fsid 306 nodeid 246c8
a/m/ctime 1039040869.000000 1039039592.000000 1039039592.000000  (DF) (ttl
64, id 0, len 156)
17:32:19.616315 seblade2.159750 > dayton.nfs: 112 lookup fh Unknown/1
"console" (DF) (ttl 64, id 0, len 140)
17:32:19.616353 dayton.nfs > seblade2.159750: reply ok 128 lookup fh Unknown/1
CHR 20600 ids 504/0 sz 0 nlink 1 rdev 501 fsid 306 nodeid 247e4 a/m/ctime
1015747714.000000 1027439792.000000 1039029441.000000  (DF) (ttl 64, id 0,
len 156)
17:32:19.628334 seblade2.159751 > dayton.nfs: 108 lookup fh Unknown/1 "bin"
(DF) (ttl 64, id 0, len 136)
17:32:19.628400 dayton.nfs > seblade2.159751: reply ok 128 lookup fh Unknown/1
DIR 40755 ids 0/0 sz 4096 nlink 2 rdev ffffffff fsid 306 nodeid 1d38b9
a/m/ctime 1039040880.000000 1026358299.000000 1030454764.000000  (DF) (ttl
64, id 0, len 156)
17:32:19.629347 seblade2.159752 > dayton.nfs: 116 lookup fh Unknown/1
"ash.static" (DF) (ttl 64, id 0, len 144)
17:32:19.629382 dayton.nfs > seblade2.159752: reply ok 128 lookup fh Unknown/1
REG 100755 ids 0/0 sz 522456 nlink 1 rdev ffffffff fsid 306 nodeid 1d38f8
a/m/ctime 1039040880.000000 1015669398.000000 1030454763.000000  (DF) (ttl
64, id 0, len 156)
17:32:19.640029 seblade2.159753 > dayton.nfs: 112 read fh Unknown/1 4096 bytes
@ 0 (DF) (ttl 64, id 0, len 140)
17:32:19.640181 dayton > seblade2: (frag 51580:1244@2960) (ttl 64, len 1264)
17:32:19.640192 dayton > seblade2: (frag 51580:1480@1480+) (ttl 64, len 1500)
17:32:19.640201 dayton.nfs > seblade2.159753: reply ok 1472 read REG 100755
ids 0/0 sz 522456 nlink 1 rdev ffffffff fsid 306 nodeid 1d38f8 a/m/ctime
1039041139.000000 1015669398.000000 1030454763.000000  (frag 51580:1480@0+)
(ttl 64, len 1500)




Thanks
Brian

> One thing that sometimes helps in debugging these problems is to use
> an ethernet sniffer to see what your target is really getting from the
> NFS server.  You can use something like "tcpdump -vvv -s 1500", or
> something fancier like ethereal.  Then you can see whether the target
> ever even tries to read the init file, etc.
>
> Best,
>   Roland


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: NFS root woes: No init found

[Dan Vatca]

On Thursday 05 December 2002 00:36, Brian Waite wrote:
> I tried that but things look pretty happy. Here is the output I get with
> tcpdump -vvv -s 1500 host seblade2
>
> I know this NFS root is set up because other PPC boxes use it for NFS root.
> I am pretty stumped.
>
> 17:32:19.528377 seblade2.800 > dayton.sunrpc:  [udp sum ok] udp 56 (DF)
> (ttl 64, id 0, len 84)
> 17:32:19.528732 dayton.sunrpc > seblade2.800:  [udp sum ok] udp 28 (DF)
> (ttl 64, id 0, len 56)
> 17:32:19.559211 seblade2.800 > dayton.sunrpc:  [udp sum ok] udp 56 (DF)
> (ttl 64, id 0, len 84)
> 17:32:19.559469 dayton.sunrpc > seblade2.800:  [udp sum ok] udp 28 (DF)
> (ttl 64, id 0, len 56)
> 17:32:19.579903 seblade2.800 > dayton.32771:  [udp sum ok] udp 56 (DF) (ttl
> 64, id 0, len 84)
> 17:32:19.585120 dayton.32771 > seblade2.800:  [udp sum ok] udp 60 (DF) (ttl
> 64, id 0, len 88)
> 17:32:19.585790 seblade2.159747 > dayton.nfs: 100 getattr fh Unknown/1 (DF)
> (ttl 64, id 0, len 128)
> 17:32:19.585865 dayton.nfs > seblade2.159747: reply ok 96 getattr DIR 40755
> ids 0/0 sz 4096  (DF) (ttl 64, id 0, len 124)
> 17:32:19.586681 seblade2.159748 > dayton.nfs: 100 fsstat fh Unknown/1 (DF)
> (ttl 64, id 0, len 128)
> 17:32:19.586781 dayton.nfs > seblade2.159748: reply ok 48 fsstat [|nfs]
> (DF) (ttl 64, id 0, len 76)
> 17:32:19.615317 seblade2.159749 > dayton.nfs: 108 lookup fh Unknown/1 "dev"
> (DF) (ttl 64, id 0, len 136)
> 17:32:19.615396 dayton.nfs > seblade2.159749: reply ok 128 lookup fh
> Unknown/1 DIR 40755 ids 0/0 sz 77824 nlink 17 rdev ffffffff fsid 306 nodeid
> 246c8 a/m/ctime 1039040869.000000 1039039592.000000 1039039592.000000  (DF)
> (ttl 64, id 0, len 156)
> 17:32:19.616315 seblade2.159750 > dayton.nfs: 112 lookup fh Unknown/1
> "console" (DF) (ttl 64, id 0, len 140)
> 17:32:19.616353 dayton.nfs > seblade2.159750: reply ok 128 lookup fh
> Unknown/1 CHR 20600 ids 504/0 sz 0 nlink 1 rdev 501 fsid 306 nodeid 247e4
> a/m/ctime 1015747714.000000 1027439792.000000 1039029441.000000  (DF) (ttl
> 64, id 0, len 156)
> 17:32:19.628334 seblade2.159751 > dayton.nfs: 108 lookup fh Unknown/1 "bin"
> (DF) (ttl 64, id 0, len 136)
> 17:32:19.628400 dayton.nfs > seblade2.159751: reply ok 128 lookup fh
> Unknown/1 DIR 40755 ids 0/0 sz 4096 nlink 2 rdev ffffffff fsid 306 nodeid
> 1d38b9 a/m/ctime 1039040880.000000 1026358299.000000 1030454764.000000
> (DF) (ttl 64, id 0, len 156)
> 17:32:19.629347 seblade2.159752 > dayton.nfs: 116 lookup fh Unknown/1
> "ash.static" (DF) (ttl 64, id 0, len 144)
> 17:32:19.629382 dayton.nfs > seblade2.159752: reply ok 128 lookup fh
> Unknown/1 REG 100755 ids 0/0 sz 522456 nlink 1 rdev ffffffff fsid 306
> nodeid 1d38f8 a/m/ctime 1039040880.000000 1015669398.000000
> 1030454763.000000  (DF) (ttl 64, id 0, len 156)
> 17:32:19.640029 seblade2.159753 > dayton.nfs: 112 read fh Unknown/1 4096
> bytes @ 0 (DF) (ttl 64, id 0, len 140)
> 17:32:19.640181 dayton > seblade2: (frag 51580:1244@2960) (ttl 64, len
> 1264) 17:32:19.640192 dayton > seblade2: (frag 51580:1480@1480+) (ttl 64,
> len 1500) 17:32:19.640201 dayton.nfs > seblade2.159753: reply ok 1472 read
> REG 100755 ids 0/0 sz 522456 nlink 1 rdev ffffffff fsid 306 nodeid 1d38f8
> a/m/ctime 1039041139.000000 1015669398.000000 1030454763.000000  (frag
> 51580:1480@0+) (ttl 64, len 1500)
>

- From your output it seems that your system cannot find a /bin, /dev, and other
things on that nfs mountpoint. But the nfs seems to be up and responding with
read errors ... Are you sure you did not overlooked a path? Because the /home
(as I saw from a previous email ...) is very strange place to hold a
filesystem root ...

Dan.


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: NFS root woes: No init found

[Brian Waite]

But my target believe it was able to correctly open the file because it is
parsing the header of the file to determine the file type. Also, If I remove
my /dev/console node from the nfsroot, then console_init() throws a warning
about no default console found, so it must have found the file on the remote
host right?
My NFS root is infact loacted in /home/ppc. I have used this exact NFS root to
bring up an eval board.


Thanks
Brian
On Thursday 05 December 2002 3:50 am, Dan Vatca wrote:
>
> On Thursday 05 December 2002 00:36, Brian Waite wrote:
> > I tried that but things look pretty happy. Here is the output I get with
> > tcpdump -vvv -s 1500 host seblade2
> >
> > I know this NFS root is set up because other PPC boxes use it for NFS
> > root. I am pretty stumped.
> >
> > 17:32:19.528377 seblade2.800 > dayton.sunrpc:  [udp sum ok] udp 56 (DF)
> > (ttl 64, id 0, len 84)
> > 17:32:19.528732 dayton.sunrpc > seblade2.800:  [udp sum ok] udp 28 (DF)
> > (ttl 64, id 0, len 56)
> > 17:32:19.559211 seblade2.800 > dayton.sunrpc:  [udp sum ok] udp 56 (DF)
> > (ttl 64, id 0, len 84)
> > 17:32:19.559469 dayton.sunrpc > seblade2.800:  [udp sum ok] udp 28 (DF)
> > (ttl 64, id 0, len 56)
> > 17:32:19.579903 seblade2.800 > dayton.32771:  [udp sum ok] udp 56 (DF)
> > (ttl 64, id 0, len 84)
> > 17:32:19.585120 dayton.32771 > seblade2.800:  [udp sum ok] udp 60 (DF)
> > (ttl 64, id 0, len 88)
> > 17:32:19.585790 seblade2.159747 > dayton.nfs: 100 getattr fh Unknown/1
> > (DF) (ttl 64, id 0, len 128)
> > 17:32:19.585865 dayton.nfs > seblade2.159747: reply ok 96 getattr DIR
> > 40755 ids 0/0 sz 4096  (DF) (ttl 64, id 0, len 124)
> > 17:32:19.586681 seblade2.159748 > dayton.nfs: 100 fsstat fh Unknown/1
> > (DF) (ttl 64, id 0, len 128)
> > 17:32:19.586781 dayton.nfs > seblade2.159748: reply ok 48 fsstat [|nfs]
> > (DF) (ttl 64, id 0, len 76)
> > 17:32:19.615317 seblade2.159749 > dayton.nfs: 108 lookup fh Unknown/1
> > "dev" (DF) (ttl 64, id 0, len 136)
> > 17:32:19.615396 dayton.nfs > seblade2.159749: reply ok 128 lookup fh
> > Unknown/1 DIR 40755 ids 0/0 sz 77824 nlink 17 rdev ffffffff fsid 306
> > nodeid 246c8 a/m/ctime 1039040869.000000 1039039592.000000
> > 1039039592.000000  (DF) (ttl 64, id 0, len 156)
> > 17:32:19.616315 seblade2.159750 > dayton.nfs: 112 lookup fh Unknown/1
> > "console" (DF) (ttl 64, id 0, len 140)
> > 17:32:19.616353 dayton.nfs > seblade2.159750: reply ok 128 lookup fh
> > Unknown/1 CHR 20600 ids 504/0 sz 0 nlink 1 rdev 501 fsid 306 nodeid 247e4
> > a/m/ctime 1015747714.000000 1027439792.000000 1039029441.000000  (DF)
> > (ttl 64, id 0, len 156)
> > 17:32:19.628334 seblade2.159751 > dayton.nfs: 108 lookup fh Unknown/1
> > "bin" (DF) (ttl 64, id 0, len 136)
> > 17:32:19.628400 dayton.nfs > seblade2.159751: reply ok 128 lookup fh
> > Unknown/1 DIR 40755 ids 0/0 sz 4096 nlink 2 rdev ffffffff fsid 306 nodeid
> > 1d38b9 a/m/ctime 1039040880.000000 1026358299.000000 1030454764.000000
> > (DF) (ttl 64, id 0, len 156)
> > 17:32:19.629347 seblade2.159752 > dayton.nfs: 116 lookup fh Unknown/1
> > "ash.static" (DF) (ttl 64, id 0, len 144)
> > 17:32:19.629382 dayton.nfs > seblade2.159752: reply ok 128 lookup fh
> > Unknown/1 REG 100755 ids 0/0 sz 522456 nlink 1 rdev ffffffff fsid 306
> > nodeid 1d38f8 a/m/ctime 1039040880.000000 1015669398.000000
> > 1030454763.000000  (DF) (ttl 64, id 0, len 156)
> > 17:32:19.640029 seblade2.159753 > dayton.nfs: 112 read fh Unknown/1 4096
> > bytes @ 0 (DF) (ttl 64, id 0, len 140)
> > 17:32:19.640181 dayton > seblade2: (frag 51580:1244@2960) (ttl 64, len
> > 1264) 17:32:19.640192 dayton > seblade2: (frag 51580:1480@1480+) (ttl 64,
> > len 1500) 17:32:19.640201 dayton.nfs > seblade2.159753: reply ok 1472
> > read REG 100755 ids 0/0 sz 522456 nlink 1 rdev ffffffff fsid 306 nodeid
> > 1d38f8 a/m/ctime 1039041139.000000 1015669398.000000 1030454763.000000
> > (frag 51580:1480@0+) (ttl 64, len 1500)
>
> - From your output it seems that your system cannot find a /bin, /dev, and
> other things on that nfs mountpoint. But the nfs seems to be up and
> responding with read errors ... Are you sure you did not overlooked a path?
> Because the /home (as I saw from a previous email ...) is very strange
> place to hold a filesystem root ...
>
> Dan.


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

RE: NFS root woes: No init found

[Allen Curtis]

Stupid question, is the processor you are trying to boot the same as the
other processors using the same NFS RFS? Not all PPCs are created equally.

Just a thought...

> But my target believe it was able to correctly open the file because it is
> parsing the header of the file to determine the file type. Also,
> If I remove
> my /dev/console node from the nfsroot, then console_init() throws
> a warning
> about no default console found, so it must have found the file on
> the remote
> host right?
> My NFS root is infact loacted in /home/ppc. I have used this
> exact NFS root to
> bring up an eval board.
>
>
> Thanks
> Brian
> On Thursday 05 December 2002 3:50 am, Dan Vatca wrote:
> >
> > On Thursday 05 December 2002 00:36, Brian Waite wrote:
> > > I tried that but things look pretty happy. Here is the output
> I get with
> > > tcpdump -vvv -s 1500 host seblade2
> > >
> > > I know this NFS root is set up because other PPC boxes use it for NFS
> > > root. I am pretty stumped.
> > >
> > > 17:32:19.528377 seblade2.800 > dayton.sunrpc:  [udp sum ok]
> udp 56 (DF)
> > > (ttl 64, id 0, len 84)
> > > 17:32:19.528732 dayton.sunrpc > seblade2.800:  [udp sum ok]
> udp 28 (DF)
> > > (ttl 64, id 0, len 56)
> > > 17:32:19.559211 seblade2.800 > dayton.sunrpc:  [udp sum ok]
> udp 56 (DF)
> > > (ttl 64, id 0, len 84)
> > > 17:32:19.559469 dayton.sunrpc > seblade2.800:  [udp sum ok]
> udp 28 (DF)
> > > (ttl 64, id 0, len 56)
> > > 17:32:19.579903 seblade2.800 > dayton.32771:  [udp sum ok] udp 56 (DF)
> > > (ttl 64, id 0, len 84)
> > > 17:32:19.585120 dayton.32771 > seblade2.800:  [udp sum ok] udp 60 (DF)
> > > (ttl 64, id 0, len 88)
> > > 17:32:19.585790 seblade2.159747 > dayton.nfs: 100 getattr fh Unknown/1
> > > (DF) (ttl 64, id 0, len 128)
> > > 17:32:19.585865 dayton.nfs > seblade2.159747: reply ok 96 getattr DIR
> > > 40755 ids 0/0 sz 4096  (DF) (ttl 64, id 0, len 124)
> > > 17:32:19.586681 seblade2.159748 > dayton.nfs: 100 fsstat fh Unknown/1
> > > (DF) (ttl 64, id 0, len 128)
> > > 17:32:19.586781 dayton.nfs > seblade2.159748: reply ok 48
> fsstat [|nfs]
> > > (DF) (ttl 64, id 0, len 76)
> > > 17:32:19.615317 seblade2.159749 > dayton.nfs: 108 lookup fh Unknown/1
> > > "dev" (DF) (ttl 64, id 0, len 136)
> > > 17:32:19.615396 dayton.nfs > seblade2.159749: reply ok 128 lookup fh
> > > Unknown/1 DIR 40755 ids 0/0 sz 77824 nlink 17 rdev ffffffff fsid 306
> > > nodeid 246c8 a/m/ctime 1039040869.000000 1039039592.000000
> > > 1039039592.000000  (DF) (ttl 64, id 0, len 156)
> > > 17:32:19.616315 seblade2.159750 > dayton.nfs: 112 lookup fh Unknown/1
> > > "console" (DF) (ttl 64, id 0, len 140)
> > > 17:32:19.616353 dayton.nfs > seblade2.159750: reply ok 128 lookup fh
> > > Unknown/1 CHR 20600 ids 504/0 sz 0 nlink 1 rdev 501 fsid 306
> nodeid 247e4
> > > a/m/ctime 1015747714.000000 1027439792.000000 1039029441.000000  (DF)
> > > (ttl 64, id 0, len 156)
> > > 17:32:19.628334 seblade2.159751 > dayton.nfs: 108 lookup fh Unknown/1
> > > "bin" (DF) (ttl 64, id 0, len 136)
> > > 17:32:19.628400 dayton.nfs > seblade2.159751: reply ok 128 lookup fh
> > > Unknown/1 DIR 40755 ids 0/0 sz 4096 nlink 2 rdev ffffffff
> fsid 306 nodeid
> > > 1d38b9 a/m/ctime 1039040880.000000 1026358299.000000 1030454764.000000
> > > (DF) (ttl 64, id 0, len 156)
> > > 17:32:19.629347 seblade2.159752 > dayton.nfs: 116 lookup fh Unknown/1
> > > "ash.static" (DF) (ttl 64, id 0, len 144)
> > > 17:32:19.629382 dayton.nfs > seblade2.159752: reply ok 128 lookup fh
> > > Unknown/1 REG 100755 ids 0/0 sz 522456 nlink 1 rdev ffffffff fsid 306
> > > nodeid 1d38f8 a/m/ctime 1039040880.000000 1015669398.000000
> > > 1030454763.000000  (DF) (ttl 64, id 0, len 156)
> > > 17:32:19.640029 seblade2.159753 > dayton.nfs: 112 read fh
> Unknown/1 4096
> > > bytes @ 0 (DF) (ttl 64, id 0, len 140)
> > > 17:32:19.640181 dayton > seblade2: (frag 51580:1244@2960) (ttl 64, len
> > > 1264) 17:32:19.640192 dayton > seblade2: (frag
> 51580:1480@1480+) (ttl 64,
> > > len 1500) 17:32:19.640201 dayton.nfs > seblade2.159753: reply ok 1472
> > > read REG 100755 ids 0/0 sz 522456 nlink 1 rdev ffffffff fsid
> 306 nodeid
> > > 1d38f8 a/m/ctime 1039041139.000000 1015669398.000000 1030454763.000000
> > > (frag 51580:1480@0+) (ttl 64, len 1500)
> >
> > - From your output it seems that your system cannot find a
> /bin, /dev, and
> > other things on that nfs mountpoint. But the nfs seems to be up and
> > responding with read errors ... Are you sure you did not
> overlooked a path?
> > Because the /home (as I saw from a previous email ...) is very strange
> > place to hold a filesystem root ...
> >
> > Dan.
>
>
>
>


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

RE: NFS root woes: No init found

[Pagnotta, Chris]

I am having a problem with NFS mounting the root filesystem. It seems that
init
is not being executed. However, the problem may be with rootpath not being
set.
Should that parameter be set from the kernel command nfsroot=?



## Booting image at 00400000 ...
   Image Name:   Linux-2.4.19-pre6
   Created:      2002-12-06  17:44:09 UTC
   Image Type:   PowerPC Linux Kernel Image (gzip compressed)
   Data Size:    901003 Bytes = 879 kB = 0 MB
   Load Address: 00000000
   Entry Point:  00000000
   Verifying Checksum ... OK
   Uncompressing Kernel Image ... OK
id mach(): done
MMU:enter
MMU:hw init
MMU:mapin
MMU:mapin_ram done
MMU:setio
MMU:exit
setup_arch: enter
setup_arch: bootmem
arch: exit
Linux version 2.4.19-pre6 (cpagnotta@lb-deviant-linux) (gcc version 2.95.4
20010
319 (prerelease/franzo/20011204)) #8 Fri Dec 6 09:28:29 PST 2002
On node 0 totalpages: 32768
zone(0): 4096 pages.
zone(1): 28672 pages.
zone(2): 0 pages.
Kernel command line: root=/dev/nfs nfsroot=/tftpboot/powerpc-rootfs
ip=172.25.59
.11:172.25.59.15::255.255.0.0:vib::off
Calibrating delay loop... 263.78 BogoMIPS
Memory: 127092k available (1524k kernel code, 676k data, 212k init, 0k
highmem)
Dentry-cache hash table entries: 16384 (order: 5, 131072 bytes)
Inode-cache hash table entries: 8192 (order: 4, 65536 bytes)
Mount-cache hash table entries: 2048 (order: 2, 16384 bytes)
Buffer-cache hash table entries: 8192 (order: 3, 32768 bytes)
Page-cache hash table entries: 32768 (order: 5, 131072 bytes)
POSIX conformance testing by UNIFIX
PCI: Probing PCI hardware

Linux NET4.0 for Linux 2.4
Based upon Swansea University Computer Society NET3.039
Initializing RT netlink socket
Starting kswapd
devfs: v1.12 (20020219) Richard Gooch (rgooch@atnf.csiro.au)
devfs: boot_options: 0x1
Installing knfsd (copyright (C) 1996 okir@monad.swb.de).
JFFS2 version 2.1. (C) 2001 Red Hat, Inc., designed by Axis Communications
AB.
i2c-core.o: i2c core module
i2c-dev.o: i2c /dev entries driver module
i2c-core.o: driver i2c-dev dummy driver registered.
i2c-proc.o version 2.6.1 (20010825)
pty: 256 Unix98 ptys configured
Serial driver version 5.05c (2001-07-08) with MANY_PORTS SHARE_IRQ
SERIAL_PCI en
abled
ttyS00 at 0xef600300 (irq = 0) is a 16550A
ttyS01 at 0xef600400 (irq = 1) is a 16550A
ttyS02 at 0xf4100000 (irq = 26) is a ST16650V2
ttyS03 at 0xf4200000 (irq = 26) is a ST16650V2
PPC 405 watchdog driver v0.5
IBM gpio driver version 02.01.21.d
GPIO #0 at 0xc900d700
RAMDISK driver initialized: 16 RAM disks of 4096K size 1024 blocksize
loop: loaded (max 8 devices)
eth0: Phy @ 0x1, type LXT971A (0x001378e2)
pcnet32.c:v1.27a 10.02.2002 tsbogend@alpha.franken.de
Equalizer1996: $Revision: 1.2.1 $ $Date: 1996/09/22 13:52:00 $ Simon Janes
(simo
n@ncm.com)
Universal TUN/TAP device driver 1.4 (C)1999-2001 Maxim Krasnyansky
NFTL driver: nftlcore.c $Revision: 1.85 $, nftlmount.c $Revision: 1.25 $
NET4: Linux TCP/IP 1.0 for NET4.0
IP Protocols: ICMP, UDP, TCP, IGMP
IP: routing cache hash table of 1024 buckets, 8Kbytes
TCP: Hash tables configured (established 8192 bind 8192)
IPv4 over IPv4 tunneling driver
GRE over IPv4 tunneling driver
Reset ethernet interfaces
eth0: IBM EMAC: link up, 10 Mbps Half Duplex, auto-negotiation complete.
eth0: IBM EMAC: MAC 00:60:c2:0a:00:1f.
eth0: IBM EMAC: open completed
IP-Config: Complete:
      device=eth0, addr=172.25.59.11, mask=255.255.0.0, gw=255.255.255.255,
     host=vib, domain=, nis-domain=(none),
     bootserver=172.25.59.15, rootserver=172.25.59.15, rootpath=
ip_conntrack (1024 buckets, 8192 max)
ip_tables: (C) 2000-2002 Netfilter core team
arp_tables: (C) 2002 David S. Miller
NET4: Unix domain sockets 1.0/SMP for Linux NET4.0.
Looking up port of RPC 100003/2 on 172.25.59.15
Looking up port of RPC 100005/1 on 172.25.59.15
VFS: Mounted root (nfs filesystem).
Mounted devfs on /dev
Freeing unused kernel memory: 212k init
Kernel panic: No init found.  Try passing init= option to kernel.
 <0>Rebooting in 180 seconds..<NULL>

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: NFS root woes: No init found

[Wolfgang Denk]

In message <0509218DDAD7D6118055006008F6D5F6A1E39A@postal.viasat.com> you wrote:
>
> I am having a problem with NFS mounting the root filesystem. It seems that
> init
> is not being executed. However, the problem may be with rootpath not being
> set.
> Should that parameter be set from the kernel command nfsroot=?

What are you talking about?

> Kernel command line: root=/dev/nfs nfsroot=/tftpboot/powerpc-rootfs
> ip=172.25.59
> .11:172.25.59.15::255.255.0.0:vib::off

Your rootpath _is_ set here: you're using "/tftpboot/powerpc-rootfs"
as root directory.

...
> Looking up port of RPC 100003/2 on 172.25.59.15
> Looking up port of RPC 100005/1 on 172.25.59.15
> VFS: Mounted root (nfs filesystem).

And the root filesystem was found and mounted.

> Mounted devfs on /dev
> Freeing unused kernel memory: 212k init
> Kernel panic: No init found.  Try passing init= option to kernel.

Are you sure you NEED devfs here? For now I recommend to disable this
option, as it adds just additional complexity. To anlyze what's going
on with your  NFS  root  filesystem,  run  a  network  sniffer  (like
ethereal) and check wich accesses work, and which are failing.

Best regards,

Wolfgang Denk

--
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd@denx.de
Imagination is more important than knowledge.      -- Albert Einstein

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/