NFS root woes: No init found
In message 0509218DDAD7D6118055006008F6D5F6A1E39A at 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 13/2 on 172.25.59.15 Looking up port of RPC 15/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 at denx.de Imagination is more important than knowledge. -- Albert Einstein ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
NFS root woes: No init found
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 0040 ... 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: Entry Point: 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 at 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 at atnf.csiro.au) devfs: boot_options: 0x1 Installing knfsd (copyright (C) 1996 okir at 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 0xf410 (irq = 26) is a ST16650V2 ttyS03 at 0xf420 (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 at alpha.franken.de Equalizer1996: $Revision: 1.2.1 $ $Date: 1996/09/22 13:52:00 $ Simon Janes (simo n at 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 13/2 on 172.25.59.15 Looking up port of RPC 15/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. 0Rebooting in 180 seconds..NULL ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
NFS root woes: No init found
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 fsid 306 nodeid 246c8 a/m/ctime 1039040869.00 1039039592.00 1039039592.00 (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.00 1027439792.00 1039029441.00 (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 fsid 306 nodeid 1d38b9 a/m/ctime 1039040880.00 1026358299.00 1030454764.00 (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 fsid 306 nodeid 1d38f8 a/m/ctime 1039040880.00 1015669398.00 1030454763.00 (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 at 2960) (ttl 64, len 1264) 17:32:19.640192 dayton seblade2: (frag 51580:1480 at 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 fsid 306 nodeid 1d38f8 a/m/ctime 1039041139.00 1015669398.00 1030454763.00 (frag 51580:1480 at 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/
NFS root woes: No init found
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 fsid 306 nodeid 246c8 a/m/ctime 1039040869.00 1039039592.00 1039039592.00 (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.00 1027439792.00 1039029441.00 (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 fsid 306 nodeid 1d38b9 a/m/ctime 1039040880.00 1026358299.00 1030454764.00 (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 fsid 306 nodeid 1d38f8 a/m/ctime 1039040880.00 1015669398.00 1030454763.00 (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 at 2960) (ttl 64, len 1264) 17:32:19.640192 dayton seblade2: (frag 51580:1480 at 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 fsid 306 nodeid 1d38f8 a/m/ctime 1039041139.00 1015669398.00 1030454763.00 (frag 51580:1480 at 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/
NFS root woes: No init found
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 fsid 306 nodeid 246c8 a/m/ctime 1039040869.00 1039039592.00 1039039592.00 (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.00 1027439792.00 1039029441.00 (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 fsid 306 nodeid 1d38b9 a/m/ctime 1039040880.00 1026358299.00 1030454764.00 (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 fsid 306 nodeid 1d38f8 a/m/ctime 1039040880.00 1015669398.00 1030454763.00 (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 at 2960) (ttl 64, len 1264) 17:32:19.640192 dayton seblade2: (frag 51580:1480 at 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 fsid 306 nodeid 1d38f8 a/m/ctime 1039041139.00 1015669398.00 1030454763.00 (frag 51580:1480 at 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/
NFS root woes: No init found
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 = 0200 Looking up port of RPC 13/2 on 192.9.200.220 Root-NFS: Portmapper on server returned 2049 as nfsd port Looking up port of RPC 15/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. 0Rebooting in 180 seconds.. ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
NFS root woes: No init found
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/
NFS root woes: No init found
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/
NFS root woes: No init found
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/
NFS root woes: No init found
Brian == Brian Waite waite at 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/
NFS root woes: No init found
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/
NFS root woes: No init found
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 fsid 306 nodeid 246c8 a/m/ctime 1039040869.00 1039039592.00 1039039592.00 (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.00 1027439792.00 1039029441.00 (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 fsid 306 nodeid 1d38b9 a/m/ctime 1039040880.00 1026358299.00 1030454764.00 (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 fsid 306 nodeid 1d38f8 a/m/ctime 1039040880.00 1015669398.00 1030454763.00 (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 at 2960) (ttl 64, len 1264) 17:32:19.640192 dayton seblade2: (frag 51580:1480 at 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 fsid 306 nodeid 1d38f8 a/m/ctime 1039041139.00 1015669398.00 1030454763.00 (frag 51580:1480 at 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/
NFS root woes: No init found
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/
NFS root woes: No init found
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/
