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

@Tom Elliott: Yes, selinux was disabled and removed via:

sed -i 's/SELINUX=enforcing/SELINUX=disabled/' /etc/sysconfig/selinux sed -i 's/SELINUX=enforcing/SELINUX=disabled/' /etc/selinux/config systemctl stop firewalld systemctl disable firewalld

Thanks for the reply, the process isn’t being interrupted at this point. I’m not relying on WOL at the moment for my needs.

@Jason-Sauders Hi, have you solved your problem ?

Just following up…

The CentOS7 install (from link on previous) seemed pretty straight-forward.
Only change was that I couldn’t rename eth0 from it’s preset ens32, but it’s working anyway.

It’s up and I’m pushing my Win7 image now.

@Wayne-Workman

Er… during your post I was trying to find a better way to describe why was 2 different post, and tried to state better what I wanted. Sorry again for being a bit confusing. Pls read what I wrote now. Anyway, p4p1 thing you suggested is a bit more dangerous than you may wanted 😄 It is like killing a moskito with gunship, full power. It will kill, but… well, a bit more damage than wanted. 🙂

My problem maybe originated that some things can be configured on the web ui, but sometimes config information is kept in different location which is ok if I dont want to reconfigure “all things” after setup. It is hard to be done if I dont know where to make changes (ip addresses are located in many places, but in config files duplicated, cannot be modified from webui. This makes things harder for debugging.