@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.

Check this out on the wiki

https://wiki.fogproject.org/wiki/index.php/Troubleshoot_FTP#You_must_first_upload_an_image_to_create_a_download_task

Had the same issue myself a while back and this resolved it.

Actually,

I added checks to know when you need the seccomp_sandbox=NO settings. It will not add this item for versions of VSFTPD that do not allow this setting. This is only viable for dev/trunk versions though as I was not aware of this requirement when we first released 1.2.0.

So I got this working in a round about way. I tried to create a new snap in and it gave me an FTP credential error, so I went in and changed my fog user password to match what the configuration showed it should be and now it works. The log viewer also works.

Not sure but maybe the install script is changing the fog password in one place and not another. But I am able to edit snap ins and view my event logs again.

@Wayne-Workman I will keep that in mind and share anything I find.

OK thanks for the info. Doesn’t sound like anything major.

@Lee-Rowlett Thanks. I’ll give it a try!

I restarted the installer several times - the only file, which could not be downloaded was the “FOGService.msi” maybe because I’m downloading behind a proxy. But because I’m cloning ubuntu machines I think I don’t need this file. Otherwise the installer said I can download it with:
wget -O /var/www/html/fog/client/FOGService.msi https://github.com/FOGProject/fog-client/releases/download/0.9.4/FOGService.msi.

The other files like “bzimage,bzimage_32,init.xz,init_32.xz” were downloaded properly.
Still the same Problem. I’m not sure but i think the problem is in the upgraded php5 packeges - if they are upgraded then some of the dependencies to the packages like libonig2 break. I’m not really good in linux and can’t manage it to repair the dependencies.
Did someone have the same problems? Ubuntu 14.04.2 LTS --> apt-get update, upgrade and dist-upgrade.
Thanks

thanks for all the mysql pointers, and that last line worked like a charm.

Spoke to soon.
Wrong data in the columns. Note image ID and image Name. Then it just gets worse.
Capture.JPG