From: Brian Waite <hidden> Date: 2002-12-04 21:35:31
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/
From: Dan Malek <hidden> Date: 2002-12-04 21:48:12
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/
From: Brian Waite <hidden> Date: 2002-12-04 22:11:04
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:
quoted
...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
From: Wolfgang Grandegger <hidden> Date: 2002-12-04 22:20:24
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:
quoted
Brian Waite wrote:
quoted
...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
From: Roland Dreier <hidden> Date: 2002-12-04 22:27:46
quoted
quoted
quoted
quoted
"Brian" == Brian Waite [off-list ref] 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/
From: Brian Waite <hidden> Date: 2002-12-04 22:30:00
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:
quoted
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:
quoted
Brian Waite wrote:
quoted
...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
From: Brian Waite <hidden> Date: 2002-12-04 22:36:16
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
From: Jerry Van Baren <hidden> Date: 2002-12-04 22:47:09
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:
quoted
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:
quoted
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:
quoted
Brian Waite wrote:
quoted
...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
From: Roland Dreier <hidden> Date: 2002-12-04 22:49:30
quoted
quoted
quoted
quoted
"Brian" == Brian Waite [off-list ref] 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/
From: Brian Waite <hidden> Date: 2002-12-04 22:52:24
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
From: Brian Waite <hidden> Date: 2002-12-04 23:03:21
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:
quoted
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:
quoted
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:
quoted
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:
quoted
Brian Waite wrote:
quoted
...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
From: Dan Vatca <hidden> Date: 2002-12-05 08:50:15
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/
From: Brian Waite <hidden> Date: 2002-12-05 15:20:53
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:
quoted
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.
From: Allen Curtis <hidden> Date: 2002-12-05 15:58:42
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:
quoted
On Thursday 05 December 2002 00:36, Brian Waite wrote:
quoted
I tried that but things look pretty happy. Here is the output
I get with
quoted
quoted
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)
quoted
quoted
(ttl 64, id 0, len 84)
17:32:19.528732 dayton.sunrpc > seblade2.800: [udp sum ok]
udp 28 (DF)
quoted
quoted
(ttl 64, id 0, len 56)
17:32:19.559211 seblade2.800 > dayton.sunrpc: [udp sum ok]
udp 56 (DF)
quoted
quoted
(ttl 64, id 0, len 84)
17:32:19.559469 dayton.sunrpc > seblade2.800: [udp sum ok]
udp 28 (DF)
quoted
quoted
(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]
quoted
quoted
(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
quoted
quoted
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
quoted
quoted
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
quoted
quoted
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