diskless installation, nfs: server not responding, still trying

[the_ultimate_samurai]

i have been attempting to set up this second computer (amd athalon xp 1.6ghz, same make an model as my client but with about 512 megs less of ram) to boot diskless with pxe. i have been doing much google searching, asking on the #debian chanel (irc.debian.org) and using various tutorials, this latest one has gotten me the most success. the system boots up...then it comes to a certain point, after mounting the kernel i think...yes, loading kernel modules, checking file systems...little bit past there then it says "nfs: server 192.168.1.202 not responding, still trying"
after which it gives /etc/init.d/rc: lin 288: sed: command not found.
there doesnt seem to be a log of this (if there is its on the ram disk of the client which i have no access to since it doesnt have a bash input.
all of the other things work fine, the system is currently without HDD, it gets the other files fine, im not sure what its set up to do after loading the kernel or if the kernel itself is at fault. a few bits of relevant files:
/etc/network/interfaces

# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).

# The loopback network interface
auto lo
iface lo inet loopback
address 127.0.0.1
netmask 255.0.0.0

# The primary network interface
auto eth0
iface eth0 inet static
    address 192.168.1.202
    netmask 255.255.255.0
    gateway 192.168.1.2

/etc/exports:

/       192.168.1.*(rw,sync,no_root_squash)
/mnt/hdb1       192.168.1.*(rw,sync,no_root_squash)
/pxeroot    debian(rw,sync,no_root_squash)

/etc/hosts

127.0.0.1 localhost.localdomain localhost ip-citznet-64-184-5-29
192.168.1.202   ip-citznet-64-184-5-29
192.168.1.201   debian

# The following lines are desirable for IPv6 capable hosts
::1 ip6-localhost ip6-loopback
fe00::0 ip6-localnet
ff00::0 ip6-mcastprefix
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters
ff02::3 ip6-allhosts

also my hdcp (least the important parts)

host debian {
  hardware ethernet 00:40:ca:4d:1c:27;
  fixed-address debian;
  filename "pxelinux.0";
  option root-path "192.168.1.202:/pxeroot";
  next-server 192.168.1.202;

}
default-lease-time 600;
max-lease-time 7200;
option domain-name "citznet";
option domain-name-servers 192.168.1.2;
option routers 192.168.1.2;
subnet 192.168.1.0 netmask 255.255.255.0 {
    range 192.168.1.201 192.168.1.255;
   # option root-path "192.168.100.1:/pxeroot";
    next-server 192.168.1.202;
    filename "pxelinux.0";
}

this one could be important but i dont know enough about the ramdisk or its function to say:

# /etc/fstab: static file system information.
# <file system>   <mount point>   <type>   <options>   <dump>    <pass>
/dev/ram0  /       ext2   defaults    0   0
proc       /proc      proc   defaults    0   1
tmpfs      /tmp       tmpfs  defaults    0   1

at one point the tutorial said "we will run partimage for dumping partition." but then never mentions actually running it...so im not sure when i was supposed to, or even if indeed i was to run it then, and for that mater how...

the reason for using a ramdisk for / and not an nfs mount perplexes me.
also netstat confirms debian being connected:
tcp 0 120 ip-citznet-64-184-5:nfs debian:1004 ESTABLISHED

also an interesting bit, even though the client says it has bound to 192.168.1.201, and the netstat shows a connection from debian(defined in /etc/hosts as 192.168.1.201) pinging either debian or 192.168.1.201 fails with "no route to host"

i followed the instructions very closely in the link i gave, most of them are copy pasted with network variables changed as needed. though if you need a file, i'll be more than happy to oblige anything to get this resolved faster.

also, i looked over my syslog and found this little bit:

Dec 14 04:28:05 ip-citznet-64-184-5-29 dhcpd: DHCPDISCOVER from 00:40:ca:4d:1c:27 via eth0
Dec 14 04:28:05 ip-citznet-64-184-5-29 dhcpd: DHCPOFFER on 192.168.1.201 to 00:40:ca:4d:1c:27 via eth0
Dec 14 04:28:07 ip-citznet-64-184-5-29 dhcpd: DHCPREQUEST for 192.168.1.201 (192.168.1.202) from 00:40:ca:4d:1c:27 via eth0
Dec 14 04:28:07 ip-citznet-64-184-5-29 dhcpd: DHCPACK on 192.168.1.201 to 00:40:ca:4d:1c:27 via eth0
Dec 14 04:28:07 ip-citznet-64-184-5-29 in.tftpd[10125]: tftp: client does not accept options 
Dec 14 04:28:14 ip-citznet-64-184-5-29 dhcpd: DHCPDISCOVER from 00:40:ca:4d:1c:27 via eth0
Dec 14 04:28:14 ip-citznet-64-184-5-29 dhcpd: DHCPOFFER on 192.168.1.201 to 00:40:ca:4d:1c:27 via eth0
Dec 14 04:28:14 ip-citznet-64-184-5-29 dhcpd: DHCPREQUEST for 192.168.1.201 (192.168.1.202) from 00:40:ca:4d:1c:27 via eth0
Dec 14 04:28:14 ip-citznet-64-184-5-29 dhcpd: DHCPACK on 192.168.1.201 to 00:40:ca:4d:1c:27 via eth0
Dec 14 04:28:15 ip-citznet-64-184-5-29 dhcpd: DHCPREQUEST for 192.168.1.201 (192.168.1.202) from 00:40:ca:4d:1c:27 via eth0
Dec 14 04:28:15 ip-citznet-64-184-5-29 dhcpd: DHCPACK on 192.168.1.201 to 00:40:ca:4d:1c:27 via eth0
Dec 14 04:28:15 ip-citznet-64-184-5-29 mountd[4513]: authenticated mount request from debian:1016 for /pxeroot (/pxeroot)
Dec 14 04:30:09 ip-citznet-64-184-5-29 dhcpd: DHCPDISCOVER from 00:40:ca:4d:1c:27 via eth0
Dec 14 04:30:09 ip-citznet-64-184-5-29 dhcpd: DHCPOFFER on 192.168.1.201 to 00:40:ca:4d:1c:27 via eth0
Dec 14 04:30:09 ip-citznet-64-184-5-29 dhcpd: DHCPREQUEST for 192.168.1.201 (192.168.1.202) from 00:40:ca:4d:1c:27 via eth0
Dec 14 04:30:09 ip-citznet-64-184-5-29 dhcpd: DHCPACK on 192.168.1.201 to 00:40:ca:4d:1c:27 via eth0
Dec 14 04:39:02 ip-citznet-64-184-5-29 /USR/SBIN/CRON[10162]: (root) CMD (  [ -d /var/lib/php4 ] && find /var/lib/php4/ -type f -cmin +$(/usr/lib/php4/maxlifetime) -print0 | xargs -r -0 rm)

after that it just repeats request and ack on a regular basis.
i think the most telling are these two lines:
Dec 14 04:28:07 ip-citznet-64-184-5-29 in.tftpd[10125]: tftp: client does not accept options
and
Dec 14 04:28:15 ip-citznet-64-184-5-29 mountd[4513]: authenticated mount request from debian:1016 for /pxeroot (/pxeroot)

google has returned similar issues with other people but no applicable solution, nor a notable cause of the problem.

[the_ultimate_samurai]

perhaps this would help:
booting up in knoppix i found the eth0 to be unusable. though i couldnt figure out why, the computer couldnt get an active internet connection via knoppix. however i installed an OS on it via net install cd (though i guess the boot sector of the hdd is damaged or hell maybe the ide port is broken i dont know, but it doesnt boot that drive. though knoppix confirms all data present and accounted for.)

so it seems the eth0 works, and the reason its disabled in knoppix and unable to be enabled is unknown. but could this be related, could the eth0 be able to connect to the pc via pxe but when it becomes time to mount via nfs it cant get a working connection. what would be a good way to test this?

[dilbert]

after which it gives /etc/init.d/rc: lin 288: sed: command not found.

[...]

option domain-name-servers 192.168.1.2;
option routers 192.168.1.2;

I would look after this sed command in "/etc/init.d/rc" line 288.

Also, I don't understand the address 192.168.1.2 for DNS. Either you get the DNS servers via DHCP from your network provider (almost all people) or you must have setup your own DNS server (mine are at 127.0.0.1). Does your router really act as a DNS server on its own?

[the_ultimate_samurai]

hm...no...i dont suppose it does...does that matter? that system doesnt need to reach out.

the sed command exists, i confirmed it with chroot /pxeroot on the server and the sed command was found.

but do you think having the wrong DNS there makes the difference? i dont know much about dns so i dont know how it would affect it

[dilbert]

DNS is only for translating ASCII domain names into IP addresses the IP protocol actually works with. So, "abc.com" --> "1.1.1.1", e.g. You need to specify a server for those queries or your router or your ISP do that via DHCP protocol automatically for you, hopefully in the right way.

This can be an issue if you have somewhere ASCII domain names.

When the sed command executes why doesn't do it at execution of that script? Depending on the importance of that command I would fix that, too.

[the_ultimate_samurai]

the only place the pc is mentioned by host name is in my hosts.allow, the /etc/exports has the host "debian" which was mentioned in the hosts.allow explicitly mentioned though i have also tried it with a numerical number too, which didnt make a difference.

i imagine the reason it fails to run the sed is because it fails to load the /pxeroot by nfs, so that pc doesnt HAVE the sed command which is located in /pxeroot.

its failure to mount the root file system probably has a lot to do with the problems..but i cant find out why it cant mount the pxeroot dirrectory. the netstat shows a connection from host debian on nfs...sometimes it shows two...even so i show no sign that the client is getting any files located on pxeroot (though i suppose /etc/init.d would be on the pxeroot wouldnt it...i wish i could querry the file system and see what it has loaded and what it hasnt...i feel a notable lack of information here...the system doesnt have a command line so i cant check it, and its logs are, as far as i can tell, kept in ram...which disapears after its shut down. i cant telnet to it, i cant even ping it. if i didnt have an established connection i wouldnt even think the damn thing was online...)

--edit--
also the line in rc 288 reads:
level=$(echo $s | sed 's/.*\/S\([0-9][0-9]\).*/\1/')
full function is as follows:

# Now run the START scripts for this runlevel.
	# Run all scripts with the same level in parallel
	CURLEVEL=""
	for s in /etc/rc$runlevel.d/S*
	do
		level=$(echo $s | sed 's/.*\/S\([0-9][0-9]\).*/\1/')
		if [ "$level" = "$CURLEVEL" ]
		then
			continue
		fi
		CURLEVEL=$level
		SCRIPTS=""
		for i in /etc/rc$runlevel.d/S$level*
		do
			[ ! -f $i ] && continue

			if [ "$previous" != N ]
			then
				#
				# Find start script in previous runlevel and
				# stop script in this runlevel.
				#
				suffix=${i#/etc/rc$runlevel.d/S[0-9][0-9]}
				stop=/etc/rc$runlevel.d/K[0-9][0-9]$suffix
				previous_start=/etc/rc$previous.d/S[0-9][0-9]$suffix
				#
				# If there is a start script in the previous level
				# and _no_ stop script in this level, we don't
				# have to re-start the service.
				#
				[ -f $previous_start ] && [ ! -f $stop ] && continue
			fi
			SCRIPTS="$SCRIPTS $i"
		done
		startup $ACTION $SCRIPTS
	done

but i dont know what that means.

[dilbert]

I'm not a sed guru, so I don't see much from only looking at it and getting to the bottom of it could take me easily an hour or two.

But I guess it only has to do with a two-digit runlevel number what might be important, too.

I don't know pxe at all. Maybe the installation of pxe is faulty.

I don't know if you could setup a standard NFS connection and if this succeeds look what could be wrong with pxe.

For a standard NFS setup you need to start a NFS server service and the server PC and also some NFS client on the client PC if I'm not mistaken.

Then you can run a manual mount command like
"mount -o nolock,rsize=1024,wsize=1024 192.168.1.1:/export/target /mnt/target"

where "192.168.1.1" is the server PC's IP address of the network card you're using, "/export/target" would be the NFS directory on the server PC, and "/mnt/target" the NFS directory on the client PC. So, the directory "target" on both PCs should have the same contents.

If you doublecheck on both PCs with ifconfig, arp, and ping if all things are consistent and make sense, then you try the mount command on the client PC and look what errors you will get.

This approach would have the advantage that you get plenty of info as this NFS setup is a standard procedure whereas pxe might not be that well documented. At least, it gives you clues when doing it step by step.

[the_ultimate_samurai]

unfortunately i cant run anything on the client pc, it doesnt have a HDD and depends on my server to boot up. thus i cant run anything on it. knoppix isnt able to enable the eth0 also.

and i still dont know why i cant ping it...

[dilbert]

and i still dont know why i cant ping it...

Try to use arping (see "man arping") and/or use tcpdump or ethereal/wireshark to see what's going on.