Is this a timing problem? Machines sometimes boot properly
-
Instead of using the [url]http://svn.code.sf.net/p/freeghost/code/tags/1.2.0/packages/tftp[/url]
can you try:
[url]http://svn.code.sf.net/p/freeghost/code/trunk/packages/tftp[/url] files? -
Tom,
I just tried the undionly.kpxe from the trunk files and it appears to work, except that I had to manually enter the tftp server address before the multicast would start. I’ve seen that with one other kernel I tried this morning. Any idea about that?
-
It sounds to me like you may be using DNSMasq?
-
We are using dnsmasq. The /etc/ltsp.conf file shows: “dhcp-boot=undionly.0,xx.xx.xx.xx”.
-
I think the middle option can go away to allow dynamic updating of next-server flag:
Maybe the dhcp-boot needs to be:
[code]dhcp-boot=undionly.0,xx.xx.xx.xx[/code]
rather than
[code]dhcp-boot=undionly.0,xx.xx.xx.xx[/code]The reason the tftp is asked is simply because it doesn’t know what it should be, and would simply fail because it can’t (for whatever reason) find it
-
Do any services need to be restarted after changing the ltsp.conf file?
-
[quote=“Glenn Wilson, post: 40626, member: 240”]Do any services need to be restarted after changing the ltsp.conf file?[/quote]
Yes you need to restart dnsmasq
[code]sudo service dnsmasq restart[/code]
-
I tried the edit and restarting dnsmasq, but the tftp server prompt persists, even after several reboots. Should the change be immediately evident, or does it take some time?
-
It would be evident.
I don’t know why it’s not working, but it is why I added the prompt in the first place.
You could create your own undionly.kpxe to thwart this issue by specifying the next-server variable natively and skipping the prompt for the server address entirely.
-
Is it possible to roll my own using the kernel that is working for me now?
