@liquidprinter Since this thread is a year old, we need all of your specific details. Fog Version, Linux Distribution and Version, and the model of the target host you’re trying to network boot, if you’re network booting in BIOS mode or UEFI mode, and what boot file you’re using, and what you’re using to hand out the file (DHCP, ProxyDHCP).

Also, you might want to take a look at the WiKi, there are troubleshooting articles in there. Here’s one on TFTP: https://wiki.fogproject.org/wiki/index.php/Troubleshoot_TFTP

I confirmed and was working on a fix. While I was at it, I cleaned up the management page. This is now pushed. 4248 should correct these issues.

Thanks for reporting.

OK. That’s what I was afraid of. No big deal and life goes on. Strange that it didn’t take the settings though. Thanks

@Wayne-Workman

Wayne, I apologize I was in a huge hurry and was kind of freaking out, but once I calmed down, I realized I should’ve looked before posting. Sorry bout that, again.

@Wayne-Workman ok, yeah, i understand my images are separate but i just wanted to make sure they wouldnt lose their DB identity. This may be a little above my area of expertise or even more than i have time for, but i will give it a look tomorrow and tackle it thursday if i am back down this way, or next monday. (I bet you cant wait!) Thanks so much, really, thanks

@Wayne-Workman

It was my compression I get around 1 gig now once I turned it down a bit

What version of FOG and Ubuntu are you using? Did you recently update either of them?

@Tom-Elliott YESSSSSS!!! I commented out line "port=0 ", and…voilá! I have full clonning system working, with fog machine capable to access the internet!
Thanks a lot my friends!

SOLVED!

I will give that a try later this week and report back. I’ve got nothing to lose at this point.

@szecca1 said:

@Wayne-Workman Also the test.txt file is in the /images folder on the FOG server but not on the Synology box, just for your information

You should be altering the commands so that you are testing the synology box. The test file should exist on the Synology box.

When the directory successfully mounts via NFS, you shouldn’t get any messages at all.

Have you updated to the latest yet?

@pabloinza Hi my friends. Finally i could solve this changing Ubuntu to ver 12.04. Here muticast works fine.

@Wayne-Workman Wayne!!..Ah ah!!..Savior of the Universe! Finally the solution! It finally works! I think the error is an issue of dnsmasq, since when I tried all of this stuff configuring Fog server machine as dhcp server, all worked fine, and in the dhcpd.conf file, the proper line said “undionly.kpxe”. So, I think dnsmasq is who´s mistaking the name of the file.
Well, what ever, it works!
Thanks a lot my friend! I really appreciate your help.
I don´t know how to tag this post as “SOLVED”. Would you please tell me?

@Wolfbane8653 thanks for the help. I thought there might be issues running both svn and git but it went smoothly. Thanks again.

@Exig3nci said:

@Wayne-Workman Yes.
I’m running tcpdump on the Ubuntu vm, getting the file to my host machine through tftp, then opening it in Wireshark,

If you’re only getting three packets from TCPDump for the entire time that you’re attempting to network boot the target host, then you have a network communications issue with your VM and the target host.

Perhaps it’s a VM configuration, or a switch configuration, a DHCP Helper address configuration, or a DHCP configuration. But something is very wrong somewhere.

You should be seeing TONs of traffic, you should be seeing hundreds of packets.

To further troubleshoot this using TCPDump, we need to see what the target host is doing. For this, you will require a network hub (not a switch, a hub).

Place the hub between the target host and whatever network device it connects to. Then attach a laptop or something to the hub and boot a Live Linux CD on that computer and run TCPDump as you have before. Because the hub replicates all packets to all ports, the extra computer on the hub will be able to see all traffic coming and going to the target host.

If you use a graphical Live Linux distribution, you can even install wireshark directly on it and open the PCAP files right there or alternatively transfer them using a flash drive to a PC with wireshark on it.

Doing this will allow us to see what the client is receiving from DHCP and what - if anything - from dnsmasq.

@Tom-Elliott said:

@Pikmin Do you have separate storage nodes?

No, I don’t just the master which is on the fog server

@ch3i said:

FOG_STORAGENODE_MYSQLPASS is not a unix password, it’s stored in MySQL database (in nfsGroupMembers table), has said Tom, it’s only to communicate between FOG node storage.
Ensure that in you FOG settings (in web UI) the FOG_TFTP_FTP_PASSWORD has the password 68c364.
The password in there is already set to that

fog.PNG

Thanks so much, I kinda did check the tables in sql but was looking for one called users

+---------+---------+ | ngmUser | ngmPass | +---------+---------+ | fog | 68c364 | +---------+---------+

In the FOG_STORAGENODE_MYSQLUSER I had fogstorage, but shouldn’t that be just fog? I have tried with fog, same thing.

This is what the other place looks like
storage node.PNG
Thank you both for helping out, much appreciated

You likely have dirty data in your FOG DB. The easiest way to find the dirty data is to enable remote access on the DB and then connect to the DB using a graphical DB viewer. I would recommend HeidiSQL for this: http://www.heidisql.com/

There are some pointers for enabling remote access on the DB here: https://wiki.fogproject.org/wiki/index.php/Troubleshoot_MySQL Forgive the roughness of the article, it’s under construction currently.

Once connected to the DB, just take your time and look closely at all the data inside the hosts and hostMAC tables. If anything glaringly stands out, make note of that entry, and then just delete that row.

Each row of host data that you delete will mean you need to go and re-register that particular host (eventually).

x32 bit machines should now be fixed in the latest git.

x32 Upload times are slow but they will upload all the way. ~84Mib/s with lvl 9 compression (4:20:15) x32 Download times are “fast” ~1.8Gib/s lvl 9 compression (00:12:01) x64 Up 3.2Gib/s lvl9 (00:20:00) Down 7.3Gib/s lvl9 (00:09:00)

Full Description of problem:
1.)nfs mount issue was due to not getting an ip address during init boot.
2.)Not getting an ip was due to an addition of fixing VLAN issues for networks and sleep command was an “Illegal Instruction” (along with other commands essential to “init fog script”)
3.)sleep was not working due to a compiling issue in the glibc v2.21.

*Solution:
1.) Downgraded init’s to use glibc v2.20 (fixed sleep function).
2.) init’s now get ips from edits in files K40Network and S40Network.
3.)NFS mounts successfully now that init gets an ip address at boot.

These changes have been pushed to both init_32.xz and init.xz.

If you see this issue with your old 32 bit only processors please make sure you update to the latest version and this should be fixed.

P.S. @Tom-Elliott thanks for the remote sessions and time. Took us a while but we nailed down the problem

sorry I’m running ubuntu 14.04.2 & SVN 3791

Solved with 24/07/15 git update

Everyone this was my problem. You have to take the user and password from the fog storage nodes under the fog system settings and put them into a hidden file in the opt/fog directory .fogsettings config file. After I did this the image created successfully without complaining about the ftp password. I will now try to drop the new image onto a new computer and see how I make out, but I think this will do it for me. Wow I have struggled with this for two weeks now. I like the concept of the fog imaging server and will now be able to really test it out.

Like everything else in life if you don’t struggle with it you will never learn anything. I learned a lot about linux by setting this up.

Thanks again.