DNSMasq Setup - No Boot Filename

[dholtz-docbox]

Hi!

I have successfully run FOG in an isolated network. However, switching to our primary network, where DHCP is handled by the router, I am unable to get the host machines to correctly boot into the TFTP. Each time I try to correct this, I always receive the “PXE-E53: No boot filename” error.

I am not very familiar with DNSMasq or configuring something of this nature, so I am not entirely sure what might be right or wrong throughout the process. That said, at this point, I have…

• Installed DNSMasq
• Updated ‘/etc/dnsmasq.conf’ to reflect configuration
  ** Should I instead use the ‘/etc/dnsmasq.d/ltsp.conf’ file? What are the differences?
• Given ‘/tftpboot’ all rights
• Dropped firewall
• Given undionly.kpxe its sym-link
• Ensure ‘xinet’ service is disabled
• Ensure ‘/etc/default/tftpd-hpa’ is configured correctly

I may have done a few more things, but this is the broad stretch of what I have tried.

During installation, I selected to NOT allow FOG to handle either DHCP or DNS as well.

A lot of the articles I find in both the wikipedia and online are a little dated or have made understanding what might, possibly, be correct. If anyone has a moment to help me understand what I am missing, I would be very appreciative.

Thanks!

-Dustin

[george1421]

@dholtz-docbox said in DNSMasq Setup - No Boot Filename:

I was in sync with what you were saying until here

where DNS is handled by the route

I assume you meant that DHCP is now handled by your router.

If you are installing dnsmasq on your FOG server then all you need to do is install dnsmasq and ensure it starts upon reboot then update/create /etc/dnsmasq.d/ltsp.conf then restart dnsmasq. That is all.
As long as your dhcp server, fog server, and target computers are on the same subnet it will just work. If your target computers are on a different subnet than your dhcp server and FOG server then there are a few more things you need to do.

I do have a tutorial on how to set dnsmasq up under Centos with an example config file you can use.
https://forums.fogproject.org/topic/6376/install-dnsmasq-on-centos-7

As part of installing fog you should have already disabled the firewall on the fog server as well as set selinux to disable.

[dholtz-docbox]

Yes, apologies. My terminology is still a WIP regarding networking. Yes, you are correct though; where the router handles DHCP. I have updated the original inquiry.

Now! Let me read the rest of your reply…

[dholtz-docbox]

Holy! Thank you. I was so close; I was missing the FOG server IP from one of the settings. Please make this the #1 wikipedia entry regarding the configuration of this.

Let me test this with the test group of PC’s I have real quick, see if there are any immediate issues I should be concerned with when capturing/deploying images in this configuration.

Again, thank you for that article. It is the article I have been looking for all morning.

-Dustin

[dholtz-docbox]

I am having one more issue, which I figure I should also ask about while I am digging around for an answer.

During image capture, I now receive an error from Partclone stating, “bitmap free count error” on ‘/dev/sda1’. I have checked the partitions in both ‘/images/dev/…’ and validated them against the host machine - which are valid. I am not sure if this is just a side effect of recent imaging operations (potentially gone wrong), or some other larger issue in finalizing the configuration for everything. The PC I am imaging is just a test box, so I can wipe it with a clean 14.04 installation as necessary. Which may very well be one of my next tests, as I am not having much headway with finding the answer.

Thanks again.

-Dustin

[Wayne Workman]

@dholtz-docbox Can you please copy/paste your last post and start a new thread please? When you get that done, I’ll delete your last post here and mine too.

[dholtz-docbox]

Understood - I felt I should have done that as well; my mistake.

That said, I have resolved the issue. The issue was addressed by updating the swap drive’s UUID. I raised this question before, how the swap drive does not correctly re-assign its UUID upon deploying an existing image. I had to manually re-assign this to get the image capture to work correctly. Moving forward, the swap drive’s UUID needs to be set as a part of the post-imaging process. Otherwise, subsequent image captures will fail, it appears, from my experience so far.

Nonetheless, thank you for being so attentive - all of you. You guys are seriously the most enjoyable group of dev’s I have had the pleasure of asking questions.

-Dustin