SLUG Mailing List Archives
[SLUG] Network Booting PA-RISC (HP9000 712/60) Take 2
- To: slug@xxxxxxxxxxx
- Subject: [SLUG] Network Booting PA-RISC (HP9000 712/60) Take 2
- From: Gerard Blacklock <gbla5989@xxxxxxxxxxxxxxxx>
- Date: Tue, 15 Apr 2003 22:16:25 +1000
- User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.2.1) Gecko/20021130
Thanks to Roger, Peter, David, dave and Stephen for your ideas and help.
I still have no joy in getting it to work....i also feel it is a
"simple" networking prob but it is eluding my networking knowledge :),
it seems the pa-risc machine is not accepting the allocated IP provided
by the server, this to me indicates my dhcp is broken and/or the pa-risc
machine is playing funny buggers with me...(or it is most likey
something i stuffed up:))
I had a go at ensuring all the correct services were operating correctly
when i got home today, heres a quick list of what i have done/checked:
Tweaked with the dhcpd.conf file, which is where i feel my problem may
lie....someone mentioned conflicting ips due to already static ips
Not sure what you mean here, do u suggest i use another range, like 10.0.0.0
"You may find it better not to overlap dynamicly assigned and
staticly assigned addresses"
Ensured the tftpd was started, did this by checking the file:
socket_type = dgram
protocol = udp
wait = yes
user = root
server = /usr/sbin/in.tftpd
server_args = -s /tftpboot
disable = no
per_source = 11
cps = 100 2
seems OK...restarted xinet.d to get this running....correct??
checked xinetd.conf was ok....
# Simple configuration file for xinetd
# Some defaults, and include /etc/xinetd.d/
instances = 60
log_type = SYSLOG authpriv
log_on_success = HOST PID
log_on_failure = HOST
cps = 25 30
tftp dgram udp wait nobody
/usr/sbin/in.tftpd /tftpboot -l
Checked the boot image and path were indeed correct, even copied the
lifimage to the root of the tftpboot dir.
Updated my dhcp version to 3.0
There is a firewall but it is not running when i attempt the network boot.
There are only a few other machines on the network, which works fine...
The logs and packet files are the same as before......
if anyone has any ideas regarding this they would greatly appreciated!!